From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 14:11:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15287 for ; Mon, 3 Nov 2003 14:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGk7I-0002km-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 14:11:56 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGk7I-0002ki-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 14:11:56 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C34215@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 14:11:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59297377 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 14:11:54 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 14:11:54 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA3J8dB6007077 for ; Mon, 3 Nov 2003 19:08:39 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA3J64P23780 for ; Mon, 3 Nov 2003 19:06:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110311115108020 for ; Mon, 03 Nov 2003 11:11:51 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Nov 2003 11:11:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3A23E.55F0D028" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: yes Thread-Topic: Updated agenda, ForCES Meeting, IETF 58 Thread-Index: AcOiPiFcBID+raCuSJiHzJl/3W5j9g== X-OriginalArrivalTime: 03 Nov 2003 19:11:52.0090 (UTC) FILETIME=[5696C7A0:01C3A23E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F66A@orsmsx409.jf.intel.com> Date: Mon, 3 Nov 2003 11:11:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Updated agenda, ForCES Meeting, IETF 58 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A23E.55F0D028 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Please find attached the current agenda for the ForCES meeting at IETF 58. Cheers, David ------_=_NextPart_001_01C3A23E.55F0D028 Content-Type: application/x-zip-compressed; name="agenda.ZIP" Content-Description: agenda.ZIP Content-Disposition: attachment; filename="agenda.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAOpYYy9pbfukbgIAAHoFAAAKAAAAYWdlbmRhLnR4dK1U227aQBB9R+If5qlKpBpM IqQK0QqHW3ohQkAbqW+DPdhb1rvWegyEr++uLwgpfaii7Mt6LzPnzDmznmlzRBMJFQOqCMZasdES ppJSUgxrytAgC63gZqbNeLq+hXYriElF+BG+Tjcz6H9qt9qthbY7L/CkD5RuyUDP5wTufP8ekKF3 7/ter+/77dbn/xou4/gx+LpaDwBgggcRwbLgs5YFDMtlp16OhGKSnVCnX9otuIwlshHhHiZGn2EY GT06F3Yj6YhtWl+2ZUzyQXU9kHSC30IJBcOzm0ZZHr9K+iCkhBkpZesb7sp5ZCgnNDYxMr8KaLcm q2C2gWA+fZoEA4fZB0gtigfPc8gZucjtd5igMLk77vn1cQCZ0ZnOKYKDDnFbSDQvpUWhViFlXKCE VEckYacNXKFGIg+LPHeOpsQYISMcBSc2beWgyy5RwYS+6/1VYMKcDbrd4/HYEcS7jjZx16lrFLEX Gdxx3i0nL6K93nsWN6Tca0A83+/wiV0Vd/26ihpwUfL8mdlrZHfXTAdS8CBxT2/Cd8cXeJfb83sX 7EbBOVl/rEgrXdgcsECFcdXUS6NZh7bLb+arxfIWfpHJXYf3nC0kUifdM6r4TdyONrDhFps0u5Kl UWVjjZU6fgFDmesfxdULc0bWis2mtbnvzKhSi2sC15Y1sj0RS6H2d67/KpXewbA/SW4SbEioGuJf rq2rN1FUvVIqEow312RWmMJcZyjfxCR2kQ2RHYbs+f2GRK8x6IdQxQnYBuxE6B5c+U+kE5NyjZLD B+CkZGezXIz6hqltt0eMBKxRivSK343SUOIDHlBI3Eq6/QtQSwECFAsUAAAACADqWGMvaW37pG4C AAB6BQAACgAAAAAAAAABACAAAAAAAAAAYWdlbmRhLnR4dFBLBQYAAAAAAQABADgAAACWAgAAAAA= ------_=_NextPart_001_01C3A23E.55F0D028-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 14:43:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16875 for ; Mon, 3 Nov 2003 14:43:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGkcN-0003HX-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 14:44:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGkcM-0003HU-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 14:44:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3403B@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 14:44:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59301172 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 14:44:01 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 14:44:01 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5726142 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 03 Nov 2003 14:44:01 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031103144231.02162578@localhost> Date: Mon, 3 Nov 2003 14:43:47 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Updated agenda, ForCES Meeting, IETF 58 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F66A@orsmsx409.jf.intel. com> Precedence: list I would think it would make more sense to present to datapathID concept before the GRMP work that makes use of that. Of course, this is probably motivated in part by my discomfort with the PdfID structure. I am concerned that it will be hard to discuss the GRMP work if we can not get past the PkfID issue first. Yours, Joel At 11:11 AM 11/3/2003 -0800, you wrote: >All, > >Please find attached the current agenda for the ForCES >meeting at IETF 58. > >Cheers, >David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 15:11:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19021 for ; Mon, 3 Nov 2003 15:11:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGl3A-0003qW-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 15:11:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGl39-0003qT-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 15:11:43 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C34281@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 15:11:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59303302 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 15:11:41 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 15:11:41 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA3KBeXA011251 for ; Mon, 3 Nov 2003 20:11:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA3KAwJl008684 for ; Mon, 3 Nov 2003 20:11:00 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110312113810993 for ; Mon, 03 Nov 2003 12:11:38 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Nov 2003 12:11:38 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Updated agenda, ForCES Meeting, IETF 58 Thread-Index: AcOiQtqX19PO/nuDR6qro+AxO+xJ6wAA1VCw X-OriginalArrivalTime: 03 Nov 2003 20:11:38.0605 (UTC) FILETIME=[B05189D0:01C3A246] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A42F89@orsmsx410.jf.intel.com> Date: Mon, 3 Nov 2003 12:11:37 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Updated agenda, ForCES Meeting, IETF 58 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I agree, it makes more sense to present the Topology draft before GRMP and spend sometime explaining the basics (PdfID). Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Monday, November 03, 2003 11:44 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Updated agenda, ForCES Meeting, IETF 58 I would think it would make more sense to present to datapathID concept before the GRMP work that makes use of that. Of course, this is probably motivated in part by my discomfort with the PdfID structure. I am concerned that it will be hard to discuss the GRMP work if we can not get past the PkfID issue first. Yours, Joel At 11:11 AM 11/3/2003 -0800, you wrote: >All, > >Please find attached the current agenda for the ForCES >meeting at IETF 58. > >Cheers, >David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 16:13:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21778 for ; Mon, 3 Nov 2003 16:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGm0w-0004iw-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 16:13:30 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGm0w-0004it-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 16:13:30 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C343A0@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 15:54:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59306032 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 15:54:07 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 15:54:07 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5726343 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 03 Nov 2003 15:54:06 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031103154633.02162148@localhost> Date: Mon, 3 Nov 2003 15:53:51 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list In looking at the protocol proposals, I have been trying to understand the significant differences between them. One interesting difference is in the way "operations" on entities are supported. [What follows is over-simplified and not intended to denigrate any of the proposals.] In some of the proposals, the base protocol has the "operations". The defined operations tend to be read and write. In some of the protocols, the elements each define the operations, and the protocol is defined to carry an opaque block to be interpreted by the element. One could also imagine an intermediate point where the protocol is defined to carry a target, and operation identifier, and operation parameters, and then to return operation results. And each element type definition included the list of permitted operations. It seems to me that if LFBs (target elements) will have very similar operations most of the time, then those operations ought to be called out in the base protocol. On the other hand, if the operations on LFBs tend to be very different, then the protocol ought to be designed to carry more generic blocks. This topic comes up in many management / control applications. It would seem to behoove us to address it directly and explicitly rather than choosing a protocol and then accepting the operational implications of the protocol. Yours, Joel M. Halpern PS: I will admit that both extreme approaches (and most midpoints) can work. One can suggest that this is a philosophical difference. But it has practical implications in the protocol structuring. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 17:01:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26237 for ; Mon, 3 Nov 2003 17:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGmlP-00065M-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 17:01:31 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGmlO-00065I-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 17:01:30 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C345F1@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 17:01:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59317586 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 17:00:39 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 17:00:38 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003110313592659:1764 ; Mon, 3 Nov 2003 13:59:26 -0800 References: <5.1.0.14.0.20031103154633.02162148@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/03/2003 01:59:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/03/2003 01:59:28 PM, Serialize complete at 11/03/2003 01:59:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1067896835.1039.49.camel@jzny.localdomain> Date: Mon, 3 Nov 2003 17:00:35 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031103154633.02162148@localhost> Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2003-11-03 at 15:53, Joel M. Halpern wrote: > In looking at the protocol proposals, I have been trying to understand the > significant differences between them. > > One interesting difference is in the way "operations" on entities are > supported. > [What follows is over-simplified and not intended to denigrate any of the > proposals.] > > In some of the proposals, the base protocol has the "operations". The > defined operations tend to be read and write. > > In some of the protocols, the elements each define the operations, and the > protocol is defined to carry an opaque block to be interpreted by the element. > You must be refering to netlink2 with the above statement - in which case you have oversimplified. What you refer to as "operation" is infact both an operation and a reference/addressing to a specific LFB. > One could also imagine an intermediate point where the protocol is defined > to carry a target, and operation identifier, and operation parameters, and > then to return operation results. Everything you describe above already happens with netlink2 with a caveat that the operation results are optional; you have to request for them otherwise you dont get them. > And each element type definition > included the list of permitted operations. Should this be a discovery phase activity? > It seems to me that if LFBs (target elements) will have very similar > operations most of the time, then those operations ought to be called out > in the base protocol. On the other hand, if the operations on LFBs tend to > be very different, then the protocol ought to be designed to carry more > generic blocks. > It doesnt buy you much in terms of saving bits or looking beautiful. You can move the LFB referencing to somewhere else on the header and keep specific operations; end result is you will end up using just as many bits. Infact there cant be that many operations per LFB other than the classical add/del/get so it should be a lot more efficient in bit-saving to have one space for both LFB-addressing and operation. (In netlink2 the add/del are also polymorphic and reused for event throwing - saving even more space). cheers, jamal > > This topic comes up in many management / control applications. It would > seem to behoove us to address it directly and explicitly rather than > choosing a protocol and then accepting the operational implications of the > protocol. > > Yours, > Joel M. Halpern > > PS: I will admit that both extreme approaches (and most midpoints) can > work. One can suggest that this is a philosophical difference. But it has > practical implications in the protocol structuring. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 3 21:44:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10008 for ; Mon, 3 Nov 2003 21:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrB6-0003U9-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 21:44:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGrB6-0003U6-00 for forces-archive@IETF.ORG; Mon, 03 Nov 2003 21:44:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C34A64@cherry.ease.lsoft.com>; Mon, 3 Nov 2003 21:44:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59339096 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Nov 2003 21:44:19 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Nov 2003 21:44:19 -0400 Received: from wwm1([218.108.152.53]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jma3fa77b1e; Tue, 04 Nov 2003 10:42:55 +0800 References: <9CB758BBEE58754F8F33234D75B9F4B0A42F89@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006a01c3a27d$5e633ec0$3d19fea9@wwm1> Date: Tue, 4 Nov 2003 10:42:20 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Updated agenda, ForCES Meeting, IETF 58 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgSm9lbCBhbmQgSG9ybXV6ZCwNCg0KSSBhc2tlZCBEYXZpZCB0byBjaGFuZ2UgdGhlIGFnZW5k YSwgZm9yIEkgY29uc2lkZXIgdG8gdGFrZSBQa2ZJRCBwYXJ0DQphcyBhbiBleHRlbnNpb24gcGFy dCBvZiBHUk1QIGluc3RlYWQgb2YgYW4gaW5kZXBlbmRhbnQgb25lLCBhbmQgaGF2ZSANCnRoZSBw b3NzaWJsZSBkaXNjdXNzaW9ucyBwdXQgdG9nZXRoZXIuIEkgZG8gaGF2ZSB0cmllZCB0byBwcmVz ZW50IFBrZklEIGZpcnN0LCANCmJ1dCBqdXN0IGZvdW5kIEkgY291bGQgbm90IGRvIGl0IHdlbGwg d2l0aGluIHRoZSBhc3NpZ25lZCB0aW1lIHdpdGggbXkgbGltaXRlZCANCnNwb2tlbiBlbmcuIGFi aWxpdHkuIFRvIHB1dCBpdCBhZnRlciBHUk1QIGlzIGFjdHVhbGx5IGEgc2ltcGxpZmllZCB2ZXJz aW9uIGZvciANCm15IHByZXNlbnRhdGlvbiwgd2l0aCBzb21lIGNvbnRlbnRzIGN1dC4gSSByZWFs bHkgYXBwcmVjaWF0ZSBpdCBpZiBtb3JlIGRpc2N1c3Npb25zIA0KY2FuIGJlIGhvbGQgb2ZmIHRo ZSBtZWV0aW5nIHRpbWUgYnkgV0cgb3Vyc2VsZiwgYnkgd2hpY2ggSSBob3BlIHRvIGhhdmUgY2hh bmNlIA0KdG8gZXhwbGFpbiBtb3JlLg0KDQpUaGFua3MgZm9yIHlvdXIgYXR0ZW50aW9uLg0KDQpZ b3VycywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJL aG9zcmF2aSwgSG9ybXV6ZCBNIiA8aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbT4NClRvOiA8 Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDQs IDIwMDMgNDoxMSBBTQ0KU3ViamVjdDogUmU6IFVwZGF0ZWQgYWdlbmRhLCBGb3JDRVMgTWVldGlu ZywgSUVURiA1OA0KDQoNCkkgYWdyZWUsIGl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8gcHJlc2VudCB0 aGUgVG9wb2xvZ3kgZHJhZnQgYmVmb3JlIEdSTVANCmFuZCBzcGVuZCBzb21ldGltZSBleHBsYWlu aW5nIHRoZSBiYXNpY3MgKFBkZklEKS4NCg0KSG9ybXV6ZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uDQpb bWFpbHRvOkZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTV0gT24gQmVoYWxmIE9mIEpvZWwgTS4g SGFscGVybg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMywgMjAwMyAxMTo0NCBBTQ0KVG86IEZP UkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTQ0KU3ViamVjdDogUmU6IFtGT1JDRVNdIFVwZGF0ZWQg YWdlbmRhLCBGb3JDRVMgTWVldGluZywgSUVURiA1OA0KDQoNCkkgd291bGQgdGhpbmsgaXQgd291 bGQgbWFrZSBtb3JlIHNlbnNlIHRvIHByZXNlbnQgdG8gZGF0YXBhdGhJRCBjb25jZXB0DQpiZWZv cmUgdGhlIEdSTVAgd29yayB0aGF0IG1ha2VzIHVzZSBvZiB0aGF0Lg0KT2YgY291cnNlLCB0aGlz IGlzIHByb2JhYmx5IG1vdGl2YXRlZCBpbiBwYXJ0IGJ5IG15IGRpc2NvbWZvcnQgd2l0aCB0aGUN ClBkZklEIHN0cnVjdHVyZS4gIEkgYW0gY29uY2VybmVkIHRoYXQgaXQgd2lsbCBiZSBoYXJkIHRv IGRpc2N1c3MgdGhlDQpHUk1QDQp3b3JrIGlmIHdlIGNhbiBub3QgZ2V0IHBhc3QgdGhlIFBrZklE IGlzc3VlIGZpcnN0Lg0KDQpZb3VycywNCkpvZWwNCg0KQXQgMTE6MTEgQU0gMTEvMy8yMDAzIC0w ODAwLCB5b3Ugd3JvdGU6DQo+QWxsLA0KPg0KPlBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSBjdXJy ZW50IGFnZW5kYSBmb3IgdGhlIEZvckNFUw0KPm1lZXRpbmcgYXQgSUVURiA1OC4NCj4NCj5DaGVl cnMsDQo+RGF2aWQNCg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 4 04:26:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05318 for ; Tue, 4 Nov 2003 04:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxSC-0001bV-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 04:26:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AGxSC-0001bS-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 04:26:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C3530C@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 4:26:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59369446 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 04:26:13 -0500 Received: from 137.222.10.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 04:26:13 -0400 Received: from ncs.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 4 Nov 2003 09:22:57 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by ncs.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hA49M9M15209 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 4 Nov 2003 09:22:10 GMT References: <5.1.0.14.0.20031103154633.02162148@localhost> Originator-Info: login-token=Mulberry:01po8HgQv0aPXe0IDr1Az1NOre8X2k5hgFNePj+YCl1Am9fOw=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <434092662.1067937728@EEN9169.een.bris.ac.uk> Date: Tue, 4 Nov 2003 09:22:08 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031103154633.02162148@localhost> Precedence: list Content-Transfer-Encoding: 7bit Hi All, Based on Joel's observations and Jamal's comments on them: > I will admit that both extreme approaches (and most midpoints) can > work. One can suggest that this is a philosophical difference. But it > has practical implications in the protocol structuring. I don't think it's a philosophical difference, more a real practical one. There are many lessons - RPC, SNMP, IPFIX, MIDCOM,... Generic create/add/get/set/query base functions tend to be qualified by references to specifics: next-hop, rule, counter, etc. as well as per-transaction handles for LFB instances, resources and so on. If we embed the specifics then we trade extensibility for efficiency; if we don't then we risk a low level of interoperability. I think interoperability should be the (first) main concern, less so efficiency, so let's look at embedding specifics (or candidates that do so). Given the likely diversity of LFBs and devices built from them, I would like to see a protocol built from small modules specific to LFBs. This seems to me to reflect the diversity in the model and I think it would align nicely with developing NPF work. Topology/capability discovery will tell the CE which (versions of which) modules to use. My second main concern is the CE-FE transport, but I don't know if I have anything new to contribute here - just a concern based on discussions/choices in other groups. Our position is possibly better than theirs as we don't have to allow arbitrary CE-FE distance. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 4 13:33:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26842 for ; Tue, 4 Nov 2003 13:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5zc-0002Pd-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 13:33:28 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AH5zc-0002Pa-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 13:33:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C35CC2@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 13:32:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59444978 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 13:32:53 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 13:32:52 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA4IWqHd026608 for ; Tue, 4 Nov 2003 18:32:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA4IQrZ10622 for ; Tue, 4 Nov 2003 18:26:53 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110410323814681 for ; Tue, 04 Nov 2003 10:32:39 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Nov 2003 10:32:38 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: An oversimplified comment on protocols and operations Thread-Index: AcOitbiE18KCahoXRfSjsWkB5KiJcwASsgTQ X-OriginalArrivalTime: 04 Nov 2003 18:32:38.0565 (UTC) FILETIME=[06311D50:01C3A302] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEA5@orsmsx410.jf.intel.com> Date: Tue, 4 Nov 2003 10:32:34 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable A somewhat related issue (or an instance of the general issue at hand):=20 A few weeks back Joel brought up the issue on FE topology and how that = should/could be discovered by CE. Joel suggested that FE connectivity = with its neighbors (that is, info about how an FE is connected with = other neighboring FEs) can be viewed as part of FE attributes, and hence = part of FE model. So such connectivity can be queried by the CE via = generic attribute query message in the ForCES protocol. The alternative = would be to define FE topology specific query message in the ForCES = protocol.=20 Since this is one of the open issues on FE model team's open issue list, = I just want to raise this again and see if indeed people agree that such = FE connectivity info (local info from that FE's point of view) should be = embedded in the information element carried by ForCES protocol so the = base protocol doesn't need to deal with it directly and explicitly? > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > Sent: Tuesday, November 04, 2003 1:22 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: An oversimplified comment on protocols and operations >=20 >=20 > Hi All, >=20 > Based on Joel's observations and Jamal's comments on them: >=20 > > I will admit that both extreme approaches (and most midpoints) can > > work. One can suggest that this is a philosophical=20 > difference. But it > > has practical implications in the protocol structuring. >=20 > I don't think it's a philosophical difference, more a real=20 > practical one. > There are many lessons - RPC, SNMP, IPFIX, MIDCOM,... >=20 > Generic create/add/get/set/query base functions tend to be=20 > qualified by > references to specifics: next-hop, rule, counter, etc. as well as > per-transaction handles for LFB instances, resources and so on. >=20 > If we embed the specifics then we trade extensibility for=20 > efficiency; if we > don't then we risk a low level of interoperability. I think > interoperability should be the (first) main concern, less so=20 > efficiency, so > let's look at embedding specifics (or candidates that do so). >=20 > Given the likely diversity of LFBs and devices built from=20 > them, I would > like to see a protocol built from small modules specific to LFBs. This > seems to me to reflect the diversity in the model and I think it would > align nicely with developing NPF work. Topology/capability=20 > discovery will > tell the CE which (versions of which) modules to use. >=20 > My second main concern is the CE-FE transport, but I don't=20 > know if I have > anything new to contribute here - just a concern based on > discussions/choices in other groups. Our position is possibly=20 > better than > theirs as we don't have to allow arbitrary CE-FE distance. >=20 > Regards, >=20 > Alistair >=20 > -- > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eagroup.com >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 4 14:48:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00823 for ; Tue, 4 Nov 2003 14:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7Al-0003vA-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 14:49:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AH7Al-0003v6-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 14:49:03 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C35F50@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 14:49:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59454409 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 14:49:01 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 14:49:00 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA4JmmqF021401 for ; Tue, 4 Nov 2003 19:48:48 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA4Jgwb10754 for ; Tue, 4 Nov 2003 19:42:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110411484208727 for ; Tue, 04 Nov 2003 11:48:42 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Nov 2003 11:48:42 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] An oversimplified comment on protocols and operations Thread-Index: AcOiTMKkmlfWM5dbT663KC/3hAHAxQAvW+eQ X-OriginalArrivalTime: 04 Nov 2003 19:48:42.0741 (UTC) FILETIME=[A6A71A50:01C3A30C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A43104@orsmsx410.jf.intel.com> Date: Tue, 4 Nov 2003 11:48:41 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Joel You have brought up a v. good point.=20 I don't think this is one of the big differences between the protocols. As far as I know, all the protocols have defined some sort of operations to be performed on the LFBs like Add/Delete, etc. But the question is whether the model should also define operations or methods on individual LFBs. I don't believe this is a good design practice; I have attended a lot of IETF meetings in which I have heard a lot of vendors complaining about how ugly it is to have methods as part of MIBs and how much complexity it adds to the implementation. My understanding is that one of the reasons=20 why this is needed with SNMP is cause the protocol does not support command bundling. However, there may be other reasons as well for doing this. But my point is that as long as the protocol is designed to support features like command bundling and defines the generic operations or methods to be applied on LFBs or modules in the data model, I don't think that methods belong in the data model as part of LFBs unless there are very good reasons for doing so. This would cause unnecessary implementation complexity and would be redundant if protocol operations are defined. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Monday, November 03, 2003 12:54 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] An oversimplified comment on protocols and operations In looking at the protocol proposals, I have been trying to understand the significant differences between them. One interesting difference is in the way "operations" on entities are supported. [What follows is over-simplified and not intended to denigrate any of the proposals.] In some of the proposals, the base protocol has the "operations". The defined operations tend to be read and write. In some of the protocols, the elements each define the operations, and the protocol is defined to carry an opaque block to be interpreted by the element. One could also imagine an intermediate point where the protocol is defined to carry a target, and operation identifier, and operation parameters, and then to return operation results. And each element type definition included the list of permitted operations. It seems to me that if LFBs (target elements) will have very similar operations most of the time, then those operations ought to be called out in the base protocol. On the other hand, if the operations on LFBs tend to be very different, then the protocol ought to be designed to carry more generic blocks. This topic comes up in many management / control applications. It would seem to behoove us to address it directly and explicitly rather than choosing a protocol and then accepting the operational implications of the protocol. Yours, Joel M. Halpern PS: I will admit that both extreme approaches (and most midpoints) can work. One can suggest that this is a philosophical difference. But it has practical implications in the protocol structuring. From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 4 15:33:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04150 for ; Tue, 4 Nov 2003 15:33:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7rv-0004kL-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 15:33:39 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AH7rv-0004kI-00 for forces-archive@IETF.ORG; Tue, 04 Nov 2003 15:33:39 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C36021@cherry.ease.lsoft.com>; Tue, 4 Nov 2003 15:33:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59457687 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 Nov 2003 15:33:31 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Nov 2003 15:33:31 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 8B3231F011E; Tue, 4 Nov 2003 15:33:31 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id C752C1F010A; Tue, 4 Nov 2003 15:33:27 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FA80D16.44BDACCF@idt.com> Date: Tue, 4 Nov 2003 15:33:26 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference, Tuesday 4th Comments: To: npf-sw-fapi@npforum.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit John Renwick wrote: > > I thought I'd try to put in writing some of the comments I had > today about the ForCES model draft. I see two major issues, > and some smaller things. The first major one is about metadata: I've cross-posted your NPF post to the ForCES list, where ForCES related discussion belongs. That list is open to all, and I suggest you join it, if you haven't already done so. > Section 4.4.4 lists, as one of the Capability attributes of > LFBs: "Metadata pass-through limitations of the LFB." If an > LFB definition must indicate all metadata elements that are > "passed through" it, it would have to refer to metadata that > it is not at all concerned with, and maybe hasn't even been > thought of at the time the LFB is defined. There is a simple solution to this problem. The LFB's describe only the metadata they care about. All other metadata can pass through the LFB unchanged, and un-examined. > If the FE must > expose all this detail about the routing of metadata, does it > suggest that there are metadata flow paths that are distinct > from packet flow paths, that also need to be revealed in the > LFB topology? Perhaps. See the NPF hardware "lookaside" interface design. Packets do NOT flow through a piece of "lookaside" hardware, but that hardware does produce metadata. Something must manage that metadata, and correlate it with the packet. That management should be modelled. > On the other hand, why do we care at all? > Isn't it enough to indicate, for each metadatum, which LFB > produces it and which LFBs use it, and then assume that the > implementation is functional enough to make each available > in some way to the LFBs that need it? Making implicit assumptions is almost always bad. The purpose of the ForCES model document is to *model* the functionality of the FE. Not including large aspects of the FE in the model means that the model is less effective > The second major thing concerns ingress/egress ("hybrid") > ports. If a port represents both ingress and egress, making > an LFB topology acyclic may require the port to be represented > as two LFBs -- or two instances of the same LFB. We have a > similar problem in FAPI. How will ForCES resolve this? The LFB topology may be acyclic, even if there *appear* to be loops with it. See Page 23 of the document, under Figure 6: "It is important to point out that the LFB topology here is the logical topology that the packets flow through, not the physical topology as determined by how the FE hardware is laid out." What this means is that the even though a port LFB may be both ingress and egress, there is NO cyclic flow of packets through that LFB, around & around the model. That is, at the egress, the packets LEAVE the LFB model. There are therefore no cycles. > Other things: > > 1. At the top of page 5: "LFB topology is outside of the LFB > model, but part of the FE model." Can this be clarified? It > sounds self-contradictory. Each individual part in your car can be described in isolation. Yet no one claims that the method of interconnecting them to create a "car" is part of the "engine" concept, or part of the "tire" concept. That interconnection is part of the "car" concept alone. > 2. Section 4.1.2 talks about "Structures." Are they like 'C' > structures, whose layout in memory can be compiler-dependent, > or are they meant to specify a machine-independent layout in > memory or in a PDU? This doesn't seem to be clear. It's not clear because the document does not yet describe them in detail. The ForCES model group has been working on that part of the document. > How are > they to be used? If their only purpose is to give names and > limits to data elements in the abstract, and not to specify > byte-by-byte organization, that makes sense and I'm fine > with it. I'm uncertain as to how anything will be interoperable if we don't specify byte-by-byte organization of data within ForCES. > 3. Section 4.3: the title is "Frame Format," but the description > talks about packet types -- not formats. > > 4. Section 7.2: Can a dropper count packets? The description > should probably say so. Such comments should be posted to the ForcES list, or to the authors. > 5. Section 7.3 says the Redirector LFB uses metadata to > determine where to send each packet. Why couldn't it use > packet content as well? We have had this discussion ad nauseum in NPF. Please see historical NPF discussions as to why we have a seperate "classifier" block, and why it's not appropriate to have a generic classifier inside of every block. > 6. Section 7.4 & 7.5, Scheduler and Queue: it may be hard to > make these work as separate LFBs, because as currently > written, a scheduler can't see what's in a queue; it can only > release backpressure and allow a packet to be sent to it. > Depending on the scheduling algorithm, the scheduler may need > to see attributes of the queue, such as whether it's empty or > not and how big the first packet is, without actually moving > the packet. The document is still in progress. We welcome suggested replacement text. > 7. Section 7.6: Must every packet counted actually flow through > a counter LFB, or can the LFB have implicit connections to > events in other LFBs without having to direct all packets > through it? Like metadata? > Can a counter LFB contain more than one counter, > and if so, does it use metadata to determine which counters to > increment? And why would a counter LFB ever modify metadata? > I don't understand the last paragraph; it sounds self-contradictory. A counter counts events, not the rate of change of events over time. > 8. 7.7: Shouldn't the description of a Meter LFB say something > about assigning a "color" to a packet? We welcome suggested text. > 9. 7.8: The Classifier description reads as if it were written > by two different authors who didn't agree. First it says a > classifier has just one output, then in the last paragraph it > says it can have a different output for each class. Which is > true? The document is still in development. Earlier versions of the document had two classifier LFBs, which have been merged in this version. Not all of the relevant text was updated. > The next-to-last paragraph seems to be saying that only > a classifier LFB may make decisions based on packet content > (is that what "P" means?) Yes. See Section 3.2 "LFB Modelling", where it defines P. >, and other LFBs are only allowed to > base decisions on "S, t, and M" (what are those? I don't see > them defined anywhere). They were defined in an earlier version of the document, and that text was erroneously deleted. > Why must the classifier try to restrict > other LFBs in this way? Turf issue? Grow up. You've been party to NPF discussions where it was made clear that having a classifier in every block was nonsense. I suggest you re-visit those discussions. > 10. 7.9, 7.10: The Packet Modifier LFB description says there > will be other LFBs for modifications needed by specific protocols. > Then there's a Packet Header Rewriter for header modifications. > All the legitimate packet modifications seem to be covered by > LFBs that obey the rules of specific protocols, and that's good. > What's left for the Packet Modifier to do? It sounds tailor- > made for hackers! :-) If you say so. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 10:10:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08831 for ; Wed, 5 Nov 2003 10:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPJK-0005Xc-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 10:11:06 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHPJK-0005XZ-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 10:11:06 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C37747@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 10:11:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59463376 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 10:11:05 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 10:11:05 -0400 Received: from wwm1([218.108.159.25]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm143fa983a4; Wed, 05 Nov 2003 23:09:40 +0800 References: <5.1.0.14.0.20031103154633.02162148@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003e01c3a3ae$da55f810$3d19fea9@wwm1> Date: Wed, 5 Nov 2003 23:09:47 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: An oversimplified comment on protocols and operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 Sm9lbCdzIHF1ZXN0aW9uIGFuZCB0aGUgZm9sbG93ZWQgY29tbWVudHMgcmVtaW5kIG1lIG9mIGEg ZmVlZGJhY2sgZnJvbSBBRHMsIGFzIGZvbGxvd2luZyBsaW5rDQoNCmh0dHA6Ly9wZWFjaC5lYXNl Lmxzb2Z0LmNvbS9zY3JpcHRzL3dhLmV4ZT9BMj1pbmQwMzA3Jkw9Zm9yY2VzJlQ9MCZGPSZTPSZQ PTIxNjYNCg0KSSB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbiBKb2VsIHJhaXNlZCBqdXN0IGFzIGhv dyBtdWNoIHNoYWxsIHdlIHB1dCBvZmYtbG9hZGVkIGZ1bmN0aW9ucyB0byBGRS4gVGhlIA0KZXh0 cmVtZSBpcyBmb3IgTEZCIHRvIHN1cHBvcnQgY29kZXMsIGp1c3QgbGlrZSB3aGF0IGFjdGl2ZSBu ZXR3b3JrIGRvZXMuIEknbSBhZnJhaWQgdG8gcHV0IG1vcmUgb3IgbGVzcyANCm1heWJlIG5vdCBq dXN0IHRyYWRlb2ZmIGJldHdlZW4gZXh0ZW5zaWJpbGl0eSBhbmQgZWZmaWNpZW5jeSwgaXQgbWF5 IGFsc28gaW5jbHVkZSB0cmFkZSBvZiBjb21wbGV4aXR5LCANCmZlYXNpYmlsaXR5LiBFeHBlcmll bmNlIG9mIGFjdGl2ZSBuZXR3b3JrIG1heSBnaXZlIHVzIHNvbWUgZmVlZGJhY2sgaW5mb3JtYXRp b24gb24gdGhpcy4gSXQgaXMgYWxzbyANCmEgcXVlc3Rpb24gaWYgdGhlIGludGVyb3BlcmFiaWxp dHkgb2YgTEZCcyB3aWxsIGJlIG1vcmUsIG5vdCBhZmZlY3RlZCwgb3IgZXZlbiBsZXNzIGJ5IHB1 dGluZyANCm1vcmUgb2ZmLWxvYWRlZCBvbiB0aGVtPyANCg0KSSBzaG91bGQgc3RhdGUgdGhhdCB3 aGF0IEkgYWRkcmVzc2VkIGlzIG9ubHkgc29tZXRoaW5nIEkgdW5kZXJzdG9vZCB0byB0aGUgcXVl c3Rpb24uIEkgZG9uJ3QgaGF2ZSBhbnkgbWVhbg0KdG8gYW55IHByb3Bvc2FsLiBJIHRoaW5rIGN1 cnJlbnQgcHJvcG9zYWxzIGFyZSBhbGwgZmFyIGF3YXkgZnJvbSB0aGUgcHJvYmxlbXMgSSBhZGRy ZXNzZWQuDQoNClJlZ2FyZHMsDQpXZWltaW5nIFdhbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+ DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDA0LCAyMDAzIDQ6NTMgQU0NClN1YmplY3Q6IEFuIG92ZXJzaW1wbGlmaWVkIGNvbW1lbnQg b24gcHJvdG9jb2xzIGFuZCBvcGVyYXRpb25zDQoNCg0KPiBJbiBsb29raW5nIGF0IHRoZSBwcm90 b2NvbCBwcm9wb3NhbHMsIEkgaGF2ZSBiZWVuIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZQ0KPiBz aWduaWZpY2FudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZW0uDQo+IA0KPiBPbmUgaW50ZXJlc3Rp bmcgZGlmZmVyZW5jZSBpcyBpbiB0aGUgd2F5ICJvcGVyYXRpb25zIiBvbiBlbnRpdGllcyBhcmUN Cj4gc3VwcG9ydGVkLg0KPiBbV2hhdCBmb2xsb3dzIGlzIG92ZXItc2ltcGxpZmllZCBhbmQgbm90 IGludGVuZGVkIHRvIGRlbmlncmF0ZSBhbnkgb2YgdGhlDQo+IHByb3Bvc2Fscy5dDQo+IA0KPiBJ biBzb21lIG9mIHRoZSBwcm9wb3NhbHMsIHRoZSBiYXNlIHByb3RvY29sIGhhcyB0aGUgIm9wZXJh dGlvbnMiLiAgVGhlDQo+IGRlZmluZWQgb3BlcmF0aW9ucyB0ZW5kIHRvIGJlIHJlYWQgYW5kIHdy aXRlLg0KPiANCj4gSW4gc29tZSBvZiB0aGUgcHJvdG9jb2xzLCB0aGUgZWxlbWVudHMgZWFjaCBk ZWZpbmUgdGhlIG9wZXJhdGlvbnMsIGFuZCB0aGUNCj4gcHJvdG9jb2wgaXMgZGVmaW5lZCB0byBj YXJyeSBhbiBvcGFxdWUgYmxvY2sgdG8gYmUgaW50ZXJwcmV0ZWQgYnkgdGhlIGVsZW1lbnQuDQo+ IA0KPiBPbmUgY291bGQgYWxzbyBpbWFnaW5lIGFuIGludGVybWVkaWF0ZSBwb2ludCB3aGVyZSB0 aGUgcHJvdG9jb2wgaXMgZGVmaW5lZA0KPiB0byBjYXJyeSBhIHRhcmdldCwgYW5kIG9wZXJhdGlv biBpZGVudGlmaWVyLCBhbmQgb3BlcmF0aW9uIHBhcmFtZXRlcnMsIGFuZA0KPiB0aGVuIHRvIHJl dHVybiBvcGVyYXRpb24gcmVzdWx0cy4gIEFuZCBlYWNoIGVsZW1lbnQgdHlwZSBkZWZpbml0aW9u DQo+IGluY2x1ZGVkIHRoZSBsaXN0IG9mIHBlcm1pdHRlZCBvcGVyYXRpb25zLg0KPiANCj4gSXQg c2VlbXMgdG8gbWUgdGhhdCBpZiBMRkJzICh0YXJnZXQgZWxlbWVudHMpIHdpbGwgaGF2ZSB2ZXJ5 IHNpbWlsYXINCj4gb3BlcmF0aW9ucyBtb3N0IG9mIHRoZSB0aW1lLCB0aGVuIHRob3NlIG9wZXJh dGlvbnMgb3VnaHQgdG8gYmUgY2FsbGVkIG91dA0KPiBpbiB0aGUgYmFzZSBwcm90b2NvbC4gIE9u IHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgb3BlcmF0aW9ucyBvbiBMRkJzIHRlbmQgdG8NCj4gYmUg dmVyeSBkaWZmZXJlbnQsIHRoZW4gdGhlIHByb3RvY29sIG91Z2h0IHRvIGJlIGRlc2lnbmVkIHRv IGNhcnJ5IG1vcmUNCj4gZ2VuZXJpYyBibG9ja3MuDQo+IA0KPiANCj4gVGhpcyB0b3BpYyBjb21l cyB1cCBpbiBtYW55IG1hbmFnZW1lbnQgLyBjb250cm9sIGFwcGxpY2F0aW9ucy4gIEl0IHdvdWxk DQo+IHNlZW0gdG8gYmVob292ZSB1cyB0byBhZGRyZXNzIGl0IGRpcmVjdGx5IGFuZCBleHBsaWNp dGx5IHJhdGhlciB0aGFuDQo+IGNob29zaW5nIGEgcHJvdG9jb2wgYW5kIHRoZW4gYWNjZXB0aW5n IHRoZSBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMgb2YgdGhlDQo+IHByb3RvY29sLg0KPiANCj4g WW91cnMsDQo+IEpvZWwgTS4gSGFscGVybg0KPiANCj4gUFM6IEkgd2lsbCBhZG1pdCB0aGF0IGJv dGggZXh0cmVtZSBhcHByb2FjaGVzIChhbmQgbW9zdCBtaWRwb2ludHMpIGNhbg0KPiB3b3JrLiAg T25lIGNhbiBzdWdnZXN0IHRoYXQgdGhpcyBpcyBhIHBoaWxvc29waGljYWwgZGlmZmVyZW5jZS4g IEJ1dCBpdCBoYXMNCj4gcHJhY3RpY2FsIGltcGxpY2F0aW9ucyBpbiB0aGUgcHJvdG9jb2wgc3Ry dWN0dXJpbmcuDQo+IA0KPiA= From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 11:51:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12668 for ; Wed, 5 Nov 2003 11:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQsS-0006oL-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 11:51:28 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHQsS-0006oI-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 11:51:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C37801@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 11:51:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59470231 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 11:51:26 -0500 Received: from 192.19.192.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 11:51:26 -0400 Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail1.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hA5GpQT01238 for ; Wed, 5 Nov 2003 11:51:26 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hA5GpQX13683 for ; Wed, 5 Nov 2003 11:51:26 -0500 (EST) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Nov 2003 11:51:25 -0500 Received: from jrenwick ([135.149.51.19]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Nov 2003 11:51:25 -0500 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.4910.0300 X-OriginalArrivalTime: 05 Nov 2003 16:51:25.0572 (UTC) FILETIME=[0CD1AC40:01C3A3BD] Approved-By: John Renwick Message-ID: Date: Wed, 5 Nov 2003 10:51:25 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: FW: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alan, I apologize for the "turf issues" remark in my earlier email. I can understand how that's a personal attack, even though I didn't really mean it that way. The statement I took issue with, "...other blocks may make decisions based on the parameters S, t, and M, but not on P," seems to contradict the previous paragraph -- unless I understand "P" to mean the LFB examines the entire packet or major parts of it. I agree with the statement in the previous paragraph, "...other FE LFBs MAY perform simple classification on the packet...." It hangs on the definition of "simple classification," I guess. If you regard validating and interpreting one header at a time as simple classification, then the forwarding plane could be constructed of protocol-specific processing LFBs without the need for a classifier LFB. I'm not sure if the model is allowing that or prohibiting it. John > -----Original Message----- > From: Alan DeKok [mailto:alan.dekok@idt.com] > Sent: Tuesday, November 04, 2003 2:31 PM > To: npf-sw-fapi@npforum.org; > "FORCES@PEACH.EASE.LSOFT.COM"@thunder.amsl.com > Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI > > > John Renwick wrote: > > > I thought I'd try to put in writing some of the comments I had > > today about the ForCES model draft. I see two major issues, > > and some smaller things. The first major one is about metadata: > > I've cross-posted your NPF post to the ForCES list, where ForCES > related discussion belongs. That list is open to all, and I suggest you > join it, if you haven't already done so. > > > Section 4.4.4 lists, as one of the Capability attributes of > > LFBs: "Metadata pass-through limitations of the LFB." If an > > LFB definition must indicate all metadata elements that are > > "passed through" it, it would have to refer to metadata that > > it is not at all concerned with, and maybe hasn't even been > > thought of at the time the LFB is defined. > > There is a simple solution to this problem. The LFB's describe only > the metadata they care about. All other metadata can pass through the > LFB unchanged, and un-examined. > > > If the FE must > > expose all this detail about the routing of metadata, does it > > suggest that there are metadata flow paths that are distinct > > from packet flow paths, that also need to be revealed in the > > LFB topology? > > Perhaps. See the NPF hardware "lookaside" interface design. Packets > do NOT flow through a piece of "lookaside" hardware, but that hardware > does produce metadata. Something must manage that metadata, and > correlate it with the packet. That management should be modelled. > > > On the other hand, why do we care at all? > > Isn't it enough to indicate, for each metadatum, which LFB > > produces it and which LFBs use it, and then assume that the > > implementation is functional enough to make each available > > in some way to the LFBs that need it? > > Making implicit assumptions is almost always bad. The purpose of the > ForCES model document is to *model* the functionality of the FE. Not > including large aspects of the FE in the model means that the model is > less effective > > > The second major thing concerns ingress/egress ("hybrid") > > ports. If a port represents both ingress and egress, making > > an LFB topology acyclic may require the port to be represented > > as two LFBs -- or two instances of the same LFB. We have a > > similar problem in FAPI. How will ForCES resolve this? > > The LFB topology may be acyclic, even if there *appear* to be loops > with it. > > See Page 23 of the document, under Figure 6: > > "It is important to point out that the LFB topology here is > the logical topology that the packets flow through, not the > physical topology as determined by how the FE hardware is > laid out." > > What this means is that the even though a port LFB may be both ingress > and egress, there is NO cyclic flow of packets through that LFB, around > & around the model. That is, at the egress, the packets LEAVE the LFB > model. There are therefore no cycles. > > > Other things: > > > > 1. At the top of page 5: "LFB topology is outside of the LFB > > model, but part of the FE model." Can this be clarified? It > > sounds self-contradictory. > > Each individual part in your car can be described in isolation. Yet > no one claims that the method of interconnecting them to create a "car" > is part of the "engine" concept, or part of the "tire" concept. That > interconnection is part of the "car" concept alone. > > > 2. Section 4.1.2 talks about "Structures." Are they like 'C' > > structures, whose layout in memory can be compiler-dependent, > > or are they meant to specify a machine-independent layout in > > memory or in a PDU? This doesn't seem to be clear. > > It's not clear because the document does not yet describe them in > detail. > > The ForCES model group has been working on that part of the document. > > > How are > > they to be used? If their only purpose is to give names and > > limits to data elements in the abstract, and not to specify > > byte-by-byte organization, that makes sense and I'm fine > > with it. > > I'm uncertain as to how anything will be interoperable if we don't > specify byte-by-byte organization of data within ForCES. > > > 3. Section 4.3: the title is "Frame Format," but the description > > talks about packet types -- not formats. > > > > 4. Section 7.2: Can a dropper count packets? The description > > should probably say so. > > Such comments should be posted to the ForcES list, or to the authors. > > > 5. Section 7.3 says the Redirector LFB uses metadata to > > determine where to send each packet. Why couldn't it use > > packet content as well? > > We have had this discussion ad nauseum in NPF. Please see historical > NPF discussions as to why we have a seperate "classifier" block, and why > it's not appropriate to have a generic classifier inside of every block. > > > 6. Section 7.4 & 7.5, Scheduler and Queue: it may be hard to > > make these work as separate LFBs, because as currently > > written, a scheduler can't see what's in a queue; it can only > > release backpressure and allow a packet to be sent to it. > > Depending on the scheduling algorithm, the scheduler may need > > to see attributes of the queue, such as whether it's empty or > > not and how big the first packet is, without actually moving > > the packet. > > The document is still in progress. We welcome suggested replacement > text. > > > 7. Section 7.6: Must every packet counted actually flow through > > a counter LFB, or can the LFB have implicit connections to > > events in other LFBs without having to direct all packets > > through it? > > Like metadata? > > > Can a counter LFB contain more than one counter, > > and if so, does it use metadata to determine which counters to > > increment? And why would a counter LFB ever modify metadata? > > I don't understand the last paragraph; it sounds self-contradictory. > > A counter counts events, not the rate of change of events over time. > > > 8. 7.7: Shouldn't the description of a Meter LFB say something > > about assigning a "color" to a packet? > > We welcome suggested text. > > > 9. 7.8: The Classifier description reads as if it were written > > by two different authors who didn't agree. First it says a > > classifier has just one output, then in the last paragraph it > > says it can have a different output for each class. Which is > > true? > > The document is still in development. Earlier versions of the > document had two classifier LFBs, which have been merged in this > version. Not all of the relevant text was updated. > > > The next-to-last paragraph seems to be saying that only > > a classifier LFB may make decisions based on packet content > > (is that what "P" means?) > > Yes. See Section 3.2 "LFB Modelling", where it defines P. > > >, and other LFBs are only allowed to > > base decisions on "S, t, and M" (what are those? I don't see > > them defined anywhere). > > They were defined in an earlier version of the document, and that text > was erroneously deleted. > > > Why must the classifier try to restrict > > other LFBs in this way? Turf issue? > > Grow up. You've been party to NPF discussions where it was made clear > that having a classifier in every block was nonsense. I suggest you > re-visit those discussions. > > > 10. 7.9, 7.10: The Packet Modifier LFB description says there > > will be other LFBs for modifications needed by specific protocols. > > Then there's a Packet Header Rewriter for header modifications. > > All the legitimate packet modifications seem to be covered by > > LFBs that obey the rules of specific protocols, and that's good. > > What's left for the Packet Modifier to do? It sounds tailor- > > made for hackers! :-) > > If you say so. > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 12:12:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13389 for ; Wed, 5 Nov 2003 12:12:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRD8-00076d-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:12:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHRD8-00076a-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:12:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C37827@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 12:12:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59471701 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 12:12:49 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 12:12:49 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA5HCmTd017664 for ; Wed, 5 Nov 2003 17:12:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA5HC9ag020457 for ; Wed, 5 Nov 2003 17:12:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110509124624234 for ; Wed, 05 Nov 2003 09:12:46 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 09:12:46 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FE model open issues Thread-Index: AcOdhee3k/nVewozR3ekT81rr3z/fwGLVkcg X-OriginalArrivalTime: 05 Nov 2003 17:12:46.0742 (UTC) FILETIME=[0874B360:01C3A3C0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 09:12:41 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable In the model draft it states:=20 "LFB topology reconfiguration is considered an important aspect of the FE model." It seems like one of the questions that has not been resolved by the working group is how much dynamic reconfigurability is required. A number of possibilities have been proposed in various drafts, ranging from the ability to completely reconfigure an FE - changing the service by adding/deleting LFBs to supporting only a limited amount of reconfigurability.=20 The ability for the CE to treat the FE as a blank sheet of paper and download LFBs and their associated topology seems unnecessary. If the goal is for ForCES to define a protocol to allow CEs and FEs from different vendors to interoperate, this seems to be out of scope for the ForCES WG. I assume that FEs would have capabilities built in that the CEs could query, and customize the LFB behavior at runtime (the degree is dependent on the capability of the FE), but not to add new functionality by downloading LFB code. =20 I'd also argue that dynamically reconfiguring LFB topology does not require the ability to add or delete paths, assuming the approach of using a combination of encoded state and a topological graph approach is used to model the LFB topology. Functionality such as redirecting traffic flows dynamically can be handled by changing the encoded state, the topology graph itself is static. Regards, Ellen Deleganes =20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L Sent: Tuesday, October 28, 2003 11:02 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: FE model open issues Hi, all -- I hope you've had a chance reviewing the latest FE model draft. Here is the link, in case you have not done that.=20 http://www.ietf.org/internet-drafts/draft-ietf-forces-model-01.txt The FE model design team also identified a list of open issues that we consider either not fully resolved or completely missing in v01. Here is the list: #1 FE connectivity: Whether or not the FE connectivity information should be part of the FE model?=20 #2 metadata: How to define the metadata in LFB model?=20 #3 XML schema for LFB class: We need to refine LFB model and turn it into XML schema for Section 4. #4 LFB class partition: How to partition common FE functions (starting with IPv4 forwarding) into a list of LFB classes? When to use a base class ? (Section 7) #5 Satisfying requirements: We need to provide examples to demonstrate that the FE model can address all the requirements in Section 8. #6 FE capabilities and attributes: We need to define the FE level capabilities and attributes in Section 6. #7 LFB topology for Section 5. We would like to continue working on these issues to move the FE model forward. Your ideas, suggestions & contribution in these areas are most welcome! Lily From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 12:28:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13791 for ; Wed, 5 Nov 2003 12:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRS2-0007IY-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:28:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHRS1-0007IU-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:28:13 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C37992@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 12:28:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59472593 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 12:28:12 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 12:28:12 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5731797 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 Nov 2003 12:28:12 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031105122147.021976e0@localhost> Date: Wed, 5 Nov 2003 12:27:57 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel. com> Precedence: list There will certainly be FEs whose internal LFB topoloogy is static or nearly static. There will be FEs whose only "adjustability" is in the metadata. There will also be FEs where LFBs can be selected to be used in different data paths, and services created in a more dynamic fashion. The most capable FEs will have an extremely flexible topology where most any LFB can occur anywhere. One could argue that for the first release we should support only static topology. Based on experience, I feel that is too limiting. Hence, I would like to see the protocol include mechanisms for "creating" LFBs and connecting them to other LFBs in the FE. This is not primarily to support the blank sheet model (although that will happen to be supportable) but to support the large range of FEs with some adjustability in the LFB topology. The consequence of course is that the CE must be prepared to have its attempt to adjust the topology fail, since most FEs will have limits on their adjustability. This is largely inevitable. If a CE is trying to install a service, the FE might not be able to deliver it (the capabilities information is about helping the CE have information to judge whether and how to configure the service on a given FE.) Related to this, as we say in the documents, some of the mapping requires human intelligence and will not work without a person in the loop. Joel At 09:12 AM 11/5/2003 -0800, you wrote: >Subject: Re: FE model open issues >To: FORCES@PEACH.EASE.LSOFT.COM > >In the model draft it states: >"LFB topology reconfiguration is considered an important aspect of the >FE model." It seems like one of the questions that has not been resolved >by the working group is how much dynamic reconfigurability is required. >A number of possibilities have been proposed in various drafts, ranging >from the ability to completely reconfigure an FE - changing the service >by adding/deleting LFBs to supporting only a limited amount of >reconfigurability. > >The ability for the CE to treat the FE as a blank sheet of paper and >download LFBs and their associated topology seems unnecessary. If the >goal is for ForCES to define a protocol to allow CEs and FEs from >different vendors to interoperate, this seems to be out of scope for the >ForCES WG. I assume that FEs would have capabilities built in that the >CEs could query, and customize the LFB behavior at runtime (the degree >is dependent on the capability of the FE), but not to add new >functionality by downloading LFB code. > >I'd also argue that dynamically reconfiguring LFB topology does not >require the ability to add or delete paths, assuming the approach of >using a combination of encoded state and a topological graph approach is >used to model the LFB topology. Functionality such as redirecting >traffic flows dynamically can be handled by changing the encoded state, >the topology graph itself is static. > >Regards, >Ellen Deleganes From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 12:33:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14083 for ; Wed, 5 Nov 2003 12:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRWr-0007NZ-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:33:13 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHRWq-0007NW-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:33:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C379CC@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 12:33:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59472778 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 12:33:11 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 12:33:07 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA5HX6Td025515 for ; Wed, 5 Nov 2003 17:33:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA5HWIaj025460 for ; Wed, 5 Nov 2003 17:32:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110509330525628 for ; Wed, 05 Nov 2003 09:33:05 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 09:33:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference, Tuesday 4th Thread-Index: AcOjEvLhc8782xYSTwaRZrgEEvqvQwArt4Ow X-OriginalArrivalTime: 05 Nov 2003 17:33:05.0672 (UTC) FILETIME=[DEFEA880:01C3A3C2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEB4@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 09:33:05 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference, Tuesday 4th To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable John -- First of all, I want to thank you for the comments. It is good = to finally see some concrete feedback on the FE model draft. Thanks to = Alan for forwarding this to ForCES mailing list, otherwise I won't even = see it. I believe Alan has answered most of your questions. Just one comment = about the questions you raised regarding data type (as shown following). = It is my understanding that the FE model defines the logical data = structure but not the byte-by-byte organization. The byte-by-byte = encoding of such data structure will be defined by the ForCES protocol = instead. Lily >=20 > > 2. Section 4.1.2 talks about "Structures." Are they like 'C' > > structures, whose layout in memory can be compiler-dependent, > > or are they meant to specify a machine-independent layout in > > memory or in a PDU? This doesn't seem to be clear. >=20 > >=20 > > How are > > they to be used? If their only purpose is to give names and > > limits to data elements in the abstract, and not to specify > > byte-by-byte organization, that makes sense and I'm fine > > with it. >=20 =20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 12:55:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14850 for ; Wed, 5 Nov 2003 12:55:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRsr-0007gI-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:55:57 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHRsr-0007gF-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 12:55:57 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C37A62@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 12:55:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59475356 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 12:55:51 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 12:55:51 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003110509543865:3649 ; Wed, 5 Nov 2003 09:54:38 -0800 References: <5.1.0.14.0.20031105122147.021976e0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/05/2003 09:54:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/05/2003 09:54:40 AM, Serialize complete at 11/05/2003 09:54:40 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1068054948.1024.157.camel@jzny.localdomain> Date: Wed, 5 Nov 2003 12:55:48 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031105122147.021976e0@localhost> Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-11-05 at 12:27, Joel M. Halpern wrote: > There will certainly be FEs whose internal LFB topoloogy is static or > nearly static. There will be FEs whose only "adjustability" is in the > metadata. There will also be FEs where LFBs can be selected to be used in > different data paths, and services created in a more dynamic fashion. The > most capable FEs will have an extremely flexible topology where most any > LFB can occur anywhere. > > One could argue that for the first release we should support only static > topology. Based on experience, I feel that is too limiting. Hence, I > would like to see the protocol include mechanisms for "creating" LFBs and > connecting them to other LFBs in the FE. This is not primarily to support > the blank sheet model (although that will happen to be supportable) but to > support the large range of FEs with some adjustability in the LFB topology. > I am in agreement with you. And infact have proof of concept existing already. Have we talked about "creating" LFBs before? My presentation (last in the agenda) talks about an implementation that is capable of doing what is being refered to as "dynamic". In that model, downloading LFB modules and inserting them in the FE is what i would term as "creating". I think this is more out of scope for Forces. Creating policies that use the downloaded LFBs is more "instatiating" a LFB instance. This is within scope and you may have meant to say this. In other words, FE capabilities may change and be rediscovered at any point in time by Forces requiring adjustements (example lost capabilities). Moral of the point here, is this is not a blank sheet to the FE; it is there today (and yes that code is known to work with static LFB FEs like ASICs and some NPs). Nobody cares how the dynamic LFBs get there, just that you can use Forces to configure them when you need to. > The consequence of course is that the CE must be prepared to have its > attempt to adjust the topology fail, since most FEs will have limits on > their adjustability. This is largely inevitable. If a CE is trying to > install a service, the FE might not be able to deliver it (the > capabilities information is about helping the CE have information to judge > whether and how to configure the service on a given FE.) Related to this, > as we say in the documents, some of the mapping requires human intelligence > and will not work without a person in the loop. Indeed. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 13:26:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15974 for ; Wed, 5 Nov 2003 13:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSMI-0000Jp-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:26:22 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHSMI-0000Jm-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:26:22 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C379A6@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 13:26:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59477415 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 13:26:21 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 13:26:21 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5731987 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 Nov 2003 13:26:20 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B0A42F89@orsmsx410.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031105132535.0218de18@localhost> Date: Wed, 5 Nov 2003 13:26:05 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Updated agenda, ForCES Meeting, IETF 58 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006a01c3a27d$5e633ec0$3d19fea9@wwm1> Precedence: list A reasonable request. I look forward to the discussion. Yours, Joel M. Halpern At 10:42 AM 11/4/2003 +0800, you wrote: >Hi Joel and Hormuzd, > >I asked David to change the agenda, for I consider to take PkfID part >as an extension part of GRMP instead of an independant one, and have >the possible discussions put together. I do have tried to present PkfID >first, >but just found I could not do it well within the assigned time with my >limited >spoken eng. ability. To put it after GRMP is actually a simplified version >for >my presentation, with some contents cut. I really appreciate it if more >discussions >can be hold off the meeting time by WG ourself, by which I hope to have >chance >to explain more. > >Thanks for your attention. > >Yours, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 13:48:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16610 for ; Wed, 5 Nov 2003 13:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHShg-0000bh-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:48:28 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHShg-0000bd-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:48:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C37BA6@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 13:48:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59479955 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 13:48:24 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 13:48:24 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA5ImNOf003368 for ; Wed, 5 Nov 2003 12:48:23 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <26BDFAFFB541B047B24179002EBE6D278CAEB4@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FA945F6.3BA95522@alcatel.com> Date: Wed, 5 Nov 2003 12:48:22 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference,Tuesday 4th To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit And the ForCES protocol depends on a firm data model to derive byte-by-byte organization of the objects representative of the LFBs' data. Alex. "Yang, Lily L" wrote: > John -- First of all, I want to thank you for the comments. It is good to finally see some concrete feedback on the FE model draft. Thanks to Alan for forwarding this to ForCES mailing list, otherwise I won't even see it. > I believe Alan has answered most of your questions. Just one comment about the questions you raised regarding data type (as shown following). It is my understanding that the FE model defines the logical data structure but not the byte-by-byte organization. The byte-by-byte encoding of such data structure will be defined by the ForCES protocol instead. > > Lily > > > > > > 2. Section 4.1.2 talks about "Structures." Are they like 'C' > > > structures, whose layout in memory can be compiler-dependent, > > > or are they meant to specify a machine-independent layout in > > > memory or in a PDU? This doesn't seem to be clear. > > > > > > > > > How are > > > they to be used? If their only purpose is to give names and > > > limits to data elements in the abstract, and not to specify > > > byte-by-byte organization, that makes sense and I'm fine > > > with it. > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 13:57:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17134 for ; Wed, 5 Nov 2003 13:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSqa-0000nW-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:57:41 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHSqa-0000nT-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 13:57:40 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C37BAC@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 13:57:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59480577 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 13:57:36 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 13:57:36 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA5IvaTd025256 for ; Wed, 5 Nov 2003 18:57:36 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA5IuUam015076 for ; Wed, 5 Nov 2003 18:56:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110510573508947 for ; Wed, 05 Nov 2003 10:57:35 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 10:57:35 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference,Tuesday 4th Thread-Index: AcOjzXZRIYRQ4bQ/T2O4r7XVy3lqlgAAQ30Q X-OriginalArrivalTime: 05 Nov 2003 18:57:35.0751 (UTC) FILETIME=[ACFF5170:01C3A3CE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEBB@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 10:57:35 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference,Tuesday 4th To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Yes. And as it stands today, the data model is still a bit "fluid" but = it will firm up over time :-) > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alex Audu > Sent: Wednesday, November 05, 2003 10:48 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI > Teleconference,Tuesday 4th >=20 >=20 > And the ForCES protocol depends on a firm data model to=20 > derive byte-by-byte > organization of the objects representative of the LFBs' data. >=20 > Alex. >=20 > "Yang, Lily L" wrote: >=20 > > John -- First of all, I want to thank you for the comments.=20 > It is good to finally see some concrete feedback on the FE=20 > model draft. Thanks to Alan for forwarding this to ForCES=20 > mailing list, otherwise I won't even see it. > > I believe Alan has answered most of your questions. Just=20 > one comment about the questions you raised regarding data=20 > type (as shown following). It is my understanding that the FE=20 > model defines the logical data structure but not the=20 > byte-by-byte organization. The byte-by-byte encoding of such=20 > data structure will be defined by the ForCES protocol instead. > > > > Lily > > > > > > > > > 2. Section 4.1.2 talks about "Structures." Are they like 'C' > > > > structures, whose layout in memory can be compiler-dependent, > > > > or are they meant to specify a machine-independent layout in > > > > memory or in a PDU? This doesn't seem to be clear. > > > > > > > > > > > > > How are > > > > they to be used? If their only purpose is to give names and > > > > limits to data elements in the abstract, and not to specify > > > > byte-by-byte organization, that makes sense and I'm fine > > > > with it. > > > > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 14:44:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19839 for ; Wed, 5 Nov 2003 14:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTaV-0001lS-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 14:45:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHTaU-0001lP-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 14:45:06 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C37DC3@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 14:45:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59482339 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 14:45:05 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 14:45:05 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA5Jfqf2028111 for ; Wed, 5 Nov 2003 19:41:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA5JdFB01990 for ; Wed, 5 Nov 2003 19:39:15 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110511450322727 for ; Wed, 05 Nov 2003 11:45:03 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 11:45:03 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] FE model open issues Thread-Index: AcOjwjwvEe9VLvt5RoS/zWxPZt6iGQADC5kg X-OriginalArrivalTime: 05 Nov 2003 19:45:03.0473 (UTC) FILETIME=[4E5F3610:01C3A3D5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A4330C@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 11:45:03 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Joel Let me try to explain what I am thinking here and let me know if you agree. An FE initially reports its LFB topology to the CE. This is the capability graph which includes all the possible LFBs and paths connecting the LFBs that an FE can handle (acc to its implementation). Now this topology might express multiple services that a FE implements. For example, Say this is the FE Capability graph (LFB topology) which is reported=20 during capability discovery. |--| | |-->|B|-->|C|-->|D|--| --->|A | |--->|H|--> | |-->|E|-->|F|-->|G|--| |--| Now, paths A->B->C->D->H might perform Service 1 and paths A->E->F->G->H might perform Service 2. Now at runtime you need the ability to direct packets or flows through either of these different paths in the FE. You can do this by using the encoded state approach in which you will define a metadata like the "NextLFBID" which will specify what is the next block or LFB.=20 For example, when you configure LFB A in the figure above, you will specify=20 in its configuration information what should be the NextLFBID (B or E). If you use this approach, then you do not need to reconfigure the LFB topology at runtime, you just use a type of generic metadata "NextLFBID" to dynamically change the paths. The only time that you will need to change any LFB topology at runtime will be if you are dynamically downloading code on the FE for an LFB which is currently out of the scope of ForCES and also there are no commercially shipping products which support this. Does that make sense ? Hope this helps, Thanks Hormuzd P.s. BTW, this is also the current thinking in the NPF as regards topology. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Wednesday, November 05, 2003 9:28 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] FE model open issues There will certainly be FEs whose internal LFB topoloogy is static or nearly static. There will be FEs whose only "adjustability" is in the metadata. There will also be FEs where LFBs can be selected to be used in different data paths, and services created in a more dynamic fashion. The most capable FEs will have an extremely flexible topology where most any LFB can occur anywhere. One could argue that for the first release we should support only static topology. Based on experience, I feel that is too limiting. Hence, I would like to see the protocol include mechanisms for "creating" LFBs and connecting them to other LFBs in the FE. This is not primarily to support the blank sheet model (although that will happen to be supportable) but to support the large range of FEs with some adjustability in the LFB topology. The consequence of course is that the CE must be prepared to have its attempt to adjust the topology fail, since most FEs will have limits on their adjustability. This is largely inevitable. If a CE is trying to install a service, the FE might not be able to deliver it (the capabilities information is about helping the CE have information to judge whether and how to configure the service on a given FE.) Related to this, as we say in the documents, some of the mapping requires human intelligence and will not work without a person in the loop. Joel At 09:12 AM 11/5/2003 -0800, you wrote: >Subject: Re: FE model open issues >To: FORCES@PEACH.EASE.LSOFT.COM > >In the model draft it states: >"LFB topology reconfiguration is considered an important aspect of the >FE model." It seems like one of the questions that has not been resolved >by the working group is how much dynamic reconfigurability is required. >A number of possibilities have been proposed in various drafts, ranging >from the ability to completely reconfigure an FE - changing the service >by adding/deleting LFBs to supporting only a limited amount of >reconfigurability. > >The ability for the CE to treat the FE as a blank sheet of paper and >download LFBs and their associated topology seems unnecessary. If the >goal is for ForCES to define a protocol to allow CEs and FEs from >different vendors to interoperate, this seems to be out of scope for the >ForCES WG. I assume that FEs would have capabilities built in that the >CEs could query, and customize the LFB behavior at runtime (the degree >is dependent on the capability of the FE), but not to add new >functionality by downloading LFB code. > >I'd also argue that dynamically reconfiguring LFB topology does not >require the ability to add or delete paths, assuming the approach of >using a combination of encoded state and a topological graph approach is >used to model the LFB topology. Functionality such as redirecting >traffic flows dynamically can be handled by changing the encoded state, >the topology graph itself is static. > >Regards, >Ellen Deleganes From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 14:54:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20419 for ; Wed, 5 Nov 2003 14:54:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTk3-00021K-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 14:54:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHTk3-00021G-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 14:54:59 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C37D1E@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 14:54:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59482897 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 14:54:57 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 14:54:57 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5732313 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 Nov 2003 14:54:57 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031105144759.020c77b0@localhost> Date: Wed, 5 Nov 2003 14:54:42 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0A4330C@orsmsx410.jf.intel. com> Precedence: list If I have read this right, there are LFBs that will work this way. However, I am not sure. Let me rephrase. 1) At any time (ncluding startup) an FE has an LFB topology that is actually instantiated. For some FEs this will be initially empty, for others it will be initially populated and always the same. This is not capability information, this the actual LFB topology. 2) Some FEs (particularly software / NPU based FEs, but also some hardware ones) have deployable components. That is, data paths may be adjusted to cause different elements to receive different packets. (Some folks will think of this as the configured equivalent of meta-data based steering.) 2') For FEs with deployable components, there should be capability infromation indicating what LFBs the FE supports, and something about how they can be interconnected. What you describe is a static LFB topology with service based steering among the paths (either by metadata or by classification. This will commonly happen (After all, not all packets receive the same service.) But there are other things that happen. During operation, the service owner decides to start offering a new service. If the FE supports conbfigurable LFBs, this may involve creating / instantiating / enabling new LFBs, and connecting such LFBs to existing LFBs. The owner may also decide to stop offering a service, and may cancel use of certain LFBs. Both of these might involve only changing classifiers (in static FEs) or instructing the FE to create a whole new LFB, or ... Yours, Joel M. Halpern At 11:45 AM 11/5/2003 -0800, you wrote: >Hi Joel > >Let me try to explain what I am thinking here and let me know if you >agree. > >An FE initially reports its LFB topology to the CE. This is the >capability >graph which includes all the possible LFBs and paths connecting the LFBs > >that an FE can handle (acc to its implementation). Now this topology >might >express multiple services that a FE implements. For example, > >Say this is the FE Capability graph (LFB topology) which is reported >during capability discovery. > > |--| > | |-->|B|-->|C|-->|D|--| >--->|A | |--->|H|--> > | |-->|E|-->|F|-->|G|--| > |--| > >Now, paths A->B->C->D->H might perform Service 1 and paths A->E->F->G->H >might perform Service 2. Now at runtime you need the ability to direct >packets >or flows through either of these different paths in the FE. You can do >this >by using the encoded state approach in which you will define a metadata >like >the "NextLFBID" which will specify what is the next block or LFB. >For example, when you configure LFB A in the figure above, you will >specify >in its configuration information what should be the NextLFBID (B or E). > >If you use this approach, then you do not need to reconfigure the LFB >topology >at runtime, you just use a type of generic metadata "NextLFBID" to >dynamically >change the paths. The only time that you will need to change any LFB >topology >at runtime will be if you are dynamically downloading code on the FE for >an >LFB which is currently out of the scope of ForCES and also there are no >commercially shipping products which support this. > >Does that make sense ? Hope this helps, > >Thanks >Hormuzd >P.s. BTW, this is also the current thinking in the NPF as regards >topology. > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Wednesday, November 05, 2003 9:28 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] FE model open issues > > >There will certainly be FEs whose internal LFB topoloogy is static or >nearly static. There will be FEs whose only "adjustability" is in the >metadata. There will also be FEs where LFBs can be selected to be used >in >different data paths, and services created in a more dynamic fashion. >The >most capable FEs will have an extremely flexible topology where most any >LFB can occur anywhere. > >One could argue that for the first release we should support only static >topology. Based on experience, I feel that is too limiting. Hence, I >would like to see the protocol include mechanisms for "creating" LFBs >and >connecting them to other LFBs in the FE. This is not primarily to >support >the blank sheet model (although that will happen to be supportable) but >to >support the large range of FEs with some adjustability in the LFB >topology. > >The consequence of course is that the CE must be prepared to have its >attempt to adjust the topology fail, since most FEs will have limits on >their adjustability. This is largely inevitable. If a CE is trying to >install a service, the FE might not be able to deliver it (the >capabilities information is about helping the CE have information to >judge >whether and how to configure the service on a given FE.) Related to >this, >as we say in the documents, some of the mapping requires human >intelligence >and will not work without a person in the loop. > >Joel > >At 09:12 AM 11/5/2003 -0800, you wrote: > >Subject: Re: FE model open issues > >To: FORCES@PEACH.EASE.LSOFT.COM > > > >In the model draft it states: > >"LFB topology reconfiguration is considered an important aspect of the > >FE model." It seems like one of the questions that has not been >resolved > >by the working group is how much dynamic reconfigurability is required. > >A number of possibilities have been proposed in various drafts, ranging > >from the ability to completely reconfigure an FE - changing the service > >by adding/deleting LFBs to supporting only a limited amount of > >reconfigurability. > > > >The ability for the CE to treat the FE as a blank sheet of paper and > >download LFBs and their associated topology seems unnecessary. If the > >goal is for ForCES to define a protocol to allow CEs and FEs from > >different vendors to interoperate, this seems to be out of scope for >the > >ForCES WG. I assume that FEs would have capabilities built in that the > >CEs could query, and customize the LFB behavior at runtime (the degree > >is dependent on the capability of the FE), but not to add new > >functionality by downloading LFB code. > > > >I'd also argue that dynamically reconfiguring LFB topology does not > >require the ability to add or delete paths, assuming the approach of > >using a combination of encoded state and a topological graph approach >is > >used to model the LFB topology. Functionality such as redirecting > >traffic flows dynamically can be handled by changing the encoded state, > >the topology graph itself is static. > > > >Regards, > >Ellen Deleganes From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 15:25:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22475 for ; Wed, 5 Nov 2003 15:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHUDI-0002Ug-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 15:25:12 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHUDI-0002Ud-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 15:25:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C37DB5@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 15:25:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59485914 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 15:25:10 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 15:25:10 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA5KLxf2008288 for ; Wed, 5 Nov 2003 20:21:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA5KJMB13815 for ; Wed, 5 Nov 2003 20:19:22 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110512251011883 for ; Wed, 05 Nov 2003 12:25:10 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 12:25:10 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] FE model open issues Thread-Index: AcOj1rcgqzOlvKQfRzi+BZROdSRONQAAimoQ X-OriginalArrivalTime: 05 Nov 2003 20:25:10.0564 (UTC) FILETIME=[E91C2640:01C3A3DA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 12:25:10 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks for the clarification. My comments below... -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Wednesday, November 05, 2003 11:55 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] FE model open issues If I have read this right, there are LFBs that will work this way. However, I am not sure. Let me rephrase. 1) At any time (ncluding startup) an FE has an LFB topology that is actually instantiated. For some FEs this will be initially empty, for others it will be initially populated and always the same. This is not capability information, this the actual LFB topology. [HK] I believe that during the capability discovery phase of the ForCES protocol (post-association), the FE will report the LFB graph of all possible LFBs and all possible connections. This will basically represent any constraints on the connections between LFBs. 2) Some FEs (particularly software / NPU based FEs, but also some hardware ones) have deployable components. That is, data paths may be adjusted to cause different elements to receive different packets. (Some folks will think of this as the configured equivalent of meta-data based steering.) 2') For FEs with deployable components, there should be capability infromation indicating what LFBs the FE supports, and something about how they can be interconnected. [HK] Agree, same as my point above. What you describe is a static LFB topology with service based steering among the paths (either by metadata or by classification. This will commonly happen (After all, not all packets receive the same service.) But there are other things that happen. During operation, the service owner decides to start offering a new service. If the FE supports conbfigurable LFBs, this may involve creating / instantiating / enabling new LFBs, and connecting such LFBs to existing LFBs. The owner may also decide to stop offering a service, and may cancel use of certain LFBs. Both of these might involve only changing classifiers (in static FEs) or instructing the FE to create a whole new LFB, or ... [HK] I guess my question is what do you mean by creating or instantiating LFBs ? If you mean downloading code onto FEs for new LFBs then this is out of the current scope of ForCES is my understanding. If you mean=20 activating certain paths between LFBs that we not used during the previous operational state, then you could do that at runtime using the NextLFBID metadata. This in turn is conceptually changing the Operational LFB topology, so I agree in that sense it is a topology change. However, it is not changing the Topology (constraint) graph which was=20 reported during capability discovery. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 16:52:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25925 for ; Wed, 5 Nov 2003 16:52:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVZp-00048B-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 16:52:33 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHVZo-000486-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 16:52:33 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C37FC2@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 16:52:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59493476 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 16:52:31 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 16:52:31 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5732690 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 Nov 2003 16:52:30 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031105164547.021b0418@localhost> Date: Wed, 5 Nov 2003 16:51:58 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel. com> Precedence: list A few further comments. If by "all possible LFBs and all possible connections" you mean the kind of thing in the diffserv MIB (list of supported types and supported connections) then we are in agreement. However, the phrase "the graph of all possible LFBs and all possible connections" conures up anb image of a series on graphs, one for every possible topology. I doubt you meant that, but I wanted to check. (To phrase this another way, the capabilities are a set of constraints on the possible LFB graphs. The capabilities are not themselves a graph.) By "creating" an LFB I mean causing the FE to instantiate an LFB that it supports. This could be a table entry for a subrouting (for a pure software LFB). This could be enabling and connecting up another block of FPGA for traditional FPGAs. It might be loading an FPGA block with one of a (predefined on the FE) set of definitions so as to enable a kind of LFB, if one has the types of FPGAs that have been in the news lately. I do not envision the CE providing the code for the LFB, and I do not believe anyone has asked for ForCES to support teh creation of new kinds of LFBs on an FE (as distinct from new instances of already supported kinds). One could imaging a protocol extension to support that, but I do not consider that to be within scope. Yours, Joel At 12:25 PM 11/5/2003 -0800, you wrote: >Thanks for the clarification. My comments below... > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Wednesday, November 05, 2003 11:55 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] FE model open issues > > >If I have read this right, there are LFBs that will work this >way. However, I am not sure. Let me rephrase. > >1) At any time (ncluding startup) an FE has an LFB topology that is >actually instantiated. For some FEs this will be initially empty, for >others it will be initially populated and always the same. This is not >capability information, this the actual LFB topology. > >[HK] I believe that during the capability discovery phase of the ForCES >protocol (post-association), the FE will report the LFB graph of all >possible LFBs and all possible connections. This will basically >represent >any constraints on the connections between LFBs. > >2) Some FEs (particularly software / NPU based FEs, but also some >hardware >ones) have deployable components. That is, data paths may be adjusted >to >cause different elements to receive different packets. (Some folks will >think of this as the configured equivalent of meta-data based steering.) >2') For FEs with deployable components, there should be capability >infromation indicating what LFBs the FE supports, and something about >how >they can be interconnected. > >[HK] Agree, same as my point above. > >What you describe is a static LFB topology with service based steering >among the paths (either by metadata or by classification. This will >commonly happen (After all, not all packets receive the same service.) > >But there are other things that happen. During operation, the service >owner decides to start offering a new service. If the FE supports >conbfigurable LFBs, this may involve creating / instantiating / enabling >new LFBs, and connecting such LFBs to existing LFBs. The owner may also >decide to stop offering a service, and may cancel use of certain >LFBs. Both of these might involve only changing classifiers (in static >FEs) or instructing the FE to create a whole new LFB, or ... > >[HK] I guess my question is what do you mean by creating or >instantiating >LFBs ? If you mean downloading code onto FEs for new LFBs then this is >out of the current scope of ForCES is my understanding. If you mean >activating certain paths between LFBs that we not used during the >previous >operational state, then you could do that at runtime using the NextLFBID >metadata. This in turn is conceptually changing the Operational LFB >topology, >so I agree in that sense it is a topology change. >However, it is not changing the Topology (constraint) graph which was >reported during capability discovery. > >Yours, >Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 18:13:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29989 for ; Wed, 5 Nov 2003 18:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWqo-0005Qm-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 18:14:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHWqn-0005Qj-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 18:14:09 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C38204@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 18:14:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59500537 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 18:14:08 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 18:14:08 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hA5NE8h72430 for ; Wed, 5 Nov 2003 18:14:08 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hA5NE8F14182 for ; Wed, 5 Nov 2003 18:14:08 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id SAA21580 for ; Wed, 5 Nov 2003 18:14:07 -0500 (EST) References: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1068074047.13316.98.camel@empress.torrentnet.com> Date: Wed, 5 Nov 2003 18:14:07 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IP Infrastructures Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hormuzd, See my comments below. (I see that Joel has answered in the meantime, but I decided to send this anyway.) On Wed, 2003-11-05 at 15:25, Khosravi, Hormuzd M wrote: > Thanks for the clarification. My comments below... > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Wednesday, November 05, 2003 11:55 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] FE model open issues > > > If I have read this right, there are LFBs that will work this > way. However, I am not sure. Let me rephrase. > > 1) At any time (ncluding startup) an FE has an LFB topology that is > actually instantiated. For some FEs this will be initially empty, for > others it will be initially populated and always the same. This is not > capability information, this the actual LFB topology. > > [HK] I believe that during the capability discovery phase of the ForCES > protocol (post-association), the FE will report the LFB graph of all > possible LFBs and all possible connections. This will basically > represent > any constraints on the connections between LFBs. I don't think this is feasible for the generic case. If the FE is very rigid, the above approach may work to describe the "maximum" configuration. But, in a very programmable FE (where a large set of LFBs classes can be instantiated and configured in almost arbitrary topologies) the above approach does not work. We need to come up with a scheme that can provide for both of these extremes. We have to keep in mind, that the capability description does not have to be perfect; we can leave some details to the try-and-fail feedback. > > 2) Some FEs (particularly software / NPU based FEs, but also some > hardware > ones) have deployable components. That is, data paths may be adjusted > to > cause different elements to receive different packets. (Some folks will > think of this as the configured equivalent of meta-data based steering.) > 2') For FEs with deployable components, there should be capability > infromation indicating what LFBs the FE supports, and something about > how > they can be interconnected. > > [HK] Agree, same as my point above. > > What you describe is a static LFB topology with service based steering > among the paths (either by metadata or by classification. This will > commonly happen (After all, not all packets receive the same service.) > > But there are other things that happen. During operation, the service > owner decides to start offering a new service. If the FE supports > conbfigurable LFBs, this may involve creating / instantiating / enabling > new LFBs, and connecting such LFBs to existing LFBs. The owner may also > decide to stop offering a service, and may cancel use of certain > LFBs. Both of these might involve only changing classifiers (in static > FEs) or instructing the FE to create a whole new LFB, or ... > > [HK] I guess my question is what do you mean by creating or > instantiating > LFBs ? If you mean downloading code onto FEs for new LFBs then this is > out of the current scope of ForCES is my understanding. If you mean > activating certain paths between LFBs that we not used during the > previous > operational state, then you could do that at runtime using the NextLFBID > metadata. > This in turn is conceptually changing the Operational LFB > topology, > so I agree in that sense it is a topology change. > However, it is not changing the Topology (constraint) graph which was > reported during capability discovery. > Since when does the topology graph represent *constraint* rather than the actual current topology? Maybe I missed some conversation? > Yours, > Joel M. Halpern -- Zsolt Haraszti Tel: +1 919 472 9949 Ericsson IP Infrastructure Fax: +1 919 472 9999 Raleigh NC USA Email: Zsolt.Haraszti@ericsson.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 19:00:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02172 for ; Wed, 5 Nov 2003 19:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXZt-0006Bt-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 19:00:45 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHXZt-0006Bq-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 19:00:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C382AA@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 19:00:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59505255 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 19:00:43 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 19:00:43 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA600iTd023446 for ; Thu, 6 Nov 2003 00:00:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA5Nxtak016082 for ; Thu, 6 Nov 2003 00:00:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110516004329893 for ; Wed, 05 Nov 2003 16:00:43 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 16:00:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] FE model open issues Thread-Index: AcOj5yZTMbWoy8QZS2Sh4UK+Y5c05wABaojg X-OriginalArrivalTime: 06 Nov 2003 00:00:43.0133 (UTC) FILETIME=[058592D0:01C3A3F9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A433B4@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 16:00:42 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Joel My comments below... Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Wednesday, November 05, 2003 1:52 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] FE model open issues A few further comments. If by "all possible LFBs and all possible connections" you mean the kind of thing in the diffserv MIB (list of supported types and supported connections) then we are in agreement. However, the phrase "the graph of all possible LFBs and all possible connections" conures up anb image of a series on graphs, one for every possible topology. I doubt you meant that, but I wanted to check. (To phrase this another way, the capabilities are a set of constraints on the possible LFB graphs. The capabilities are not themselves a graph.) [HK] Yes, I think this is where there is a subtle difference. I see the Capabilities as being a graph of LFBs based on the possible constraints, which are currently already instantiated on the FE. I thought that is what was exchanged during the post-association phase. I had in mind some capability exchange during pre-association which might be along the lines of what your suggesting or even more high level than that. (For e.g., an FE might say that it can do IPv4 fwd & DiffServ QoS) During post-association, I assume that an FE will already have LFB instantiated and their instance IDs will be reported as part of the capability graph. Now the CE can configure whatever LFB instances it wants, to perform the particular services without having to change the capability graph(s). By "creating" an LFB I mean causing the FE to instantiate an LFB that it supports. This could be a table entry for a subrouting (for a pure software LFB). This could be enabling and connecting up another block of FPGA for traditional FPGAs. It might be loading an FPGA block with one of a (predefined on the FE) set of definitions so as to enable a kind of LFB, if one has the types of FPGAs that have been in the news lately. I do not envision the CE providing the code for the LFB, and I do not believe anyone has asked for ForCES to support teh creation of new kinds of LFBs on an FE (as distinct from new instances of already supported kinds). One could imaging a protocol extension to support that, but I do not consider that to be within scope. [HK] So we are on the same page here. FE instantiates LFBs, FE assigns the instance IDs to LFBs, so LFB IDs are unique on a per FE basis. FE reports the LFB instance IDs to CE, the CE does not instantiate LFBs. Now the CE can may be enable, disable LFBs, but what does that really mean at runtime or post-association ? Isnt this something which will happen during pre-association or when the FE is down and not in service ? Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 21:53:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07115 for ; Wed, 5 Nov 2003 21:53:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHaHO-0000Zd-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 21:53:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHaHN-0000ZZ-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 21:53:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C3853D@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 21:53:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59516744 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 21:53:47 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 21:53:47 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA62rlTd032459 for ; Thu, 6 Nov 2003 02:53:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA62qsaj015106 for ; Thu, 6 Nov 2003 02:53:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110518534632636 for ; Wed, 05 Nov 2003 18:53:46 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Nov 2003 18:53:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: LFB topology reconfguration Thread-Index: AcOkD4yJ6Yk8cmsgRtCY4Bcmyf+dKgAAWlYw X-OriginalArrivalTime: 06 Nov 2003 02:53:46.0861 (UTC) FILETIME=[32B4B9D0:01C3A411] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEC3@orsmsx410.jf.intel.com> Date: Wed, 5 Nov 2003 18:53:46 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Oops ... forgot to cc to the list. Too late into the night :-) > -----Original Message----- > From: Yang, Lily L =20 > Sent: Wednesday, November 05, 2003 6:42 PM > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. Halpern'; = Deleganes, Ellen M; 'Jamal Hadi Salim' > Subject: LFB topology reconfguration >=20 > Some clarifications: > 1) LFB topology (the "graph") reprensents state, not capability. > 2) There are different ways to represent topology capability. One way = is to list all the possible graphs and name them up front. Then to = reconfigure the LFB topology is to switch between the different graphs. = Another way is to describe the linkage constraint (like LFB A can only = be followed by LFB B and C but not D). We can argue which is more = flexible, efficient etc later.=20 >=20 > But I still have some questions of my own.=20 > 1) How feasible & frequent it really is for an FE to change from = service A to B at runtime? I heard a few people said "yes, we do that = today". I would really like to hear a few concrete examples and = understand what is involved at the FE and CE to accomplish that. I don't = consider recompiling codes as dynamic run time configuration. =20 > The reason that I am asking this is that I don't want to end up = designing some feature that is cool but nobody can really uses in the = products. >=20 > 2) Is providing ability to switch between graphs flexible enough for = topology reconfiguration? I realize it is limited. But is it good = enough? >=20 > 3) Do we really want the ultimate flexibility to rearrange LFB by = adding (instantiating) new LFB instances, deleting LFB instances, or = re-connecting two LFBs (by deleting and then adding connections)? > Again, we can do this in ForCES, but only if people really see the = need/benefit of it. >=20 > 4) I imagine before you change service on FE from A to B, you probably = have to stop sending packets to this FE all together if you don't want = to have unpredictable behavior or loss of traffic temporarily. So it is = almost equivalent to take down an FE and plug in a new one later, isn't = it?=20 >=20 > 5) For those of you who are invovled in NPF -- Is NPF supporting = dynamic LFB topology? We want to align ForCES and NPF to the same = direction. >=20 > Lily From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 21:55:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07184 for ; Wed, 5 Nov 2003 21:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHaJa-0000b9-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 21:56:06 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHaJZ-0000b6-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 21:56:05 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C384E8@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 21:56:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59516810 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 21:56:04 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 21:56:04 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hA640Zw16880 for ; Wed, 5 Nov 2003 20:00:35 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Wed, 5 Nov 2003 20:00:34 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0A433B4@orsmsx410.jf.intel.com> Precedence: list On Wed, 5 Nov 2003, Khosravi, Hormuzd M wrote: > [HK] So we are on the same page here. FE instantiates LFBs, FE assigns > the instance IDs to LFBs, so LFB IDs are unique on a per FE basis. > FE reports the LFB instance IDs to CE, the CE does not instantiate LFBs. The request for a policy comes from the CE. That request results in instantiation out of a LFB class at the FE. The CE could request for a specific LFB instance id to be instatianted on an FE. I would think if no specific instance ID is requested then the FE would allocate say the next available index. > Now the CE can may be enable, disable LFBs, but what does that really > mean at runtime or post-association ? Isnt this something which will > happen > during pre-association or when the FE is down and not in service ? I think you may be thinking too hard on fixed feature LFBs i.e FEs which can only connect LFBs in a certain topology and can never have new LFBs "created". If you think more general, then factor in ability to express that an LFB instance that can connect to any other LFB instance; some of these graphs may not make sense. Intelligence of what topology doesnt make sense resides on the CE. i.e if you create a nonsensical service its your fault. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 22:59:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08838 for ; Wed, 5 Nov 2003 22:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbJE-0001ME-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 22:59:48 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHbJE-0001MB-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 22:59:48 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C385D2@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 22:59:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59521917 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 22:59:44 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 22:59:44 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5733280 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 Nov 2003 22:59:44 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031105225522.020d1e50@localhost> Date: Wed, 5 Nov 2003 22:59:28 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CAEC2@orsmsx410.jf.intel. com> Precedence: list It is my opinion that changing services on the fly is quite supportable and useful. No, I do not expect the change to be fequent. But once a month is more than often enough to need support. And I would expect that many reconfigurable FEs would be able to cope with changes on the fly. A typical sequence of events might be: 1) Create / select a (new) set of LFBs for the new service. 2) Create a new output from a classifier, and connect it to the new service path 3) Add filter entries to the classifier selecting traffic to get the new service. In fact, in many cases 1 and 2 would occur based on service definition, and 3 would occur based on sales / customer provisioning. Basically, LFB topology modification is service provisioning. It is certainly not done at the same rate as customer provisioning. But it is a behavior that operators generally seek to have, and seek to have without needing to disable service delivery components. (In my experience "demand" is more accurate than seek, but your mileage may vary.) Yours, Joel At 06:41 PM 11/5/2003 -0800, you wrote: >4) I imagine before you change service on FE from A to B, you probably >have to stop sending packets to this FE all together if you don't want to >have unpredictable behavior or loss of traffic temporarily. So it is >almost equivalent to take down an FE and plug in a new one later, isn't it? From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 5 23:55:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10271 for ; Wed, 5 Nov 2003 23:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHcBk-00020e-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 23:56:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHcBk-00020b-00 for forces-archive@IETF.ORG; Wed, 05 Nov 2003 23:56:08 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C38783@cherry.ease.lsoft.com>; Wed, 5 Nov 2003 23:56:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59526776 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Nov 2003 23:56:06 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Nov 2003 23:56:06 -0400 Received: from wwm1([218.108.152.118]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm213faa19fd; Thr, 06 Nov 2003 12:54:42 +0800 References: <5.1.0.14.0.20031105225522.020d1e50@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <014801c3a422$1b9f64a0$3d19fea9@wwm1> Date: Thu, 6 Nov 2003 12:54:49 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSdtIHRoaW5raW5nIGlmIHdlIG5lZWQgdG8gY2hhbmdlIHRoZSBMRkIgdG9wb2xvZ3kgc28gYXMg dG8gc3VwcG9ydCBSU1ZQIHRvIHNldHVwIGEgDQpjb25uZWN0aW9uIGFuZCByZXNlcnZlIHJlc291 cmNlcyBmb3IgaXQ/IFRoZSBzYW1lIGlzIGZvciBEaWZmc2Vydi4gIElmIHRoZSBhbnN3ZXIgaXMg eWVzLA0Kb2J2aW91c2x5IHRoZSBMRkIgdG9wb2xvZ3kgd2lsbCBiZSBjaGFuZ2VkIGZyZXF1ZW50 bHkuIA0KIA0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClRvOiA8Rk9SQ0VTQFBF QUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA2LCAyMDAzIDEx OjU5IEFNDQpTdWJqZWN0OiBSZTogTEZCIHRvcG9sb2d5IHJlY29uZmd1cmF0aW9uDQoNCg0KPiBJ dCBpcyBteSBvcGluaW9uIHRoYXQgY2hhbmdpbmcgc2VydmljZXMgb24gdGhlIGZseSBpcyBxdWl0 ZSBzdXBwb3J0YWJsZSBhbmQNCj4gdXNlZnVsLiAgIE5vLCBJIGRvIG5vdCBleHBlY3QgdGhlIGNo YW5nZSB0byBiZSBmZXF1ZW50LiAgQnV0IG9uY2UgYSBtb250aA0KPiBpcyBtb3JlIHRoYW4gb2Z0 ZW4gZW5vdWdoIHRvIG5lZWQgc3VwcG9ydC4NCj4gDQo+IEFuZCBJIHdvdWxkIGV4cGVjdCB0aGF0 IG1hbnkgcmVjb25maWd1cmFibGUgRkVzIHdvdWxkIGJlIGFibGUgdG8gY29wZSB3aXRoDQo+IGNo YW5nZXMgb24gdGhlIGZseS4NCj4gQSB0eXBpY2FsIHNlcXVlbmNlIG9mIGV2ZW50cyBtaWdodCBi ZToNCj4gMSkgQ3JlYXRlIC8gc2VsZWN0IGEgKG5ldykgc2V0IG9mIExGQnMgZm9yIHRoZSBuZXcg c2VydmljZS4NCj4gMikgQ3JlYXRlIGEgbmV3IG91dHB1dCBmcm9tIGEgY2xhc3NpZmllciwgYW5k IGNvbm5lY3QgaXQgdG8gdGhlIG5ldyBzZXJ2aWNlDQo+IHBhdGgNCj4gMykgQWRkIGZpbHRlciBl bnRyaWVzIHRvIHRoZSBjbGFzc2lmaWVyIHNlbGVjdGluZyB0cmFmZmljIHRvIGdldCB0aGUgbmV3 DQo+IHNlcnZpY2UuDQo+IA0KPiBJbiBmYWN0LCBpbiBtYW55IGNhc2VzIDEgYW5kIDIgd291bGQg b2NjdXIgYmFzZWQgb24gc2VydmljZSBkZWZpbml0aW9uLCBhbmQNCj4gMyB3b3VsZCBvY2N1ciBi YXNlZCBvbiBzYWxlcyAvIGN1c3RvbWVyIHByb3Zpc2lvbmluZy4NCj4gDQo+IEJhc2ljYWxseSwg TEZCIHRvcG9sb2d5IG1vZGlmaWNhdGlvbiBpcyBzZXJ2aWNlIHByb3Zpc2lvbmluZy4gIEl0IGlz DQo+IGNlcnRhaW5seSBub3QgZG9uZSBhdCB0aGUgc2FtZSByYXRlIGFzIGN1c3RvbWVyIHByb3Zp c2lvbmluZy4gIEJ1dCBpdCBpcyBhDQo+IGJlaGF2aW9yIHRoYXQgb3BlcmF0b3JzIGdlbmVyYWxs eSBzZWVrIHRvIGhhdmUsIGFuZCBzZWVrIHRvIGhhdmUgd2l0aG91dA0KPiBuZWVkaW5nIHRvIGRp c2FibGUgc2VydmljZSBkZWxpdmVyeSBjb21wb25lbnRzLiAgKEluIG15IGV4cGVyaWVuY2UgImRl bWFuZCINCj4gaXMgbW9yZSBhY2N1cmF0ZSB0aGFuIHNlZWssIGJ1dCB5b3VyIG1pbGVhZ2UgbWF5 IHZhcnkuKQ0KPiANCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IEF0IDA2OjQxIFBNIDExLzUvMjAw MyAtMDgwMCwgeW91IHdyb3RlOg0KPiA+NCkgSSBpbWFnaW5lIGJlZm9yZSB5b3UgY2hhbmdlIHNl cnZpY2Ugb24gRkUgZnJvbSBBIHRvIEIsIHlvdSBwcm9iYWJseQ0KPiA+aGF2ZSB0byBzdG9wIHNl bmRpbmcgcGFja2V0cyB0byB0aGlzIEZFIGFsbCB0b2dldGhlciBpZiB5b3UgZG9uJ3Qgd2FudCB0 bw0KPiA+aGF2ZSB1bnByZWRpY3RhYmxlIGJlaGF2aW9yIG9yIGxvc3Mgb2YgdHJhZmZpYyB0ZW1w b3JhcmlseS4gU28gaXQgaXMNCj4gPmFsbW9zdCBlcXVpdmFsZW50IHRvIHRha2UgZG93biBhbiBG RSBhbmQgcGx1ZyBpbiBhIG5ldyBvbmUgbGF0ZXIsIGlzbid0IGl0Pw0KPiA= From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 00:11:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10924 for ; Thu, 6 Nov 2003 00:11:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHcRF-0002I0-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 00:12:09 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHcRF-0002Hu-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 00:12:09 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C3890F@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 0:08:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59528386 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 00:06:59 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 00:03:14 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5733364 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 06 Nov 2003 00:03:15 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031105225522.020d1e50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031106000033.020c37d0@localhost> Date: Thu, 6 Nov 2003 00:02:58 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <014801c3a422$1b9f64a0$3d19fea9@wwm1> Precedence: list My guess is that 1) To assign a subset of customer traffic to an existing DiffServ service will not require LFB reconfiguration on almost any FE. 2) To deploy a new DiffServ service to be used by customers will require reconfiguration on many FEs. 3) To accept an RSVP request and assign resources to a flow in an RSVP capable FE configuration will likely not require any LFB reconfiguration. 4) To enable RSVP support on an LFB that was not used for it (but has the necessary capabilities) will require LFB reconfiguration on many FEs. Yours, Joel M. Halpern At 12:54 PM 11/6/2003 +0800, you wrote: >I'm thinking if we need to change the LFB topology so as to support RSVP >to setup a >connection and reserve resources for it? The same is for Diffserv. If the >answer is yes, >obviously the LFB topology will be changed frequently. > >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Thursday, November 06, 2003 11:59 AM >Subject: Re: LFB topology reconfguration > > > > It is my opinion that changing services on the fly is quite supportable and > > useful. No, I do not expect the change to be fequent. But once a month > > is more than often enough to need support. > > > > And I would expect that many reconfigurable FEs would be able to cope with > > changes on the fly. > > A typical sequence of events might be: > > 1) Create / select a (new) set of LFBs for the new service. > > 2) Create a new output from a classifier, and connect it to the new service > > path > > 3) Add filter entries to the classifier selecting traffic to get the new > > service. > > > > In fact, in many cases 1 and 2 would occur based on service definition, and > > 3 would occur based on sales / customer provisioning. > > > > Basically, LFB topology modification is service provisioning. It is > > certainly not done at the same rate as customer provisioning. But it is a > > behavior that operators generally seek to have, and seek to have without > > needing to disable service delivery components. (In my experience "demand" > > is more accurate than seek, but your mileage may vary.) > > > > Yours, > > Joel > > > > At 06:41 PM 11/5/2003 -0800, you wrote: > > >4) I imagine before you change service on FE from A to B, you probably > > >have to stop sending packets to this FE all together if you don't want to > > >have unpredictable behavior or loss of traffic temporarily. So it is > > >almost equivalent to take down an FE and plug in a new one later, > isn't it? > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 00:19:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11147 for ; Thu, 6 Nov 2003 00:19:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHcY7-0002Pt-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 00:19:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHcY7-0002Pq-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 00:19:15 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C38A9E@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 0:19:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59537395 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 00:19:14 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 00:19:08 -0400 Received: from wwm1([218.108.152.118]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm3a3faa1f54; Thr, 06 Nov 2003 13:17:29 +0800 References: <9CB758BBEE58754F8F33234D75B9F4B0A4330C@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <014e01c3a425$4a0bac10$3d19fea9@wwm1> Date: Thu, 6 Nov 2003 13:17:35 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgSG9ybXV6ZCwNCg0KTXkgdW5kZXJzdGFuZGluZyBvZiBlbmNvZGVkIHN0YXRlIGFwcHJvYWNo IGlzIG9ubHkgYSB3YXkgdG8gcmVwcmVzZW50IHRoZSBkYXRhcGF0aHMNCmluc3RlYWQgb2YgdGhl IHRvcG9sb2d5LiBUaGF0IGlzLCB0aGUgbWV0YWRhdGEgaW4gaXQgaXMgb25seSByZWFkIGJ5IGZv bGxvd2VkIExGQnMgaW5zdGVhZCANCm9mIGJ5IG90aGVycy4gSWYgdGhlIGluZm9ybWF0aW9uIGxp a2UgIk5leHRMRkJJRCIgaXMgYWxsb3dlZCBpbiB0aGUgbWV0YWRhdGEsIGl0IG1heSBpbXBseQ0K dGhlcmUgaXMgYSBzd2l0Y2ggZmFicmljIGJldHdlZW4gdGhlIExGQnMgdGhhdCByZWFkcyB0aGUg aW5mbyBzbyBhcyB0byBzd2l0Y2ggdG8gdGhlIGRlc2lyZWQgTEZCIA0KKGJhc2VkIG9uIHBlciBw YWNrZXQgc3BlZWQpLiBJIHRoaW5rIHRoZSAiTmV4dExGQklEIiBpbmZvIGNhbiBiZSB0b2xkIHRv IHRoZSBMRkIsIGJ1dCBub3QgaW4gbWV0YWRhdGEgDQptb2RlLiBXaGVuIHdlIHRlbGwgdGhlIExG QiBvbiB0aGlzLCB3ZSBhY3R1YWxseSBkbyB0aGUgdG9wb2xvZ3kgY29uZmlndXJhdGlvbiwgd2hp Y2ggaXMgcXVpdGUgDQppZGVudGljYWwgdG8gd2hhdCBQa2ZJRHMgZG8uIA0KDQpSZWdhcmRzLA0K V2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIktob3NyYXZp LCBIb3JtdXpkIE0iIDxob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tPg0KVG86IDxGT1JDRVNA UEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDYsIDIwMDMg Mzo0NSBBTQ0KU3ViamVjdDogUmU6IEZFIG1vZGVsIG9wZW4gaXNzdWVzDQoNCg0KSGkgSm9lbA0K DQpMZXQgbWUgdHJ5IHRvIGV4cGxhaW4gd2hhdCBJIGFtIHRoaW5raW5nIGhlcmUgYW5kIGxldCBt ZSBrbm93IGlmIHlvdQ0KYWdyZWUuDQoNCkFuIEZFIGluaXRpYWxseSByZXBvcnRzIGl0cyBMRkIg dG9wb2xvZ3kgdG8gdGhlIENFLiBUaGlzIGlzIHRoZQ0KY2FwYWJpbGl0eQ0KZ3JhcGggd2hpY2gg aW5jbHVkZXMgYWxsIHRoZSBwb3NzaWJsZSBMRkJzIGFuZCBwYXRocyBjb25uZWN0aW5nIHRoZSBM RkJzDQoNCnRoYXQgYW4gRkUgY2FuIGhhbmRsZSAoYWNjIHRvIGl0cyBpbXBsZW1lbnRhdGlvbiku IE5vdyB0aGlzIHRvcG9sb2d5DQptaWdodA0KZXhwcmVzcyBtdWx0aXBsZSBzZXJ2aWNlcyB0aGF0 IGEgRkUgaW1wbGVtZW50cy4gRm9yIGV4YW1wbGUsDQoNClNheSB0aGlzIGlzIHRoZSBGRSBDYXBh YmlsaXR5IGdyYXBoIChMRkIgdG9wb2xvZ3kpIHdoaWNoIGlzIHJlcG9ydGVkIA0KZHVyaW5nIGNh cGFiaWxpdHkgZGlzY292ZXJ5Lg0KDQogICAgfC0tfA0KICAgIHwgIHwtLT58QnwtLT58Q3wtLT58 RHwtLXwNCi0tLT58QSB8ICAgICAgICAgICAgICAgICAgICB8LS0tPnxIfC0tPg0KICAgIHwgIHwt LT58RXwtLT58RnwtLT58R3wtLXwNCiAgICB8LS18DQoNCk5vdywgcGF0aHMgQS0+Qi0+Qy0+RC0+ SCBtaWdodCBwZXJmb3JtIFNlcnZpY2UgMSBhbmQgcGF0aHMgQS0+RS0+Ri0+Ry0+SA0KbWlnaHQg cGVyZm9ybSBTZXJ2aWNlIDIuIE5vdyBhdCBydW50aW1lIHlvdSBuZWVkIHRoZSBhYmlsaXR5IHRv IGRpcmVjdA0KcGFja2V0cw0Kb3IgZmxvd3MgdGhyb3VnaCBlaXRoZXIgb2YgdGhlc2UgZGlmZmVy ZW50IHBhdGhzIGluIHRoZSBGRS4gWW91IGNhbiBkbw0KdGhpcw0KYnkgdXNpbmcgdGhlIGVuY29k ZWQgc3RhdGUgYXBwcm9hY2ggaW4gd2hpY2ggeW91IHdpbGwgZGVmaW5lIGEgbWV0YWRhdGENCmxp a2UNCnRoZSAiTmV4dExGQklEIiB3aGljaCB3aWxsIHNwZWNpZnkgd2hhdCBpcyB0aGUgbmV4dCBi bG9jayBvciBMRkIuIA0KRm9yIGV4YW1wbGUsIHdoZW4geW91IGNvbmZpZ3VyZSBMRkIgQSBpbiB0 aGUgZmlndXJlIGFib3ZlLCB5b3Ugd2lsbA0Kc3BlY2lmeSANCmluIGl0cyBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uIHdoYXQgc2hvdWxkIGJlIHRoZSBOZXh0TEZCSUQgKEIgb3IgRSkuDQoNCklm IHlvdSB1c2UgdGhpcyBhcHByb2FjaCwgdGhlbiB5b3UgZG8gbm90IG5lZWQgdG8gcmVjb25maWd1 cmUgdGhlIExGQg0KdG9wb2xvZ3kNCmF0IHJ1bnRpbWUsIHlvdSBqdXN0IHVzZSBhIHR5cGUgb2Yg Z2VuZXJpYyBtZXRhZGF0YSAiTmV4dExGQklEIiB0bw0KZHluYW1pY2FsbHkNCmNoYW5nZSB0aGUg cGF0aHMuIFRoZSBvbmx5IHRpbWUgdGhhdCB5b3Ugd2lsbCBuZWVkIHRvIGNoYW5nZSBhbnkgTEZC DQp0b3BvbG9neQ0KYXQgcnVudGltZSB3aWxsIGJlIGlmIHlvdSBhcmUgZHluYW1pY2FsbHkgZG93 bmxvYWRpbmcgY29kZSBvbiB0aGUgRkUgZm9yDQphbg0KTEZCIHdoaWNoIGlzIGN1cnJlbnRseSBv dXQgb2YgdGhlIHNjb3BlIG9mIEZvckNFUyBhbmQgYWxzbyB0aGVyZSBhcmUgbm8NCmNvbW1lcmNp YWxseSBzaGlwcGluZyBwcm9kdWN0cyB3aGljaCBzdXBwb3J0IHRoaXMuDQoNCkRvZXMgdGhhdCBt YWtlIHNlbnNlID8gSG9wZSB0aGlzIGhlbHBzLA0KDQpUaGFua3MNCkhvcm11emQNClAucy4gQlRX LCB0aGlzIGlzIGFsc28gdGhlIGN1cnJlbnQgdGhpbmtpbmcgaW4gdGhlIE5QRiBhcyByZWdhcmRz DQp0b3BvbG9neS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZvcndhcmRp bmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uDQpbbWFpbHRvOkZPUkNFU0BQRUFDSC5F QVNFLkxTT0ZULkNPTV0gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAwNSwgMjAwMyA5OjI4IEFNDQpUbzogRk9SQ0VTQFBFQUNILkVBU0UuTFNP RlQuQ09NDQpTdWJqZWN0OiBSZTogW0ZPUkNFU10gRkUgbW9kZWwgb3BlbiBpc3N1ZXMNCg0KDQpU aGVyZSB3aWxsIGNlcnRhaW5seSBiZSBGRXMgd2hvc2UgaW50ZXJuYWwgTEZCIHRvcG9sb29neSBp cyBzdGF0aWMgb3INCm5lYXJseSBzdGF0aWMuICBUaGVyZSB3aWxsIGJlIEZFcyB3aG9zZSBvbmx5 ICJhZGp1c3RhYmlsaXR5IiBpcyBpbiB0aGUNCm1ldGFkYXRhLiAgVGhlcmUgd2lsbCBhbHNvIGJl IEZFcyB3aGVyZSBMRkJzIGNhbiBiZSBzZWxlY3RlZCB0byBiZSB1c2VkDQppbg0KZGlmZmVyZW50 IGRhdGEgcGF0aHMsIGFuZCBzZXJ2aWNlcyBjcmVhdGVkIGluIGEgbW9yZSBkeW5hbWljIGZhc2hp b24uDQpUaGUNCm1vc3QgY2FwYWJsZSBGRXMgd2lsbCBoYXZlIGFuIGV4dHJlbWVseSBmbGV4aWJs ZSB0b3BvbG9neSB3aGVyZSBtb3N0IGFueQ0KTEZCIGNhbiBvY2N1ciBhbnl3aGVyZS4NCg0KT25l IGNvdWxkIGFyZ3VlIHRoYXQgZm9yIHRoZSBmaXJzdCByZWxlYXNlIHdlIHNob3VsZCBzdXBwb3J0 IG9ubHkgc3RhdGljDQp0b3BvbG9neS4gIEJhc2VkIG9uIGV4cGVyaWVuY2UsIEkgZmVlbCB0aGF0 IGlzIHRvbyBsaW1pdGluZy4gIEhlbmNlLCBJDQp3b3VsZCBsaWtlIHRvIHNlZSB0aGUgcHJvdG9j b2wgaW5jbHVkZSAgbWVjaGFuaXNtcyBmb3IgImNyZWF0aW5nIiBMRkJzDQphbmQNCmNvbm5lY3Rp bmcgdGhlbSB0byBvdGhlciBMRkJzIGluIHRoZSBGRS4gICBUaGlzIGlzIG5vdCBwcmltYXJpbHkg dG8NCnN1cHBvcnQNCnRoZSBibGFuayBzaGVldCBtb2RlbCAoYWx0aG91Z2ggdGhhdCB3aWxsIGhh cHBlbiB0byBiZSBzdXBwb3J0YWJsZSkgYnV0DQp0bw0Kc3VwcG9ydCB0aGUgbGFyZ2UgcmFuZ2Ug b2YgRkVzIHdpdGggc29tZSBhZGp1c3RhYmlsaXR5IGluIHRoZSBMRkINCnRvcG9sb2d5Lg0KDQpU aGUgY29uc2VxdWVuY2Ugb2YgY291cnNlIGlzIHRoYXQgdGhlIENFIG11c3QgYmUgcHJlcGFyZWQg dG8gaGF2ZSBpdHMNCmF0dGVtcHQgdG8gYWRqdXN0IHRoZSB0b3BvbG9neSBmYWlsLCBzaW5jZSBt b3N0IEZFcyB3aWxsIGhhdmUgbGltaXRzIG9uDQp0aGVpciBhZGp1c3RhYmlsaXR5LiAgVGhpcyBp cyBsYXJnZWx5IGluZXZpdGFibGUuICBJZiBhIENFIGlzIHRyeWluZyB0bw0KaW5zdGFsbCBhIHNl cnZpY2UsIHRoZSBGRSBtaWdodCBub3QgYmUgYWJsZSB0byBkZWxpdmVyIGl0ICAodGhlDQpjYXBh YmlsaXRpZXMgaW5mb3JtYXRpb24gaXMgYWJvdXQgaGVscGluZyB0aGUgQ0UgaGF2ZSBpbmZvcm1h dGlvbiB0bw0KanVkZ2UNCndoZXRoZXIgYW5kIGhvdyB0byBjb25maWd1cmUgdGhlIHNlcnZpY2Ug b24gYSBnaXZlbiBGRS4pICBSZWxhdGVkIHRvDQp0aGlzLA0KYXMgd2Ugc2F5IGluIHRoZSBkb2N1 bWVudHMsIHNvbWUgb2YgdGhlIG1hcHBpbmcgcmVxdWlyZXMgaHVtYW4NCmludGVsbGlnZW5jZQ0K YW5kIHdpbGwgbm90IHdvcmsgd2l0aG91dCBhIHBlcnNvbiBpbiB0aGUgbG9vcC4NCg0KSm9lbA0K DQpBdCAwOToxMiBBTSAxMS81LzIwMDMgLTA4MDAsIHlvdSB3cm90ZToNCj5TdWJqZWN0OiBSZTog RkUgbW9kZWwgb3BlbiBpc3N1ZXMNCj5UbzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NDQo+ DQo+SW4gdGhlIG1vZGVsIGRyYWZ0IGl0IHN0YXRlczoNCj4iTEZCIHRvcG9sb2d5IHJlY29uZmln dXJhdGlvbiBpcyBjb25zaWRlcmVkIGFuIGltcG9ydGFudCBhc3BlY3Qgb2YgdGhlDQo+RkUgbW9k ZWwuIiBJdCBzZWVtcyBsaWtlIG9uZSBvZiB0aGUgcXVlc3Rpb25zIHRoYXQgaGFzIG5vdCBiZWVu DQpyZXNvbHZlZA0KPmJ5IHRoZSB3b3JraW5nIGdyb3VwIGlzIGhvdyBtdWNoIGR5bmFtaWMgcmVj b25maWd1cmFiaWxpdHkgaXMgcmVxdWlyZWQuDQo+QSBudW1iZXIgb2YgcG9zc2liaWxpdGllcyBo YXZlIGJlZW4gcHJvcG9zZWQgaW4gdmFyaW91cyBkcmFmdHMsIHJhbmdpbmcNCj5mcm9tIHRoZSBh YmlsaXR5IHRvIGNvbXBsZXRlbHkgcmVjb25maWd1cmUgYW4gRkUgLSBjaGFuZ2luZyB0aGUgc2Vy dmljZQ0KPmJ5IGFkZGluZy9kZWxldGluZyBMRkJzIHRvIHN1cHBvcnRpbmcgb25seSBhIGxpbWl0 ZWQgYW1vdW50IG9mDQo+cmVjb25maWd1cmFiaWxpdHkuDQo+DQo+VGhlIGFiaWxpdHkgZm9yIHRo ZSBDRSB0byB0cmVhdCB0aGUgRkUgYXMgYSBibGFuayBzaGVldCBvZiBwYXBlciBhbmQNCj5kb3du bG9hZCBMRkJzIGFuZCB0aGVpciBhc3NvY2lhdGVkIHRvcG9sb2d5IHNlZW1zIHVubmVjZXNzYXJ5 LiBJZiB0aGUNCj5nb2FsIGlzIGZvciBGb3JDRVMgdG8gZGVmaW5lIGEgcHJvdG9jb2wgdG8gYWxs b3cgQ0VzIGFuZCBGRXMgZnJvbQ0KPmRpZmZlcmVudCB2ZW5kb3JzIHRvIGludGVyb3BlcmF0ZSwg dGhpcyBzZWVtcyB0byBiZSBvdXQgb2Ygc2NvcGUgZm9yDQp0aGUNCj5Gb3JDRVMgV0cuIEkgYXNz dW1lIHRoYXQgRkVzIHdvdWxkIGhhdmUgY2FwYWJpbGl0aWVzIGJ1aWx0IGluIHRoYXQgdGhlDQo+ Q0VzIGNvdWxkIHF1ZXJ5LCBhbmQgY3VzdG9taXplIHRoZSBMRkIgYmVoYXZpb3IgYXQgcnVudGlt ZSAodGhlIGRlZ3JlZQ0KPmlzIGRlcGVuZGVudCBvbiB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgRkUp LCBidXQgbm90IHRvIGFkZCBuZXcNCj5mdW5jdGlvbmFsaXR5IGJ5IGRvd25sb2FkaW5nIExGQiBj b2RlLg0KPg0KPkknZCBhbHNvIGFyZ3VlIHRoYXQgZHluYW1pY2FsbHkgcmVjb25maWd1cmluZyBM RkIgdG9wb2xvZ3kgZG9lcyBub3QNCj5yZXF1aXJlIHRoZSBhYmlsaXR5IHRvIGFkZCBvciBkZWxl dGUgcGF0aHMsIGFzc3VtaW5nIHRoZSBhcHByb2FjaCBvZg0KPnVzaW5nIGEgY29tYmluYXRpb24g b2YgZW5jb2RlZCBzdGF0ZSBhbmQgYSB0b3BvbG9naWNhbCBncmFwaCBhcHByb2FjaA0KaXMNCj51 c2VkIHRvIG1vZGVsIHRoZSBMRkIgdG9wb2xvZ3kuIEZ1bmN0aW9uYWxpdHkgc3VjaCBhcyByZWRp cmVjdGluZw0KPnRyYWZmaWMgZmxvd3MgZHluYW1pY2FsbHkgY2FuIGJlIGhhbmRsZWQgYnkgY2hh bmdpbmcgdGhlIGVuY29kZWQgc3RhdGUsDQo+dGhlIHRvcG9sb2d5IGdyYXBoIGl0c2VsZiBpcyBz dGF0aWMuDQo+DQo+UmVnYXJkcywNCj5FbGxlbiBEZWxlZ2FuZXMNCg== From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 10:32:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13470 for ; Thu, 6 Nov 2003 10:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHm85-0002Yf-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 10:33:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHm85-0002Yc-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 10:33:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C3931F@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 10:33:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59591038 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 10:32:59 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 10:32:59 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 5A18A1F00F6 for ; Thu, 6 Nov 2003 10:32:59 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id CA4901F007B for ; Thu, 6 Nov 2003 10:32:53 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20031105225522.020d1e50@localhost> <5.1.0.14.0.20031106000033.020c37d0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FAA69A3.EDFC91CB@idt.com> Date: Thu, 6 Nov 2003 10:32:51 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > My guess is that > 1) To assign a subset of customer traffic to an existing DiffServ service > will not require LFB reconfiguration on almost any FE. ... I would tend to agree. For me, the boundary between internal changes to an LFB's configuration, and changes to inter-LFB connections is most often a protocol boundary. Provisioning new connections/services within a protocol requires updating entries in the LFB's which implement that protocol. Provisioning a new protocol requires re-arranging LFB's, or creating new LFB's. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 17:33:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05421 for ; Thu, 6 Nov 2003 17:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHshX-00028O-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 17:34:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHshW-00028K-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 17:34:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C39CA4@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 17:34:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59632365 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 17:34:00 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 17:34:00 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA6MUnmd013794 for ; Thu, 6 Nov 2003 22:30:49 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA6MS9J06261 for ; Thu, 6 Nov 2003 22:28:09 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110614335728871 for ; Thu, 06 Nov 2003 14:33:58 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Nov 2003 14:33:58 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: LFB topology reconfguration Thread-Index: AcOke4LRCn6+9qxPTZSW2FUHEnSgtQAOFVAA X-OriginalArrivalTime: 06 Nov 2003 22:33:58.0075 (UTC) FILETIME=[117A80B0:01C3A4B6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAED2@orsmsx410.jf.intel.com> Date: Thu, 6 Nov 2003 14:33:57 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Seems like most people agree that micro-change within one given service = (protocol as Alan put it) does not result in topology change. so no = argument there. Now lets look at the macro-change which invovles change of service = ("service provisiong" as Joel called it). For example, suppose FE0 supports IPv4 forwarding, DiffServ and MPLS. = But the operator only wants to use IPv4 at the beginning. Well, the FE = can still be modeled by a topology that includes all the services it is = capable of. So the CE can model the FE by a topology like this (or, FE = can just report its topology to CE): +------------------+ |classifier V out1|-----> IPv4 path (subgraph) | out2|-----> DiffServ path (subgraph) | out3|-----> MPLS path (subgraph) +------------------+ Note that each path by itself is a subgraph potentially involving = multiple LFBs and multiple datapath. Now, "classifier V" is only a virtual classifier. FE0 may not have a = classifier at all. But we use "classifier V" to model FE0's ability to = support multiple services. Now at the begining since only IPv4 is used, = CE can configure "classifier V" such that packets all go to out1 (IPv4 = path).=20 Later (like a month later), the operator want to use MPLS instead, they = can configure classifier V such that packets now flow to out3. Another month later, if they want to use both IPv4 and DiffServ, sure. But the topology remains static. Now, what if the operator wants to do IPv6, but FE0 does not support = that to begin with. Well, the operator either buys another FE (FE1) that = support IPv6, or he takes FE0 down and loads up the code to do IPv6, = plug it in, and start all over again. Remember, all we do here is just modeling the "logical" bahavior of FE = with a bunch of "logical" LFBs. I can't see why we can't model the = service provisioning this way, without the need to reconfigure LFB = topology. Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alan DeKok > Sent: Thursday, November 06, 2003 7:33 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: LFB topology reconfguration >=20 >=20 > "Joel M. Halpern" wrote: > > > > My guess is that > > 1) To assign a subset of customer traffic to an existing=20 > DiffServ service > > will not require LFB reconfiguration on almost any FE. > ... >=20 > I would tend to agree. >=20 > For me, the boundary between internal changes to an LFB's > configuration, and changes to inter-LFB connections is most often a > protocol boundary. Provisioning new connections/services within a > protocol requires updating entries in the LFB's which implement that > protocol. Provisioning a new protocol requires re-arranging LFB's, or > creating new LFB's. >=20 > Alan DeKok. >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 17:49:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06069 for ; Thu, 6 Nov 2003 17:49:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHswi-0002MW-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 17:49:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHswh-0002MT-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 17:49:43 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C39CB5@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 17:49:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59634167 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 17:49:42 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 17:49:42 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5735944 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 06 Nov 2003 17:49:41 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031106174122.021be200@localhost> Date: Thu, 6 Nov 2003 17:49:20 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CAED2@orsmsx410.jf.intel. com> Precedence: list I would argue that there is no such thing as "the diffserv path". Diffserv is a mechanism for offering a number of services. While one can have an FE that has a fixed toplogy of classifiers, markers, meters, queues and schedulers, many FEs will have some flexibility in that topology. It is quite likely that even if one could envision the topology for all possible services, there are not enough LFBs to offer them all simultaneously. So the operator picks the ones he is offering now, and uses some of the resources to offer those. As he decides to offer more services, he provisions them on the FE (via the CE) and makes them available to customers. I do not know of an operator who can determine at box installation time all the services he will offer from that platform. Equally, I do not know any operator who will be happy being told that new service offerings will requrie that he disable the box. And there seems to be no point in having some other protocol for extablishing these. Let me put it another way. Someone has to tell the FE what that initially topology ought to be. It may be fixed by the factory. If it is not fixed by the factory, it is clearly the CEs job to set it up. It is clearly desirable to be able to change that setup during operation. If the FE can support such a change, it is clearly the CEs job to make such a change. And it is not possible to enumerate all possible graphs, or all possible services. Yours, Joel M. Halpern At 02:33 PM 11/6/2003 -0800, you wrote: >Seems like most people agree that micro-change within one given service >(protocol as Alan put it) does not result in topology change. so no >argument there. > >Now lets look at the macro-change which invovles change of service >("service provisiong" as Joel called it). > >For example, suppose FE0 supports IPv4 forwarding, DiffServ and MPLS. But >the operator only wants to use IPv4 at the beginning. Well, the FE can >still be modeled by a topology that includes all the services it is >capable of. So the CE can model the FE by a topology like this (or, FE can >just report its topology to CE): >+------------------+ >|classifier V out1|-----> IPv4 path (subgraph) >| out2|-----> DiffServ path (subgraph) >| out3|-----> MPLS path (subgraph) >+------------------+ >Note that each path by itself is a subgraph potentially involving multiple >LFBs and multiple datapath. > >Now, "classifier V" is only a virtual classifier. FE0 may not have a >classifier at all. But we use "classifier V" to model FE0's ability to >support multiple services. Now at the begining since only IPv4 is used, CE >can configure "classifier V" such that packets all go to out1 (IPv4 path). > >Later (like a month later), the operator want to use MPLS instead, they >can configure classifier V such that packets now flow to out3. > >Another month later, if they want to use both IPv4 and DiffServ, sure. >But the topology remains static. > >Now, what if the operator wants to do IPv6, but FE0 does not support that >to begin with. Well, the operator either buys another FE (FE1) that >support IPv6, or he takes FE0 down and loads up the code to do IPv6, plug >it in, and start all over again. > >Remember, all we do here is just modeling the "logical" bahavior of FE >with a bunch of "logical" LFBs. I can't see why we can't model the service >provisioning this way, without the need to reconfigure LFB topology. > >Lily > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alan DeKok > > Sent: Thursday, November 06, 2003 7:33 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: LFB topology reconfguration > > > > > > "Joel M. Halpern" wrote: > > > > > > My guess is that > > > 1) To assign a subset of customer traffic to an existing > > DiffServ service > > > will not require LFB reconfiguration on almost any FE. > > ... > > > > I would tend to agree. > > > > For me, the boundary between internal changes to an LFB's > > configuration, and changes to inter-LFB connections is most often a > > protocol boundary. Provisioning new connections/services within a > > protocol requires updating entries in the LFB's which implement that > > protocol. Provisioning a new protocol requires re-arranging LFB's, or > > creating new LFB's. > > > > Alan DeKok. > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 18:14:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07742 for ; Thu, 6 Nov 2003 18:14:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtKn-0002dg-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 18:14:37 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHtKn-0002dd-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 18:14:37 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C39DA6@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 18:14:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59637110 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 18:14:36 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 18:14:36 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA6NEZOf007458 for ; Thu, 6 Nov 2003 17:14:35 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <26BDFAFFB541B047B24179002EBE6D278CAEC3@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FAAD5DA.5CF8AD9F@alcatel.com> Date: Thu, 6 Nov 2003 17:14:34 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Lily, Not only service change from A to B, but also, service level maintenance within some constraints falls within bounds in my view. For example, one may want to maintain a certain level of QoS which may require some sort of feedback process to dynamically bring in more resources (LFBs) to make up for increased demands, or loss of resources in some other NE. This sort of change may need to take place much more often than the once-in-a-while service change. Regards, Alex. "Yang, Lily L" wrote: > Oops ... forgot to cc to the list. Too late into the night :-) > > > -----Original Message----- > > From: Yang, Lily L > > Sent: Wednesday, November 05, 2003 6:42 PM > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > Subject: LFB topology reconfguration > > > > Some clarifications: > > 1) LFB topology (the "graph") reprensents state, not capability. > > 2) There are different ways to represent topology capability. One way is to list all the possible graphs and name them up front. Then to reconfigure the LFB topology is to switch between the different graphs. Another way is to describe the linkage constraint (like LFB A can only be followed by LFB B and C but not D). We can argue which is more flexible, efficient etc later. > > > > But I still have some questions of my own. > > 1) How feasible & frequent it really is for an FE to change from service A to B at runtime? I heard a few people said "yes, we do that today". I would really like to hear a few concrete examples and understand what is involved at the FE and CE to accomplish that. I don't consider recompiling codes as dynamic run time configuration. > > The reason that I am asking this is that I don't want to end up designing some feature that is cool but nobody can really uses in the products. > > > > 2) Is providing ability to switch between graphs flexible enough for topology reconfiguration? I realize it is limited. But is it good enough? > > > > 3) Do we really want the ultimate flexibility to rearrange LFB by adding (instantiating) new LFB instances, deleting LFB instances, or re-connecting two LFBs (by deleting and then adding connections)? > > Again, we can do this in ForCES, but only if people really see the need/benefit of it. > > > > 4) I imagine before you change service on FE from A to B, you probably have to stop sending packets to this FE all together if you don't want to have unpredictable behavior or loss of traffic temporarily. So it is almost equivalent to take down an FE and plug in a new one later, isn't it? > > > > 5) For those of you who are invovled in NPF -- Is NPF supporting dynamic LFB topology? We want to align ForCES and NPF to the same direction. > > > > Lily From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 20:25:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11470 for ; Thu, 6 Nov 2003 20:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvNW-000463-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:25:34 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHvNW-000460-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:25:34 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C3A066@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 20:25:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59648945 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 20:25:34 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 20:25:34 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA71MMmd029962 for ; Fri, 7 Nov 2003 01:22:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA71JgY20896 for ; Fri, 7 Nov 2003 01:19:42 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110617252912837 for ; Thu, 06 Nov 2003 17:25:29 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Nov 2003 17:25:29 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: LFB topology reconfguration Thread-Index: AcOkuErtQKy+pVkWS+qrGt1L1HUtXwABWrow X-OriginalArrivalTime: 07 Nov 2003 01:25:29.0516 (UTC) FILETIME=[07A7C6C0:01C3A4CE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190B38@orsmsx410.jf.intel.com> Date: Thu, 6 Nov 2003 17:25:29 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable It seems like what is being proposed here is for the case of a very generic FE that contains a lot of different kinds of LFBs, and the services that can be supported depend on the topology configured for those LFBs (or various subsets of the LFBs). In this case, I can see where expressing all of the possible topologies might not be feasible. However, in the case where all possible (or even reasonable) topologies for all of the services cannot be expressed, the operator must be aware of what the FE is capable of supporting and how to configure the FE to provide the desired service. The operator may not be able to depend solely on the FE protocol to determine its capabilities and the configuration that is required in order to support such a capability. It seems like the operator may need to use some vendor-supplied tools to add a service or new capability to a service. In this case, I'm not sure how much sense it makes to have a generic protocol. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, November 06, 2003 2:49 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: LFB topology reconfguration I would argue that there is no such thing as "the diffserv path". Diffserv is a mechanism for offering a number of services. While one can have an FE that has a fixed toplogy of classifiers, markers, meters, queues and schedulers, many FEs will have some flexibility in that topology. It is quite likely that even if one could envision the topology for all possible services, there are not enough LFBs to offer them all simultaneously. So the operator picks the ones he is offering now, and uses some of the resources to offer those. As he decides to offer more services, he provisions them on the FE (via the CE) and makes them available to customers. I do not know of an operator who can determine at box installation time all the services he will offer from that platform. Equally, I do not know any operator who will be happy being told that new service offerings will requrie that he disable the box. And there seems to be no point in having some other protocol for extablishing these. Let me put it another way. Someone has to tell the FE what that initially topology ought to be. It may be fixed by the factory. If it is not fixed by the factory, it is clearly the CEs job to set it up. It is clearly desirable to be able to change that setup during operation. If the FE can support such a change, it is clearly the CEs job to make such a change. And it is not possible to enumerate all possible graphs, or all possible services. Yours, Joel M. Halpern At 02:33 PM 11/6/2003 -0800, you wrote: >Seems like most people agree that micro-change within one given service >(protocol as Alan put it) does not result in topology change. so no >argument there. > >Now lets look at the macro-change which invovles change of service >("service provisiong" as Joel called it). > >For example, suppose FE0 supports IPv4 forwarding, DiffServ and MPLS. But >the operator only wants to use IPv4 at the beginning. Well, the FE can >still be modeled by a topology that includes all the services it is >capable of. So the CE can model the FE by a topology like this (or, FE can >just report its topology to CE): >+------------------+ >|classifier V out1|-----> IPv4 path (subgraph) >| out2|-----> DiffServ path (subgraph) >| out3|-----> MPLS path (subgraph) >+------------------+ >Note that each path by itself is a subgraph potentially involving multiple >LFBs and multiple datapath. > >Now, "classifier V" is only a virtual classifier. FE0 may not have a >classifier at all. But we use "classifier V" to model FE0's ability to >support multiple services. Now at the begining since only IPv4 is used, CE >can configure "classifier V" such that packets all go to out1 (IPv4 path). > >Later (like a month later), the operator want to use MPLS instead, they >can configure classifier V such that packets now flow to out3. > >Another month later, if they want to use both IPv4 and DiffServ, sure. >But the topology remains static. > >Now, what if the operator wants to do IPv6, but FE0 does not support that >to begin with. Well, the operator either buys another FE (FE1) that >support IPv6, or he takes FE0 down and loads up the code to do IPv6, plug >it in, and start all over again. > >Remember, all we do here is just modeling the "logical" bahavior of FE >with a bunch of "logical" LFBs. I can't see why we can't model the service >provisioning this way, without the need to reconfigure LFB topology. > >Lily > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alan DeKok > > Sent: Thursday, November 06, 2003 7:33 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: LFB topology reconfguration > > > > > > "Joel M. Halpern" wrote: > > > > > > My guess is that > > > 1) To assign a subset of customer traffic to an existing > > DiffServ service > > > will not require LFB reconfiguration on almost any FE. > > ... > > > > I would tend to agree. > > > > For me, the boundary between internal changes to an LFB's > > configuration, and changes to inter-LFB connections is most often a > > protocol boundary. Provisioning new connections/services within a > > protocol requires updating entries in the LFB's which implement that > > protocol. Provisioning a new protocol requires re-arranging LFB's, or > > creating new LFB's. > > > > Alan DeKok. > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 20:40:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11990 for ; Thu, 6 Nov 2003 20:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvc0-0004JP-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:40:32 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHvbz-0004JM-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:40:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C3A072@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 20:40:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59650092 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 20:40:31 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 20:40:31 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5736299 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 06 Nov 2003 20:40:30 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031106203711.02049b48@localhost> Date: Thu, 6 Nov 2003 20:40:13 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B38@orsmsx410.jf.intel. com> Precedence: list I believe we can represent enough about the capabilities of the FE to be useful. I would certainly agree that it would be a rare FE that could support any and all topologies possible from the LFBs it supports. I believe that using information similar to what is in the Diffserv PIB we can create a useful set of FE level and LFB level capability information. (That is, at the FE level there would be information such as whether the topology can be changed, and which LFB types can follow which other LFB types, via which ports. At the LFB level there would be information about how many of this LFB type can be in existence, how large the arrays of information within this LFB type for classifiers may be, etc.) It is true that this will not perfectly describe all capability information. That is why the document calls this a compromise. Yours, Joel At 05:25 PM 11/6/2003 -0800, you wrote: >It seems like what is being proposed here is for the case of a very >generic FE that contains a lot of different kinds of LFBs, and the >services that can be supported depend on the topology configured for >those LFBs (or various subsets of the LFBs). In this case, I can see >where expressing all of the possible topologies might not be feasible. > >However, in the case where all possible (or even reasonable) topologies >for all of the services cannot be expressed, the operator must be aware >of what the FE is capable of supporting and how to configure the FE to >provide the desired service. The operator may not be able to depend >solely on the FE protocol to determine its capabilities and the >configuration that is required in order to support such a capability. It >seems like the operator may need to use some vendor-supplied tools to >add a service or new capability to a service. In this case, I'm not sure >how much sense it makes to have a generic protocol. > >Regards, >Ellen > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, November 06, 2003 2:49 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: LFB topology reconfguration > >I would argue that there is no such thing as "the diffserv path". >Diffserv >is a mechanism for offering a number of services. While one can have an >FE >that has a fixed toplogy of classifiers, markers, meters, queues and >schedulers, many FEs will have some flexibility in that topology. >It is quite likely that even if one could envision the topology for all >possible services, there are not enough LFBs to offer them all >simultaneously. So the operator picks the ones he is offering now, and >uses some of the resources to offer those. As he decides to offer more >services, he provisions them on the FE (via the CE) and makes them >available to customers. > >I do not know of an operator who can determine at box installation time >all >the services he will offer from that platform. >Equally, I do not know any operator who will be happy being told that >new >service offerings will requrie that he disable the box. >And there seems to be no point in having some other protocol for >extablishing these. > > >Let me put it another way. >Someone has to tell the FE what that initially topology ought to be. It >may be fixed by the factory. >If it is not fixed by the factory, it is clearly the CEs job to set it >up. >It is clearly desirable to be able to change that setup during >operation. >If the FE can support such a change, it is clearly the CEs job to make >such >a change. > >And it is not possible to enumerate all possible graphs, or all possible >services. > >Yours, >Joel M. Halpern > >At 02:33 PM 11/6/2003 -0800, you wrote: > >Seems like most people agree that micro-change within one given service > >(protocol as Alan put it) does not result in topology change. so no > >argument there. > > > >Now lets look at the macro-change which invovles change of service > >("service provisiong" as Joel called it). > > > >For example, suppose FE0 supports IPv4 forwarding, DiffServ and MPLS. >But > >the operator only wants to use IPv4 at the beginning. Well, the FE can > >still be modeled by a topology that includes all the services it is > >capable of. So the CE can model the FE by a topology like this (or, FE >can > >just report its topology to CE): > >+------------------+ > >|classifier V out1|-----> IPv4 path (subgraph) > >| out2|-----> DiffServ path (subgraph) > >| out3|-----> MPLS path (subgraph) > >+------------------+ > >Note that each path by itself is a subgraph potentially involving >multiple > >LFBs and multiple datapath. > > > >Now, "classifier V" is only a virtual classifier. FE0 may not have a > >classifier at all. But we use "classifier V" to model FE0's ability to > >support multiple services. Now at the begining since only IPv4 is used, >CE > >can configure "classifier V" such that packets all go to out1 (IPv4 >path). > > > >Later (like a month later), the operator want to use MPLS instead, they > >can configure classifier V such that packets now flow to out3. > > > >Another month later, if they want to use both IPv4 and DiffServ, sure. > >But the topology remains static. > > > >Now, what if the operator wants to do IPv6, but FE0 does not support >that > >to begin with. Well, the operator either buys another FE (FE1) that > >support IPv6, or he takes FE0 down and loads up the code to do IPv6, >plug > >it in, and start all over again. > > > >Remember, all we do here is just modeling the "logical" bahavior of FE > >with a bunch of "logical" LFBs. I can't see why we can't model the >service > >provisioning this way, without the need to reconfigure LFB topology. > > > >Lily > > > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alan DeKok > > > Sent: Thursday, November 06, 2003 7:33 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: LFB topology reconfguration > > > > > > > > > "Joel M. Halpern" wrote: > > > > > > > > My guess is that > > > > 1) To assign a subset of customer traffic to an existing > > > DiffServ service > > > > will not require LFB reconfiguration on almost any FE. > > > ... > > > > > > I would tend to agree. > > > > > > For me, the boundary between internal changes to an LFB's > > > configuration, and changes to inter-LFB connections is most often a > > > protocol boundary. Provisioning new connections/services within a > > > protocol requires updating entries in the LFB's which implement that > > > protocol. Provisioning a new protocol requires re-arranging LFB's, >or > > > creating new LFB's. > > > > > > Alan DeKok. > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 6 20:54:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12340 for ; Thu, 6 Nov 2003 20:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvpr-0004TC-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:54:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AHvpq-0004T9-00 for forces-archive@IETF.ORG; Thu, 06 Nov 2003 20:54:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C3A0F6@cherry.ease.lsoft.com>; Thu, 6 Nov 2003 20:54:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59650686 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Nov 2003 20:54:49 -0500 Received: from 218.108.250.186 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Nov 2003 20:54:48 -0400 Received: from wwm1([218.108.151.52]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm563fab48ae; Fri, 07 Nov 2003 09:51:17 +0800 References: <26BDFAFFB541B047B24179002EBE6D278CAEC3@orsmsx410.jf.intel.com> <3FAAD5DA.5CF8AD9F@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006b01c3a4d1$f11b1570$3d19fea9@wwm1> Date: Fri, 7 Nov 2003 09:53:28 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgTGlseSwNCg0KSSBhc2xvIHdvdWxkIGxpa2UgdG8gYXJndWUgdGhhdCBldmVuIG1pY3JvLWNo YW5nZSAgaW4gYSBzYW1lIHNlcnZpZSBtYXkgcmVzdWx0IGluDQpMRkIgYW5kIGl0cyBjb25uZWN0 aW9ucyBjaGFuZ2UuIEFsZXggdGFrZXMgdGhlIFFvUyBsZXZlbHMsIEkganVzdCB3YW50IHRvIHRh a2UgYSBSU1ZQIGNvbm5lY3Rpb24NCnNldHVwIGFzIGEgY29uc2lkZXJhdGlvbi4gV2hlbiB3ZSBk ZXBsb3kgcmVzb3VyY2VzIGZvciBhIG5ldyBSU1ZQIGNvbm5lY3Rpb24sIGNhbiB3ZSByZWFsbHkg ZG8gaXQgb25seSANCmp1c3QgYnkgY2hhbmdpbmcgc29tZSBMRkIgYXR0cmlidXRlcz8gIEkgdGhp bmsgY3VycmVudCBhbGwtaW4tb25lIHJvdXRlcnMgYWN0dWFsbHkgaGF2ZSBhbHJlYWR5IG1hZGUg c3VjaA0KcmVzb3VyY2VzIGR5bmFtaWMgZGVwbG95bWVudHMsIHdoaWNoLCB3aGVuIHJlZmxlY3Rz IGludG8gRm9yQ0VTIGFyY2hpdGV0dXJlLCBhcmUgTEZCIGNoYW5nZXMuIEFjdHVhbGx5IEkgDQp0 aGluayBzdWNoIGNoYW5nZXMgYXJlIG5vdCBhcyBhd2Z1bCB0byBkbyBhcyB3ZSBtaWdodCB0aGlu aywgIGVzcGVjaWFsbHkgd2hlbiB0aGUgcmVzb3VyY2VzIGFyZSBhbHJlYWR5IA0KbWFuYWdlZCBi eSBhIGNlbnRlciBuZXR3b3JrIHByb2Nlc3NvcnMuIA0KDQpSZWdhcmRzLA0KDQpXZWltaW5nDQoN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWxleCBBdWR1IiA8YWxleC5h dWR1QGFsY2F0ZWwuY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50 OiBGcmlkYXksIE5vdmVtYmVyIDA3LCAyMDAzIDc6MTQgQU0NClN1YmplY3Q6IFJlOiBGVzogTEZC IHRvcG9sb2d5IHJlY29uZmd1cmF0aW9uDQoNCg0KPiBIaSBMaWx5LA0KPiANCj4gTm90IG9ubHkg c2VydmljZSBjaGFuZ2UgZnJvbSBBIHRvIEIsIGJ1dCBhbHNvLCBzZXJ2aWNlIGxldmVsIG1haW50 ZW5hbmNlIHdpdGhpbg0KPiBzb21lIGNvbnN0cmFpbnRzIGZhbGxzIHdpdGhpbiBib3VuZHMgaW4g bXkgdmlldy4gRm9yIGV4YW1wbGUsIG9uZSBtYXkgd2FudA0KPiB0byBtYWludGFpbiBhIGNlcnRh aW4gbGV2ZWwgb2YgUW9TIHdoaWNoIG1heSByZXF1aXJlIHNvbWUgc29ydCBvZiBmZWVkYmFjaw0K PiBwcm9jZXNzIHRvIGR5bmFtaWNhbGx5IGJyaW5nIGluIG1vcmUgcmVzb3VyY2VzIChMRkJzKSB0 byBtYWtlIHVwIGZvciBpbmNyZWFzZWQNCj4gZGVtYW5kcywgb3IgbG9zcyBvZiByZXNvdXJjZXMg aW4gc29tZSBvdGhlciBORS4gIFRoaXMgc29ydCBvZiBjaGFuZ2UgbWF5IG5lZWQNCj4gdG8gdGFr ZSBwbGFjZSBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiB0aGUgb25jZS1pbi1hLXdoaWxlIHNlcnZpY2Ug Y2hhbmdlLg0KPiANCj4gUmVnYXJkcywNCj4gQWxleC4NCj4gDQo+ICJZYW5nLCBMaWx5IEwiIHdy b3RlOg0KPiANCj4gPiBPb3BzIC4uLiBmb3Jnb3QgdG8gY2MgdG8gdGhlIGxpc3QuIFRvbyBsYXRl IGludG8gdGhlIG5pZ2h0IDotKQ0KPiA+DQo+ID4gPiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+IEZyb206ICAgICAgICAgWWFuZywgTGlseSBMDQo+ID4gPiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDA1LCAyMDAzIDY6NDIgUE0NCj4gPiA+IFRvOiAgICdac29sdCBIYXJhc3p0 aSc7IEtob3NyYXZpLCBIb3JtdXpkIE07ICdKb2VsIE0uIEhhbHBlcm4nOyBEZWxlZ2FuZXMsIEVs bGVuIE07ICdKYW1hbCBIYWRpIFNhbGltJw0KPiA+ID4gU3ViamVjdDogICAgICBMRkIgdG9wb2xv Z3kgcmVjb25mZ3VyYXRpb24NCj4gPiA+DQo+ID4gPiBTb21lIGNsYXJpZmljYXRpb25zOg0KPiA+ ID4gMSkgTEZCIHRvcG9sb2d5ICh0aGUgImdyYXBoIikgcmVwcmVuc2VudHMgc3RhdGUsIG5vdCBj YXBhYmlsaXR5Lg0KPiA+ID4gMikgVGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIHRvIHJlcHJlc2Vu dCB0b3BvbG9neSBjYXBhYmlsaXR5LiBPbmUgd2F5IGlzIHRvIGxpc3QgYWxsIHRoZSBwb3NzaWJs ZSBncmFwaHMgYW5kIG5hbWUgdGhlbSB1cCBmcm9udC4gVGhlbiB0byByZWNvbmZpZ3VyZSB0aGUg TEZCIHRvcG9sb2d5IGlzIHRvIHN3aXRjaCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgZ3JhcGhzLiBB bm90aGVyIHdheSBpcyB0byBkZXNjcmliZSB0aGUgbGlua2FnZSBjb25zdHJhaW50IChsaWtlIExG QiBBIGNhbiBvbmx5IGJlIGZvbGxvd2VkIGJ5IExGQiBCIGFuZCBDIGJ1dCBub3QgRCkuICBXZSBj YW4gYXJndWUgd2hpY2ggaXMgbW9yZSBmbGV4aWJsZSwgZWZmaWNpZW50IGV0YyBsYXRlci4NCj4g PiA+DQo+ID4gPiBCdXQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG9mIG15IG93bi4NCj4g PiA+IDEpIEhvdyBmZWFzaWJsZSAmIGZyZXF1ZW50IGl0IHJlYWxseSBpcyBmb3IgYW4gRkUgdG8g Y2hhbmdlIGZyb20gc2VydmljZSBBIHRvIEIgYXQgcnVudGltZT8gSSBoZWFyZCBhIGZldyBwZW9w bGUgc2FpZCAieWVzLCB3ZSBkbyB0aGF0IHRvZGF5Ii4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBo ZWFyIGEgZmV3IGNvbmNyZXRlIGV4YW1wbGVzIGFuZCB1bmRlcnN0YW5kIHdoYXQgaXMgaW52b2x2 ZWQgYXQgdGhlIEZFIGFuZCBDRSB0byBhY2NvbXBsaXNoIHRoYXQuIEkgZG9uJ3QgY29uc2lkZXIg cmVjb21waWxpbmcgY29kZXMgYXMgZHluYW1pYyBydW4gdGltZSBjb25maWd1cmF0aW9uLg0KPiA+ ID4gVGhlIHJlYXNvbiB0aGF0IEkgYW0gYXNraW5nIHRoaXMgaXMgdGhhdCBJIGRvbid0IHdhbnQg dG8gZW5kIHVwIGRlc2lnbmluZyBzb21lIGZlYXR1cmUgdGhhdCBpcyBjb29sIGJ1dCBub2JvZHkg Y2FuIHJlYWxseSB1c2VzIGluICB0aGUgcHJvZHVjdHMuDQo+ID4gPg0KPiA+ID4gMikgSXMgcHJv dmlkaW5nIGFiaWxpdHkgdG8gc3dpdGNoIGJldHdlZW4gZ3JhcGhzIGZsZXhpYmxlIGVub3VnaCBm b3IgdG9wb2xvZ3kgcmVjb25maWd1cmF0aW9uPyBJIHJlYWxpemUgaXQgaXMgbGltaXRlZC4gQnV0 IGlzIGl0IGdvb2QgZW5vdWdoPw0KPiA+ID4NCj4gPiA+IDMpIERvIHdlIHJlYWxseSB3YW50IHRo ZSB1bHRpbWF0ZSBmbGV4aWJpbGl0eSB0byByZWFycmFuZ2UgTEZCIGJ5IGFkZGluZyAoaW5zdGFu dGlhdGluZykgbmV3IExGQiBpbnN0YW5jZXMsIGRlbGV0aW5nIExGQiBpbnN0YW5jZXMsIG9yIHJl LWNvbm5lY3RpbmcgdHdvIExGQnMgKGJ5IGRlbGV0aW5nIGFuZCB0aGVuIGFkZGluZyBjb25uZWN0 aW9ucyk/DQo+ID4gPiBBZ2Fpbiwgd2UgY2FuIGRvIHRoaXMgaW4gRm9yQ0VTLCBidXQgb25seSBp ZiBwZW9wbGUgcmVhbGx5IHNlZSB0aGUgbmVlZC9iZW5lZml0IG9mIGl0Lg0KPiA+ID4NCj4gPiA+ IDQpIEkgaW1hZ2luZSBiZWZvcmUgeW91IGNoYW5nZSBzZXJ2aWNlIG9uIEZFIGZyb20gQSB0byBC LCB5b3UgcHJvYmFibHkgaGF2ZSB0byBzdG9wIHNlbmRpbmcgcGFja2V0cyB0byB0aGlzIEZFIGFs bCB0b2dldGhlciBpZiB5b3UgZG9uJ3Qgd2FudCB0byBoYXZlIHVucHJlZGljdGFibGUgYmVoYXZp b3Igb3IgbG9zcyBvZiB0cmFmZmljIHRlbXBvcmFyaWx5LiBTbyBpdCBpcyBhbG1vc3QgZXF1aXZh bGVudCB0byB0YWtlIGRvd24gYW4gRkUgYW5kIHBsdWcgaW4gYSBuZXcgb25lIGxhdGVyLCBpc24n dCBpdD8NCj4gPiA+DQo+ID4gPiA1KSBGb3IgdGhvc2Ugb2YgeW91IHdobyBhcmUgaW52b3ZsZWQg aW4gTlBGIC0tIElzIE5QRiBzdXBwb3J0aW5nIGR5bmFtaWMgTEZCIHRvcG9sb2d5PyBXZSB3YW50 IHRvIGFsaWduIEZvckNFUyBhbmQgTlBGIHRvIHRoZSBzYW1lIGRpcmVjdGlvbi4NCj4gPiA+DQo+ ID4gPiBMaWx5DQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 12:54:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26752 for ; Fri, 7 Nov 2003 12:54:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAoK-0000QU-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 12:54:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIAoJ-0000QR-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 12:54:16 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C3B3A9@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 12:54:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59738756 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 12:54:12 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 12:54:12 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA7HsBLl004400 for ; Fri, 7 Nov 2003 17:54:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA7HrNF0012868 for ; Fri, 7 Nov 2003 17:53:30 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110709540523111 for ; Fri, 07 Nov 2003 09:54:05 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 09:54:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FW: LFB topology reconfguration Thread-Index: AcOk0iV3hu+cCXaBQj6joYwzztFaMAAgs5rA X-OriginalArrivalTime: 07 Nov 2003 17:54:05.0598 (UTC) FILETIME=[22CB9BE0:01C3A558] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEDB@orsmsx410.jf.intel.com> Date: Fri, 7 Nov 2003 09:54:04 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I guess that largely depends on how you model LFB and the topology to = start with.=20 To model the LFB topology, we recommend using a combination of = topological approach and encoded state approach in the FE model dradf = -v01: "The topological approach should primarily be used when the packet = datapath forks into areas with distinct LFB classes (not just distinct = parameterizations of the same LFB classes), and when the fan-outs do not = require changes (adding/removing LFB outputs) at all or require only = very infrequent changes. Configuration information that needs to change = frequently should preferably be expressed by the internal attributes of = one or more LFBs (and hence using the encoded state approach). (Section = 3.3.1)" The granularity of LFB also matters. The finer grain the LFBs are, the = more likely you run into dynamic topology change.=20 But all in all, I still think setting up a new RSVP connection does not = result in topology change. It seems adding a new entry in the LFB table = would do it.=20 Maybe if you draw out the topology example you have in your mind, that = would certainly help. Isn't it great that we have all these warm-up exercises on FE model = before going to the IETF meeting next week? For those of you who will be = at Minneapolis, lets make sure we continue this discussion face to face = and (hopefully) reach some consensus. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Weiming Wang > Sent: Thursday, November 06, 2003 5:53 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: FW: LFB topology reconfguration >=20 >=20 > Hi Lily, >=20 > I aslo would like to argue that even micro-change in a same=20 > servie may result in > LFB and its connections change. Alex takes the QoS levels, I=20 > just want to take a RSVP connection > setup as a consideration. When we deploy resources for a new=20 > RSVP connection, can we really do it only=20 > just by changing some LFB attributes? I think current=20 > all-in-one routers actually have already made such > resources dynamic deployments, which, when reflects into=20 > ForCES architeture, are LFB changes. Actually I=20 > think such changes are not as awful to do as we might think, =20 > especially when the resources are already=20 > managed by a center network processors.=20 >=20 > Regards, >=20 > Weiming >=20 > ----- Original Message -----=20 > From: "Alex Audu" > To: > Sent: Friday, November 07, 2003 7:14 AM > Subject: Re: FW: LFB topology reconfguration >=20 >=20 > > Hi Lily, > >=20 > > Not only service change from A to B, but also, service=20 > level maintenance within > > some constraints falls within bounds in my view. For=20 > example, one may want > > to maintain a certain level of QoS which may require some=20 > sort of feedback > > process to dynamically bring in more resources (LFBs) to=20 > make up for increased > > demands, or loss of resources in some other NE. This sort=20 > of change may need > > to take place much more often than the once-in-a-while=20 > service change. > >=20 > > Regards, > > Alex. > >=20 > > "Yang, Lily L" wrote: > >=20 > > > Oops ... forgot to cc to the list. Too late into the night :-) > > > > > > > -----Original Message----- > > > > From: Yang, Lily L > > > > Sent: Wednesday, November 05, 2003 6:42 PM > > > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M.=20 > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > > > Subject: LFB topology reconfguration > > > > > > > > Some clarifications: > > > > 1) LFB topology (the "graph") reprensents state, not capability. > > > > 2) There are different ways to represent topology=20 > capability. One way is to list all the possible graphs and=20 > name them up front. Then to reconfigure the LFB topology is=20 > to switch between the different graphs. Another way is to=20 > describe the linkage constraint (like LFB A can only be=20 > followed by LFB B and C but not D). We can argue which is=20 > more flexible, efficient etc later. > > > > > > > > But I still have some questions of my own. > > > > 1) How feasible & frequent it really is for an FE to=20 > change from service A to B at runtime? I heard a few people=20 > said "yes, we do that today". I would really like to hear a=20 > few concrete examples and understand what is involved at the=20 > FE and CE to accomplish that. I don't consider recompiling=20 > codes as dynamic run time configuration. > > > > The reason that I am asking this is that I don't want=20 > to end up designing some feature that is cool but nobody can=20 > really uses in the products. > > > > > > > > 2) Is providing ability to switch between graphs=20 > flexible enough for topology reconfiguration? I realize it is=20 > limited. But is it good enough? > > > > > > > > 3) Do we really want the ultimate flexibility to=20 > rearrange LFB by adding (instantiating) new LFB instances,=20 > deleting LFB instances, or re-connecting two LFBs (by=20 > deleting and then adding connections)? > > > > Again, we can do this in ForCES, but only if people=20 > really see the need/benefit of it. > > > > > > > > 4) I imagine before you change service on FE from A to=20 > B, you probably have to stop sending packets to this FE all=20 > together if you don't want to have unpredictable behavior or=20 > loss of traffic temporarily. So it is almost equivalent to=20 > take down an FE and plug in a new one later, isn't it? > > > > > > > > 5) For those of you who are invovled in NPF -- Is NPF=20 > supporting dynamic LFB topology? We want to align ForCES and=20 > NPF to the same direction. > > > > > > > > Lily > >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 13:05:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27129 for ; Fri, 7 Nov 2003 13:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAzi-0000aI-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 13:06:02 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIAzh-0000aF-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 13:06:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C3B2E4@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 13:06:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59739864 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 13:05:56 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 13:05:56 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA7I2jmm021877 for ; Fri, 7 Nov 2003 18:02:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA7I03O24711 for ; Fri, 7 Nov 2003 18:00:03 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110710055323224 for ; Fri, 07 Nov 2003 10:05:53 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 10:05:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FW: LFB topology reconfguration Thread-Index: AcOku8icvwroF/mNR8KnsgsGRfzR7gAnGQag X-OriginalArrivalTime: 07 Nov 2003 18:05:52.0944 (UTC) FILETIME=[C8680B00:01C3A559] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEDC@orsmsx410.jf.intel.com> Date: Fri, 7 Nov 2003 10:05:52 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Alex -- I am a bit confused when you said "bring in more resources (LFBs)" -- Do = you mean more instances of the same LFB, or more resources for existing = LFBs? What do you mean by resources here? Like memory, processing, = bandwidth on FE?=20 Can I ask you a favor here? Can you draw the example you have in mind = for me :-) ? I would really like to collect some examples that people have in mind = and examine them to understand what are required here for FE model to = support these examples. As I said (in my response to Weiming), how we = model LFB (granularity), how we model the datapath, all affect how = dymanic the topology will become. Comparing to six month ago, I think we = have better ideas on these issues but by no means firm and complete. So = I would like to use some examples as a way to sanity-check our thinking = here. That is why I am pushing for some examples with certain level of = details. I believe these examples can help deepen our discussion on the = subject. Thank you! Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alex Audu > Sent: Thursday, November 06, 2003 3:15 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: FW: LFB topology reconfguration >=20 >=20 > Hi Lily, >=20 > Not only service change from A to B, but also, service level=20 > maintenance within > some constraints falls within bounds in my view. For example,=20 > one may want > to maintain a certain level of QoS which may require some=20 > sort of feedback > process to dynamically bring in more resources (LFBs) to make=20 > up for increased > demands, or loss of resources in some other NE. This sort of=20 > change may need > to take place much more often than the once-in-a-while service change. >=20 > Regards, > Alex. >=20 > "Yang, Lily L" wrote: >=20 > > Oops ... forgot to cc to the list. Too late into the night :-) > > > > > -----Original Message----- > > > From: Yang, Lily L > > > Sent: Wednesday, November 05, 2003 6:42 PM > > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M.=20 > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > > Subject: LFB topology reconfguration > > > > > > Some clarifications: > > > 1) LFB topology (the "graph") reprensents state, not capability. > > > 2) There are different ways to represent topology=20 > capability. One way is to list all the possible graphs and=20 > name them up front. Then to reconfigure the LFB topology is=20 > to switch between the different graphs. Another way is to=20 > describe the linkage constraint (like LFB A can only be=20 > followed by LFB B and C but not D). We can argue which is=20 > more flexible, efficient etc later. > > > > > > But I still have some questions of my own. > > > 1) How feasible & frequent it really is for an FE to=20 > change from service A to B at runtime? I heard a few people=20 > said "yes, we do that today". I would really like to hear a=20 > few concrete examples and understand what is involved at the=20 > FE and CE to accomplish that. I don't consider recompiling=20 > codes as dynamic run time configuration. > > > The reason that I am asking this is that I don't want to=20 > end up designing some feature that is cool but nobody can=20 > really uses in the products. > > > > > > 2) Is providing ability to switch between graphs flexible=20 > enough for topology reconfiguration? I realize it is limited.=20 > But is it good enough? > > > > > > 3) Do we really want the ultimate flexibility to=20 > rearrange LFB by adding (instantiating) new LFB instances,=20 > deleting LFB instances, or re-connecting two LFBs (by=20 > deleting and then adding connections)? > > > Again, we can do this in ForCES, but only if people=20 > really see the need/benefit of it. > > > > > > 4) I imagine before you change service on FE from A to B,=20 > you probably have to stop sending packets to this FE all=20 > together if you don't want to have unpredictable behavior or=20 > loss of traffic temporarily. So it is almost equivalent to=20 > take down an FE and plug in a new one later, isn't it? > > > > > > 5) For those of you who are invovled in NPF -- Is NPF=20 > supporting dynamic LFB topology? We want to align ForCES and=20 > NPF to the same direction. > > > > > > Lily >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 13:14:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27503 for ; Fri, 7 Nov 2003 13:14:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIB7w-0000h0-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 13:14:32 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIB7v-0000gx-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 13:14:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C3B3DA@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 13:14:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59740752 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 13:14:30 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 13:14:29 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 4CAE61F0082 for ; Fri, 7 Nov 2003 13:14:29 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 26FB51F0079 for ; Fri, 7 Nov 2003 13:14:29 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0190B38@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FABE102.718D12CF@idt.com> Date: Fri, 7 Nov 2003 13:14:26 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Deleganes, Ellen M" wrote: > > It seems like what is being proposed here is for the case of a very > generic FE that contains a lot of different kinds of LFBs, and the > services that can be supported depend on the topology configured for > those LFBs (or various subsets of the LFBs). In this case, I can see > where expressing all of the possible topologies might not be feasible. Some vendors systems are highly programmable (e.g. software), and thus can do "anything". It's difficult for those vendors to see why they should restrict their solutions to being described in LFBs. It's also difficult for them to see why they need to describe their solutions, because they can do "anything". At the other extreme, we have vendors with dedicated (and limited) hardware. Their systems are too simple to implement any ForCES protocol, and can be easily described without resorting to LFB's. ForCES allows everyone to meet in the middle. This means that most vendors have to perform additional work to support ForCES, without clear and immediate benefits. Much of the conversations (and concerns) on the list have been about agreeing on what, exactly, those benefits are. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 16:54:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09590 for ; Fri, 7 Nov 2003 16:54:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEYd-0003b1-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 16:54:19 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIEYc-0003ay-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 16:54:18 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C3B93E@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 16:54:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59757036 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 16:54:15 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 16:54:15 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA7LsELl015817 for ; Fri, 7 Nov 2003 21:54:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA7LraEu001408 for ; Fri, 7 Nov 2003 21:53:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110713541116891 for ; Fri, 07 Nov 2003 13:54:11 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 13:54:11 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: LFB topology reconfguration Thread-Index: AcOlWwtBj2jV0NwgSzOICmV6i6Z07gAGXFXw X-OriginalArrivalTime: 07 Nov 2003 21:54:11.0394 (UTC) FILETIME=[AD51A220:01C3A579] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190B3B@orsmsx410.jf.intel.com> Date: Fri, 7 Nov 2003 13:54:10 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Alan, Thanks. I think that it will be helpful to understand where that "middle ground" is and to have an idea of the bounds of flexibility that the protocol is expected to support. It makes sense to try to narrow in on the amount of flexibility that we expect the protocol and model to support by discussing real applications and usage models. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alan DeKok Sent: Friday, November 07, 2003 10:14 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: LFB topology reconfguration "Deleganes, Ellen M" wrote: > > It seems like what is being proposed here is for the case of a very > generic FE that contains a lot of different kinds of LFBs, and the > services that can be supported depend on the topology configured for > those LFBs (or various subsets of the LFBs). In this case, I can see > where expressing all of the possible topologies might not be feasible. Some vendors systems are highly programmable (e.g. software), and thus can do "anything". It's difficult for those vendors to see why they should restrict their solutions to being described in LFBs. It's also difficult for them to see why they need to describe their solutions, because they can do "anything". At the other extreme, we have vendors with dedicated (and limited) hardware. Their systems are too simple to implement any ForCES protocol, and can be easily described without resorting to LFB's. ForCES allows everyone to meet in the middle. This means that most vendors have to perform additional work to support ForCES, without clear and immediate benefits. Much of the conversations (and concerns) on the list have been about agreeing on what, exactly, those benefits are. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 18:10:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13058 for ; Fri, 7 Nov 2003 18:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFkj-0004cz-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:10:53 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIFki-0004cv-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:10:53 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C3BABE@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 18:10:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59761826 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 18:10:51 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 18:10:51 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA7NAocb022034 for ; Fri, 7 Nov 2003 17:10:50 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <26BDFAFFB541B047B24179002EBE6D278CAEDC@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FAC2677.6F37DF20@alcatel.com> Date: Fri, 7 Nov 2003 17:10:47 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Exactly. This assumes that all your resources for processing traffic can be mapped somewhat to some LFBs (either in whole or in part). If a configured channel is getting overwhelmed due to excessive traffic, you can react to this scenario in one of two ways : drop packets or accommodate the traffic by springing in more channels to cope with increased demand. It is not unlike bringing a new link on-line on a macro scale. But definitely, you can imagine all the ramifications of this action on the microscopic LFB scale. Regards, Alex. "Yang, Lily L" wrote: > Alex -- > I am a bit confused when you said "bring in more resources (LFBs)" -- Do you mean more instances of the same LFB, or more resources for existing LFBs? What do you mean by resources here? Like memory, processing, bandwidth on FE? > Can I ask you a favor here? Can you draw the example you have in mind for me :-) ? > > I would really like to collect some examples that people have in mind and examine them to understand what are required here for FE model to support these examples. As I said (in my response to Weiming), how we model LFB (granularity), how we model the datapath, all affect how dymanic the topology will become. Comparing to six month ago, I think we have better ideas on these issues but by no means firm and complete. So I would like to use some examples as a way to sanity-check our thinking here. That is why I am pushing for some examples with certain level of details. I believe these examples can help deepen our discussion on the subject. > > Thank you! > Lily > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alex Audu > > Sent: Thursday, November 06, 2003 3:15 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: FW: LFB topology reconfguration > > > > > > Hi Lily, > > > > Not only service change from A to B, but also, service level > > maintenance within > > some constraints falls within bounds in my view. For example, > > one may want > > to maintain a certain level of QoS which may require some > > sort of feedback > > process to dynamically bring in more resources (LFBs) to make > > up for increased > > demands, or loss of resources in some other NE. This sort of > > change may need > > to take place much more often than the once-in-a-while service change. > > > > Regards, > > Alex. > > > > "Yang, Lily L" wrote: > > > > > Oops ... forgot to cc to the list. Too late into the night :-) > > > > > > > -----Original Message----- > > > > From: Yang, Lily L > > > > Sent: Wednesday, November 05, 2003 6:42 PM > > > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. > > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > > > Subject: LFB topology reconfguration > > > > > > > > Some clarifications: > > > > 1) LFB topology (the "graph") reprensents state, not capability. > > > > 2) There are different ways to represent topology > > capability. One way is to list all the possible graphs and > > name them up front. Then to reconfigure the LFB topology is > > to switch between the different graphs. Another way is to > > describe the linkage constraint (like LFB A can only be > > followed by LFB B and C but not D). We can argue which is > > more flexible, efficient etc later. > > > > > > > > But I still have some questions of my own. > > > > 1) How feasible & frequent it really is for an FE to > > change from service A to B at runtime? I heard a few people > > said "yes, we do that today". I would really like to hear a > > few concrete examples and understand what is involved at the > > FE and CE to accomplish that. I don't consider recompiling > > codes as dynamic run time configuration. > > > > The reason that I am asking this is that I don't want to > > end up designing some feature that is cool but nobody can > > really uses in the products. > > > > > > > > 2) Is providing ability to switch between graphs flexible > > enough for topology reconfiguration? I realize it is limited. > > But is it good enough? > > > > > > > > 3) Do we really want the ultimate flexibility to > > rearrange LFB by adding (instantiating) new LFB instances, > > deleting LFB instances, or re-connecting two LFBs (by > > deleting and then adding connections)? > > > > Again, we can do this in ForCES, but only if people > > really see the need/benefit of it. > > > > > > > > 4) I imagine before you change service on FE from A to B, > > you probably have to stop sending packets to this FE all > > together if you don't want to have unpredictable behavior or > > loss of traffic temporarily. So it is almost equivalent to > > take down an FE and plug in a new one later, isn't it? > > > > > > > > 5) For those of you who are invovled in NPF -- Is NPF > > supporting dynamic LFB topology? We want to align ForCES and > > NPF to the same direction. > > > > > > > > Lily > > From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Nov 7 18:15:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13557 for ; Fri, 7 Nov 2003 18:15:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFp2-0004hW-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:15:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIFp2-0004hS-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:15:20 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C3BBF4@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 18:15:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59762118 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 18:15:20 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 18:15:16 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA7NFEcb022413 for ; Fri, 7 Nov 2003 17:15:15 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <26BDFAFFB541B047B24179002EBE6D278CAEDC@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FAC2780.ED5AFBD0@alcatel.com> Date: Fri, 7 Nov 2003 17:15:12 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit To add to my previous e-mail, one can also imagine logic devices that react to security violation detection by causing changes in some LFBs. Regards, Alex. "Yang, Lily L" wrote: > Alex -- > I am a bit confused when you said "bring in more resources (LFBs)" -- Do you mean more instances of the same LFB, or more resources for existing LFBs? What do you mean by resources here? Like memory, processing, bandwidth on FE? > Can I ask you a favor here? Can you draw the example you have in mind for me :-) ? > > I would really like to collect some examples that people have in mind and examine them to understand what are required here for FE model to support these examples. As I said (in my response to Weiming), how we model LFB (granularity), how we model the datapath, all affect how dymanic the topology will become. Comparing to six month ago, I think we have better ideas on these issues but by no means firm and complete. So I would like to use some examples as a way to sanity-check our thinking here. That is why I am pushing for some examples with certain level of details. I believe these examples can help deepen our discussion on the subject. > > Thank you! > Lily > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alex Audu > > Sent: Thursday, November 06, 2003 3:15 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: FW: LFB topology reconfguration > > > > > > Hi Lily, > > > > Not only service change from A to B, but also, service level > > maintenance within > > some constraints falls within bounds in my view. For example, > > one may want > > to maintain a certain level of QoS which may require some > > sort of feedback > > process to dynamically bring in more resources (LFBs) to make > > up for increased > > demands, or loss of resources in some other NE. This sort of > > change may need > > to take place much more often than the once-in-a-while service change. > > > > Regards, > > Alex. > > > > "Yang, Lily L" wrote: > > > > > Oops ... forgot to cc to the list. Too late into the night :-) > > > > > > > -----Original Message----- > > > > From: Yang, Lily L > > > > Sent: Wednesday, November 05, 2003 6:42 PM > > > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. > > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > > > Subject: LFB topology reconfguration > > > > > > > > Some clarifications: > > > > 1) LFB topology (the "graph") reprensents state, not capability. > > > > 2) There are different ways to represent topology > > capability. One way is to list all the possible graphs and > > name them up front. Then to reconfigure the LFB topology is > > to switch between the different graphs. Another way is to > > describe the linkage constraint (like LFB A can only be > > followed by LFB B and C but not D). We can argue which is > > more flexible, efficient etc later. > > > > > > > > But I still have some questions of my own. > > > > 1) How feasible & frequent it really is for an FE to > > change from service A to B at runtime? I heard a few people > > said "yes, we do that today". I would really like to hear a > > few concrete examples and understand what is involved at the > > FE and CE to accomplish that. I don't consider recompiling > > codes as dynamic run time configuration. > > > > The reason that I am asking this is that I don't want to > > end up designing some feature that is cool but nobody can > > really uses in the products. > > > > > > > > 2) Is providing ability to switch between graphs flexible > > enough for topology reconfiguration? I realize it is limited. > > But is it good enough? > > > > > > > > 3) Do we really want the ultimate flexibility to > > rearrange LFB by adding (instantiating) new LFB instances, > > deleting LFB instances, or re-connecting two LFBs (by > > deleting and then adding connections)? > > > > Again, we can do this in ForCES, but only if people > > really see the need/benefit of it. > > > > > > > > 4) I imagine before you change service on FE from A to B, > > you probably have to stop sending packets to this FE all > > together if you don't want to have unpredictable behavior or > > loss of traffic temporarily. So it is almost equivalent to > > take down an FE and plug in a new one later, isn't it? > > > > > > > > 5) For those of you who are invovled in NPF -- Is NPF > > supporting dynamic LFB topology? We want to align ForCES and > > NPF to the same direction. > > > > > > > > Lily > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 18:58:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14968 for ; Fri, 7 Nov 2003 18:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGVP-0005D1-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:59:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIGVP-0005Cy-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 18:59:07 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C3BB78@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 18:59:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59764697 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 18:59:02 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 18:59:02 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA7Ntrmm001771 for ; Fri, 7 Nov 2003 23:55:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA7NrAJ05238 for ; Fri, 7 Nov 2003 23:53:11 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110715590026851 for ; Fri, 07 Nov 2003 15:59:00 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 15:59:00 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] LFB topology reconfguration Thread-Index: AcOke4JxxR/SC/oiTmWxahKpq+vWMgBDBVPA X-OriginalArrivalTime: 07 Nov 2003 23:59:00.0473 (UTC) FILETIME=[1D286690:01C3A58B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel.com> Date: Fri, 7 Nov 2003 15:58:59 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat off] > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alan DeKok > Sent: Thursday, November 06, 2003 7:33 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] LFB topology reconfguration >=20 > For me, the boundary between internal changes to an LFB's > configuration, and changes to inter-LFB connections is most often a > protocol boundary. Provisioning new connections/services within a > protocol requires updating entries in the LFB's which implement that > protocol. Provisioning a new protocol requires re-arranging LFB's, or > creating new LFB's. Hi Alan. Can you (or others) clarify a bit further on this? In particular, I am trying to understand if there is a requirement to add support for entirely new protocols (or other such actions=20 requiring LFB rearranging) at run time, and if so, what is the=20 concrete example that requires a LFB-rearranging mechanism? My impression is that the state of the art engineering approach is to bring down blades one at a time to upgrade their=20 firmware/software/hardware functions, using active/passive or other HA mechanisms to retain non-stop forwarding in the face of upgrades. In this sort of approach there is indeed FE LFB=20 topology change, but that change occurs while an FE is offline (and thus not during the post-association phase). I am aware of active networking approaches that allow a more=20 dynamic, runtime-based reconfiguration of FE functionality. =20 Are these what people have in mind, and if so, are they=20 engineering practice (shipping product) or still research? Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 19:39:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16608 for ; Fri, 7 Nov 2003 19:39:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH8e-0005uA-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 19:39:40 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIH8d-0005u7-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 19:39:40 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C3BC40@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 19:39:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59767589 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 19:39:39 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 19:39:39 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hA81hY415939 for ; Fri, 7 Nov 2003 17:43:34 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Fri, 7 Nov 2003 17:43:34 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel.com> Precedence: list Packet massaging starts at the classifier; this is followed by one or more LFB instances that do something to the packet. You could define the massaging of the packet as a service. A simple rearrangement of such as a service could be to temporarily add a mirroring LFB instance for debug or other reasons and then removing it later. This does not require bringing down anything. There are more interesting things, but this is within the charter. Whether the mirroring LFB shows up at ASIC design time or 10 years later as downloaded firmware to an FPGA or a software kernel module is beyond the scope of Forces. IMO it does not in any way affect how a ForCES protocol should look like. Infact theres no point in even discussing the issue of how it got there. Forces role is to configure from the CE what it knows the FE can do. I think theres a mental block which results from a COPS mindset that is affecting how people are thinking about this. For simplicty sake assume that the LFBs already exist ... cheers, jamal On Fri, 7 Nov 2003, Putzolu, David wrote: > Can you (or others) clarify a bit further on this? > > In particular, I am trying to understand if there is a requirement > to add support for entirely new protocols (or other such actions > requiring LFB rearranging) at run time, and if so, what is the > concrete example that requires a LFB-rearranging mechanism? > > > My impression is that the state of the art engineering approach > is to bring down blades one at a time to upgrade their > firmware/software/hardware functions, using active/passive or > other HA mechanisms to retain non-stop forwarding in the face of > upgrades. In this sort of approach there is indeed FE LFB > topology change, but that change occurs while an FE is offline > (and thus not during the post-association phase). > > I am aware of active networking approaches that allow a more > dynamic, runtime-based reconfiguration of FE functionality. > Are these what people have in mind, and if so, are they > engineering practice (shipping product) or still research? > > Thanks, > David > From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 22:17:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20387 for ; Fri, 7 Nov 2003 22:17:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJc1-0007ad-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 22:18:09 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIJc0-0007aa-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 22:18:08 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C3BDE2@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 22:18:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59776696 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 22:18:08 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 22:18:08 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA83I7Ll025098 for ; Sat, 8 Nov 2003 03:18:07 GMT Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with ESMTP id hA82x5mY018931 for ; Sat, 8 Nov 2003 03:17:31 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA816uu21124 for ; Sat, 8 Nov 2003 01:06:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110717124527902 for ; Fri, 07 Nov 2003 17:12:45 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 Nov 2003 17:12:46 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] LFB topology reconfguration Thread-Index: AcOlkM3p0Co4mA5cRXKT9/EpySoM3wAAK/3A X-OriginalArrivalTime: 08 Nov 2003 01:12:46.0123 (UTC) FILETIME=[6B0CFFB0:01C3A595] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F6A2@orsmsx409.jf.intel.com> Date: Fri, 7 Nov 2003 17:12:45 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat still off] Jamal Hadi Salim wrote> > A simple rearrangement of such as a service could be to temporarily > add a mirroring LFB instance for debug or other reasons and then > removing it later. This does not require bringing down anything. Hi Jamal. I agree that adding a new LFB instance is one way of doing this. That is not the only way to do this however. Since you mention=20 software kernel modules, let's use Linux as an example: as far as I know, the Linux kernel has a very specific, fixed set of places where one can mirror packets (using the QUEUE target I believe) -=20 here's a simplified drawing I found of it: http://iptables-tutorial.frozentux.net/images/tables_traverse.jpg The ability to mirror packets is always latently present at those specific places in the Linux kernel's packet processing code. One could imagine an FE based on Linux would contain a LFB=20 graph very much like what that image shows (although there would be a lot more LFBs since a lot more packet processing is done in the Linux kernel). In order to turn on mirroring, one would add the appropriate rule with a QUEUE target to the appropriate chain (i.e. add the=20 appropriate entry to some table in an LFB). This doesn't require instantiating new LFBs or reconnecting them - this is merely adding=20 a rule to LFBs that already appear in the graph pictured. Under the covers, the Linux kernel might actually load (or unload) a kernel module based on what rules are in force at a particular time. However, what happens under the covers seems to me like it should not be the ken of forces, because FEs are likely to vary widely. Apologies to those less familiar with Linux - hopefully the combination of the picture and the text here is enough to make the point clear. > I think theres a mental block which results from a COPS mindset > that is affecting how people are thinking about this. > For simplicty sake assume that the LFBs already exist ... I am not a COPS person myself, having never worked on that specification or implementations of it. You are probably=20 thinking of another David :) Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 7 22:59:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21399 for ; Fri, 7 Nov 2003 22:59:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIKGN-0000FY-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 22:59:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIKGM-0000FM-00 for forces-archive@IETF.ORG; Fri, 07 Nov 2003 22:59:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C3BEF2@cherry.ease.lsoft.com>; Fri, 7 Nov 2003 22:59:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59778803 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Nov 2003 22:59:49 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Nov 2003 22:59:49 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hA853jG17005 for ; Fri, 7 Nov 2003 21:03:45 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Fri, 7 Nov 2003 21:03:44 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F6A2@orsmsx409.jf.intel.com> Precedence: list On Fri, 7 Nov 2003, Putzolu, David wrote: > Hi Jamal. > > I agree that adding a new LFB instance is one way of doing this. > That is not the only way to do this however. Since you mention > software kernel modules, let's use Linux as an example: as far as > I know, the Linux kernel has a very specific, fixed set of places > where one can mirror packets (using the QUEUE target I believe) - > here's a simplified drawing I found of it: > http://iptables-tutorial.frozentux.net/images/tables_traverse.jpg > Actually thats a bad example to relate to Forces. A better one maybe (no diagrams) is: http://www.cyberus.ca/~hadi/patches/action/README jump to " cut here" to see a sample policy that adds new LFB instances. That documentation is slightly dated [..] > > In order to turn on mirroring, one would add the appropriate rule > with a QUEUE target to the appropriate chain (i.e. add the > appropriate entry to some table in an LFB). This doesn't require > instantiating new LFBs or reconnecting them - this is merely adding > a rule to LFBs that already appear in the graph pictured. > So the sample i pointed to for example could have a s/add/replace to get a new Mirroring LFB instance in its path. " replace" could be considered an atomic del/add. > Under the covers, the Linux kernel might actually load (or > unload) a kernel module based on what rules are in force at > a particular time. However, what happens under the covers > seems to me like it should not be the ken of forces, because > FEs are likely to vary widely. > Theoretically you could compile a kernel that does LFB mirroring somewhere, download it to the FE; have the FE announce a new capability to the CE and use a replace policy from the CE to instantiate a instance of it in an existing topology. This (downloading) is outside the scope of forces though. The dynamic loading you describe would happen if the CE is already knowledgeable about LFB capability. And btw to the skeptics, this is doable on NPs, FPGAs etc. Just pay me enough $ and i can show you how;-> Maybe i should tune my presentation to explain this stuff but i only have 15 minutes. > I am not a COPS person myself, having never worked on that > specification or implementations of it. You are probably > thinking of another David :) > Apologies, yes i did ;-> I guess i saw too many " nextlfb" emails and you happened to show at the right^Wwrong time. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 8 01:11:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24404 for ; Sat, 8 Nov 2003 01:11:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMJc-0001m4-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 01:11:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIMJc-0001lz-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 01:11:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C3C36D@cherry.ease.lsoft.com>; Sat, 8 Nov 2003 1:11:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59794545 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 8 Nov 2003 01:11:20 -0500 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Nov 2003 01:11:20 -0400 Received: from user-2ivfu4b.dialup.mindspring.com ([165.247.248.139] helo=JLaptop.stevecrocker.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIMJa-0000OP-00 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 07 Nov 2003 22:11:19 -0800 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031108010838.02001800@localhost> Date: Sat, 8 Nov 2003 01:11:11 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B3B@orsmsx410.jf.intel. com> Precedence: list Let me propose a very simple example system. One has a classical Unix system with dynamic streams drivers. One has a whole collection of streams modules available. One can decide to add a policer / shaper to the streams stack to change the service one is delivering. It would seem that if such a machine were an FE being controlled by a CE, one would want the CE to be able to give such an instruction. One should not have had to anticipate the particular combination one wants to deploy, and create that graph as an alternative in order to be able to invoke it. Yours, Joel M. Halpern At 01:54 PM 11/7/2003 -0800, you wrote: >Alan, > >Thanks. I think that it will be helpful to understand where that "middle >ground" is and to have an idea of the bounds of flexibility that the >protocol is expected to support. It makes sense to try to narrow in on >the amount of flexibility that we expect the protocol and model to >support by discussing real applications and usage models. > >Regards, >Ellen > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alan DeKok >Sent: Friday, November 07, 2003 10:14 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: LFB topology reconfguration > >"Deleganes, Ellen M" wrote: > > > > It seems like what is being proposed here is for the case of a very > > generic FE that contains a lot of different kinds of LFBs, and the > > services that can be supported depend on the topology configured for > > those LFBs (or various subsets of the LFBs). In this case, I can see > > where expressing all of the possible topologies might not be feasible. > > Some vendors systems are highly programmable (e.g. software), and thus >can do "anything". It's difficult for those vendors to see why they >should restrict their solutions to being described in LFBs. It's also >difficult for them to see why they need to describe their solutions, >because they can do "anything". > > At the other extreme, we have vendors with dedicated (and limited) >hardware. Their systems are too simple to implement any ForCES >protocol, and can be easily described without resorting to LFB's. > > ForCES allows everyone to meet in the middle. This means that most >vendors have to perform additional work to support ForCES, without clear >and immediate benefits. Much of the conversations (and concerns) on the >list have been about agreeing on what, exactly, those benefits are. > > Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 8 09:32:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16801 for ; Sat, 8 Nov 2003 09:32:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIU8S-0007hs-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 09:32:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIU8S-0007ho-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 09:32:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C3C876@cherry.ease.lsoft.com>; Sat, 8 Nov 2003 9:32:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59833433 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 8 Nov 2003 09:32:09 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Nov 2003 09:32:09 -0400 Received: from user-2ivfvai.dialup.mindspring.com ([165.247.253.82] helo=JLaptop.stevecrocker.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIU8F-0004lG-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 08 Nov 2003 06:32:08 -0800 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031108093145.020cbde0@localhost> Date: Sat, 8 Nov 2003 09:31:55 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FW: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list My own guess is that one would typically not need to reconfigure LFBs for a new RSVP flow. (I would not be surprised if most FEs that could support reconfiguration could not support that rate of change.) To try to fill that in a little bit, I will sketch LFBs that I think one might use to support RSVP, and then an example of a different case where I think one might need to change the LFB topology. For RSVP support, I would expect that one would have a high capacity classifier applying metadata marking indicating the bandwidth that was accepted. This would feed to a policer that would measure the rate per metadata marked flow, and compare with the accepted rate. Then all RSVP traffic would go into a high priority queue. If one were implementing RSVP support without any metadata support at all one would either need to omit policing or one would indeed need to reconfigure the LFBs to have a policer for each accepted flow. A different case where LFB modification is almost certainly necessary would come up when a service provider has an FE offering conventional IP forwarding at access line rate. Suppose that he then decides to offer a reduced rate policed service (where packets over a contracted rate are dropped). It would be necessary to add a policer into the data path. The provider could not reasonably have known beforehand that he needed such an element in his data path. (Obviously he can only make this transition if the FEs he is using support the change.) Yours, Joel M. Halpern At 09:54 AM 11/7/2003 -0800, you wrote: >I guess that largely depends on how you model LFB and the topology to >start with. >To model the LFB topology, we recommend using a combination of topological >approach and encoded state approach in the FE model dradf -v01: >"The topological approach should primarily be used when the packet >datapath forks into areas with distinct LFB classes (not just distinct >parameterizations of the same LFB classes), and when the fan-outs do not >require changes (adding/removing LFB outputs) at all or require only very >infrequent changes. Configuration information that needs to change >frequently should preferably be expressed by the internal attributes of >one or more LFBs (and hence using the encoded state approach). (Section 3.3.1)" > >The granularity of LFB also matters. The finer grain the LFBs are, the >more likely you run into dynamic topology change. > >But all in all, I still think setting up a new RSVP connection does not >result in topology change. It seems adding a new entry in the LFB table >would do it. > >Maybe if you draw out the topology example you have in your mind, that >would certainly help. > >Isn't it great that we have all these warm-up exercises on FE model before >going to the IETF meeting next week? For those of you who will be at >Minneapolis, lets make sure we continue this discussion face to face and >(hopefully) reach some consensus. > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Weiming Wang > > Sent: Thursday, November 06, 2003 5:53 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: FW: LFB topology reconfguration > > > > > > Hi Lily, > > > > I aslo would like to argue that even micro-change in a same > > servie may result in > > LFB and its connections change. Alex takes the QoS levels, I > > just want to take a RSVP connection > > setup as a consideration. When we deploy resources for a new > > RSVP connection, can we really do it only > > just by changing some LFB attributes? I think current > > all-in-one routers actually have already made such > > resources dynamic deployments, which, when reflects into > > ForCES architeture, are LFB changes. Actually I > > think such changes are not as awful to do as we might think, > > especially when the resources are already > > managed by a center network processors. > > > > Regards, > > > > Weiming > > > > ----- Original Message ----- > > From: "Alex Audu" > > To: > > Sent: Friday, November 07, 2003 7:14 AM > > Subject: Re: FW: LFB topology reconfguration > > > > > > > Hi Lily, > > > > > > Not only service change from A to B, but also, service > > level maintenance within > > > some constraints falls within bounds in my view. For > > example, one may want > > > to maintain a certain level of QoS which may require some > > sort of feedback > > > process to dynamically bring in more resources (LFBs) to > > make up for increased > > > demands, or loss of resources in some other NE. This sort > > of change may need > > > to take place much more often than the once-in-a-while > > service change. > > > > > > Regards, > > > Alex. > > > > > > "Yang, Lily L" wrote: > > > > > > > Oops ... forgot to cc to the list. Too late into the night :-) > > > > > > > > > -----Original Message----- > > > > > From: Yang, Lily L > > > > > Sent: Wednesday, November 05, 2003 6:42 PM > > > > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M. > > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > > > > Subject: LFB topology reconfguration > > > > > > > > > > Some clarifications: > > > > > 1) LFB topology (the "graph") reprensents state, not capability. > > > > > 2) There are different ways to represent topology > > capability. One way is to list all the possible graphs and > > name them up front. Then to reconfigure the LFB topology is > > to switch between the different graphs. Another way is to > > describe the linkage constraint (like LFB A can only be > > followed by LFB B and C but not D). We can argue which is > > more flexible, efficient etc later. > > > > > > > > > > But I still have some questions of my own. > > > > > 1) How feasible & frequent it really is for an FE to > > change from service A to B at runtime? I heard a few people > > said "yes, we do that today". I would really like to hear a > > few concrete examples and understand what is involved at the > > FE and CE to accomplish that. I don't consider recompiling > > codes as dynamic run time configuration. > > > > > The reason that I am asking this is that I don't want > > to end up designing some feature that is cool but nobody can > > really uses in the products. > > > > > > > > > > 2) Is providing ability to switch between graphs > > flexible enough for topology reconfiguration? I realize it is > > limited. But is it good enough? > > > > > > > > > > 3) Do we really want the ultimate flexibility to > > rearrange LFB by adding (instantiating) new LFB instances, > > deleting LFB instances, or re-connecting two LFBs (by > > deleting and then adding connections)? > > > > > Again, we can do this in ForCES, but only if people > > really see the need/benefit of it. > > > > > > > > > > 4) I imagine before you change service on FE from A to > > B, you probably have to stop sending packets to this FE all > > together if you don't want to have unpredictable behavior or > > loss of traffic temporarily. So it is almost equivalent to > > take down an FE and plug in a new one later, isn't it? > > > > > > > > > > 5) For those of you who are invovled in NPF -- Is NPF > > supporting dynamic LFB topology? We want to align ForCES and > > NPF to the same direction. > > > > > > > > > > Lily > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 8 09:41:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16965 for ; Sat, 8 Nov 2003 09:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIUH8-0007kp-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 09:41:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIUH8-0007km-00 for forces-archive@IETF.ORG; Sat, 08 Nov 2003 09:41:18 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C3C6CC@cherry.ease.lsoft.com>; Sat, 8 Nov 2003 9:41:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59833766 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 8 Nov 2003 09:41:07 -0500 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Nov 2003 09:41:07 -0400 Received: from user-2ivfvai.dialup.mindspring.com ([165.247.253.82] helo=JLaptop.stevecrocker.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIUGw-0005cm-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 08 Nov 2003 06:41:07 -0800 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031108093927.01ff2108@localhost> Date: Sat, 8 Nov 2003 09:40:55 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel. com> Precedence: list many (not all) vendors support on the fly modification of router configs in ways that change the delivered service. hence, from an operators perspective he should not need to take down a service delivery element (an FE) in order to provision new services. Yes, with some vendors and some devices he will have to. But the protocol ought to recognize that the more dynamic situation is both common and desirable. Yours, Joel At 03:58 PM 11/7/2003 -0800, you wrote: >My impression is that the state of the art engineering approach >is to bring down blades one at a time to upgrade their >firmware/software/hardware functions, using active/passive or >other HA mechanisms to retain non-stop forwarding in the face of >upgrades. In this sort of approach there is indeed FE LFB >topology change, but that change occurs while an FE is offline >(and thus not during the post-association phase). From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 9 02:50:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22962 for ; Sun, 9 Nov 2003 02:50:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIkKy-0004wq-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 02:50:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIkKx-0004wm-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 02:50:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C3D667@cherry.ease.lsoft.com>; 9 Nov 2003 2:50:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59880478 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Nov 2003 02:50:18 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Nov 2003 02:50:17 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA97oOEx011375 for ; Sun, 9 Nov 2003 07:50:24 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA97fhQ00797 for ; Sun, 9 Nov 2003 07:41:43 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110823501513071 for ; Sat, 08 Nov 2003 23:50:15 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 8 Nov 2003 23:50:15 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] LFB topology reconfguration Thread-Index: AcOmBlpEPqSswt/yT1GfUF0EbRoX/AAjWnbQ X-OriginalArrivalTime: 09 Nov 2003 07:50:15.0697 (UTC) FILETIME=[1CEAF010:01C3A696] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F6A4@orsmsx409.jf.intel.com> Date: Sat, 8 Nov 2003 23:50:15 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat still off] Joel Halpern wrote> > many (not all) vendors support on the fly modification of=20 > router configs in ways that change the delivered service. > hence, from an operators perspective he should not need to take down a > service delivery element (an FE) in order to provision new services. > Yes, with some vendors and some devices he will have to. > But the protocol ought to recognize that the more dynamic=20 > situation is both common and desirable. Hi Joel. I agree that the delivered service a FE is configured for can=20 changes at run time. My question is more along the lines of=20 whether such changes can only be supported by topology changes. =20 In general I think a good design principle for a protocol or=20 model is "just enough complexity and no more". I think having=20 dynamic topology is more complex than static topology, so I=20 want to better understand where a static approach falls down. Imagine a FE that has IPv4 and DiffServ features, and is represented by a static LFB graph as shown below (obviously a real graph would have a lot more LFBs, both in terms of additional functions and in terms of higher granularity): Ingress --> IPv4 forwarder --> DiffServ --> Egress The operator might initially not be using differentiated services. However, the FE, being capable of DiffServ, would expose the LFB graph shown above. The DiffServ LFB in this case would simply be configured to treat all traffic identically @ best effort, with no differentiated treatment of packets going on. At some point in time the operator wants to change the delivered=20 service. To do so, the operator would use some means of configuring the CE (e.g. telnet in and type in some CLI commands). In response to this, the CE would use ForCES, touching DiffServ LFB above=20 by pushing additional configuration information into it (and likely to other FEs in the NE as well). The mirroring example previously discussed is similar - a FE capable of mirroring will have some known set of points where mirroring can occur. Rather than dynamically instantiating LFBs, why not just expose the exact set of points where such mirroring can occur, since it is built into the FE? I did take a look at http://www.cyberus.ca/~hadi/patches/action/README (the example Jamal provided). The hooks appeared to be well known/ static locations in the packet processing sequence, so I think they=20 fit the static model. I assume the pipes capability mentioned is where dynamic ordering of functions can occur. However, the main application I saw was what appeared to be a hierarchical CBQ=20 functionality - which I thought there was already some consensus=20 around being supportable via a static approach? The blade down/upgrade blade/blade up I mentioned is in the context of adding entirely new functions to a FE that where not present before. In that case I agree that topology change is necessary - but my impression is that is a different case than the one being suggested above. Thanks, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Saturday, November 08, 2003 6:41 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] LFB topology reconfguration >=20 >=20 >=20 > Yours, > Joel >=20 > At 03:58 PM 11/7/2003 -0800, you wrote: > >My impression is that the state of the art engineering approach > >is to bring down blades one at a time to upgrade their > >firmware/software/hardware functions, using active/passive or > >other HA mechanisms to retain non-stop forwarding in the face of > >upgrades. In this sort of approach there is indeed FE LFB > >topology change, but that change occurs while an FE is offline > >(and thus not during the post-association phase). >=20 From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 9 11:04:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02529 for ; Sun, 9 Nov 2003 11:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIs38-00033l-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 11:04:26 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIs37-00033i-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 11:04:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C3DB72@cherry.ease.lsoft.com>; 9 Nov 2003 11:04:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59919018 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Nov 2003 11:04:24 -0500 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Nov 2003 11:04:24 -0400 Received: from user-2ivfuin.dialup.mindspring.com ([165.247.250.87] helo=JLaptop.stevecrocker.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIs33-0004hk-00 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 09 Nov 2003 08:04:22 -0800 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031109105536.01ff24b0@localhost> Date: Sun, 9 Nov 2003 11:04:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F6A4@orsmsx409.jf.intel. com> Precedence: list The issue is that there is no such thing as the "diffserv" graph segment. There are multiple different graphs that one can use to provide diffserv baseed services (there also is not just one diffserv service). If there were only one such graph, one could expect it to pre-exist. I agree with the constraint that the LFBs must pre-exist. The creation of new LFBs types is clearly outside our scope. If we want to declare topologies changes to be outside our scope, we are essentially declaring that all flexible service delivery will be meta-data based. I would prefer not to place such a constraint on our work. Another area where it becomes clear that one needs some dynamics is when one delves into complex queueing / scheduling disciplines. On the surface it appears that a single scheduler with multiple disciplines pulling from a collection of queues can cover all that is needed. (After all, that is what most routers actually have.) But if you try to model some of the complex schedulers out there (Xedia is a good example) one needs multiple levels of schedulers, and sometimes multiple levels of queues. Hence, if the topology is static then I am stuck with the queueing services I picked at rollout (probably one level) rather than being able to add more complexity later. Another issue example is tunnelling. I could easily install a box with support for multiple tunneling protocols. I might initially be using none of them. It could easily have constraints that it supports 6 different kinds of tunnels, but can only use up to 4 of them in any config (internal resource constraint). I am then required to guess which 4 I will want during my service evolution, or can I roll out with the one I need now, and adjust the topology to add services as I go forward. Another aspect here is consistent simplicity. Many flexible FEs will come up with a blank topology. We could declare that setting the topology up to match the CEs needs is outside the scope of the protocol. But that will significantly reduce the CE - FE interoperability. I well understand that to get the work done we need to reduce scope. But unless we really are saying that the only important scope is the IP forwarding table, I think removing topology change from scope will seriously restrict our capabilities. Yours, Joel M. Halpern At 11:50 PM 11/8/2003 -0800, you wrote: >[chair hat still off] >Joel Halpern wrote> > > many (not all) vendors support on the fly modification of > > router configs in ways that change the delivered service. > > hence, from an operators perspective he should not need to take down a > > service delivery element (an FE) in order to provision new services. > > Yes, with some vendors and some devices he will have to. > > But the protocol ought to recognize that the more dynamic > > situation is both common and desirable. > >Hi Joel. > >I agree that the delivered service a FE is configured for can >changes at run time. My question is more along the lines of >whether such changes can only be supported by topology changes. >In general I think a good design principle for a protocol or >model is "just enough complexity and no more". I think having >dynamic topology is more complex than static topology, so I >want to better understand where a static approach falls down. > >Imagine a FE that has IPv4 and DiffServ features, and is represented >by a static LFB graph as shown below (obviously a real >graph would have a lot more LFBs, both in terms of additional >functions and in terms of higher granularity): > >Ingress --> IPv4 forwarder --> DiffServ --> Egress > >The operator might initially not be using differentiated services. >However, the FE, being capable of DiffServ, would expose the LFB >graph shown above. The DiffServ LFB in this case would simply >be configured to treat all traffic identically @ best effort, >with no differentiated treatment of packets going on. > >At some point in time the operator wants to change the delivered >service. To do so, the operator would use some means of configuring >the CE (e.g. telnet in and type in some CLI commands). In response >to this, the CE would use ForCES, touching DiffServ LFB above >by pushing additional configuration information into it (and >likely to other FEs in the NE as well). The mirroring example >previously discussed is similar - a FE capable of mirroring will >have some known set of points where mirroring can occur. Rather >than dynamically instantiating LFBs, why not just expose the exact >set of points where such mirroring can occur, since it is built >into the FE? > >I did take a look at http://www.cyberus.ca/~hadi/patches/action/README >(the example Jamal provided). The hooks appeared to be well known/ >static locations in the packet processing sequence, so I think they >fit the static model. I assume the pipes capability mentioned is >where dynamic ordering of functions can occur. However, the main >application I saw was what appeared to be a hierarchical CBQ >functionality - which I thought there was already some consensus >around being supportable via a static approach? > >The blade down/upgrade blade/blade up I mentioned is in the >context of adding entirely new functions to a FE that where >not present before. In that case I agree that topology change >is necessary - but my impression is that is a different case >than the one being suggested above. > >Thanks, >David > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > Sent: Saturday, November 08, 2003 6:41 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] LFB topology reconfguration > > > > > > > > Yours, > > Joel > > > > At 03:58 PM 11/7/2003 -0800, you wrote: > > >My impression is that the state of the art engineering approach > > >is to bring down blades one at a time to upgrade their > > >firmware/software/hardware functions, using active/passive or > > >other HA mechanisms to retain non-stop forwarding in the face of > > >upgrades. In this sort of approach there is indeed FE LFB > > >topology change, but that change occurs while an FE is offline > > >(and thus not during the post-association phase). > > From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 9 16:27:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10984 for ; Sun, 9 Nov 2003 16:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIx6H-0007LV-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 16:28:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AIx6G-0007LS-00 for forces-archive@IETF.ORG; Sun, 09 Nov 2003 16:28:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C3DD4F@cherry.ease.lsoft.com>; 9 Nov 2003 16:28:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 59929717 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Nov 2003 16:28:01 -0500 Received: from 195.212.29.156 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Nov 2003 16:28:00 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9LRcxm019118 for ; Sun, 9 Nov 2003 21:27:38 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9LRSb9255446 for ; Sun, 9 Nov 2003 22:27:28 +0100 Received: from zurich.ibm.com (sig-9-145-227-92.de.ibm.com [9.145.227.92]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA42866 for ; Sun, 9 Nov 2003 22:27:27 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id hA9LRcxm019118 Approved-By: Robert Haas Message-ID: <3FAEB13E.5090209@zurich.ibm.com> Date: Sun, 9 Nov 2003 22:27:26 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: LFB topology reconfguration & Active Networking To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: quoted-printable On the active networking (AN) question raised by David: There are roughly two approaches in AN, one is the really active=20 approach (each packet specifies the code that it must be processed with=20 in its journey through the network). The other is the programmable=20 approach, in which code/plug-ins/service-modules are dynamically added=20 into network nodes by some signaling mechanism. An example of each:=20 =20 1) An active packet may specify which LFBs it want to be processed with.=20 New specific LFBs may have to be "installed". The "path" across LFBs is=20 decided by the packet itself. One LFB may even be a virtual execution=20 environment. 2) A new service may be deployed in a network by specifying how LFBs=20 should be configured, possibly requesting new LFBs to be "installed"=20 wherever possible/necessary. 2) is receiving much attention in the (european) AN community nowadays.=20 It addresses the problem of dynamic service provisioning, which is=20 believed to be crucial for ISPs to switftly provide competitive=20 services. The relevance of ForCES is therefore high, as interoperable=20 products depend on it. For those interested in further reading, there are various papers=20 describing implementations of AN in network processors, one I=20 co-authored in the August 2003 issue of IEEE Network. More by Roman=20 Pletka et al in the upcoming IWAN 2003 conference. Regards, -Robert Putzolu, David wrote: >[chair hat off] > > =20 > >>From: Forwarding and Control Element Separation=20 >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alan DeKok >>Sent: Thursday, November 06, 2003 7:33 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: [FORCES] LFB topology reconfguration >> >> For me, the boundary between internal changes to an LFB's >>configuration, and changes to inter-LFB connections is most often a >>protocol boundary. Provisioning new connections/services within a >>protocol requires updating entries in the LFB's which implement that >>protocol. Provisioning a new protocol requires re-arranging LFB's, or >>creating new LFB's. >> =20 >> > >Hi Alan. > >Can you (or others) clarify a bit further on this? > >In particular, I am trying to understand if there is a requirement >to add support for entirely new protocols (or other such actions=20 >requiring LFB rearranging) at run time, and if so, what is the=20 >concrete example that requires a LFB-rearranging mechanism? > >My impression is that the state of the art engineering approach >is to bring down blades one at a time to upgrade their=20 >firmware/software/hardware functions, using active/passive or >other HA mechanisms to retain non-stop forwarding in the face of >upgrades. In this sort of approach there is indeed FE LFB=20 >topology change, but that change occurs while an FE is offline >(and thus not during the post-association phase). > >I am aware of active networking approaches that allow a more=20 >dynamic, runtime-based reconfiguration of FE functionality. =20 >Are these what people have in mind, and if so, are they=20 >engineering practice (shipping product) or still research? > >Thanks, >David > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 06:34:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16243 for ; Mon, 10 Nov 2003 06:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJAJW-0003AG-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 06:34:34 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJAJV-0003AC-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 06:34:33 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C3EBB8@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 6:34:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60015495 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 06:34:33 -0500 Received: from 137.222.10.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 06:34:33 -0400 Received: from ncs.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 10 Nov 2003 11:33:32 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by ncs.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hAABWMM19684 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 10 Nov 2003 11:32:23 GMT References: <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel.com> Originator-Info: login-token=Mulberry:01RDVhT6mawsN8dtq5cqqbjrh8l9dyhLarj7GBn9pzcqdj1ro=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <437505559.1068463942@EEN9169.een.bris.ac.uk> Date: Mon, 10 Nov 2003 11:32:22 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hi All, I'm writing to express my opinion about the ForCES model draft in my role as editor of the corresponding document in the Network Processing Forum. There are only two points that I can tease out as separate from the ongoing discussion threads. First, the main gripe I have right now is about terminology. The requirements and purpose of the NPF and IETF models overlap sufficiently well that we can use the same names for things. Specifically, at present NPF uses "resources" as a term where the IETF text refers to "attributes". Neither is good enough right now - NPF probably doesn't qualify resources enough, while the ITEF text has at least three categories of attribute. It would be good to get this aligned. My point: several of the IETF editors are also present and contributing in the NPF, so it shouldn't be too hard. Second, as a general comment, there are several parts of the draft that I would find too constraining because they seem to imply [assumptions about] implementation behaviour. For example, section 4.4.4: metadata pass through limitations, metadata CONSUME/PROPAGATE mode selector. I think this comes about because of the dynamic reconfiguration capability that the model is apparently intended to support, which requires a very specific operational model and semantics if it is to be invoked at a fine grain by the CE. My point: this capability isn't, as far as I can tell, a ForCES requirement on the model. Or am I mistaken? Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 11:03:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26942 for ; Mon, 10 Nov 2003 11:03:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEVf-0006uL-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:03:23 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJEVe-0006uI-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:03:22 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3F01D@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:03:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60037464 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:03:21 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:03:21 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAG3Kc18873 for ; Mon, 10 Nov 2003 18:03:20 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 18:03:20 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 08:03:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: LFB topology reconfguration Thread-Index: AcOkD4yJ6Yk8cmsgRtCY4Bcmyf+dKgAAWlYwAOE4PmA= X-OriginalArrivalTime: 10 Nov 2003 16:03:00.0263 (UTC) FILETIME=[1D2F7370:01C3A7A4] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Mon, 10 Nov 2003 11:02:35 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: LFB topology reconfguration Comments: cc: david.putzolu@intel.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello Lily, Comments are inline. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of ext Yang, Lily L > Sent: Wednesday, November 05, 2003 9:54 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: FW: LFB topology reconfguration >=20 >=20 > Oops ... forgot to cc to the list. Too late into the night :-) >=20 > > -----Original Message----- > > From: Yang, Lily L =20 > > Sent: Wednesday, November 05, 2003 6:42 PM > > To: 'Zsolt Haraszti'; Khosravi, Hormuzd M; 'Joel M.=20 > Halpern'; Deleganes, Ellen M; 'Jamal Hadi Salim' > > Subject: LFB topology reconfguration > >=20 > > Some clarifications: > > 1) LFB topology (the "graph") reprensents state, not capability. > > 2) There are different ways to represent topology=20 > capability. One way is to list all the possible graphs and=20 > name them up front. Then to reconfigure the LFB topology is=20 > to switch between the different graphs. Another way is to=20 > describe the linkage constraint (like LFB A can only be=20 > followed by LFB B and C but not D). We can argue which is=20 > more flexible, efficient etc later.=20 > >=20 > > But I still have some questions of my own.=20 > > 1) How feasible & frequent it really is for an FE to change=20 > from service A to B at runtime? I heard a few people said=20 > "yes, we do that today". I would really like to hear a few=20 > concrete examples and understand what is involved at the FE=20 > and CE to accomplish that. I don't consider recompiling codes=20 > as dynamic run time configuration. =20 Let me try to provide in two parts. 1) For example consider a wireless edge providing basic 3 services like = gaming, video-on-demand and browsing. Operator provision this service = and the rate of change of such service is very slow. But there may be = several thousands of users (subscribers) subscring to this service. But = operator don't have an exact number of users (subscriber) going to = use a particular service. When a user connects to the wireless depending = upon the user's subscription the LFB instances in the FE are configured. = =20 It may happen that at a given instance that all the users subscribed are = subscribed to the same service and connected via same FE will have one = topology (processing path). But if users are subscribed to various services and connected to the = same FE then there may one or more processing path( LFB topology). =20 Most of the subscriber provision has either time-out or some for = teardown associated with it and changing from Service A to B may = require deleting or modifying existing LFB instances. To summarize, - We can have situation where user(s) are subscribed to only one = service. (say only IPv4 traffic)=20 - It may also be possible that where the users are subscribed to more = than one services. ( say IPv4 and IPv6 traffic) In the later case, you may need to program two sets of LFB instances to = achieve different processing (service) path. 2) NPE has bunch of LFB, NPE should provide capabilities to manipulate LFB = interconnection via LFB configuration. If this is not the case even if = we LFBs in the but doesn't support such reorganization of stage = processing we will not be able to provide the required service. =20 > > The reason that I am asking this is that I don't want to=20 > end up designing some feature that is cool but nobody can=20 > really uses in the products. > >=20 > > 2) Is providing ability to switch between graphs flexible=20 > enough for topology reconfiguration? I realize it is limited.=20 > But is it good enough? > >=20 > > 3) Do we really want the ultimate flexibility to rearrange=20 > LFB by adding (instantiating) new LFB instances, deleting LFB=20 > instances, or re-connecting two LFBs (by deleting and then=20 > adding connections)? > > Again, we can do this in ForCES, but only if people really=20 > see the need/benefit of it. NPE may support static or semi-static or fully dynamic LFB topology. = IMHO we have very little flexibility with current NPE's fully dynamic = re-connecting LFB looks like beyond the scope of LFB. In the case of = fully-reconnecting LFB we may need like topology discover etc because = LFB's can be programmed in any manner by CE. =20 May be we should restrict ourselves to only semi-dynamic topology where = CE after getting FE and LFB capaiblity, configures instances of LFB to = accomudate new services (processing path). Since we are working in FE model (software) and we can keep extending = our model to any level.=20 We should ask ourselves following question. Does current NPEs supports fully dynamic LFB configuration, if so what = extent? I would suggest let David P take this with NPF as we have liaison = relationship and he can provide better answer. =20 End of my comment Regards Ramg > >=20 > > 4) I imagine before you change service on FE from A to B,=20 > you probably have to stop sending packets to this FE all=20 > together if you don't want to have unpredictable behavior or=20 > loss of traffic temporarily. So it is almost equivalent to=20 > take down an FE and plug in a new one later, isn't it?=20 > >=20 > > 5) For those of you who are invovled in NPF -- Is NPF=20 > supporting dynamic LFB topology? We want to align ForCES and=20 > NPF to the same direction. > >=20 =20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 11:18:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27698 for ; Mon, 10 Nov 2003 11:18:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEkU-0007BY-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:18:42 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJEkT-0007BU-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:18:41 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C3F206@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:18:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60039135 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:16:49 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:16:49 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJEiY-0008tj-Lg for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:16:48 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: <35CE2AD0-1399-11D8-B5F0-000393CC2112@acm.org> Date: Mon, 10 Nov 2003 10:16:16 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote: > If you mean downloading code onto FEs for new LFBs then this is > out of the current scope of ForCES is my understanding. I have seen this statement several times, but other then the assertion, don't understand why it is out of scope. There is nothing in the charter that prohibits as far as I can tell. I also don't see the architecture are precluding it. It seems to me an important capability to include even if current HW designs cannot, currently, take advantage of a full dynamic capability. It concerns me that at ever step of the decision process we seem t limit the capability and the dynamicity of the architecture and of the models. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 11:32:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28519 for ; Mon, 10 Nov 2003 11:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEy6-0007Ul-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:32:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJEy5-0007Ui-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:32:46 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C3F229@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:32:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60040088 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:32:42 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:32:42 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hAAGWii03326 for ; Mon, 10 Nov 2003 08:32:44 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Mon, 10 Nov 2003 08:32:44 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <35CE2AD0-1399-11D8-B5F0-000393CC2112@acm.org> Precedence: list I think making such a feature part of the protocol may be unnecessary. LFBs can be downloaded via other mechanisms (http(s), ssh, ftp, tftp etc). CEM-FEM communication in the preassociation or even at runtime phase can say which are trusted places to download such LFBs (and what transport to use etc). That interface may also be used to download such code (and "create or installing the LFB" to use what Robert/Joel terms) . Note you already trust the CE, so you can use the CE to store such LFBs. I think we may have bigger problems to resolve first (although i am indifferent to this). So lets not get too excited about this (peripheral issue). cheers, jamal On Mon, 10 Nov 2003, Avri Doria wrote: > On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote: > > > If you mean downloading code onto FEs for new LFBs then this is > > out of the current scope of ForCES is my understanding. > > I have seen this statement several times, but other then the assertion, > don't understand why it is out of scope. There is nothing in the > charter that prohibits as far as I can tell. I also don't see the > architecture are precluding it. > > It seems to me an important capability to include even if current HW > designs cannot, currently, take advantage of a full dynamic capability. > > It concerns me that at ever step of the decision process we seem t > limit the capability and the dynamicity of the architecture and of the > models. > > a. > From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 11:45:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29184 for ; Mon, 10 Nov 2003 11:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFAk-0007jU-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:45:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJFAk-0007jR-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:45:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C3F28E@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:45:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60042090 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:45:47 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:45:47 -0400 Received: from [130.129.64.237] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5752002 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:45:47 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel.com> <9CB758BBEE58754F8F33234D75B9F4B0190B2C@orsmsx410.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031110114242.0204c2a8@localhost> Date: Mon, 10 Nov 2003 11:45:33 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <437505559.1068463942@EEN9169.een.bris.ac.uk> Precedence: list I think that there are two issues here. We are discussing reconfigurability. I would really like to retain that (as most folks have gathered by now.) Separately, there is the question of describing and using metadata. If we are going to allow the system to talk about metadata (which seems sensible) then evenin a fexed topology the CE needs to understand how the metadata is handled. Whether the right way to do that is CONSUME / PROPAGATE or some other model entirely is still very much up in the air. We have not agreed on how to talk about metadata at all. I expect we will try to keep it in the system, and therefore we will have to talk in some fashion about how it moves / is used inside the FE, even for static topologies. Yours, Joel M. Halpern At 11:32 AM 11/10/2003 +0000, you wrote: >Second, as a general comment, there are several parts of the draft that I >would find too constraining because they seem to imply [assumptions about] >implementation behaviour. For example, section 4.4.4: metadata pass through >limitations, metadata CONSUME/PROPAGATE mode selector. I think this comes >about because of the dynamic reconfiguration capability that the model is >apparently intended to support, which requires a very specific operational >model and semantics if it is to be invoked at a fine grain by the CE. > >My point: this capability isn't, as far as I can tell, a ForCES requirement >on the model. Or am I mistaken? From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 11:54:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29806 for ; Mon, 10 Nov 2003 11:54:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFJB-00007r-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:54:33 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJFJB-00007n-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 11:54:33 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C3F2BA@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:54:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60042589 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:54:29 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:54:29 -0400 Received: from [130.129.64.237] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5752033 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:54:28 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031110115123.01ff4f80@localhost> Date: Mon, 10 Nov 2003 11:54:12 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <35CE2AD0-1399-11D8-B5F0-000393CC2112@acm.org> Precedence: list My only concern is that defining the protocol envelop for carrying code fragments gets rather "interesting". I certainly would hope / expect that the architecture would not preclude supporting this in the future. Partially, I am trying to find a reasonable balance point on what we include in the initial support. I was trying to suggest that reconfigurable topology but not reconfigurable LFB types was a reasonable and useful point for the initial protocol. We should always be watching both sides of the tension, to provide enough capability to be useful but not so much that we can not complete the task. Yours, Joel M. Halpern At 10:16 AM 11/10/2003 -0600, you wrote: >On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote: > >>If you mean downloading code onto FEs for new LFBs then this is >>out of the current scope of ForCES is my understanding. > >I have seen this statement several times, but other then the assertion, >don't understand why it is out of scope. There is nothing in the >charter that prohibits as far as I can tell. I also don't see the >architecture are precluding it. > >It seems to me an important capability to include even if current HW >designs cannot, currently, take advantage of a full dynamic capability. > >It concerns me that at ever step of the decision process we seem t >limit the capability and the dynamicity of the architecture and of the >models. > >a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 14:19:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06983 for ; Mon, 10 Nov 2003 14:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHZO-0002iW-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 14:19:26 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJHZO-0002iT-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 14:19:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C3F7B9@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 14:19:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60056294 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 14:19:25 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 14:19:25 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 980C81F00D1 for ; Mon, 10 Nov 2003 14:19:24 -0500 (EST) Received: from idt.com (phoenix.ott.idt.com [192.168.102.13]) by post.ott.idt.com (Postfix) with ESMTP id 34F881F00BD for ; Mon, 10 Nov 2003 14:19:23 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0A4331C@orsmsx410.jf.intel.com> <5.1.0.14.0.20031110115123.01ff4f80@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FAECB6C.EC662552@idt.com> Date: Sun, 9 Nov 2003 18:19:09 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > My only concern is that defining the protocol envelop for carrying code > fragments gets rather "interesting". I certainly would hope / expect that > the architecture would not preclude supporting this in the future. Security considerations make this capability very problematic. Email systems sending viruses are on thing, but re-programming an FE on the fly has a whole other set of issues. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 14:33:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07674 for ; Mon, 10 Nov 2003 14:33:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHnQ-0002y4-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 14:33:56 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJHnP-0002y1-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 14:33:55 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C3F6C9@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 14:33:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60057218 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 14:33:55 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 14:33:54 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJHnN-0004Su-LT for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 19:33:53 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: <886707B5-13B4-11D8-B5F0-000393CC2112@acm.org> Date: Mon, 10 Nov 2003 13:31:51 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FAECB6C.EC662552@idt.com> Precedence: list Content-Transfer-Encoding: quoted-printable On s=F6ndag, nov 9, 2003, at 17:19 US/Central, Alan DeKok wrote: > "Joel M. Halpern" wrote: >> >> My only concern is that defining the protocol envelop for carrying=20 >> code >> fragments gets rather "interesting". I certainly would hope / expect=20= >> that >> the architecture would not preclude supporting this in the future. > > Security considerations make this capability very problematic. = Email > systems sending viruses are on thing, but re-programming an FE on the > fly has a whole other set of issues. > While security concerns would definitely need to be dealt with, I don't=20= see them as being of such a nature that they would preclude the=20 possibility. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 15:21:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11303 for ; Mon, 10 Nov 2003 15:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIXQ-0003uB-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 15:21:28 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJIXQ-0003u8-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 15:21:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C3F726@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 15:21:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60062417 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 15:21:27 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 15:21:27 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAAKLOA66367 for ; Mon, 10 Nov 2003 15:21:24 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAAKLJF11051 for ; Mon, 10 Nov 2003 15:21:23 -0500 (EST) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.11.6/8.11.6) id hAAKLHc04442 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 15:21:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Approved-By: Steven Blake Message-ID: <20031110152117.A4435@newcastle.torrentnet.com> Date: Mon, 10 Nov 2003 15:21:17 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Subject: My presentations from IETF58 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list are available at: http://www.petri-meat.com/slblake/networking/drafts/forces-model.pdf netlink2.pdf Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 15:39:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12480 for ; Mon, 10 Nov 2003 15:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIoz-0004JM-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 15:39:37 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJIoz-0004JJ-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 15:39:37 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C3F6D3@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 15:39:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60063926 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 15:39:36 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 15:39:36 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAAKdr7s016739 for ; Mon, 10 Nov 2003 20:39:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAAKUk219991 for ; Mon, 10 Nov 2003 20:30:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111012392700054 for ; Mon, 10 Nov 2003 12:39:27 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 12:39:27 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOnqh3NVDBzPDdmRGyqvg1EWfjtdwADYUIw X-OriginalArrivalTime: 10 Nov 2003 20:39:27.0238 (UTC) FILETIME=[BBCAFA60:01C3A7CA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F6AA@orsmsx409.jf.intel.com> Date: Mon, 10 Nov 2003 12:39:26 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat back on] Joel Halpern wrote> > We are discussing reconfigurability. I would really like to=20 > retain that (as most folks have gathered by now.) I have an impression that there is some consensus around retaining at least some degree of reconfigurability. I would like to determine if this impression is correct or not. I request that everyone weigh in on the mailing list as to whether reconfigurability is desired or not. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 16:35:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14620 for ; Mon, 10 Nov 2003 16:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJhI-00054R-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:35:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJJhI-00054O-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:35:44 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C3F843@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 16:35:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60068106 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:35:43 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 16:35:43 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJJhG-000J0c-Aa for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 21:35:42 +0000 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: Date: Mon, 10 Nov 2003 15:35:33 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Must LFBs be used for all functionality To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Joel, During the meeting you seemed to be objecting to the point that GRMP had some mechanisms, such as security and channels between the CE and FE, built in as protocol entities as opposed to being deployed with LFBs. I guess I don't understand your point. There are various features that the protocol must have as defined by the requirements. Is the LFB is the only tool that can be used to achieve these features? I actually find some value in having some of the required elements, like security and channels between CE and FE built in, not that I am adamantly against using LFBs for this purpose if it can be done reliably - though I believe there may be a bootstrapping problem in using LFB for these purposes. But perhaps I misunderstand your objections. Thanks a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 16:52:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15447 for ; Mon, 10 Nov 2003 16:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJxG-0005Q5-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:52:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJJxG-0005Q2-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:52:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C3FA39@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 16:52:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60069406 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:52:13 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 16:52:13 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAALqa7s009659 for ; Mon, 10 Nov 2003 21:52:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAALkMX05049 for ; Mon, 10 Nov 2003 21:46:22 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111013521014716 ; Mon, 10 Nov 2003 13:52:10 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 13:52:10 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] FE model open issues Thread-Index: AcOnplI7iWPAZVPCT6KP3AQmdoPh3QALOOQA X-OriginalArrivalTime: 10 Nov 2003 21:52:10.0453 (UTC) FILETIME=[E478C050:01C3A7D4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B009FFC4@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 13:52:09 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: FE model open issues Comments: cc: zinin@psg.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Avri My reason for saying this is based on the feedback we received from the IESG on the Requirements draft that explicitly asked us to clarify this. If you see section 6.5, point#8 we added an explicit sentence to clarify this before the Requirements was approved by the IESG. The Applicability Statement authors had also asked me for the same clarification a long time back. You have raised a valid question, however on this topic I do believe that we will have to consider a lot of factors that have not been considered so far, security just being one. And although the charter may not preclude this, it does not include it either and I think we will need a charter change if we are going to get into active networking. My 2 cents Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Monday, November 10, 2003 8:16 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] FE model open issues On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote: > If you mean downloading code onto FEs for new LFBs then this is > out of the current scope of ForCES is my understanding. I have seen this statement several times, but other then the assertion, don't understand why it is out of scope. There is nothing in the charter that prohibits as far as I can tell. I also don't see the architecture are precluding it. It seems to me an important capability to include even if current HW designs cannot, currently, take advantage of a full dynamic capability. It concerns me that at ever step of the decision process we seem t limit the capability and the dynamicity of the architecture and of the models. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 16:57:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15715 for ; Mon, 10 Nov 2003 16:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK2r-0005UJ-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:58:02 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJK2q-0005U7-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 16:58:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C3F973@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 16:57:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60069634 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 16:57:58 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 16:57:57 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAALwI7s013749 for ; Mon, 10 Nov 2003 21:58:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAALq4X08968 for ; Mon, 10 Nov 2003 21:52:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111013575219475 for ; Mon, 10 Nov 2003 13:57:52 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 13:57:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOnqh3NVDBzPDdmRGyqvg1EWfjtdwADYUIwAAdVaLA= X-OriginalArrivalTime: 10 Nov 2003 21:57:52.0449 (UTC) FILETIME=[B0513310:01C3A7D5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B009FFC5@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 13:57:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I would like to have one clarification in context with this issue. In the current model, does the FE instantiate LFBs or assign Instance IDs to LFBs or is it the CE ? In other words, does the LFB Instance ID namespace belong to the FE or CE ? I have heard most everyone agreeing that FE assigns LFB instance IDs, but just wanted to make sure. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Monday, November 10, 2003 12:39 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) [chair hat back on] Joel Halpern wrote> > We are discussing reconfigurability. I would really like to=20 > retain that (as most folks have gathered by now.) I have an impression that there is some consensus around retaining at least some degree of reconfigurability. I would like to determine if this impression is correct or not. I request that everyone weigh in on the mailing list as to whether reconfigurability is desired or not. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 17:36:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18118 for ; Mon, 10 Nov 2003 17:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdu-0006KW-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 17:36:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdt-0006KT-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 17:36:17 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C3FBD9@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 17:36:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60072361 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 17:36:03 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 17:36:03 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAAMaR7s010203 for ; Mon, 10 Nov 2003 22:36:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAAMRK228414 for ; Mon, 10 Nov 2003 22:27:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111014360132562 for ; Mon, 10 Nov 2003 14:36:01 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 14:36:01 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FE model open issues Thread-Index: AcOnplI7iWPAZVPCT6KP3AQmdoPh3QALOOQAAAG6n1A= X-OriginalArrivalTime: 10 Nov 2003 22:36:01.0275 (UTC) FILETIME=[049054B0:01C3A7DB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D27155FBB@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 14:35:52 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: FE model open issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I think secure code downloading may be desirable in many circumstances beyond ForCES, but I would consider that a very different problem and should be addressed outside of ForCES. I know CAPWAP (Control and Provisioning of Wireless APsP) BOF also wanted to support this as part of the control/provisioning protocol for APs but IESG is asking to remove this from that particular group. I think it is a generic problem by itself and should be addressed separately. ForCES should be able to co-exist with such mechanism but should not get into the business of standardizing a general mechanism for secure code loading. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M Sent: Monday, November 10, 2003 1:52 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: FE model open issues Hi Avri My reason for saying this is based on the feedback we received from the IESG on the Requirements draft that explicitly asked us to clarify this. If you see section 6.5, point#8 we added an explicit sentence to clarify this before the Requirements was approved by the IESG. The Applicability Statement authors had also asked me for the same clarification a long time back. You have raised a valid question, however on this topic I do believe that we will have to consider a lot of factors that have not been considered so far, security just being one. And although the charter may not preclude this, it does not include it either and I think we will need a charter change if we are going to get into active networking. My 2 cents Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Monday, November 10, 2003 8:16 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] FE model open issues On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote: > If you mean downloading code onto FEs for new LFBs then this is > out of the current scope of ForCES is my understanding. I have seen this statement several times, but other then the assertion, don't understand why it is out of scope. There is nothing in the charter that prohibits as far as I can tell. I also don't see the architecture are precluding it. It seems to me an important capability to include even if current HW designs cannot, currently, take advantage of a full dynamic capability. It concerns me that at ever step of the decision process we seem t limit the capability and the dynamicity of the architecture and of the models. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 20:35:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28038 for ; Mon, 10 Nov 2003 20:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNRX-0001uI-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 20:35:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJNRX-0001uF-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 20:35:43 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C3FF34@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 20:35:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60085086 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 20:35:41 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 20:35:41 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAB1a47s017039 for ; Tue, 11 Nov 2003 01:36:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAB1Tou25983 for ; Tue, 11 Nov 2003 01:29:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111017353813225 for ; Mon, 10 Nov 2003 17:35:38 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 17:35:38 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Must LFBs be used for all functionality Thread-Index: AcOn0p1hrsBJqxoxThKYUV1vN7RhzgACMBgg X-OriginalArrivalTime: 11 Nov 2003 01:35:38.0937 (UTC) FILETIME=[1C8D0A90:01C3A7F4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEF1@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 17:35:38 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Must LFBs be used for all functionality To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I agree with Avri that we should separate the internal functions that are meant to satisfy ForCES requirement and the other functions that FE vendor want to provide externally (as the NE services). But we need to address security and DoS issues within ForCES protocol, not relying on such general functions present on the FE data plane. =20 I actually believe there is a more general problem here, and I've discussed with several people before but never quite found a satisfactory answer -- the problem is how we treat the internal ports (between FE and CE) & the associated ForCES protocol entities on the FE? We have (in FE model) port LFB to model the external ports. Should we also model the internal ports between FE and CE as part of the FE model and hence use (probably the same port ) LFB to describe that? That is what I meant when I called this "chicken and egg" problem at the meeting -- the internal port from FE to CE is not visible outside of NE and so quite different from the external ports. You need to have these ports up and running so that ForCES is running before you can configure the external ports (and other LFBs) on external LFBs. The rate limiting mechanism (that FACT talks about) and the DoS attack mitigation mechanism employed by GRMP are all, conceptually, some functions that specifically address the issues for these internal ports to address the security concern raised by separation of CE and FE (but not the general security concern for NE). I believe that is why Weiming said in the meeting GRMP module has to be up running before you can even "mount" (I take that as instantiate and configure) any other LFBs. I believe that is also what Avri was refereeing to as bootstrapping problem. If you open up an FE, you should see some ForCES protocol logic and internal ports for FE to connect to CE, and then all the actual logic/HW for its data plane functions. I think FE model encompasses the later but not the former. FE model does not model everything happens on FE, at least not literally.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Monday, November 10, 2003 1:36 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Must LFBs be used for all functionality Hi Joel, During the meeting you seemed to be objecting to the point that GRMP had some mechanisms, such as security and channels between the CE and FE, built in as protocol entities as opposed to being deployed with LFBs. I guess I don't understand your point. There are various features that the protocol must have as defined by the requirements. Is the LFB is the only tool that can be used to achieve these features? I actually find some value in having some of the required elements, like security and channels between CE and FE built in, not that I am adamantly against using LFBs for this purpose if it can be done reliably - though I believe there may be a bootstrapping problem in using LFB for these purposes. But perhaps I misunderstand your objections. Thanks a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 21:15:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00151 for ; Mon, 10 Nov 2003 21:15:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJO4M-0002ht-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 21:15:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJO4J-0002hp-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 21:15:47 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C40095@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 21:15:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60088544 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 21:15:46 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 21:15:46 -0400 Received: from [130.129.133.196] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5753673 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 21:15:45 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031110203520.01ff4248@localhost> Date: Mon, 10 Nov 2003 20:43:19 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Must LFBs be used for all functionality To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Actually, the examples you list are things that do belong in the ForCES protocol and I do not object to them being in GRMP. (Security meaning integrity, confidentiality, and related properties. I have indicated to multiple sets of authors and when I was at the mike that I am happy to see the protocol providing for the expility separation of the control and data channels.) What I was objecting to was specifically the protection against DoS. DoS protection is needed. It applies to the traffic that needs to be forwarded from the FE data plane to the CE. (There is no need to apply DoS protection to traffic originated by the control entity on the FE. If that traffic is attempting to DoS the CE, it will also bypass the protections. And management of the traffic rate for that traffic is easily accomplished by simpler mechanism inside the FE control logic.) From this, it follows that the traffic that needs to be monitored / controlled is coming from the data plane, it is traversing a sequence of LFBs. An LFB has decided to divert it to the CE. At that point, it is easy and natural to add relevant LFBs (chosen by the CE) to that data path. By using LFBs, we gain several nice advantages. 1) If there is a limited FE that can only do a simple job, it can do that 2) We do not need to add extra mechanisms to the control protocol for this problem 3) If we later on come up with better mechanisms, those FEs which support them can have them invoked by the CE with no protocol change. Yours, Joel M. Halpern At 03:35 PM 11/10/2003 -0600, you wrote: >Hi Joel, > >During the meeting you seemed to be objecting to the point that GRMP >had some mechanisms, such as security and channels between the CE and >FE, built in as protocol entities as opposed to being deployed with >LFBs. > >I guess I don't understand your point. There are various features that >the protocol must have as defined by the requirements. Is the LFB is >the only tool that can be used to achieve these features? I actually >find some value in having some of the required elements, like security >and channels between CE and FE built in, not that I am adamantly >against using LFBs for this purpose if it can be done reliably - though >I believe there may be a bootstrapping problem in using LFB for these >purposes. > >But perhaps I misunderstand your objections. > >Thanks > >a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 22:24:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02366 for ; Mon, 10 Nov 2003 22:24:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJP98-0003dm-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 22:24:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJP97-0003dg-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 22:24:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C4001E@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 22:24:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60093138 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 22:24:48 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 22:14:48 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAB3ElW72701; Mon, 10 Nov 2003 22:14:47 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAB3Elr41086; Mon, 10 Nov 2003 22:14:47 -0500 (EST) Received: from ericsson.com (sun01.torrentnet.com [4.18.161.124]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id hAB3EkT01680; Mon, 10 Nov 2003 22:14:47 -0500 (EST) X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B009FFC5@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: zsolt@TORRENTNET.COM Message-ID: <3FB04640.FEA0BFB7@ericsson.com> Date: Mon, 10 Nov 2003 21:15:28 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hormuzd, I agree that this is an important issue (e.g., to allow efficient multicast of config requests to many same LFBs across many FEs), but we can answer David's original straw poll without nailing this issue down. Or is there a reverse dependence you see? /zsolt "Khosravi, Hormuzd M" wrote: > > I would like to have one clarification in context with this issue. > In the current model, does the FE instantiate LFBs or assign Instance > IDs to LFBs or is it the CE ? In other words, does the LFB Instance ID > namespace belong to the FE or CE ? I have heard most everyone agreeing > that FE assigns LFB instance IDs, but just wanted to make sure. > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Monday, November 10, 2003 12:39 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Reconfigurability of FE graphs - weigh in please (was: > RE: [FORCES] ForCES model - other thoughts) > > [chair hat back on] > > Joel Halpern wrote> > > We are discussing reconfigurability. I would really like to > > retain that (as most folks have gathered by now.) > > I have an impression that there is some consensus around retaining > at least some degree of reconfigurability. I would like > to determine if this impression is correct or not. > > I request that everyone weigh in on the mailing list as to whether > reconfigurability is desired or not. > > Thanks, > David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 22:30:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02521 for ; Mon, 10 Nov 2003 22:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPEK-0003hQ-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 22:30:12 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJPEK-0003hN-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 22:30:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C401BE@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 22:30:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60093407 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 22:30:12 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 22:20:12 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAB3KBW72783; Mon, 10 Nov 2003 22:20:11 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAB3KBr41442; Mon, 10 Nov 2003 22:20:11 -0500 (EST) Received: from ericsson.com (sun01.torrentnet.com [4.18.161.124]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id hAB3KBT02117; Mon, 10 Nov 2003 22:20:11 -0500 (EST) X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD881F6AA@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: zsolt@TORRENTNET.COM Message-ID: <3FB04785.4502CF05@ericsson.com> Date: Mon, 10 Nov 2003 21:20:53 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit LFB reconfigurability is a useful thing and we should address it in the protocol/model. Regarding hit-less reconfiguration, I think we should have a statement that says that "hit-less reconfiguration is not a requirement, though implementations should obviously aim to minimize service interruption when serving LFB reconfiguration requests." /zsolt "Putzolu, David" wrote: > > [chair hat back on] > > Joel Halpern wrote> > > We are discussing reconfigurability. I would really like to > > retain that (as most folks have gathered by now.) > > I have an impression that there is some consensus around retaining > at least some degree of reconfigurability. I would like > to determine if this impression is correct or not. > > I request that everyone weigh in on the mailing list as to whether > reconfigurability is desired or not. > > Thanks, > David From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 10 23:31:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04901 for ; Mon, 10 Nov 2003 23:31:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQBu-0004ZS-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 23:31:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJQBt-0004ZP-00 for forces-archive@IETF.ORG; Mon, 10 Nov 2003 23:31:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C402DB@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 23:31:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60099927 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 23:31:38 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 23:31:38 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAB4Vkvn018314 for ; Tue, 11 Nov 2003 04:31:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAB4Plu09634 for ; Tue, 11 Nov 2003 04:25:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111020313608030 for ; Mon, 10 Nov 2003 20:31:36 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 20:31:36 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOoA2Ds04Ro5Co5Shq6M4ONTaQSzQACNkCQ X-OriginalArrivalTime: 11 Nov 2003 04:31:36.0270 (UTC) FILETIME=[B13636E0:01C3A80C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0A55E34@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 20:31:35 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Nope, its not directly related. However, it would be nice to have this clarification. Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti Sent: Monday, November 10, 2003 6:15 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Hormuzd, I agree that this is an important issue (e.g., to allow efficient multicast of config requests to many same LFBs across many FEs), but we can answer David's original straw poll without nailing this issue down. Or is there a reverse dependence you see? /zsolt "Khosravi, Hormuzd M" wrote: > > I would like to have one clarification in context with this issue. > In the current model, does the FE instantiate LFBs or assign Instance > IDs to LFBs or is it the CE ? In other words, does the LFB Instance ID > namespace belong to the FE or CE ? I have heard most everyone agreeing > that FE assigns LFB instance IDs, but just wanted to make sure. > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Monday, November 10, 2003 12:39 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Reconfigurability of FE graphs - weigh in please (was: > RE: [FORCES] ForCES model - other thoughts) > > [chair hat back on] > > Joel Halpern wrote> > > We are discussing reconfigurability. I would really like to > > retain that (as most folks have gathered by now.) > > I have an impression that there is some consensus around retaining > at least some degree of reconfigurability. I would like > to determine if this impression is correct or not. > > I request that everyone weigh in on the mailing list as to whether > reconfigurability is desired or not. > > Thanks, > David From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 00:27:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06427 for ; Tue, 11 Nov 2003 00:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJR3i-00058w-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 00:27:22 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJR3h-00058t-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 00:27:21 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C405B6@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 0:27:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60113842 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 00:27:19 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 00:27:19 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAB5RRvn014155 for ; Tue, 11 Nov 2003 05:27:27 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAB5IYJ19229 for ; Tue, 11 Nov 2003 05:18:34 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111021271624765 for ; Mon, 10 Nov 2003 21:27:16 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 21:27:15 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Must LFBs be used for all functionality Thread-Index: AcOn+bwGUdOvCIVOT+GgVBeNSdW1VgAGhjdg X-OriginalArrivalTime: 11 Nov 2003 05:27:15.0765 (UTC) FILETIME=[77B4B650:01C3A814] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D27155FBD@orsmsx410.jf.intel.com> Date: Mon, 10 Nov 2003 21:27:15 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Must LFBs be used for all functionality To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Now that you explained it, I think I was mistaken you then.=20 I was more thinking of the problem of whether or not internal ports to CE has to be modeled as LFBs as well -- my intuition is no. Because you want to get ForCES running first before you get any LFBs instantiated. But DoS doesn't come in the picture at the bootstrap time (there is not data plane traffic at the time yet) as you explained.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Monday, November 10, 2003 5:43 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Must LFBs be used for all functionality Actually, the examples you list are things that do belong in the ForCES protocol and I do not object to them being in GRMP. (Security meaning integrity, confidentiality, and related properties. I have indicated to multiple sets of authors and when I was at the mike that I am happy to see the protocol providing for the expility separation of the control and data channels.) What I was objecting to was specifically the protection against DoS. DoS protection is needed. It applies to the traffic that needs to be forwarded from the FE data plane to the CE. (There is no need to apply DoS protection to traffic originated by the control entity on the FE. If that traffic is attempting to DoS the CE, it will also bypass the protections. And management of the traffic rate for that traffic is easily accomplished by simpler mechanism inside the FE control logic.) From this, it follows that the traffic that needs to be monitored / controlled is coming from the data plane, it is traversing a sequence of LFBs. An LFB has decided to divert it to the CE. At that point, it is easy and natural to add relevant LFBs (chosen by the CE) to that data path. By using LFBs, we gain several nice advantages. 1) If there is a limited FE that can only do a simple job, it can do that 2) We do not need to add extra mechanisms to the control protocol for this problem 3) If we later on come up with better mechanisms, those FEs which support them can have them invoked by the CE with no protocol change. Yours, Joel M. Halpern At 03:35 PM 11/10/2003 -0600, you wrote: >Hi Joel, > >During the meeting you seemed to be objecting to the point that GRMP >had some mechanisms, such as security and channels between the CE and >FE, built in as protocol entities as opposed to being deployed with >LFBs. > >I guess I don't understand your point. There are various features that >the protocol must have as defined by the requirements. Is the LFB is >the only tool that can be used to achieve these features? I actually >find some value in having some of the required elements, like security >and channels between CE and FE built in, not that I am adamantly >against using LFBs for this purpose if it can be done reliably - though >I believe there may be a bootstrapping problem in using LFB for these >purposes. > >But perhaps I misunderstand your objections. > >Thanks > >a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 05:39:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26354 for ; Tue, 11 Nov 2003 05:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVw8-0000tp-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 05:39:52 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJVw7-0000tm-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 05:39:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C408BC@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 5:39:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60126282 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 05:39:51 -0500 Received: from 137.222.10.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 05:39:51 -0400 Received: from ncs.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 11 Nov 2003 10:39:40 +0000 Received: from EEN2137.een.bris.ac.uk (een2137.een.bris.ac.uk [137.222.112.137]) (authenticated (0 bits)) by ncs.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hABAcpM23592 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 11 Nov 2003 10:38:52 GMT References: <52D13A805349A249960B9943E5590BD881F6AA@orsmsx409.jf.intel.com> Originator-Info: login-token=Mulberry:01TkZsPbOrzbGGh+WnfLSsmaaGqOJgjsC8mp+LsOVhfLF04ag=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <410711832.1068547131@EEN2137.een.bris.ac.uk> Date: Tue, 11 Nov 2003 10:38:51 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F6AA@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hi All, > I have an impression that there is some consensus around retaining > at least some degree of reconfigurability. I would like > to determine if this impression is correct or not. I have tried to keep pace with, and understand, the thread and I would say that there are sufficient claims of actual reconfigurability that it should be retained. But the discussion has confused me a bit. Some systems are reconfigurable by hot-plugging blades, reloading firmware, etc. I can't see any conceptual or practical problem with this. Presumably such events will generate a stream of notifications and messages to the CE from the affected FEs. Others are reconfigurable, or programmable, by rewiring the LFB topology, and/or creating new LFB instances. I'm sceptical that this can be done incrementally, (if not done incrementally then I suppose it is similar to hot-plugging a blade), or that a functional model exists that will satisfy all of us with prior art. So, reconfigurability - SHOULD; programmability - MAY. Note: lest there be any doubt, and because someone (Ram?) mentioned the NPF, one objective of the NPF's model is to provide a framework in which FE and LFB implementations from different vendors, using different component realisations, can coexist on a blade or in a system. We have steered clear of a programmable model so far, and nobody (in the NPF to my knowledge) has yet come up with a requirement for it that can't be reduced to simple whole-blade reconfiguration. But I'm sure someone will correct me. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 09:10:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01700 for ; Tue, 11 Nov 2003 09:10:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZDs-0003Vh-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 09:10:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJZDr-0003Vc-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 09:10:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C40CAD@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 9:10:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60161386 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 09:10:19 -0500 Received: from 192.19.192.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 09:10:18 -0400 Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail2.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hABEAIt01588 for ; Tue, 11 Nov 2003 09:10:18 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hABEAHJ13681 for ; Tue, 11 Nov 2003 09:10:17 -0500 (EST) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 09:10:18 -0500 Received: from jrenwick ([135.149.251.105]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 09:10:13 -0500 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.4910.0300 Importance: Normal X-OriginalArrivalTime: 11 Nov 2003 14:10:13.0246 (UTC) FILETIME=[862459E0:01C3A85D] Approved-By: John Renwick Message-ID: Date: Tue, 11 Nov 2003 08:10:12 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <410711832.1068547131@EEN2137.een.bris.ac.uk> Precedence: list Content-Transfer-Encoding: 7bit I'm not opposed to reconfigurability, but I'm concerned that it could in some cases give the protocol (or the NPF APIs) two equally valid ways of making the same change. This would damage interoperability. As a simple example: if a Meter LFB supports a table containing multiple entries, each one holding the leaky-bucket parameters for one meter, you could create a new meter either by adding an entry to the table or by adding a new Meter LFB and linking it in to the packet path. If we permit such a choice and don't offer any guidelines or requirements on which to use, we could end up with two flavors of implementations and applications unnecessarily. So if topological reconfigurability is supported in the protocol, the WG should try to restrict the available choices somehow, perhaps recommending that protocol implementations permit it only when the same change can't be made without modifying the graph. Regards, -- John Renwick Agere Systems Software Technical Manager 1230 Northland Drive Phone: (651) 675-2986 Mendota Heights, MN 55120 FAX: (707) 897-7928 Cell: (612) 669-9397 mailto:jrenwick@agere.com http://www.agere.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > Sent: Tuesday, November 11, 2003 4:39 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > [FORCES] ForCES model - other thoughts) > > > Hi All, > > > I have an impression that there is some consensus around retaining > > at least some degree of reconfigurability. I would like > > to determine if this impression is correct or not. > > I have tried to keep pace with, and understand, the thread and I would say > that there are sufficient claims of actual reconfigurability that > it should > be retained. But the discussion has confused me a bit. > > Some systems are reconfigurable by hot-plugging blades, reloading > firmware, > etc. I can't see any conceptual or practical problem with this. Presumably > such events will generate a stream of notifications and messages to the CE > from the affected FEs. > > Others are reconfigurable, or programmable, by rewiring the LFB topology, > and/or creating new LFB instances. I'm sceptical that this can be done > incrementally, (if not done incrementally then I suppose it is similar to > hot-plugging a blade), or that a functional model exists that will satisfy > all of us with prior art. > > So, reconfigurability - SHOULD; programmability - MAY. > > Note: lest there be any doubt, and because someone (Ram?) mentioned the > NPF, one objective of the NPF's model is to provide a framework > in which FE > and LFB implementations from different vendors, using different component > realisations, can coexist on a blade or in a system. We have steered clear > of a programmable model so far, and nobody (in the NPF to my > knowledge) has > yet come up with a requirement for it that can't be reduced to simple > whole-blade reconfiguration. But I'm sure someone will correct me. > > Regards, > > Alistair > > -- > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 10:33:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06047 for ; Tue, 11 Nov 2003 10:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJaWn-0004mE-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 10:34:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJaWn-0004mB-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 10:34:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C40E13@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 10:34:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60165697 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 10:33:59 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 10:33:59 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hABFY0j14748 for ; Tue, 11 Nov 2003 07:34:00 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Tue, 11 Nov 2003 07:34:00 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Must LFBs be used for all functionality To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D27155FBD@orsmsx410.jf.intel.com> Precedence: list Model them as LFBs with flags that they are also management ports. This works quiet well. I think you may also be thinking these ports are dedicated for such work. This may not always be true. cheers, jamal On Mon, 10 Nov 2003, Yang, Lily L wrote: > Now that you explained it, I think I was mistaken you then. > I was more thinking of the problem of whether or not internal ports to > CE has to be modeled as LFBs as well -- my intuition is no. Because you > want to get ForCES running first before you get any LFBs instantiated. > But DoS doesn't come in the picture at the bootstrap time (there is not > data plane traffic at the time yet) as you explained. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 10:43:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06321 for ; Tue, 11 Nov 2003 10:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJafn-0004pp-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 10:43:19 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJafm-0004pl-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 10:43:18 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C40F79@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 10:43:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60167160 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 10:43:16 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 10:43:16 -0400 Received: from [130.129.133.196] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5754923 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 10:43:15 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <410711832.1068547131@EEN2137.een.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031111103656.0212e250@localhost> Date: Tue, 11 Nov 2003 10:42:32 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list There are some interesting proprties of your example... 1) The presence of two methods does not reduce interoperability. Assuming that the capabilities of the FE indicate that reconfigurability is permitted and that multiple meter LFBs are permitted, then the CE can try adding an LFB if it wants. 2) In reality there are cases where you will need to do both. Some implementations will have limits (by hypothesis larger than 1) on the size of a meter table. Hence even in an FE which supports tabular meters there will be times when one needs new meters. Similarly, even systems which support multiple dynamic meter LFBs will sometimes be unable to create new meter LFBs. 3) While it is true that adding reconfigurability adds some complexity to the protocol and to CEs, once we have done that interoperability still exists even with FEs that are not reconfigurable. And in particular, if an FE supports new meter LFB creation and supports new meter table entries, then the CE can use either one and it will work. Yours, Joel M. Halpern At 08:10 AM 11/11/2003 -0600, you wrote: >I'm not opposed to reconfigurability, but I'm concerned that it could in >some >cases give the protocol (or the NPF APIs) two equally valid ways of making >the >same change. This would damage interoperability. > >As a simple example: if a Meter LFB supports a table containing multiple >entries, each one holding the leaky-bucket parameters for one meter, you >could >create a new meter either by adding an entry to the table or by adding a new >Meter LFB and linking it in to the packet path. If we permit such a choice >and >don't offer any guidelines or requirements on which to use, we could end up >with >two flavors of implementations and applications unnecessarily. > >So if topological reconfigurability is supported in the protocol, the WG >should >try to restrict the available choices somehow, perhaps recommending that >protocol >implementations permit it only when the same change can't be made without >modifying the graph. > >Regards, > >-- >John Renwick Agere Systems >Software Technical Manager 1230 Northland Drive >Phone: (651) 675-2986 Mendota Heights, MN 55120 >FAX: (707) 897-7928 Cell: (612) 669-9397 >mailto:jrenwick@agere.com http://www.agere.com > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > > Sent: Tuesday, November 11, 2003 4:39 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > > [FORCES] ForCES model - other thoughts) > > > > > > Hi All, > > > > > I have an impression that there is some consensus around retaining > > > at least some degree of reconfigurability. I would like > > > to determine if this impression is correct or not. > > > > I have tried to keep pace with, and understand, the thread and I would say > > that there are sufficient claims of actual reconfigurability that > > it should > > be retained. But the discussion has confused me a bit. > > > > Some systems are reconfigurable by hot-plugging blades, reloading > > firmware, > > etc. I can't see any conceptual or practical problem with this. Presumably > > such events will generate a stream of notifications and messages to the CE > > from the affected FEs. > > > > Others are reconfigurable, or programmable, by rewiring the LFB topology, > > and/or creating new LFB instances. I'm sceptical that this can be done > > incrementally, (if not done incrementally then I suppose it is similar to > > hot-plugging a blade), or that a functional model exists that will satisfy > > all of us with prior art. > > > > So, reconfigurability - SHOULD; programmability - MAY. > > > > Note: lest there be any doubt, and because someone (Ram?) mentioned the > > NPF, one objective of the NPF's model is to provide a framework > > in which FE > > and LFB implementations from different vendors, using different component > > realisations, can coexist on a blade or in a system. We have steered clear > > of a programmable model so far, and nobody (in the NPF to my > > knowledge) has > > yet come up with a requirement for it that can't be reduced to simple > > whole-blade reconfiguration. But I'm sure someone will correct me. > > > > Regards, > > > > Alistair > > > > -- > > Alistair Munro, > > Principal Engineer, U4EA Technologies Ltd. > > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > > E-mail: Alistair.Munro@u4eatech.com > > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > > +44-7974-922-442; > > Fax: +44-117-373-6751 > > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:00:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07160 for ; Tue, 11 Nov 2003 11:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJawK-000559-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:00:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJawJ-000556-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:00:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C40EE0@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:00:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60168553 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:00:19 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:00:19 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hABG0Kd14958 for ; Tue, 11 Nov 2003 08:00:20 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Tue, 11 Nov 2003 08:00:19 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031111103656.0212e250@localhost> Precedence: list On Tue, 11 Nov 2003, Joel M. Halpern wrote: > 3) While it is true that adding reconfigurability adds some complexity to > the protocol and to CEs, once we have done that interoperability still > exists even with FEs that are not reconfigurable. And in particular, if an > FE supports new meter LFB creation and supports new meter table entries, > then the CE can use either one and it will work. How does this affect the protocol? Maybe i am lookign at netlink2-centric view and so i may be missing the subtle issues. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:16:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07772 for ; Tue, 11 Nov 2003 11:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbCV-0005Jp-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:17:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJbCU-0005Jm-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:17:06 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C40EDF@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:17:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60170019 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:17:04 -0500 Received: from 192.19.192.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:17:04 -0400 Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail2.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hABGH4t05995 for ; Tue, 11 Nov 2003 11:17:04 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hABGH3J18923 for ; Tue, 11 Nov 2003 11:17:03 -0500 (EST) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:17:03 -0500 Received: from jrenwick ([135.149.251.80]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:17:02 -0500 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.4910.0300 Importance: Normal X-OriginalArrivalTime: 11 Nov 2003 16:17:03.0156 (UTC) FILETIME=[3E007740:01C3A86F] Approved-By: John Renwick Message-ID: Date: Tue, 11 Nov 2003 10:17:02 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031111103656.0212e250@localhost> Precedence: list Content-Transfer-Encoding: 7bit Joel, You're right, of course. In NPF we have an API that does the same thing (add routes) in two completely different ways, using either a single "unified" table or "discrete" tables of prefixes and next hops (http://www.npforum.org/techinfo/IPv4_IA.pdf). Since we expected this choice to involve a performance trade-off within the implementation, we added a function by which the application (CE) can ask the implementation (FE) which method it "prefers" if it supports both. I don't think anybody was completely happy with this, but it seemed to be necessary, given that no single approach (unified vs. discrete tables) could work acceptably well in all situations. Interoperability was assured only because we said implementations MUST support the (possibly suboptimal) unified mode, and could optionally support discrete mode. We didn't feel we could require applications to attempt both, in order to find out which one the implementation supports, even though that's what is required if an application wants both performance and interoperability. I think deciding on a single way of doing things is goodness. In this particular case, there were significant performance issues that were mitigated by one approach, and on the other hand, popular applications that would have needed major architectural changes if that were the only option. One way is better unless you *have* to have two. John > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, November 11, 2003 9:43 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > [FORCES] ForCES model - other thoughts) > > > There are some interesting proprties of your example... > 1) The presence of two methods does not reduce interoperability. Assuming > that the capabilities of the FE indicate that reconfigurability is > permitted and that multiple meter LFBs are permitted, then the CE can try > adding an LFB if it wants. > 2) In reality there are cases where you will need to do both. Some > implementations will have limits (by hypothesis larger than 1) on the size > of a meter table. Hence even in an FE which supports tabular meters there > will be times when one needs new meters. Similarly, even systems which > support multiple dynamic meter LFBs will sometimes be unable to create new > meter LFBs. > 3) While it is true that adding reconfigurability adds some complexity to > the protocol and to CEs, once we have done that interoperability still > exists even with FEs that are not reconfigurable. And in > particular, if an > FE supports new meter LFB creation and supports new meter table entries, > then the CE can use either one and it will work. > > Yours, > Joel M. Halpern > > At 08:10 AM 11/11/2003 -0600, you wrote: > >I'm not opposed to reconfigurability, but I'm concerned that it could in > >some > >cases give the protocol (or the NPF APIs) two equally valid ways > of making > >the > >same change. This would damage interoperability. > > > >As a simple example: if a Meter LFB supports a table containing multiple > >entries, each one holding the leaky-bucket parameters for one meter, you > >could > >create a new meter either by adding an entry to the table or by > adding a new > >Meter LFB and linking it in to the packet path. If we permit > such a choice > >and > >don't offer any guidelines or requirements on which to use, we > could end up > >with > >two flavors of implementations and applications unnecessarily. > > > >So if topological reconfigurability is supported in the protocol, the WG > >should > >try to restrict the available choices somehow, perhaps recommending that > >protocol > >implementations permit it only when the same change can't be made without > >modifying the graph. > > > >Regards, > > > >-- > >John Renwick Agere Systems > >Software Technical Manager 1230 Northland Drive > >Phone: (651) 675-2986 Mendota Heights, MN 55120 > >FAX: (707) 897-7928 Cell: (612) 669-9397 > >mailto:jrenwick@agere.com http://www.agere.com > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > > > Sent: Tuesday, November 11, 2003 4:39 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: Reconfigurability of FE graphs - weigh in please > (was: RE: > > > [FORCES] ForCES model - other thoughts) > > > > > > > > > Hi All, > > > > > > > I have an impression that there is some consensus around retaining > > > > at least some degree of reconfigurability. I would like > > > > to determine if this impression is correct or not. > > > > > > I have tried to keep pace with, and understand, the thread > and I would say > > > that there are sufficient claims of actual reconfigurability that > > > it should > > > be retained. But the discussion has confused me a bit. > > > > > > Some systems are reconfigurable by hot-plugging blades, reloading > > > firmware, > > > etc. I can't see any conceptual or practical problem with > this. Presumably > > > such events will generate a stream of notifications and > messages to the CE > > > from the affected FEs. > > > > > > Others are reconfigurable, or programmable, by rewiring the > LFB topology, > > > and/or creating new LFB instances. I'm sceptical that this can be done > > > incrementally, (if not done incrementally then I suppose it > is similar to > > > hot-plugging a blade), or that a functional model exists that > will satisfy > > > all of us with prior art. > > > > > > So, reconfigurability - SHOULD; programmability - MAY. > > > > > > Note: lest there be any doubt, and because someone (Ram?) > mentioned the > > > NPF, one objective of the NPF's model is to provide a framework > > > in which FE > > > and LFB implementations from different vendors, using > different component > > > realisations, can coexist on a blade or in a system. We have > steered clear > > > of a programmable model so far, and nobody (in the NPF to my > > > knowledge) has > > > yet come up with a requirement for it that can't be reduced to simple > > > whole-blade reconfiguration. But I'm sure someone will correct me. > > > > > > Regards, > > > > > > Alistair > > > > > > -- > > > Alistair Munro, > > > Principal Engineer, U4EA Technologies Ltd. > > > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > > > E-mail: Alistair.Munro@u4eatech.com > > > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > > > +44-7974-922-442; > > > Fax: +44-117-373-6751 > > > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:26:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08309 for ; Tue, 11 Nov 2003 11:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbLz-0005RR-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:26:55 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJbLx-0005RO-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:26:54 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C41163@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:26:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60170622 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:26:51 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:26:51 -0400 Received: from [130.129.131.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5755092 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:26:50 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031111103656.0212e250@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031111112258.02023e58@mail.stevecrocker.com> Date: Tue, 11 Nov 2003 11:26:34 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list In the particular case of meters, the existence of two "ways" is a consequence of other choices, not a goal in and of itself. We need to be able to create LFBs and adjust topology. I expect that people will want to support indexed meter LFBs which can use either port numbers of metadata to select the specific meter. I would be hestiant to prohibit such a thing from the model. And of course in reality many FEs will have limits on how many meters they can put into an LFB. While some FEs will be able to cope with this by creating multiple blocks under the cover, not all FEs will be that smart. We should (when we get far enough to usefully do so) give advice for how to use the various tools we will have in our tool kit. Yours, Joel At 10:17 AM 11/11/2003 -0600, you wrote: >Joel, > >You're right, of course. In NPF we have an API that does the same thing >(add routes) >in two completely different ways, using either a single "unified" table or >"discrete" >tables of prefixes and next hops >(http://www.npforum.org/techinfo/IPv4_IA.pdf). Since >we expected this choice to involve a performance trade-off within the >implementation, >we added a function by which the application (CE) can ask the implementation >(FE) which >method it "prefers" if it supports both. I don't think anybody was >completely happy >with this, but it seemed to be necessary, given that no single approach >(unified vs. >discrete tables) could work acceptably well in all situations. >Interoperability was >assured only because we said implementations MUST support the (possibly >suboptimal) >unified mode, and could optionally support discrete mode. We didn't feel we >could >require applications to attempt both, in order to find out which one the >implementation >supports, even though that's what is required if an application wants both >performance >and interoperability. > >I think deciding on a single way of doing things is goodness. In this >particular case, >there were significant performance issues that were mitigated by one >approach, and on >the other hand, popular applications that would have needed major >architectural changes >if that were the only option. One way is better unless you *have* to have >two. > >John > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > Sent: Tuesday, November 11, 2003 9:43 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > > [FORCES] ForCES model - other thoughts) > > > > > > There are some interesting proprties of your example... > > 1) The presence of two methods does not reduce interoperability. Assuming > > that the capabilities of the FE indicate that reconfigurability is > > permitted and that multiple meter LFBs are permitted, then the CE can try > > adding an LFB if it wants. > > 2) In reality there are cases where you will need to do both. Some > > implementations will have limits (by hypothesis larger than 1) on the size > > of a meter table. Hence even in an FE which supports tabular meters there > > will be times when one needs new meters. Similarly, even systems which > > support multiple dynamic meter LFBs will sometimes be unable to create new > > meter LFBs. > > 3) While it is true that adding reconfigurability adds some complexity to > > the protocol and to CEs, once we have done that interoperability still > > exists even with FEs that are not reconfigurable. And in > > particular, if an > > FE supports new meter LFB creation and supports new meter table entries, > > then the CE can use either one and it will work. > > > > Yours, > > Joel M. Halpern > > > > At 08:10 AM 11/11/2003 -0600, you wrote: > > >I'm not opposed to reconfigurability, but I'm concerned that it could in > > >some > > >cases give the protocol (or the NPF APIs) two equally valid ways > > of making > > >the > > >same change. This would damage interoperability. > > > > > >As a simple example: if a Meter LFB supports a table containing multiple > > >entries, each one holding the leaky-bucket parameters for one meter, you > > >could > > >create a new meter either by adding an entry to the table or by > > adding a new > > >Meter LFB and linking it in to the packet path. If we permit > > such a choice > > >and > > >don't offer any guidelines or requirements on which to use, we > > could end up > > >with > > >two flavors of implementations and applications unnecessarily. > > > > > >So if topological reconfigurability is supported in the protocol, the WG > > >should > > >try to restrict the available choices somehow, perhaps recommending that > > >protocol > > >implementations permit it only when the same change can't be made without > > >modifying the graph. > > > > > >Regards, > > > > > >-- > > >John Renwick Agere Systems > > >Software Technical Manager 1230 Northland Drive > > >Phone: (651) 675-2986 Mendota Heights, MN 55120 > > >FAX: (707) 897-7928 Cell: (612) 669-9397 > > >mailto:jrenwick@agere.com http://www.agere.com > > > > > > > -----Original Message----- > > > > From: Forwarding and Control Element Separation > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > > > > Sent: Tuesday, November 11, 2003 4:39 AM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: Reconfigurability of FE graphs - weigh in please > > (was: RE: > > > > [FORCES] ForCES model - other thoughts) > > > > > > > > > > > > Hi All, > > > > > > > > > I have an impression that there is some consensus around retaining > > > > > at least some degree of reconfigurability. I would like > > > > > to determine if this impression is correct or not. > > > > > > > > I have tried to keep pace with, and understand, the thread > > and I would say > > > > that there are sufficient claims of actual reconfigurability that > > > > it should > > > > be retained. But the discussion has confused me a bit. > > > > > > > > Some systems are reconfigurable by hot-plugging blades, reloading > > > > firmware, > > > > etc. I can't see any conceptual or practical problem with > > this. Presumably > > > > such events will generate a stream of notifications and > > messages to the CE > > > > from the affected FEs. > > > > > > > > Others are reconfigurable, or programmable, by rewiring the > > LFB topology, > > > > and/or creating new LFB instances. I'm sceptical that this can be done > > > > incrementally, (if not done incrementally then I suppose it > > is similar to > > > > hot-plugging a blade), or that a functional model exists that > > will satisfy > > > > all of us with prior art. > > > > > > > > So, reconfigurability - SHOULD; programmability - MAY. > > > > > > > > Note: lest there be any doubt, and because someone (Ram?) > > mentioned the > > > > NPF, one objective of the NPF's model is to provide a framework > > > > in which FE > > > > and LFB implementations from different vendors, using > > different component > > > > realisations, can coexist on a blade or in a system. We have > > steered clear > > > > of a programmable model so far, and nobody (in the NPF to my > > > > knowledge) has > > > > yet come up with a requirement for it that can't be reduced to simple > > > > whole-blade reconfiguration. But I'm sure someone will correct me. > > > > > > > > Regards, > > > > > > > > Alistair > > > > > > > > -- > > > > Alistair Munro, > > > > Principal Engineer, U4EA Technologies Ltd. > > > > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > > > > E-mail: Alistair.Munro@u4eatech.com > > > > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > > > > +44-7974-922-442; > > > > Fax: +44-117-373-6751 > > > > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:26:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08332 for ; Tue, 11 Nov 2003 11:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbMA-0005Rk-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:27:06 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJbM9-0005Rh-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:27:05 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C41098@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:27:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60170637 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:27:01 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:27:01 -0400 Received: from [130.129.131.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5755095 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:27:00 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031111103656.0212e250@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031111111445.01ff5668@localhost> Date: Tue, 11 Nov 2003 11:18:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list The protocol effect of the question of reconfigurability is simply whether there are protocol mechanisms to create (and presumably delete) LFBs and to create (delete / modify) links between LFBs. Once one has adopted such mechanisms, the ability to create meter instances in two ways has no impact on the protocol, and does not adversely affect interoperability. Yours, Joel At 08:00 AM 11/11/2003 -0800, you wrote: >On Tue, 11 Nov 2003, Joel M. Halpern wrote: > > > 3) While it is true that adding reconfigurability adds some complexity to > > the protocol and to CEs, once we have done that interoperability still > > exists even with FEs that are not reconfigurable. And in particular, if an > > FE supports new meter LFB creation and supports new meter table entries, > > then the CE can use either one and it will work. > >How does this affect the protocol? >Maybe i am lookign at netlink2-centric view and so i may be missing the >subtle issues. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:38:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08925 for ; Tue, 11 Nov 2003 11:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbXo-0005eK-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:39:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJbXn-0005e3-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:39:08 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C4105D@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:38:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60171021 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:38:53 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:38:50 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hABGcpQ16084 for ; Tue, 11 Nov 2003 08:38:51 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Tue, 11 Nov 2003 08:38:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031111111445.01ff5668@localhost> Precedence: list On Tue, 11 Nov 2003, Joel M. Halpern wrote: > The protocol effect of the question of reconfigurability is simply whether > there are protocol mechanisms to create (and presumably delete) LFBs and to > create (delete / modify) links between LFBs. > ok. Netlink2 can do both (which is why i was confused it is was an issue). Infact i talked about this in my presentation yesterday. I would think this is basic requirememt to be met. > Once one has adopted such mechanisms, the ability to create meter instances > in two ways has no impact on the protocol, and does not adversely affect > interoperability. nod. More related to LFB implementation details. Post association Forces shouldnt care. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 11:40:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09087 for ; Tue, 11 Nov 2003 11:40:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbZg-0005iC-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:41:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJbZf-0005hw-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 11:41:03 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C41069@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 11:41:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60171258 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 11:41:00 -0500 Received: from 192.19.192.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 11:41:00 -0400 Received: from alcerelay.agere.com (alcerelay.agere.com [128.94.210.102]) by alageremail2.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hABGext10986 for ; Tue, 11 Nov 2003 11:40:59 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alcerelay.agere.com (8.11.6/8.11.6) with ESMTP id hABGf8j23904 for ; Tue, 11 Nov 2003 11:41:08 -0500 Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:40:59 -0500 Received: from jrenwick ([135.149.251.17]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:40:53 -0500 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.4910.0300 X-OriginalArrivalTime: 11 Nov 2003 16:40:53.0456 (UTC) FILETIME=[9286ED00:01C3A872] Approved-By: John Renwick Message-ID: Date: Tue, 11 Nov 2003 10:40:53 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031111111445.01ff5668@localhost> Precedence: list Content-Transfer-Encoding: 7bit Please forgive my ignorance of the details of the three proposed protocols. Can the protocol be designed to make changes in a way that doesn't express whether the result will be adding to a table or changing the topology, and let the implementation decide how to do it? If so, topology changes could take place without the knowledge of the CE unless it explicitly rediscovers. John > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, November 11, 2003 10:18 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > [FORCES] ForCES model - other thoughts) > > > The protocol effect of the question of reconfigurability is simply whether > there are protocol mechanisms to create (and presumably delete) > LFBs and to > create (delete / modify) links between LFBs. > > Once one has adopted such mechanisms, the ability to create meter > instances > in two ways has no impact on the protocol, and does not adversely affect > interoperability. > > Yours, > Joel > > At 08:00 AM 11/11/2003 -0800, you wrote: > >On Tue, 11 Nov 2003, Joel M. Halpern wrote: > > > > > 3) While it is true that adding reconfigurability adds some > complexity to > > > the protocol and to CEs, once we have done that interoperability still > > > exists even with FEs that are not reconfigurable. And in > particular, if an > > > FE supports new meter LFB creation and supports new meter > table entries, > > > then the CE can use either one and it will work. > > > >How does this affect the protocol? > >Maybe i am lookign at netlink2-centric view and so i may be missing the > >subtle issues. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 12:08:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10478 for ; Tue, 11 Nov 2003 12:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc0V-0006Fk-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:08:47 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJc0U-0006Fg-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:08:46 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C410E6@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 12:08:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60172602 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 12:08:44 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 12:08:44 -0400 Received: from [130.129.131.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5755256 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 12:08:43 -0500 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031111111445.01ff5668@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031111120443.02118e50@mail.stevecrocker.com> Date: Tue, 11 Nov 2003 12:08:15 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list The protocol will (I expect) be explicit about whether something is an LFB attribute vs a separate LFB. However, the entire LFB structure is simply a model for exchange between the FE and the CE. The FE can do whatever it wants internally to meet the request. The FE can also say "no" to the requests. I believe / expect that the two methods of adding meters will be visible in the protocol. I believe it would be a mistake to refuse to allow adding LFBs because it can produce this duplication. I also believe that it would be an excessive topology and FE implementation requirement to say that we will never allow muti-entry meters (such a restriction would undermine our statements so far that meta-data is a useful part of the system. Removing this just to avoid one non-problematic duplication would also seem to be a mistake. Yours, Joel M. Halpern At 10:40 AM 11/11/2003 -0600, you wrote: >Please forgive my ignorance of the details of the three proposed protocols. > >Can the protocol be designed to make changes in a way that doesn't express >whether the result will be adding to a table or changing the topology, and >let the implementation decide how to do it? If so, topology changes could >take place without the knowledge of the CE unless it explicitly rediscovers. > >John > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > Sent: Tuesday, November 11, 2003 10:18 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > > [FORCES] ForCES model - other thoughts) > > > > > > The protocol effect of the question of reconfigurability is simply whether > > there are protocol mechanisms to create (and presumably delete) > > LFBs and to > > create (delete / modify) links between LFBs. > > > > Once one has adopted such mechanisms, the ability to create meter > > instances > > in two ways has no impact on the protocol, and does not adversely affect > > interoperability. > > > > Yours, > > Joel > > > > At 08:00 AM 11/11/2003 -0800, you wrote: > > >On Tue, 11 Nov 2003, Joel M. Halpern wrote: > > > > > > > 3) While it is true that adding reconfigurability adds some > > complexity to > > > > the protocol and to CEs, once we have done that interoperability still > > > > exists even with FEs that are not reconfigurable. And in > > particular, if an > > > > FE supports new meter LFB creation and supports new meter > > table entries, > > > > then the CE can use either one and it will work. > > > > > >How does this affect the protocol? > > >Maybe i am lookign at netlink2-centric view and so i may be missing the > > >subtle issues. > > > > > >cheers, > > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 12:23:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11143 for ; Tue, 11 Nov 2003 12:23:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcEW-0006RC-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:23:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJcEU-0006Qz-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:23:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C40FB8@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 12:23:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60173157 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 12:23:09 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 12:23:09 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABHN8s22542 for ; Tue, 11 Nov 2003 19:23:08 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Nov 2003 19:23:07 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 11:22:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOocNbgT/VvFhuhQfqm2O7MKS1/DQABzsrA X-OriginalArrivalTime: 11 Nov 2003 17:22:59.0217 (UTC) FILETIME=[73FF7810:01C3A878] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Tue, 11 Nov 2003 12:22:52 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello Joel, >=20 > The protocol effect of the question of reconfigurability is=20 > simply whether > there are protocol mechanisms to create (and presumably=20 > delete) LFBs and to > create (delete / modify) links between LFBs. FACT protocol has mechanism to do this. >=20 > Once one has adopted such mechanisms, the ability to create=20 > meter instances > in two ways has no impact on the protocol, and does not=20 > adversely affect > interoperability. FACT protocol is transparent to such operation Regards Ramg >=20 > Yours, > Joel >=20 > At 08:00 AM 11/11/2003 -0800, you wrote: > >On Tue, 11 Nov 2003, Joel M. Halpern wrote: > > > > > 3) While it is true that adding reconfigurability adds=20 > some complexity to > > > the protocol and to CEs, once we have done that=20 > interoperability still > > > exists even with FEs that are not reconfigurable. And in=20 > particular, if an > > > FE supports new meter LFB creation and supports new meter=20 > table entries, > > > then the CE can use either one and it will work. > > > >How does this affect the protocol? > >Maybe i am lookign at netlink2-centric view and so i may be=20 > missing the > >subtle issues. > > > >cheers, > >jamal >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 11 12:50:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13135 for ; Tue, 11 Nov 2003 12:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJceu-00075Q-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:50:32 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJcet-00075N-00 for forces-archive@IETF.ORG; Tue, 11 Nov 2003 12:50:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C41219@cherry.ease.lsoft.com>; Tue, 11 Nov 2003 12:50:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60174849 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Nov 2003 12:50:26 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Nov 2003 12:50:26 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hABHoofj012866 for ; Tue, 11 Nov 2003 17:50:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hABHfcE11042 for ; Tue, 11 Nov 2003 17:41:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111109502105796 for ; Tue, 11 Nov 2003 09:50:21 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Nov 2003 09:50:18 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOob0jjEIMWpNu4RYu2ZER2jJ9sXwAB50tQAAFCRjA= X-OriginalArrivalTime: 11 Nov 2003 17:50:18.0671 (UTC) FILETIME=[45304BF0:01C3A87C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F6B5@orsmsx409.jf.intel.com> Date: Tue, 11 Nov 2003 09:50:16 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Forwarding to list (issue with email address not matching subscribed address). -David -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com]=20 Sent: Tuesday, November 11, 2003 9:32 AM To: Forwarding and Control Element Separation Subject: RE: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) I agree with John. It would be nicer to have a=20 Single interface. But if large data bandwidht=20 interactions with FEs may need a different interface. John and Dave P. Did a good job on the NPF forum work. sue -----Original Message----- From: John Renwick [mailto:jrenwick@agere.com] Sent: Tuesday, November 11, 2003 11:17 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Joel, You're right, of course. In NPF we have an API that does the same thing (add routes) in two completely different ways, using either a single "unified" table or "discrete" tables of prefixes and next hops (http://www.npforum.org/techinfo/IPv4_IA.pdf). Since we expected this choice to involve a performance trade-off within the implementation, we added a function by which the application (CE) can ask the implementation (FE) which method it "prefers" if it supports both. I don't think anybody was completely happy with this, but it seemed to be necessary, given that no single approach (unified vs. discrete tables) could work acceptably well in all situations. Interoperability was assured only because we said implementations MUST support the (possibly suboptimal) unified mode, and could optionally support discrete mode. We didn't feel we could require applications to attempt both, in order to find out which one the implementation supports, even though that's what is required if an application wants both performance and interoperability. I think deciding on a single way of doing things is goodness. In this particular case, there were significant performance issues that were mitigated by one approach, and on the other hand, popular applications that would have needed major architectural changes if that were the only option. One way is better unless you *have* to have two. John > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, November 11, 2003 9:43 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: > [FORCES] ForCES model - other thoughts) > > > There are some interesting proprties of your example... > 1) The presence of two methods does not reduce interoperability. Assuming > that the capabilities of the FE indicate that reconfigurability is > permitted and that multiple meter LFBs are permitted, then the CE can try > adding an LFB if it wants. > 2) In reality there are cases where you will need to do both. Some > implementations will have limits (by hypothesis larger than 1) on the size > of a meter table. Hence even in an FE which supports tabular meters there > will be times when one needs new meters. Similarly, even systems which > support multiple dynamic meter LFBs will sometimes be unable to create new > meter LFBs. > 3) While it is true that adding reconfigurability adds some complexity to > the protocol and to CEs, once we have done that interoperability still > exists even with FEs that are not reconfigurable. And in > particular, if an > FE supports new meter LFB creation and supports new meter table entries, > then the CE can use either one and it will work. > > Yours, > Joel M. Halpern > > At 08:10 AM 11/11/2003 -0600, you wrote: > >I'm not opposed to reconfigurability, but I'm concerned that it could in > >some > >cases give the protocol (or the NPF APIs) two equally valid ways > of making > >the > >same change. This would damage interoperability. > > > >As a simple example: if a Meter LFB supports a table containing multiple > >entries, each one holding the leaky-bucket parameters for one meter, you > >could > >create a new meter either by adding an entry to the table or by > adding a new > >Meter LFB and linking it in to the packet path. If we permit > such a choice > >and > >don't offer any guidelines or requirements on which to use, we > could end up > >with > >two flavors of implementations and applications unnecessarily. > > > >So if topological reconfigurability is supported in the protocol, the WG > >should > >try to restrict the available choices somehow, perhaps recommending that > >protocol > >implementations permit it only when the same change can't be made without > >modifying the graph. > > > >Regards, > > > >-- > >John Renwick Agere Systems > >Software Technical Manager 1230 Northland Drive > >Phone: (651) 675-2986 Mendota Heights, MN 55120 > >FAX: (707) 897-7928 Cell: (612) 669-9397 > >mailto:jrenwick@agere.com http://www.agere.com > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alistair Munro > > > Sent: Tuesday, November 11, 2003 4:39 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: Reconfigurability of FE graphs - weigh in please > (was: RE: > > > [FORCES] ForCES model - other thoughts) > > > > > > > > > Hi All, > > > > > > > I have an impression that there is some consensus around retaining > > > > at least some degree of reconfigurability. I would like > > > > to determine if this impression is correct or not. > > > > > > I have tried to keep pace with, and understand, the thread > and I would say > > > that there are sufficient claims of actual reconfigurability that > > > it should > > > be retained. But the discussion has confused me a bit. > > > > > > Some systems are reconfigurable by hot-plugging blades, reloading > > > firmware, > > > etc. I can't see any conceptual or practical problem with > this. Presumably > > > such events will generate a stream of notifications and > messages to the CE > > > from the affected FEs. > > > > > > Others are reconfigurable, or programmable, by rewiring the > LFB topology, > > > and/or creating new LFB instances. I'm sceptical that this can be done > > > incrementally, (if not done incrementally then I suppose it > is similar to > > > hot-plugging a blade), or that a functional model exists that > will satisfy > > > all of us with prior art. > > > > > > So, reconfigurability - SHOULD; programmability - MAY. > > > > > > Note: lest there be any doubt, and because someone (Ram?) > mentioned the > > > NPF, one objective of the NPF's model is to provide a framework > > > in which FE > > > and LFB implementations from different vendors, using > different component > > > realisations, can coexist on a blade or in a system. We have > steered clear > > > of a programmable model so far, and nobody (in the NPF to my > > > knowledge) has > > > yet come up with a requirement for it that can't be reduced to simple > > > whole-blade reconfiguration. But I'm sure someone will correct me. > > > > > > Regards, > > > > > > Alistair > > > > > > -- > > > Alistair Munro, > > > Principal Engineer, U4EA Technologies Ltd. > > > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > > > E-mail: Alistair.Munro@u4eatech.com > > > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > > > +44-7974-922-442; > > > Fax: +44-117-373-6751 > > > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 12 01:27:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10296 for ; Wed, 12 Nov 2003 01:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJoTQ-0001mD-00 for forces-archive@IETF.ORG; Wed, 12 Nov 2003 01:27:28 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AJoTP-0001mA-00 for forces-archive@IETF.ORG; Wed, 12 Nov 2003 01:27:27 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C423C5@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 1:27:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60241446 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 01:27:27 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 01:27:27 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAC6Rbvn020774 for ; Wed, 12 Nov 2003 06:27:37 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAC6IcM06289 for ; Wed, 12 Nov 2003 06:18:38 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111122272632396 for ; Tue, 11 Nov 2003 22:27:26 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Nov 2003 22:27:26 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) Thread-Index: AcOnqh3NVDBzPDdmRGyqvg1EWfjtdwADYUIwAAdVaLAARC56wA== X-OriginalArrivalTime: 12 Nov 2003 06:27:26.0036 (UTC) FILETIME=[0A021940:01C3A8E6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAEFC@orsmsx410.jf.intel.com> Date: Tue, 11 Nov 2003 22:27:25 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable In the case that FE boots up with a static LFB topology already, it simply is more straightforward for FE to report the LFB topology to the CE with the LFB instance ID assigned already.=20 In the case that CE wants to reconfigure LFB topology on the FE, it seems ok for either CE or FE to assign the ID. But it probably is a good idea to let FE do that so that it is consistent in either case. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M Sent: Monday, November 10, 2003 1:58 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) I would like to have one clarification in context with this issue. In the current model, does the FE instantiate LFBs or assign Instance IDs to LFBs or is it the CE ? In other words, does the LFB Instance ID namespace belong to the FE or CE ? I have heard most everyone agreeing that FE assigns LFB instance IDs, but just wanted to make sure. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Monday, November 10, 2003 12:39 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) [chair hat back on] Joel Halpern wrote> > We are discussing reconfigurability. I would really like to=20 > retain that (as most folks have gathered by now.) I have an impression that there is some consensus around retaining at least some degree of reconfigurability. I would like to determine if this impression is correct or not. I request that everyone weigh in on the mailing list as to whether reconfigurability is desired or not. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 12 14:46:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03916 for ; Wed, 12 Nov 2003 14:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0wu-0004Zb-00 for forces-archive@IETF.ORG; Wed, 12 Nov 2003 14:46:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AK0wt-0004ZW-00 for forces-archive@IETF.ORG; Wed, 12 Nov 2003 14:46:43 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C43252@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 14:46:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60310072 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 14:46:41 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 14:46:41 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 7BFF71F0127 for ; Wed, 12 Nov 2003 14:46:38 -0500 (EST) Received: from idt.com (phoenix.ott.idt.com [192.168.102.13]) by post.ott.idt.com (Postfix) with ESMTP id EF7711F0120 for ; Wed, 12 Nov 2003 14:46:35 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-8.2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD881F69F@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FAE8B6A.D4C9CA99@idt.com> Date: Sun, 9 Nov 2003 13:46:02 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: LFB topology reconfguration To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Putzolu, David" wrote: > Can you (or others) clarify a bit further on this? > > In particular, I am trying to understand if there is a requirement > to add support for entirely new protocols (or other such actions > requiring LFB rearranging) at run time, and if so, what is the > concrete example that requires a LFB-rearranging mechanism? My examples about LFB re-configuring & topology change were meant to demonstrate what behaviours could cause LFB topology to change. I wasn't trying to say that we should require that behaviour in ForCES. > My impression is that the state of the art engineering approach > is to bring down blades one at a time to upgrade their > firmware/software/hardware functions, using active/passive or > other HA mechanisms to retain non-stop forwarding in the face of > upgrades. In this sort of approach there is indeed FE LFB > topology change, but that change occurs while an FE is offline > (and thus not during the post-association phase). I agree. > I am aware of active networking approaches that allow a more > dynamic, runtime-based reconfiguration of FE functionality. > Are these what people have in mind, and if so, are they > engineering practice (shipping product) or still research? So far as I know, they're still research. Alan DeKok. From bmnnews@altavista.net Sat Nov 15 06:35:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04886 for ; Sat, 15 Nov 2003 06:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKyiC-0006fN-00 for forces-archive@ietf.org; Sat, 15 Nov 2003 06:35:32 -0500 Received: from [203.162.21.114] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AKyi3-0006f1-00 for forces-archive@ietf.org; Sat, 15 Nov 2003 06:35:24 -0500 Reply-To: "ConstruNews" From: "Temas "Patrulhados"" To: forces-archive@ietf.org Subject: Lindenberg: opiniões "politicamente incorretas" vêm sendo marginalizadas ref.: anm X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 15 Nov 2003 06:35:24 -0500

xog EnEspañol - InEnglish

Temas "patrulhados"

Opiniões "politicamente incorretas" vêm sendo marginalizadas no debate nacional, diz Lindenberg

* Patrulhamento...

Em meios empresariais e religiosos continua repercutindo o livro "Os católicos e a economia de mercado", de autoria de Adolpho Lindenberg. O trabalho denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, comentários, livros, reportagens e opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas sociais". Noutras palavras, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Antídoto

O antídoto para esta situação de violência psicológica e espiritual consiste na difusão - por meios alternativos, se preciso for - de informações idôneas, capazes de esclarecer a opinião pública e provocar debates construtivos. Com efeito, uma vez rompidos os anteparos da censura, cada um em seu próprio ambiente poderá, sem medo, manifestar sua opinião sobre os assuntos 'patrulhados'. É a proposta inovadora de um programa de libertação ideológica, impulsionado pela coragem, em defesa do esclarecimento popular.

* Esclarecimento!

Esse programa tem alcance prático, especialmente para os católicos. O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), que favorecem as invasões de terras promovidas pelos MST, bem como às repetidas críticas à Área de Livre Comércio das Américas (ALCA), às privatizações, à alegada ameaça das multinacionais e do capital estrangeiro, e até mesmo ao plantio de transgênicos, apresenta dois inconvenientes sérios. Em primeiro lugar, tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados. Em segundo, de que as teses da Teologia da Libertação têm fundamentos sólidos na doutrina católica. Tudo isso tem muita importância prática. Com efeito, na vasta rede de movimentos contestatários, ativa no país inteiro, a ala progressista religiosa se sobressai hoje como o setor mais ativo e mais radical nas proposições.

* Temáticas

Diante deste cenário e visando alertar a opinião pública católica, o livro acima citado procura debater as seguintes temáticas:

- Capitalismo, globalização, neoliberalismo e privatizações seriam os grandes responsáveis pelos bolsões de misérias, desigualdades sociais e dependência externa (isto é, dos Estados Unidos)?

- Os programas sociais estatais seriam a solução para combater a fome, o analfabetismo, o atraso e a indigência das classes mais pobres do Brasil?

- O materialismo, o anonimato, a exclusão social, o relacionamento burocrático entre as pessoas são causados muito especialmente pelo crescimento desordenado das cidades ou sobretudo pela descristianização de nossos hábitos?

* Informe-se!

Informe-se desses assuntos - e ainda de vários outros - no livro "Os católicos e a economia de mercado". Você pode adquiri-lo, clicando nos links abaixo. E complemente seus dados com artigos de Adolpho Lindenberg que lhe serão enviados gratuitamente (clique nos links abaixo). O autor analisa tais assuntos com base na doutrina social católica, expressa nas encíclicas: discorre sobre as relações entre a economia e a moral, liberdade e responsabilidade dos atos econômicos, direito de propriedade, respeito às leis naturais no mercado, liceidade do lucro, assistência social, relações humanas na empresa e na vida civil.

* Destaque

E, por fim, um ponto com merecido destaque em "Os católicos e a economia de mercado": como as reivindicações "sociais" têm como fim o socorro aos necessitados e a diminuição de desigualdades sociais, é indispensável ter em vista que esse objetivo só poderia ser alcançado com a elevação significativa do padrão de vida do povo (para o autor, por uma dose maior de capitalismo autêntico) e sobretudo pela recristianização da sociedade. A assistência aos necessitados deve, além do mais, sempre que possível, ter um tom pessoal, familiar, típico das sociedades orgânicas harmonicamente diferenciadas, das quais ainda se encontram reflexos vivos em antigas cidades do interior brasileiro. Ali ainda hoje subsistem hospitais, creches, asilos, de iniciativa religiosa e particular, que atendem aos necessitados de modo mais humano e eficaz que a assistência estatal prestada nas grandes metrópoles.

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 30 de novembro, usando qualquer um dos três links seguintes, serão sorteados 10 exemplares do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEditora (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais SEDEX)

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 30 de novembro: R$ 8,80)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

Para solicitar alguns títulos específicos:

Artigo1 "Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone"

Artigo2 "Moral e Economia"

Artigo3 "Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz"

Artigo4 "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada"

Próximos temas:

"Capitalismo, globalização, neoliberalismo, privatizações"

"Economia de Mercado, Neoliberalismo"

"Estatização da Economia"

LINK DE REMOÇÃO

ConstruNews:Remover forces-archive@ietf.org

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 

 

From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 16 20:30:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14254 for ; Sun, 16 Nov 2003 20:30:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALYE8-00062X-00 for forces-archive@IETF.ORG; Sun, 16 Nov 2003 20:30:52 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALYE7-00062T-00 for forces-archive@IETF.ORG; Sun, 16 Nov 2003 20:30:52 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C497D8@cherry.ease.lsoft.com>; 16 Nov 2003 20:30:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60795924 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Nov 2003 20:30:50 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 16 Nov 2003 20:30:50 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAH1V51o012926 for ; Mon, 17 Nov 2003 01:31:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAH1OvL12574 for ; Mon, 17 Nov 2003 01:24:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111617304831044 for ; Sun, 16 Nov 2003 17:30:48 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Nov 2003 17:30:49 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ForCES model - other thoughts Thread-Index: AcOnfqFdLs3Xqhe+SCiPRVX7OhshcAFHZFJw X-OriginalArrivalTime: 17 Nov 2003 01:30:49.0021 (UTC) FILETIME=[6E39DED0:01C3ACAA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D27C27CA3@orsmsx410.jf.intel.com> Date: Sun, 16 Nov 2003 17:30:48 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Alistair --=20 On terminology: I agree with you we should use the same terminology between ForCES and NPF when it is appropriate. In the specific case of "resources" vs. "attributes", I would suggest NPF people (Zsolt, Steve etc.) adopt "attributes" in their NPF document, since we've discussed this before in the model team.=20 =20 On metadata pass through: The model team discussed this last week at Minneapolis and the consensus was that it is NOT needed for ForCES. So it will disappear soon from our draft. I am not sure I follow exactly what you meant when you talk about dynamic reconfiguration and the connection with metadata pass thru. Did you mean LFB topology reconfiguration? The mailing list had just witnessed some very active and healthy discussion on this very subject in the last 2-3 weeks and the consensus seems to suggest that, yes, the topology reconfiguration is considered useful and so the FE model will support it. Again, in case it is not obvious, it does not mean that every FE has to be capable of doing dynamic reconfiguration of its LFB topology. You should see all these comments being incorporated into the new v02 draft that the team is currently working on. Thank you very much for your comments. I agree it is important to keep NPF and ForCES aligned and anyone who is involved in both forums has to shoulder that responsibility. Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alistair Munro Sent: Monday, November 10, 2003 3:32 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: ForCES model - other thoughts Hi All, I'm writing to express my opinion about the ForCES model draft in my role as editor of the corresponding document in the Network Processing Forum. There are only two points that I can tease out as separate from the ongoing discussion threads. First, the main gripe I have right now is about terminology. The requirements and purpose of the NPF and IETF models overlap sufficiently well that we can use the same names for things. Specifically, at present NPF uses "resources" as a term where the IETF text refers to "attributes". Neither is good enough right now - NPF probably doesn't qualify resources enough, while the ITEF text has at least three categories of attribute. It would be good to get this aligned. My point: several of the IETF editors are also present and contributing in the NPF, so it shouldn't be too hard. Second, as a general comment, there are several parts of the draft that I would find too constraining because they seem to imply [assumptions about] implementation behaviour. For example, section 4.4.4: metadata pass through limitations, metadata CONSUME/PROPAGATE mode selector. I think this comes about because of the dynamic reconfiguration capability that the model is apparently intended to support, which requires a very specific operational model and semantics if it is to be invoked at a fine grain by the CE. My point: this capability isn't, as far as I can tell, a ForCES requirement on the model. Or am I mistaken? Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 01:52:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20510 for ; Mon, 17 Nov 2003 01:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALdFE-0002H8-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 01:52:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALdEq-0002Gz-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 01:51:57 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C49D7F@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 1:51:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60821793 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 01:51:41 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 01:51:23 -0400 Received: from wwm1([218.108.162.240]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm183fb88cc9; Mon, 17 Nov 2003 14:49:52 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0069_01C3AD1A.0F663FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006b01c3acd7$01e2c210$7b19fea9@wwm1> Date: Mon, 17 Nov 2003 14:49:53 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Fw: Presentation slides To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C3AD1A.0F663FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpBdHRhY2hlZCBhcmUgbXkgcHJlc2VudGF0aW9uIHNsaWRlcyBhdCB0aGUgNTh0aCBJ RVRGIG1lZXRpbmcuIA0KDQpUaGFuayB5b3UuDQoNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJXZWltaW5nIiA8d213YW5nMjAwMUBob3RtYWlsLmNvbT4N ClRvOiAiUHV0em9sdSwgRGF2aWQiIDxkYXZpZC5wdXR6b2x1QGludGVsLmNvbT4NCkNjOiAiRm9y d2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24iIDxGT1JDRVNAUEVBQ0guRUFT RS5MU09GVC5DT00+DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEyLCAyMDAzIDExOjI2IFBN DQpTdWJqZWN0OiBQcmVzZW50YXRpb24gc2xpZGVzDQoNCg0KPiBIaSBEYXZpZCwNCj4gDQo+IEF0 dGFjaGVkIGFyZSB0aGUgcHJlc2VudGF0aW9uIGZpbGVzLiBQbHMgY2hlY2sgaXQuIA0KPiBUaGFu ayB5b3UuIA0KPiANCj4gV2VpbWluZw0KPiANCj4g ------=_NextPart_000_0069_01C3AD1A.0F663FA0 Content-Type: application/pdf; name="GRMPPersentation.pdf" Content-Disposition: attachment; filename="GRMPPersentation.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjg4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA5MCANL0ggWyA3 OTgyIDc3NTAgXSANL0wgMzEzOTA5IA0vRSA5NzkzOSANL04gMjYgDS9UIDMxMjAzMSANPj4gDWVu ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTg4IDM3NyANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDA3ODg5IDAwMDAwIG4NCjAw MDAwMTU3MzIgMDAwMDAgbg0KMDAwMDAxNTk1MCAwMDAwMCBuDQowMDAwMDIwNjU2IDAwMDAwIG4N CjAwMDAwMjA3MDYgMDAwMDAgbg0KMDAwMDAyMDc1NiAwMDAwMCBuDQowMDAwMDIwODA2IDAwMDAw IG4NCjAwMDAwMjA4NTYgMDAwMDAgbg0KMDAwMDAyMDkwNiAwMDAwMCBuDQowMDAwMDIwOTU2IDAw MDAwIG4NCjAwMDAwMjEwMDYgMDAwMDAgbg0KMDAwMDAyMTA1NiAwMDAwMCBuDQowMDAwMDIxMTA3 IDAwMDAwIG4NCjAwMDAwMjExNTggMDAwMDAgbg0KMDAwMDAyMTIwOSAwMDAwMCBuDQowMDAwMDIx MjYwIDAwMDAwIG4NCjAwMDAwMjEzMTEgMDAwMDAgbg0KMDAwMDAyMTM2MiAwMDAwMCBuDQowMDAw MDIxNDEzIDAwMDAwIG4NCjAwMDAwMjE0NjQgMDAwMDAgbg0KMDAwMDAyMTUxNSAwMDAwMCBuDQow MDAwMDIxNTY2IDAwMDAwIG4NCjAwMDAwMjE2MTcgMDAwMDAgbg0KMDAwMDAyMTY2OCAwMDAwMCBu DQowMDAwMDIxNzE5IDAwMDAwIG4NCjAwMDAwMjE3NzAgMDAwMDAgbg0KMDAwMDAyMTgyMSAwMDAw MCBuDQowMDAwMDIxODcyIDAwMDAwIG4NCjAwMDAwMjE5MjMgMDAwMDAgbg0KMDAwMDAyMTk3NCAw MDAwMCBuDQowMDAwMDIyMDI1IDAwMDAwIG4NCjAwMDAwMjIwNjYgMDAwMDAgbg0KMDAwMDAyMjEx NyAwMDAwMCBuDQowMDAwMDIyMTY4IDAwMDAwIG4NCjAwMDAwMjIyMTkgMDAwMDAgbg0KMDAwMDAy MjI3MCAwMDAwMCBuDQowMDAwMDIyMzIxIDAwMDAwIG4NCjAwMDAwMjIzNzIgMDAwMDAgbg0KMDAw MDAyMjQyMyAwMDAwMCBuDQowMDAwMDIyNDc0IDAwMDAwIG4NCjAwMDAwMjI1MjUgMDAwMDAgbg0K MDAwMDAyMjU3NiAwMDAwMCBuDQowMDAwMDIyNjI3IDAwMDAwIG4NCjAwMDAwMjI2NzggMDAwMDAg bg0KMDAwMDAyMjcyOSAwMDAwMCBuDQowMDAwMDIyNzUxIDAwMDAwIG4NCjAwMDAwMjMzODUgMDAw MDAgbg0KMDAwMDAyMzQwNyAwMDAwMCBuDQowMDAwMDIzOTY4IDAwMDAwIG4NCjAwMDAwMjM5OTAg MDAwMDAgbg0KMDAwMDAyNDU2MiAwMDAwMCBuDQowMDAwMDI0NTg0IDAwMDAwIG4NCjAwMDAwMjUx NDggMDAwMDAgbg0KMDAwMDAyNTE3MCAwMDAwMCBuDQowMDAwMDI1NzA1IDAwMDAwIG4NCjAwMDAw MjU3MjcgMDAwMDAgbg0KMDAwMDAyNjI2OCAwMDAwMCBuDQowMDAwMDI2NzQ4IDAwMDAwIG4NCjAw MDAwMjY5NDUgMDAwMDAgbg0KMDAwMDAyNzUwOSAwMDAwMCBuDQowMDAwMDI3NzEyIDAwMDAwIG4N CjAwMDAwMjc3MzQgMDAwMDAgbg0KMDAwMDAyODI5MiAwMDAwMCBuDQowMDAwMDI4NDg2IDAwMDAw IG4NCjAwMDAwMjg2NzcgMDAwMDAgbg0KMDAwMDAyODg3OCAwMDAwMCBuDQowMDAwMDI5MDcyIDAw MDAwIG4NCjAwMDAwMjkyNjcgMDAwMDAgbg0KMDAwMDAyOTQ3OSAwMDAwMCBuDQowMDAwMDI5Njgy IDAwMDAwIG4NCjAwMDAwMjk4OTMgMDAwMDAgbg0KMDAwMDAzMDA4OSAwMDAwMCBuDQowMDAwMDMw MjY5IDAwMDAwIG4NCjAwMDAwMzA0NjEgMDAwMDAgbg0KMDAwMDAzMDY1NyAwMDAwMCBuDQowMDAw MDMwODQ1IDAwMDAwIG4NCjAwMDAwMzEwMzkgMDAwMDAgbg0KMDAwMDAzMTIyNCAwMDAwMCBuDQow MDAwMDMxNDI4IDAwMDAwIG4NCjAwMDAwMzE2MjkgMDAwMDAgbg0KMDAwMDAzMTgxMiAwMDAwMCBu DQowMDAwMDMyMDAzIDAwMDAwIG4NCjAwMDAwMzIxOTIgMDAwMDAgbg0KMDAwMDAzMjM3OCAwMDAw MCBuDQowMDAwMDMyNTgyIDAwMDAwIG4NCjAwMDAwMzI3NjkgMDAwMDAgbg0KMDAwMDAzMjk2NSAw MDAwMCBuDQowMDAwMDMzMTYwIDAwMDAwIG4NCjAwMDAwMzMzNDYgMDAwMDAgbg0KMDAwMDAzMzUy NiAwMDAwMCBuDQowMDAwMDMzNzIwIDAwMDAwIG4NCjAwMDAwMzM5MTIgMDAwMDAgbg0KMDAwMDAz NDA5OSAwMDAwMCBuDQowMDAwMDM0MjgyIDAwMDAwIG4NCjAwMDAwMzQ0NjcgMDAwMDAgbg0KMDAw MDAzNDY1MyAwMDAwMCBuDQowMDAwMDM0ODQyIDAwMDAwIG4NCjAwMDAwMzUwMjggMDAwMDAgbg0K MDAwMDAzNTIxNCAwMDAwMCBuDQowMDAwMDM1Mzk3IDAwMDAwIG4NCjAwMDAwMzU1OTkgMDAwMDAg bg0KMDAwMDAzNTgwMCAwMDAwMCBuDQowMDAwMDM1OTg5IDAwMDAwIG4NCjAwMDAwMzYxNzQgMDAw MDAgbg0KMDAwMDAzNjM3NiAwMDAwMCBuDQowMDAwMDM2NTcxIDAwMDAwIG4NCjAwMDAwMzY3NTcg MDAwMDAgbg0KMDAwMDAzNjk1MyAwMDAwMCBuDQowMDAwMDM3MTMzIDAwMDAwIG4NCjAwMDAwMzcz MTMgMDAwMDAgbg0KMDAwMDAzNzUwMyAwMDAwMCBuDQowMDAwMDM3Njg4IDAwMDAwIG4NCjAwMDAw Mzc4OTUgMDAwMDAgbg0KMDAwMDAzODA4MyAwMDAwMCBuDQowMDAwMDM4Mjg0IDAwMDAwIG4NCjAw MDAwMzg0NzMgMDAwMDAgbg0KMDAwMDAzODY1OSAwMDAwMCBuDQowMDAwMDM4ODQ0IDAwMDAwIG4N CjAwMDAwMzkwNDYgMDAwMDAgbg0KMDAwMDAzOTIzMiAwMDAwMCBuDQowMDAwMDM5NDIxIDAwMDAw IG4NCjAwMDAwMzk2MDYgMDAwMDAgbg0KMDAwMDAzOTc5MiAwMDAwMCBuDQowMDAwMDM5OTc4IDAw MDAwIG4NCjAwMDAwNDAxNjQgMDAwMDAgbg0KMDAwMDA0MDM0NCAwMDAwMCBuDQowMDAwMDQwNTI5 IDAwMDAwIG4NCjAwMDAwNDA3MjUgMDAwMDAgbg0KMDAwMDA0MDkyMCAwMDAwMCBuDQowMDAwMDQx MTEwIDAwMDAwIG4NCjAwMDAwNDEyOTYgMDAwMDAgbg0KMDAwMDA0MTQ4NSAwMDAwMCBuDQowMDAw MDQxNjgxIDAwMDAwIG4NCjAwMDAwNDE4NjEgMDAwMDAgbg0KMDAwMDA0MjA0MSAwMDAwMCBuDQow MDAwMDQyMjI3IDAwMDAwIG4NCjAwMDAwNDI0MDcgMDAwMDAgbg0KMDAwMDA0MjU5MyAwMDAwMCBu DQowMDAwMDQyNzc2IDAwMDAwIG4NCjAwMDAwNDI5NjUgMDAwMDAgbg0KMDAwMDA0MzE0NSAwMDAw MCBuDQowMDAwMDQzMzMwIDAwMDAwIG4NCjAwMDAwNDM1MTAgMDAwMDAgbg0KMDAwMDA0MzY5OSAw MDAwMCBuDQowMDAwMDQzODc5IDAwMDAwIG4NCjAwMDAwNDQwNjUgMDAwMDAgbg0KMDAwMDA0NDI1 MSAwMDAwMCBuDQowMDAwMDQ0NDQyIDAwMDAwIG4NCjAwMDAwNDQ2NDIgMDAwMDAgbg0KMDAwMDA0 NDgzMSAwMDAwMCBuDQowMDAwMDQ1MDE2IDAwMDAwIG4NCjAwMDAwNDUyMDIgMDAwMDAgbg0KMDAw MDA0NTM4OCAwMDAwMCBuDQowMDAwMDQ1NTc0IDAwMDAwIG4NCjAwMDAwNDU3NjcgMDAwMDAgbg0K MDAwMDA0NTk1MiAwMDAwMCBuDQowMDAwMDQ2MTM3IDAwMDAwIG4NCjAwMDAwNDYzMjIgMDAwMDAg bg0KMDAwMDA0NjUwNyAwMDAwMCBuDQowMDAwMDQ2NzA1IDAwMDAwIG4NCjAwMDAwNDY4OTAgMDAw MDAgbg0KMDAwMDA0NzA3NiAwMDAwMCBuDQowMDAwMDQ3MjYxIDAwMDAwIG4NCjAwMDAwNDc0NTQg MDAwMDAgbg0KMDAwMDA0NzYzNCAwMDAwMCBuDQowMDAwMDQ3ODIzIDAwMDAwIG4NCjAwMDAwNDgw MTMgMDAwMDAgbg0KMDAwMDA0ODE5OCAwMDAwMCBuDQowMDAwMDQ4Mzg0IDAwMDAwIG4NCjAwMDAw NDg1NzQgMDAwMDAgbg0KMDAwMDA0ODc2OCAwMDAwMCBuDQowMDAwMDQ4OTQ4IDAwMDAwIG4NCjAw MDAwNDkxMzMgMDAwMDAgbg0KMDAwMDA0OTMyNyAwMDAwMCBuDQowMDAwMDQ5NTE0IDAwMDAwIG4N CjAwMDAwNDk3MDUgMDAwMDAgbg0KMDAwMDA0OTg5NyAwMDAwMCBuDQowMDAwMDUwMDg2IDAwMDAw IG4NCjAwMDAwNTAyNzIgMDAwMDAgbg0KMDAwMDA1MDQ1NyAwMDAwMCBuDQowMDAwMDUwNjQ3IDAw MDAwIG4NCjAwMDAwNTA4NDIgMDAwMDAgbg0KMDAwMDA1MTAzMCAwMDAwMCBuDQowMDAwMDUxMjE4 IDAwMDAwIG4NCjAwMDAwNTE0MDQgMDAwMDAgbg0KMDAwMDA1MTU4OSAwMDAwMCBuDQowMDAwMDUx ODI3IDAwMDAwIG4NCjAwMDAwNTIwMDcgMDAwMDAgbg0KMDAwMDA1MjE5NiAwMDAwMCBuDQowMDAw MDUyMzg4IDAwMDAwIG4NCjAwMDAwNTI1NzcgMDAwMDAgbg0KMDAwMDA1Mjc2MyAwMDAwMCBuDQow MDAwMDUyOTQ5IDAwMDAwIG4NCjAwMDAwNTMxMzggMDAwMDAgbg0KMDAwMDA1MzMyMyAwMDAwMCBu DQowMDAwMDUzNTEyIDAwMDAwIG4NCjAwMDAwNTM3MDcgMDAwMDAgbg0KMDAwMDA1Mzg5MyAwMDAw MCBuDQowMDAwMDU0MDgxIDAwMDAwIG4NCjAwMDAwNTQyNjYgMDAwMDAgbg0KMDAwMDA1NDQ0OSAw MDAwMCBuDQowMDAwMDU0NjM0IDAwMDAwIG4NCjAwMDAwNTQ4MjAgMDAwMDAgbg0KMDAwMDA1NTAy MCAwMDAwMCBuDQowMDAwMDU1MjEwIDAwMDAwIG4NCjAwMDAwNTU0MDEgMDAwMDAgbg0KMDAwMDA1 NTU5MCAwMDAwMCBuDQowMDAwMDU1Nzc4IDAwMDAwIG4NCjAwMDAwNTU5NjMgMDAwMDAgbg0KMDAw MDA1NjE0OSAwMDAwMCBuDQowMDAwMDU2MzM0IDAwMDAwIG4NCjAwMDAwNTY1MTYgMDAwMDAgbg0K MDAwMDA1NjcwNCAwMDAwMCBuDQowMDAwMDU3MTIyIDAwMDAwIG4NCjAwMDAwNTc0NTUgMDAwMDAg bg0KMDAwMDA1NzczOCAwMDAwMCBuDQowMDAwMDU4MTc4IDAwMDAwIG4NCjAwMDAwNTg0NDkgMDAw MDAgbg0KMDAwMDA1ODc4NyAwMDAwMCBuDQowMDAwMDU5MjMyIDAwMDAwIG4NCjAwMDAwNTk2NDAg MDAwMDAgbg0KMDAwMDA1OTk3NCAwMDAwMCBuDQowMDAwMDYwMzE3IDAwMDAwIG4NCjAwMDAwNjA2 MDMgMDAwMDAgbg0KMDAwMDA2MDk1NiAwMDAwMCBuDQowMDAwMDYxNDI1IDAwMDAwIG4NCjAwMDAw NjE3NDAgMDAwMDAgbg0KMDAwMDA2MjA5NyAwMDAwMCBuDQowMDAwMDYyNTI4IDAwMDAwIG4NCjAw MDAwNjI4NjYgMDAwMDAgbg0KMDAwMDA2MzIwNiAwMDAwMCBuDQowMDAwMDYzNjcxIDAwMDAwIG4N CjAwMDAwNjQxMzAgMDAwMDAgbg0KMDAwMDA2NDQzNSAwMDAwMCBuDQowMDAwMDY0NjkyIDAwMDAw IG4NCjAwMDAwNjQ5NzAgMDAwMDAgbg0KMDAwMDA2NTI3OSAwMDAwMCBuDQowMDAwMDY1NjI1IDAw MDAwIG4NCjAwMDAwNjU5NjMgMDAwMDAgbg0KMDAwMDA2NjM4NCAwMDAwMCBuDQowMDAwMDY2ODM5 IDAwMDAwIG4NCjAwMDAwNjcxNjkgMDAwMDAgbg0KMDAwMDA2NzY0MSAwMDAwMCBuDQowMDAwMDY3 OTg3IDAwMDAwIG4NCjAwMDAwNjgyODQgMDAwMDAgbg0KMDAwMDA2ODYzMSAwMDAwMCBuDQowMDAw MDY4OTk1IDAwMDAwIG4NCjAwMDAwNjkyNTkgMDAwMDAgbg0KMDAwMDA2OTU5OCAwMDAwMCBuDQow MDAwMDcwMDMyIDAwMDAwIG4NCjAwMDAwNzA0ODAgMDAwMDAgbg0KMDAwMDA3MDgxNSAwMDAwMCBu DQowMDAwMDcxMDA0IDAwMDAwIG4NCjAwMDAwNzExODkgMDAwMDAgbg0KMDAwMDA3MTM3OSAwMDAw MCBuDQowMDAwMDcxNTY0IDAwMDAwIG4NCjAwMDAwNzE3NDYgMDAwMDAgbg0KMDAwMDA3MTk0MyAw MDAwMCBuDQowMDAwMDcyMTMzIDAwMDAwIG4NCjAwMDAwNzIzMTkgMDAwMDAgbg0KMDAwMDA3MjUw OSAwMDAwMCBuDQowMDAwMDcyNjk0IDAwMDAwIG4NCjAwMDAwNzI4NzkgMDAwMDAgbg0KMDAwMDA3 MzA2OCAwMDAwMCBuDQowMDAwMDczMjY1IDAwMDAwIG4NCjAwMDAwNzM0NTAgMDAwMDAgbg0KMDAw MDA3MzYzNiAwMDAwMCBuDQowMDAwMDczODI2IDAwMDAwIG4NCjAwMDAwNzQwMTUgMDAwMDAgbg0K MDAwMDA3NDIwMCAwMDAwMCBuDQowMDAwMDc0Mzg1IDAwMDAwIG4NCjAwMDAwNzQ1NzYgMDAwMDAg bg0KMDAwMDA3NDc2NiAwMDAwMCBuDQowMDAwMDc0OTUyIDAwMDAwIG4NCjAwMDAwNzUxNDcgMDAw MDAgbg0KMDAwMDA3NTM0MiAwMDAwMCBuDQowMDAwMDc1NTM2IDAwMDAwIG4NCjAwMDAwNzU3MjQg MDAwMDAgbg0KMDAwMDA3NTkxOCAwMDAwMCBuDQowMDAwMDc2MTIzIDAwMDAwIG4NCjAwMDAwNzYz MTMgMDAwMDAgbg0KMDAwMDA3NjQ5NSAwMDAwMCBuDQowMDAwMDc2Njk1IDAwMDAwIG4NCjAwMDAw NzY4ODAgMDAwMDAgbg0KMDAwMDA3NzA2OSAwMDAwMCBuDQowMDAwMDc3MjU3IDAwMDAwIG4NCjAw MDAwNzc0NDIgMDAwMDAgbg0KMDAwMDA3NzYzMSAwMDAwMCBuDQowMDAwMDc3ODExIDAwMDAwIG4N CjAwMDAwNzc5OTkgMDAwMDAgbg0KMDAwMDA3ODE4NSAwMDAwMCBuDQowMDAwMDc4Mzc2IDAwMDAw IG4NCjAwMDAwNzg1NjUgMDAwMDAgbg0KMDAwMDA3ODc0NSAwMDAwMCBuDQowMDAwMDc4OTMwIDAw MDAwIG4NCjAwMDAwNzkxMTUgMDAwMDAgbg0KMDAwMDA3OTMyNSAwMDAwMCBuDQowMDAwMDc5NTEw IDAwMDAwIG4NCjAwMDAwNzk3MDAgMDAwMDAgbg0KMDAwMDA3OTg4MyAwMDAwMCBuDQowMDAwMDgw MDc2IDAwMDAwIG4NCjAwMDAwODAyNjQgMDAwMDAgbg0KMDAwMDA4MDQ1MSAwMDAwMCBuDQowMDAw MDgwNjQyIDAwMDAwIG4NCjAwMDAwODA4MzMgMDAwMDAgbg0KMDAwMDA4MTAyNSAwMDAwMCBuDQow MDAwMDgxMjE3IDAwMDAwIG4NCjAwMDAwODE0MjIgMDAwMDAgbg0KMDAwMDA4MTYxMiAwMDAwMCBu DQowMDAwMDgxODA4IDAwMDAwIG4NCjAwMDAwODIwMDAgMDAwMDAgbg0KMDAwMDA4MjE5OCAwMDAw MCBuDQowMDAwMDgyMzk1IDAwMDAwIG4NCjAwMDAwODI2MDIgMDAwMDAgbg0KMDAwMDA4Mjc5OCAw MDAwMCBuDQowMDAwMDgyOTkzIDAwMDAwIG4NCjAwMDAwODMxNzggMDAwMDAgbg0KMDAwMDA4MzM3 MiAwMDAwMCBuDQowMDAwMDgzNTYxIDAwMDAwIG4NCjAwMDAwODM3NTIgMDAwMDAgbg0KMDAwMDA4 Mzk0NCAwMDAwMCBuDQowMDAwMDg0MTM5IDAwMDAwIG4NCjAwMDAwODQzNDMgMDAwMDAgbg0KMDAw MDA4NDUyNiAwMDAwMCBuDQowMDAwMDg0NzE1IDAwMDAwIG4NCjAwMDAwODQ5MDUgMDAwMDAgbg0K MDAwMDA4NTA5MyAwMDAwMCBuDQowMDAwMDg1Mjc4IDAwMDAwIG4NCjAwMDAwODU0NjYgMDAwMDAg bg0KMDAwMDA4NTY2MCAwMDAwMCBuDQowMDAwMDg1NjgyIDAwMDAwIG4NCjAwMDAwODY0NDIgMDAw MDAgbg0KMDAwMDA4NjY1NSAwMDAwMCBuDQowMDAwMDg2ODYyIDAwMDAwIG4NCjAwMDAwODcwNzgg MDAwMDAgbg0KMDAwMDA4NzMzMCAwMDAwMCBuDQowMDAwMDg3NTcwIDAwMDAwIG4NCjAwMDAwODc2 OTYgMDAwMDAgbg0KMDAwMDA4Nzc3NSAwMDAwMCBuDQowMDAwMDg3OTAxIDAwMDAwIG4NCjAwMDAw ODgxMjMgMDAwMDAgbg0KMDAwMDA4ODM2OSAwMDAwMCBuDQowMDAwMDg4NTc5IDAwMDAwIG4NCjAw MDAwODg4MjUgMDAwMDAgbg0KMDAwMDA4OTAzOCAwMDAwMCBuDQowMDAwMDg5MjYwIDAwMDAwIG4N CjAwMDAwOTE5MzggMDAwMDAgbg0KMDAwMDA5MjE0OCAwMDAwMCBuDQowMDAwMDkyMjcxIDAwMDAw IG4NCjAwMDAwOTI0NjMgMDAwMDAgbg0KMDAwMDA5MjY5NCAwMDAwMCBuDQowMDAwMDkyOTA0IDAw MDAwIG4NCjAwMDAwOTMwMzYgMDAwMDAgbg0KMDAwMDA5MzI0MyAwMDAwMCBuDQowMDAwMDkzNDM4 IDAwMDAwIG4NCjAwMDAwOTM2NDggMDAwMDAgbg0KMDAwMDA5Mzg1OCAwMDAwMCBuDQowMDAwMDk0 MDkyIDAwMDAwIG4NCjAwMDAwOTQzMjAgMDAwMDAgbg0KMDAwMDA5NDU1NCAwMDAwMCBuDQowMDAw MDk0Nzg4IDAwMDAwIG4NCjAwMDAwOTUwMjUgMDAwMDAgbg0KMDAwMDA5NTI2NSAwMDAwMCBuDQow MDAwMDk1NDc1IDAwMDAwIG4NCjAwMDAwOTU2OTEgMDAwMDAgbg0KMDAwMDA5NTkwMSAwMDAwMCBu DQowMDAwMDk2MTQ0IDAwMDAwIG4NCjAwMDAwOTYyNjcgMDAwMDAgbg0KMDAwMDA5NjUxMyAwMDAw MCBuDQowMDAwMDk2NzYyIDAwMDAwIG4NCjAwMDAwOTY5NzUgMDAwMDAgbg0KMDAwMDA5NzE1MiAw MDAwMCBuDQowMDAwMDk3MzU5IDAwMDAwIG4NCjAwMDAwOTc1NzUgMDAwMDAgbg0KMDAwMDAwNzk4 MiAwMDAwMCBuDQowMDAwMDE1NzA5IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNDY1DS9JbmZv IDg2IDAgUiANL1Jvb3QgODkgMCBSIA0vUHJldiAzMTIwMjEgDS9JRFs8M2I5NzU4ZTY1MGNmYTJj ZGVlZGY4OTllZWUxOGI1NmQ+PDE5MmIyMWJkMzg3OTg5OTU4NzViMTUxNjVmZDZiMGM5Pl0NPj4N c3RhcnR4cmVmDTANJSVFT0YNICAgIA04OSAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdl cyA4MyAwIFIgDS9NZXRhZGF0YSA4NyAwIFIgDS9QYWdlTGFiZWxzIDgxIDAgUiANPj4gDWVuZG9i ag00NjMgMCBvYmoNPDwgL1MgMTUyMTQgL0wgMTU4OTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCA0NjQgMCBSID4+IA1zdHJlYW0NCkiJ7JRXVNMJFof/CSAEIRJIqNJrMChNSkCkREhoBkmQ okKkGEORrqKOJNIhlFAFBEIIQuigtFGXIh2FBBgiCgIDCgiOUhxkR3f17MO+zeM+7fdwH+7L75x7 z/cDAEAAAJSPA5AfEwXAgP8C+7GDAIKASBfwd2TXxwOA5iIIUNCH4gU0wMcBUVBMvGO80qRYpwgZ bAimAM/iL1vrLapaK/kJ+YFHwRbAJ8Cvp4UfEqugWDDk38zfbPfRKxgKbOFvxlqIZw75t/B7/jby //zPCceqOGqI0noqrP3E4IdAIv2qFYs3rJUl0jC2JDwery1+j2YT3mysryicYAsy6Fzs9NWTHhvc oUZP+OgXZdobgQLGA9GwjKRWpArDQVMBkWyU2jlHMS5WyxraTT34Z3zP2086BHmY4L1eUjjf2RAk kWqvpr9ff0lbOsuelb32Jui0auawSOpKnJsrlaAOHyEwTpoUYiskh1eKGzAsG6WzySvUPWwMgZOD fQxZty63hI8mLHNUGpNRqpn93P39eBtViZerAWoB39nO2lK1VTjLIhek0iRbUA7FUr/6q8KHmNGl uQ9RHaXQPyNfeTd6ogrSTXl70c+8G2fps0Ze77bjTBXE7X+92joT2lkGdXBiTi/dMltokumfH/16 fmSF57XJoJ948LJ6Su75QhSqgkuG476JJlvlj7Fbiy0riZbkZtmMpChF2gTZ0DNUS0o+2DjIWcvp awkybSyoPtT02B10kwt7ui4/PbCbSaydQe4phHKeOtZ51MNHX8TOklte1X9x0vtlParTs95UQqfC FQyigklUEbIJHAEGlg1U8nS14FSqdY4ESlYJmkADlgBLediRZPCS34uFDfTRApwQ73P8I5+GwrFk AVz2G3tjBfHqtnPNCzgjRqa2IfLouvTdZ28nhuFoU4Da49tMRqlBhBP6qvCdASbmiPTn4y12ckV9 kQZ2K5KymxQj5VSMmsFar+f+Haxy1pVdURDmx+VnHIXkc6yYFkyYzrS8HDQRo56lzWpZEsyyV+M6 0rr8OBjNXFEM7z4Qd1pZ4sd3YIKVBbgqBpJo+ECnzKmawAbHkUxKXbQDGkz974R1XbC4GBa7Q134 6HOMOCbE4AYdXGosHCPOfe5+F2y5cNb+d1LNbKiJd0OHVO/wejS69MQVhZnl/VtdvrpfLYvppxjY 1Z2u6Tl/s5KXgXnyeuDU00z8e15XdLu7Q57jQ7q0ACz7pX+z19YhJ/GqPn+XoIyRhJG7RoEGXiEz 9OrVaw+J64+68yNbQjoIuo/RbCtW6OPztUTKDO2+V+PclrTFybKRwKb549cPI5KWhQVpgpXWNShR wUNAr7WfRIahPFQ4AfRZpAqjhRASAofzzTRkDgvYgSZvYFSkFDIPJ25zQ55cM5Nx3muDpKz460s7 D7ozZYeD1RgQjUi3Fs8osxJ6NQtXqfPXXWx5U6eY+L/AiTZMCayltIx4Qr8KTCTvsvqRtIHlCPIu xRxKH/Tflt2MTylzYMPXELYGzvk4dfer0WkgVCaOM+1oDFvZ/wWrTEgmOtbC0/FleZCdXucaV91K 0bXIPtnNU8pZKYKSMLGPHrZaZzcIfRHoYkzuSAIvZ0sUb8MYNTQpaXnWcaFRsbHD4mbPH9f18jmr tBFy250T551WOVs35qNOll3TZkU0Twe3l+h5vE5dXInuVnSVaaNvfL596k1T/u0yF82yER3e1zcb oQalLu8NR8WlqZjyyZqo9QvdPkjWqKb7YDooZfiKAR/15Z5mEo9kUN1mH9AX8I/7rUX17ZTBqciO Kc7u3EXHLs92Hw7C+8G5crf2ubppzmNKr3P9bGhsumLxREDr7MdCi8S0/ggBmg3YTYUgLQQWAPwq 9EXs5cSFBfqA/YRzalKiNBrVLOSo5OFEKjM+xRItAaEPCeRwo5/4milCtaJukkeD9IvGNPte0drr 1XOwzytVVRgBxiWZQfe8mqdDDazeZs3ufAeBqNYreE9jJRgk0XYpmx/tqiyZcibTDfvEQ12Obv97 Dn/38mmV7Ky84Rl0xXeOg+7UiLEaTq3gFBuGJOL2VNLOVOCF+7dTrSrQLG6asWQi9iZKSZQdSZGt P4fMHhb4vL5W46oqgUsh8EjoQpeHEleizTGbTjpahKpdTA5/y7dh9ljyrVre2nX0mw+BtMdBB156 iLHVjfUbTd6NC1BthYiamWDzC+JfdnL65oOfXjqR3Da/vR3S/tolmfVifKp0QucR5PnCPQPmuJZ7 14ykr27B2cDWLuduN+1yXFUzTlEphHfZgP9C2g7EmCDpe4uhjbkFL5guXrkmUYi8lvK5MI+DmMtN TrXnke1jMbZ17p1TGyaviXH5Hg1EZH7xViPXv81rs8D7G+99eItnCEjf8ygWIQiOj++pgIuBQal2 qkyRcEuVI0nPbUmyVXhtBNhWFeiMlodCBPp6qQP8mBtH6UtCU+ZPGFgzmbGYTqTE00N6MtCEKNKj 386oy4k7mJkPeJKNGfSB+4Ix3+Syh1kT/L+u/ilwt6fixPBKGAiaYSeGn8pJkvQzLBrnYgm26pLJ A8st5FJU8W2rqiNDbQdCQCWaQ6SwwXRsOf7BZEoeRVws2bYSNpTL5X+iObBgZLaNZ6MnEo7z3yYR kqyVj2DPGDIFS/FOGrz/lBVOS0pjT/fq8RLXhxphQ5RvP8tq3rXQruu39z4oRJ0pb4Tc6PtDkIG4 mdhPEWav6fZ1XqOL1zpKM6U/XPzpRdkfhbmB7XMhp5TCgkrf3TxT4aq1K0eHkgwfvKxhfCW03tLL Hw3kpVoeuGgybHR2gnJhmYPkVlmxglsQ2iSJW53RHipKGb/fVlTPzvj+U5C6f7Nf599s73kcxwki SW0h9tQSIZKGK7ailojYgyBRS7X2orQoba+2aoklihKxhFJii6A3lqrqba8lRRWTqrqCuVU7t9Or pr3d70x65px7zpx7zpyZ0zPnzA/zN3w/z/fr8VVOFwXi9Y9Axn4PpP2PgYT9Z4GU5K1lPfx/IP+9 QP5tWUGl80WyEiwnWRtXXd2SaOTPnDFSJ40pqUcNhJgEPKWloNWYRKQiKa88eUpwylKjuBW19OrD b1eGdEwM4YUHgDkjuiacY6aacvTRVV9Q9yRatZAfieMspxzRKnJdV4TuszTaKNpP3TaCvzWguSP9 xvvY+ph2+2aoWx9E7F2GL2pOmpKOc8kmt8vr5wxTbno5KRc6m6qLZdjZKYP5CDAOUkNC+e30rcq8 zDeso0dLTjLrCxhHDna8GdxI+iXNJlRuK6QugRfQ+cxTn33n0r3Qb5R/pi4N89dOW2h0nTyUdf+n FKuQrvMdD/Z+vXj/uFflUhzv9bd3as6yNlSyrGoFMebWtMnzNmzPDb+HL/qPoqs8kH/dMa8E6zVN 15BcjqizJ8JMg14YHHDMd6kxFfahO0xjZiJ6Ks0+ek0+8+6k7qRhNiyFpznU+PMal12W4r/z4z7l tpj2ht5axJ47Zcd4dGLw2EuVQ7KZcmBJMDGLHAgDyYhnZw7pqkWZw+VBEqtQtwISBgKRfM5LcjNW AeZJNOwV4A0Ow1UPbLCFF35KMmb9HKMEnRgLw7KK2gi40nlnpKLbelMEbzP5sKaXSznR991vZQ4n ktQ0f5OC5BB0Si9gjTXBeXgE1JDvoi0i1urj7bmUg5pF4+s4oTjU9poHWoChRbAwDJfW2R0YIAhe TuUwY/Ue7n0qtW+X41b4oVUa7QyVtrJZ5OtUorJgg4Zb+CIrEBKhvtxJI92Ya6etppnTUeXgFr1F WEOOPjMq8etl5WnH8G35n5OVwoXUL7KS1mPvXLifZAMnbe4/Zk6F4yo9c3ulEgNdEWV0IsERORF3 GD4N7A3nLEZc/kH7u61PAAlA1kQDL9ZWdPtyR3V529ft9RWuwtllFzpdzDSKx/W6t/kZjrra6DJu muNnSgm1jRFLZDhjL3og/Ljlu46wq/gG+fwNxcv4NNcmWKw+pHQ/0FbZY30OF9jsr1sqvfbkMfk6 Qadcob15JE20Fzoz2yn0hUoyqd19m67XvfhDyM2jcm/9WwQv0+7MP5KKn37dE3yo6tHT2VfHb4V+ D/e2XPPlzqcMaP5lSy938Mf070/In7y7sS5M7K+Vd61ltVnX+8Yq0e8BI52qSW1nucj7VGz9o+gU Virbx77cPYxhYyts5kd212DzJPTrR8L61FLjmoxqCTW9Bgmbh9CRDn3LXa93Hxyv8rvpn1i5mxvQ ltw2l9jPfYPpCub6H7JYCmWPx/QKsbc+tsw8j+AtiIsNCZpB6jKg7HA8B0YGSgH4K6VWNCBGHDia uZLp5iErTSOGC/aO2asogSSrQgZWTtvAr8tsAp4n9J0wruqIybaGTbjoy0/QGI5dIuXWyY49CefM nrmKv/HL+LLcYXg+Pkx+m6QCBea53eBxEowtYIWVEVt6OOZYhAl/HfdeMuaIVoHTqm8B3eSffj2Y EAvEZcJ5AsKXY256EFLgquXjGjkC1ipyZldEI7qP1ZANr9Gjs6Ey6XidCo+o1UY7TKV7izIkar8O UUNC+6PnGKFWtfV3v/ZYpdCX90Os2eRNM3AFRPS9vbb3g+Ba7vYNnlswDWx9kEFFj+hGSUjlCaJ7 g4pay52v85tI82bun+ap6CjcwlSg/uSzuJZ5DHUy11LofZuy+yak+PdA/P4YyBAICMzVwU+EEZUg Unh2pomhCkoyi6+DI4Ms4dKSAAJZ9LL15PKzn+/xqvHIwT+PSyQL1ldOmqgeiGa/T70XYg6daCXg DDOISIZs/CiLv33aslbWpfxSsOTfMuxXkgfWbSTErhDCeAXmpsTPuU7hyZxmSq+qtXpRqxk0D6V7 bUIPt/CaoK1YRHTPH93Ff7ro0ECG6HFbKA2+7Uq7SoNQxWLHxtJtCsFqP/2IloLb6wgjWAdauXB9 Not4yROrUBA5Ky7J9Ucpg3coPV6GHH8Ucwc2G+7B8m5m7PCX33z1mjO9txjCacV8XDWJ49+eunjG lTGxsu/+BnDCquFx1P5D864vI66GtcwxqpmKNq/BbuprxHTX+Gz2tHvqloxFDBsHfPQy7va7SUH3 T6YNth3lLse90Uzk3vPoCOAyJ6fP/RjbLez81dMoY+fsQGCnpRjexBwNADoBdKrJGCmYiELdVkg5 XfHCTEfeipWOomKO43OoWqqtqnwubURcf/6llWZJPkrCOnMgxEj1UcuusKHE2RRKd9rXRZaeCoDP oJyS+xbizWtXBaiPr95KFI/rCtQkPihJ0RwbGagXGM0Dxc6Iluo7E1PRuOoinLVMhqN6yThb4R0z AkGy1/aTXhN+BmT6HqRi/hV3g9w6jxowIXqrQWE0J61SkL4fy4rj49HCiHMmsGzb3FrLIZTJNGSV t8HWza/mLvu8beVMLNO6aCSaUOfZ+iTdttJVmuHDUXz/AHgVJcoyQaTczOHwPvWE+Uh08+OTOMMn FkWzVywqPIJkzpmpgFNuL8alFVakNHr1+3c9tbkXsObDWUqk7lKDb1FaA07133UumT7ZE3TqrWfd yINwHkA8q9FNwVQNKjmSRTZskIFI0Yd1kkEyFIBsvviwWClTQx5UMNq4MnAJa6AANr6dPLScam2l PiU1Ioy9H/pNwLRkCrq0yEO7DIzMCRatuY1mceuob/MzlSyHZ9cG4Ket5TKHtAXVWISsTJlDOHnh WDxaGftgxiUSXcQPp09E7oOmztkp5POboIrhex9KHbT+tA0DFOy2Uw1h8cQPtJc0YhM59u/sl/c7 G4oexq3YtUIPKioRhNBSxIpWiBkUMWIWIcZTmxaHFqW2EkLMGrFiFLGqqkbV1sQ6Ru85OGKk4x6q g54+96b/wLm/nN/u+Re+3+d9388nwFBKrABZUzCVLmEsnWuuNmvu/1Sn1vGyxBwPRPo0BaVWMjNp muiiXmyjJjnDNDTXITs1YVuhQ1F6xneM3N7Gze78yoodAi0OGG74driPlGLMo88Sh3zga20DD7Jf vQnV9Vh0404e3osc8Pi3W+7Ouy9Jw5Ua/ct+hx9jdJjAp3v9Mei6eQJQTZLljahk7PXoI4nJJmWL MB13ZI8dPIC2bssrdKF2jkCTsVPONci2KG8nFJ+1U52m8d3kLgxpZBnT7txGEgzrqQ5vXWUN/D2I xaXwx6GJsiF71pWWjpO2Y/XLF5gNquRxvHqZEEFws6vAXFEiKz3NunAp3KDiAmHCsfflt3s3br3+ ysML4C5C+dLj2ZQg9NDMj6GfZAO+aGAOOcblEXQvFVjiGVl/pplexyo6sx6ct8q13YTSs6E5uM8l 6EYXlZU01YupbOubhZ6nsB5ZwOg2UuC9rng10kyLf7dVk5mC6FRzfZ1+OkoZjLVOZx+sClVNZwK7 1WvLnYoZEpb4vnsDXp2gD82YujdvYzpKBVcrjwJ63a6WtTXuPg99Fq9fFfaqwaWdGam3tWgpFNf5 KX5E/vXduZmerTCE/CM9bfsYZD1dBZgo/CpTs9z+wNk6iepuXDrLvHaErklWJo5BYxNo1llTeB13 YV6McfpYsObhsoUnIkOXYLsx7+r06n7IU8+j1ZznVxq9mrY0VgU77P/WgPyS+k9A/gnI/1NAOMcU UmGFakJcqZwpmg7SPIrCDx+k7nAkmaqKC2SgUCZVCBEBwPgofRQtD+LnmTKLGt0b8rlaJZIJNBju DdSWtg0k7twe83QVn6b4O4oVWl+TtZvSRrWvhyLIjyOm3p79hyNltDYaps7OWfp4XeT0bUMV0Ww0 ZApG8YGL571qiJp+l6h1udDKcjYgtNrhvosiKWSvQhxahJFfyiqhUs4LzSF0GPfOGfqxA8jxcFJW wJSCLBUFOD3VFXZVlZwO4Px6euqsIpYFfakWovljcrO0h+Tq7yiVANWcEiFW7+48WXtLmni+chRr VB0e1zPmQUtWL81hnnyKHXbrcIvgA+YProT2VXXyfkuY3gnv+/XJTxMbH84SEJ5hTROM/f2QxaAS D57dCBSZvg9UfcPKvkrCqPRseDV5w4pfU5Zw0IJHiBAt6XeEXHDKTFAXWYMXJBs8R6A3tc9UGuTM 4l6/14MnG3a7Na60lWwFDtW5tP4PxNKHiilJAFC+DgqavILcHOl+hfRIpIJoljkErNkCgwEfjo0p DOJkpfkfTNRxkA/D9eXKMJMfU+m7QXqleU14gbweLw0yPHTcQDLPBiIhoGxmPbgfrMvm3mXg+6/f 79/YFpOWFDEHsElNjOx8ReZCJnrnGJaOY0rmTvprkVfCDUCPLBRPBPjPbPOxVFEWJboDWWwKJari Nx0lSM6PnfgpHgCOpBuwYhY31Vi6AQVzziSObVPdlOtyJiHlwik35Gty0nfFecgZdspANpNG8d41 K7F/2ZMWaHMTbQ0qWD3/V/Tg3aHqK5kxHYv9OLhrRCOR4TXi01mW84n6fns3akA235VGGv0twkBO Y+3Z6u7Xn41/u6o8F9a7noh8s2Awf5JrUmV3qC0rNx5oVO2odNIa8NkTXjLXKJFwWoHhKWLsLygr gvIYAZoy6p+BgNqJBjuZ25uSq+XaQVruGJnvTcyIZle10yFSdOXtAWe1PqO/dhA+njSeepMWdUEe Xo4xE1+xvGuyInzpnMf8FHa7AABckev60J+EuM04xeJjFYCgC1PcxKP4kUhDOdv9E0bJvJ9WKSaD BgjDWUKKstGmKOh0iJ7cAi/Nr2XTP/nF5ScHf3Jxc6VO13axVQYomDEB7jqsuq4klitXXxTfbqEt mz+l2H348h4KfFm1iBqH+u5c4NJMDEYTzdV/toE4UYtZKMlck1rRTKZEskmcZYNksJJg4QkOKWWz t6KFo2DBhXy/LzMcqkwVisVaKeNsabNXWDyMzl4vdbBttT7MVuzefOHZ6SbyBdtI/xD3dG0OELpw 2uMBL5tbXTr26fMelrNH/O5IXYsevPT+QDFj6JfE4VuiQc+Yexth/ZWilpXlzQY1jsHA7Oe8eDOy bXMMFTriol4zFxhdHlt/83qxtS/RELlBeYnvrlB/yK1UM+7bKx0b0qBRaVpBU769D1fF3+h903HK mvQpc+rEhpWyMlybo5pXwvqpn9Q6PKhYuO6Wd/0Ugbah3vetcXHHv2udY7vQpMRKCpBqkjIqDRPm En9ohhr9I+U6WDIrfby2ttb+EvthO77BvobsuuHCR41FjnholOUfcB3V9PtpyeURuGbIs7GKMhcC nFDQAhsEXCQIGNW7EqJjfvnREfDTF87UF9sOLToQAb608Z0ucgAXmG1/fse4YXsN+XxLMGNw/p4Z qFAcOH1aX83VYqFKbIWGhl0pMlEqmtH1yLZIQz4WneFmFbL3HVIUClxKvR6vShKYdEZ5i+DMQJkN x8ccaabg6tlp9Mx3G7K9CtaKmKBZ4WRcZ8N/zd3CYvmO3o+y6ls7iNAHfWD29Hl1uWtcjGhkHSX1 eT+51EmgLeydhiNk8+8sB1K3opByBWVmreOfo36I4TPSyZPiGQptQ0n2llG1XZN29vC+O6qeDis+ lxJJhpdhAnUS0NR4hq+WjPC+EaCGHtC1aaussxY8T7Yt+4jASpUu4DbDXc/jfCoxrW7wi3Nxpm1Y KpaF2HJJJLl24FRJFe87GXia+7tSj+9LB5HduHCFSCsFG6jgf9kt+5g2yjiOP3flaekVKqwt72NF gbYgo1QkDNhy3RARSndQyhA2cszZdrhgxRFAF7wWMjbkj8YRxnizQMPLAEUlBkzEq6BiM5f+4WIW iDs3ySSi4mumJsbr+qckMiPpRvpJnlx+ued+9/1+89zlZ6XtOBkk5iKBC3F2phHfE9Kee7CaIAhZ cItVbZ5OV4by2g4iae4V8769F1+9zRlcvPp8SqTmY1HkidlKZdm11jpFRGdu/C7N2QsvXHE/x/ob kS3/+Mdfr9BSpTymXcBt+ZD99x1VRQvPL9wsDnzLpQhvX3wmbWylLju248mvd4X+dClqtHTPtfzV iqbE1qfiSz6ZGUpIGj/gCM2fwcCd5mLZ57zSl9LyrMT4QwktztI3ig5J2p9QRYLm/fsl/MWH+WlY j0ZWsjZzM+j7Nnn/+WcDXJ0D517L3j3x63ur5h/qs44Jb1f2n5oum7xRmDA0d+b9Y6mSb/XLzsVb tY9HTRmTLfNf1mVWTjVMfLTx28vzVUVdyyenf2ma63nx0mqYJbPXbUjf1+pqyBoqXC35dP3dI4qL BfE/r6V38R8Z/qxHk5cdObREqp5eTxSo2/J6VNdnFBMqw9Xjb3c99meR64Z2Ur9Wn7Sacb12TF/T 4J+s/JOVf7LyT1b+yco/Wf3fk9VmcA3GhvuBc5tBbabY4GupXjYVfD8n3LhjE4ZlRh9L9bL1hPV6 va/FetnJp/hBO8Zco4+Vetl6wrkPXMIGg9HHWr3cyyn2h/wf2dkhG30s1Ys/4+3nXjL2tVYv/oi3 na1HbPSxUi87OWGD0cdSvfgj3nZ2SMS2SVZzAoOAaKWQ4MSjewGG1FMFVKw7aDbQhKrQGjBPHcdT mDg8loQk6kKzwQYgadaXBgT08gBA6tnVdNdpGAjmxl8AmQgtBGYOFQMYHshC3ELqNMe+G3zDw/9Z aDa9AxAVAIdIEKoEATkAARTAv3LBxjZLDUCC0GmJ9B1IJqvPCIgq66yIvgzNCks5pqxEr4il4zBT gZzCiCPojJgagGSSpQALKbbaxIwDSuVqk0Cps3aEUVNQmmzJ4TOlaEe4dAR2K5z5mLICZbcNQ6kC yeczxdZZiX2MLZxH+cxh1CaiHTBQ4czBlIfRPk8hTVKfwMye1pQDlsudeZiy2EqLSQeMSGK3mdnW YmoMkjJLHkaXWB0SfJRV4CQwtw7tFlPDXFpm0WJ2nafBKIxQOCswXMc+I2UVPGohMJvO2n23mxzR RNC9reJ0/Hc+c3IhQETZW6WK6g/4ct2CSkS/zl3PGIzmlePoATE+wM3JiEsXhhSjiWJigrMkG+wL JrRqLab0yAFvQlyBEB6hfRKP0yRE6ykcEuCApmR1OUaWoSsSYIc2uVOLkew2ET3icar1BNIRTg1D XK4uw0iPH+llSKSwfhg9SkuYOWhOVrNOdR6nU3Bazr6U8vihJwGYtTQLbNWc7mjchCxFITYhqOJQ 4cySDqQCF2Y3WTeC6TloSkUag3Ejh4iivuC6U5FWAV1r6YwBt+CdRGddkLQKPZ3O9EPTZl/Zv0CA gIHv2CvKrsK/BRgAJi9PPw1lbmRzdHJlYW0NZW5kb2JqDTQ2NCAwIG9iag03NjI5IA1lbmRvYmoN OTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDgyIDAgUiANL1Jlc291cmNlcyA5MSAw IFIgDS9Db250ZW50cyBbIDEzNCAwIFIgMTM2IDAgUiAxMzggMCBSIDE0MCAwIFIgMTQyIDAgUiAx NDQgMCBSIDE1MCAwIFIgNDE5IDAgUiBdIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1 IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag05MSAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQy IDE0NSAwIFIgL1RUNCAxNDcgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAy MjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAw IFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiAN L0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAv SW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAv SW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAv SW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAv SW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0v SW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9J bTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9J bTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9J bTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9J bTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9J bTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0lt NTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0lt NTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0lt NjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0lt NjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0lt NzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03 NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03 OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04 MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04 NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05 MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1 IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5 IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9J bTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAg UiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5 IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0 IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9J bTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAg UiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3 IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5 IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9J bTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAg UiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQy IDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0 IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9J bTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAg UiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5 IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5 IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9J bTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAg UiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkw IDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0 IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9J bTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAg UiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1 IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5 IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9J bTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAg UiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0 IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0 IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9J bTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAg UiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5 IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5 IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9J bTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAg UiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAx IDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0 IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9J bTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAg UiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1 IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5 IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9J bTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAg UiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2 IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0 IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9J bTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAg UiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAg UiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAg UiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAg UiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIg DS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9D czMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUg OTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAx MTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAx MDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAx MDYgMCBSID4+IA0+PiANZW5kb2JqDTkyIDAgb2JqDVsgDS9JbmRleGVkIDExOSAwIFIgNDUgNDQ2 IDAgUiANXQ1lbmRvYmoNOTMgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0OCA0NDkgMCBSIA1d DWVuZG9iag05NCAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDM5IDQ1MSAwIFIgDV0NZW5kb2Jq DTk1IDAgb2JqDVsgDS9JbmRleGVkIDExOSAwIFIgMzQgNDQyIDAgUiANXQ1lbmRvYmoNOTYgMCBv YmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0NyA0NDcgMCBSIA1dDWVuZG9iag05NyAwIG9iag1bIA0v SW5kZXhlZCAxMTkgMCBSIDM4IDQ0MSAwIFIgDV0NZW5kb2JqDTk4IDAgb2JqDVsgDS9JbmRleGVk IDExOSAwIFIgMzkgNDQ0IDAgUiANXQ1lbmRvYmoNOTkgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAg UiA0NyA0NDUgMCBSIA1dDWVuZG9iag0xMDAgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0NyA0 NDggMCBSIA1dDWVuZG9iag0xMDEgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0OSA0NTAgMCBS IA1dDWVuZG9iag0xMDIgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiAzOCA0NjAgMCBSIA1dDWVu ZG9iag0xMDMgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiAzOCA0MjEgMCBSIA1dDWVuZG9iag0x MDQgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0MyA0MzMgMCBSIA1dDWVuZG9iag0xMDUgMCBv YmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0MyA0MjggMCBSIA1dDWVuZG9iag0xMDYgMCBvYmoNWyAN L0luZGV4ZWQgMTE5IDAgUiA1MyA0MjMgMCBSIA1dDWVuZG9iag0xMDcgMCBvYmoNWyANL0luZGV4 ZWQgMTE5IDAgUiA0NiA0MzggMCBSIA1dDWVuZG9iag0xMDggMCBvYmoNWyANL0luZGV4ZWQgMTE5 IDAgUiA1MSA0MzEgMCBSIA1dDWVuZG9iag0xMDkgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA1 MCA0NTQgMCBSIA1dDWVuZG9iag0xMTAgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA1MiA0NTcg MCBSIA1dDWVuZG9iag0xMTEgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiAzOSA0NDMgMCBSIA1d DWVuZG9iag0xMTIgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA1MSA0MjkgMCBSIA1dDWVuZG9i ag0xMTMgMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA0OSA0MjQgMCBSIA1dDWVuZG9iag0xMTQg MCBvYmoNWyANL0luZGV4ZWQgMTE5IDAgUiA1MSA0NTYgMCBSIA1dDWVuZG9iag0xMTUgMCBvYmoN WyANL0luZGV4ZWQgMTE5IDAgUiAzOSA0MzUgMCBSIA1dDWVuZG9iag0xMTYgMCBvYmoNWyANL0lu ZGV4ZWQgMTE5IDAgUiA0MSA0MjIgMCBSIA1dDWVuZG9iag0xMTcgMCBvYmoNWyANL0luZGV4ZWQg MTE5IDAgUiAyMyA0MjcgMCBSIA1dDWVuZG9iag0xMTggMCBvYmoNWyANL0luZGV4ZWQgMTE5IDAg UiAzOSA0MzkgMCBSIA1dDWVuZG9iag0xMTkgMCBvYmoNWyANL0lDQ0Jhc2VkIDQzNCAwIFIgDV0N ZW5kb2JqDTEyMCAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDIyIDQzNiAwIFIgDV0NZW5kb2Jq DTEyMSAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDM5IDQzMCAwIFIgDV0NZW5kb2JqDTEyMiAw IG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDQwIDQzMiAwIFIgDV0NZW5kb2JqDTEyMyAwIG9iag1b IA0vSW5kZXhlZCAxMTkgMCBSIDQwIDQyMCAwIFIgDV0NZW5kb2JqDTEyNCAwIG9iag1bIA0vSW5k ZXhlZCAxMTkgMCBSIDM5IDQ1MyAwIFIgDV0NZW5kb2JqDTEyNSAwIG9iag1bIA0vSW5kZXhlZCAx MTkgMCBSIDM5IDQ2MiAwIFIgDV0NZW5kb2JqDTEyNiAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBS IDI4IDQ1OSAwIFIgDV0NZW5kb2JqDTEyNyAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDQwIDQ1 OCAwIFIgDV0NZW5kb2JqDTEyOCAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDQxIDQ2MSAwIFIg DV0NZW5kb2JqDTEyOSAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDIyIDQ1NSAwIFIgDV0NZW5k b2JqDTEzMCAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDIzIDQyNSAwIFIgDV0NZW5kb2JqDTEz MSAwIG9iag1bIA0vSW5kZXhlZCAxMTkgMCBSIDQxIDQ1MiAwIFIgDV0NZW5kb2JqDTEzMiAwIG9i ag1bIA0vSW5kZXhlZCAxMTkgMCBSIDI1IDQ0MCAwIFIgDV0NZW5kb2JqDTEzMyAwIG9iag01NTQg DWVuZG9iag0xMzQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzMgMCBS ID4+IA1zdHJlYW0NCkiJjJXLrtNADIb38xR+geOO7fFc1kVCIIGEukSsykUHURB0weszSdPGk8xJ UDdt6m98+f9xDsdrhPMVaPxczz/d4fWJ4NvVccKQIWVCT6DBw1NiD3++uK/uMEDHUwU8ZvBwOr53 Ht7W39+BUOEvkId38PGTh8+O4BkcsQynleEwgsv9d5IynP7Dndx0FkYfxvNKGQKI9E6o2AcD8rsm 9ZgyPHnUUOtQYQylFIglo5JXOF/c4c2F4NUv92GMZ6QSdE0kqpXIg+CZIIw8AiFPQElTCl8egNgU QVKHWKQITYoYU4eQ+mQmdLeoVL/kGYi2qJwpmb4FlWsTCWWeU9qLX7SQ5/iAkssqnBk1PcLLhgy3 +Nqvn+OriXaBpl8LEAYv64pCQJ5VI94QQbDcvCQo2hNhJfSDaKZKxhvV48QdJBFhNnUZx6YXsgxa iEFCU1iXWIy3aaUbXw8yfcT9DEEwmwyNoYpqNHoEVBmHVf8xEuYNDz6Qdr6lUT01C2FCak2o87DY /w+Sre7cmjFW66yRqqKaJcJWReEkPaRRkWnDwXeE2+VmsiiST50hL5TnxiuFpFdYldJkYdlA6krO SyFZm+WgnNZAIyPHjds+AoOIZLpIGyJOQCvhlrduwEJA46y67UNcl0QZ49yDeKs4S1yX1Ion1OyG sAoP9Y1oLvmeCEvVdHemIWLsvvcEOavdh/UG6frCilidiy/UQxqlhV9eJBNhpP4nwAAGAcGIDWVu ZHN0cmVhbQ1lbmRvYmoNMTM1IDAgb2JqDTQ4MSANZW5kb2JqDTEzNiAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzNSAwIFIgPj4gDXN0cmVhbQ0KSImMlT1SAzEMRvs9xV4A YVl/dk9DyRmoMwz3b/AmBEu7yoYuM9GbL9KTnOX1/UK8vn0tH8v3UlYErbK+FOC2llVIQKT31UoD kiLr52XZCJkEQW1iCYIIQhPRiTRIM7AB9gnYBAyIRROkNhCcSJtIhSyCOnRX32e9gGUAkw/g4gM6 Em2I8BVRKH0g2sc3s2/GifCYYbUMGQ26lOpTsLMcESsCaBOh/yDBIfPzXnYOq9OuII2yFDRg14v6 3eIyRn5EKo9p/yFYQworZkgQz/aPXoZ7l8Li3Te9rdcOGfabG3LzW08YlnibxxBJYcTdu+9kCaDQ 5s5L2C8+1u+0o4T6JGAnXerJ4d6Ax2e7icV2BBR0AkLhzisdE6I7wWdT3cyhS+CHV3srjzcr4a1S Q3aiDRCvBxi8ifoELKYZEs3ZyQH+Ijt5El6r1tAyJOrrz3vZBCKmvTQorNkPQxnLM50Xj1iWERWq A7BA11IThkIrioFRqX6zDOT2MCLYHLLWx+fxS+xmrG4bC5BmwPjgAPaPT1of23Db1aFQOKg7gjz6 m4gGJP7f3pExYPfyqJ0c1R3ZzbedXPodYYU6U4j8D2Pp3vz4b+arD5qAlZPH/QpYQZ+g3SdIrcf6 P30/AgwA+1LAuQ1lbmRzdHJlYW0NZW5kb2JqDTEzNyAwIG9iag00OTIgDWVuZG9iag0xMzggMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzcgMCBSID4+IA1zdHJlYW0NCkiJ hJU7chxBCEDzOcVcwBiaf67Eoc/gWOXy/RP3rktqmOmVo1XV8kTDA/b4/uPd6Xz7ffw8/hx4JugY 5zcElRNP5QCS00nAFPX89X484seKD3DTvAEjIHwBvAADDdYbMD+4ZJAFDEhivgGiEAsYWkuQoT2D eeZpSYC0cthCCAQ574gjwVh1WBYEIVloxwggrzReS4kg3yCkgCuNZm2XYcgOmW3IlSUWIrOTY5dl SsGClJYxGI9d/Tz/WUHKwxQ8ffew+YevWgLbw2KXRNp0RZvGoPFUKfFEEkjvKmNUlXO++I5cVAY3 lRa+SXNRGVLTvECmSimItsm3XTEPlVaKseqFt/VfVEabMdm+iwdgaXI0gveIgq4kWpqcu+jmPYt3 fGHR5eH3E6EmXjTrdCX40zqXFFRrIKNxib8qv2yv4R3gaiLbWInPJbvEd9kDm2wxusU309mvnKpd 44fPFVnx/MVVfMZzKzj1i9PzL74Zpqx3HQfe6r049v/1pwuu/SkTJAj0cZ99vSajbVsdoA/iIpi1 CXbiHdIVZz1PtE3SL23a6835RMYA9e3mzC928QZRPCDVVyUmbRjG+ptBiPVsbAuZx7yuG5ZnOewL 6cIJuTkx8w1z2WqUOlX1J0Mejp7i5/pqIfSvAAMArrXAOQ1lbmRzdHJlYW0NZW5kb2JqDTEzOSAw IG9iag00ODQgDWVuZG9iag0xNDAgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCAxMzkgMCBSID4+IA1zdHJlYW0NCkiJjJVNkloxDIT3nMIXiGL92/vZZJkzzHoqlftvosArkPwM zBJKH5K626J9/Ln8vvy99EaAhtR+dFBpval0cJyzeUcg79o+vy4/f31ht3ZnsMO0voUYDBPkLTUa A33DoMPgO0MzIzhFNwjFN/OO6PgOQjA5TZYYxBh6yA4y0Ayl2Qb4juD4PqmGPbUBcR8bRiaMJBri g5nQWa+iybgyYUqzGVtqAijvL0v1aiRyMdLj8wpUE1HezONoYEkm1DKP61q/yIqWGwy5iVSAASOv kGIlYeu5w2pDcpuBxnkFEaBHojhrBDbODcIzftSPtHFImk1GcA6TV88e9Q5k6juCgRNBvaScNk1O Vs/Shm3LSHia2mCWyhxlw8SLwUdC1J4+iztQE0JJ38iCGG6YJSVE7/dng56SS5Jzwkobmf9Hpcis ZX+Oe3RmhEFzH8ujkchOgpoYpHIaJzInJn5kXCOTTpbgi2UOwLItWE/pcn2vxBIYnS92P4CaFu7v tvDu5fDSeEtEurLxjE/jddQ/D9eTtWu08toK8adlJ4A79PSwmIoX46zTkqp8UE6v6kZEpnrKB8uL TB1ETRSX5FI+WQSuxxHSvIaVO9on7pgaKi65lXp7D2aNVXm52/qQ/Vb/T4ABADL7vlINZW5kc3Ry ZWFtDWVuZG9iag0xNDEgMCBvYmoNNDU1IA1lbmRvYmoNMTQyIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMTQxIDAgUiA+PiANc3RyZWFtDQpIiYyVMbbcMAhFe6/CGwgRIBD0 aVJmDan/ycn+mygz/jFosDOdC18jni54+/r9A9n3b7+2H9vvre0Kun9p0G1vu3SCIe77aAYsTfaf H9sDsAiIkhQMzk/xyfR2Mgg1QpzKdDwRgs6jZOYBYhk6GYFBSAXDDdoIDJ9Mh+ajZHIEvUcGy3bm g8Yyktopu+kO7eyGQxGeaZL/RaQ/EAbyiagTYDzYiAdjoVExCoiB0XgyMyyY0RDo7EY8Io7MFdLB YpnkmRhLxSw5Z9W6YsEsqkmLZ0PvVZ3FNcE3IsiuxQgEjLRCFtWE3yiTVYtlriQY86F5KNPfSCC7 FoX2YCbDsCkMwojfl5vJfBCrLhSbIJPxCmRZRK+W0vF69iQWeFlJT2K1ZFyP4xPIiij/930FiyFd rtXjdQe96OAi00UMullbT2DVwmKJ1+93Aw1XEP8LBvMyo0Vzt+BjlWQz9G6ODmZxA7Ulwwf2ipkP sQ7d7JJ/THYk3uDLLvlkFkv0bpI+mSxKTvkKWVzBN442haEYQRpCJCuQacyISWv6OZgXyPLX0jQm LqIVk8TxkPPcMXkW+9Tl8IZjGb9ZEAczWgN75vxHgAEAq8LGkA1lbmRzdHJlYW0NZW5kb2JqDTE0 MyAwIG9iag00NjEgDWVuZG9iag0xNDQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCAxNDMgMCBSID4+IA1zdHJlYW0NCkiJjJQ7chwxDETzOcVcwDBBfAjkShz6DIpVKt8/MXe1 qwFIirU5XzXY3cDx+88H0fn2efw9/h3lJCCscv4qwHaWU5ihufvZCgN5kfP94+gItnIxCqJrxoDk YtReYFBBKejgxVTgtkIqRRnii0BQWyMKFn9DL0xWDawFpqbJaKlDyQEJCMPaZ66gUUWiyhIwUAxA /H7tmfmNEb4zAt0ddQSKEhrj14Y8ElP4LdnFijORo28heoOmMk01Be9Jw0gmYgjESrTKsdd6JHIc aBjzIKltInocFNy1FLo3XRAGGLyyUK0GlfoSRMJ6iPdESlQJGfYndVB5MAYl6AhtU7wzY46mW8ce zM+edZ1SccEggoQsrW3TfzA5f5Ntx76Y3gCJvtkL/9l0QABL34aZYUznwkvywHnlNTfgOJvHHhCL hl3WPtKiB55mSwfmm8gt8Lo55Q9mbIFTOmQroIcWFs05iiwlhgK4xEUr3m/ngskFcP35WD6Rmi+Z t80Z/2ZyZ9w2Z/zJ0GCAv8BwsiCe/lsx0FYIQ72CqQU3K6Aw9aWWsunyF5DqUkuqi1L1Abh1pYRQ ODhcoNn03AHD87SOIuM4t5pYHOfZxP8CDABuwcB9DWVuZHN0cmVhbQ1lbmRvYmoNMTQ1IDAgb2Jq DTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFz dENoYXIgMTIyIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCA4MzMgMCAzMzMgMzMzIDAgMCAyNTAg MCAyNTAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgDTMzMyAwIDAgMCAwIDAgOTMwIDcyMiA2Njcg NzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCAwIDY2NyANOTQ0IDcyMiA3NzggNjExIDAg NzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCANNTU2IDQ0NCA1 NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAzMzMgNTU2IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQg DTM4OSAzMzMgNTU2IDUwMCA3MjIgMCA1MDAgNDQ0IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29k aW5nIA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9sZCANL0ZvbnREZXNjcmlwdG9yIDE0NiAw IFIgDT4+IA1lbmRvYmoNMTQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2Nl bnQgODkxIA0vQ2FwSGVpZ2h0IDY1NiANL0Rlc2NlbnQgLTIxNiANL0ZsYWdzIDM0IA0vRm9udEJC b3ggWyAtNTU4IC0zMDcgMjAzNCAxMDI2IF0gDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbixCb2xk IA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDE2MCANPj4gDWVuZG9iag0xNDcgMCBvYmoNPDwgDS9U eXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAx NTAgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgNTY0IDI1MCAzMzMgMjUw IDAgNTAwIDUwMCA1MDAgNTAwIDAgNTAwIA01MDAgMCAwIDAgMjc4IDAgNTY0IDU2NCA1NjQgNDQ0 IDAgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiANMzMzIDM4OSA3MjIgNjExIDg4OSA3 MjIgNzIyIDU1NiA3MjIgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgMCA3MjIgDTAgMCAwIDAgMCAw IDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IA01 MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCAwIDAgMCAwIDAg MCAwIDAgDTAgMCAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzUwIDUwMCBd IA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuIA0v Rm9udERlc2NyaXB0b3IgMTQ4IDAgUiANPj4gDWVuZG9iag0xNDggMCBvYmoNPDwgDS9UeXBlIC9G b250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgNjU2IA0vRGVzY2VudCAtMjE2 IA0vRmxhZ3MgMzQgDS9Gb250QkJveCBbIC01NjggLTMwNyAyMDI4IDEwMDcgXSANL0ZvbnROYW1l IC9UaW1lc05ld1JvbWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDk0IA0vWEhlaWdodCAwIA0+ PiANZW5kb2JqDTE0OSAwIG9iag00NzggDWVuZG9iag0xNTAgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAxNDkgMCBSID4+IA1zdHJlYW0NCkiJjFQ7cuRACM11Cl3AuIHm0/km G+4ZNnZt7f0TI9k1oj+acTY1eh940GxlJ2jIvL8VkLqXXapC2w0VyIrsfz+2998fxPuvf9uf7f9W dgY1rCOeCFAeeNELryBoE9zj30u+1AsfQuQjnh0slRO/Er5J+A2EioDZIBVkwIUmfAVqCW9dA/wV UPWTEALW2q4NoWQPvzgVipKsOEPjreM0o5ljJb7wg4PieRjkYgvOMD/EH3BihpI55eII2KKbcYxI uZvGS84wSuSctC4IMRqVRKjZhIXyclks8/doOJs825cHx8EzR7udL4QzZxgNoWUfd1zUNo6m/YAy TqZ1pXFoLDgtx4bVXsc2zoa6DXBdxTaNx59stEONnLtTQfRsNQ/CGDJRTqyO6CHefLoKOHav8iQQ RxxXUC/L4QIlG3S7VW3S5waYy6+dwQSv0strt7r9qfZ4ZOfqxpdsYbln85kRBiDXvcOX+EhVeYXH aHnJiJg8jbm8tIicRFYWsS+K+WK38Dzb5n5d0+qhG5zRqgYl7lScDe3vdX553/Bo5nCIpxNHdoBz uVOPTmlSZ7xTZwSd1elWnYBndb5V5yPdEV5v1etBG+Fyqx5nYFbXW3U9RjbC7VY9bkpW/xRgAHB0 wBINZW5kc3RyZWFtDWVuZG9iag0xNTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMTkgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIma N2+eGAxMnz79yJEjEPa8efMAAgwAeM8JEAplbmRzdHJlYW0NZW5kb2JqDTE1MiAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifr582dZWZkYGCgrK1+8eBEgwABQ4geuCmVuZHN0cmVhbQ1l bmRvYmoNMTUzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MTMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xl bmd0aCAzNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo4caIYKmhvb79y5YqG hgaEW1JS8vPnT4AAAwDIEwxSCmVuZHN0cmVhbQ1lbmRvYmoNMTU0IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIibp48aKysrIYDCQlJS1cuBBNBCDAALxeCQEKZW5kc3RyZWFtDWVuZG9i ag0xNTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMyAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3Ro IDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjZtmhgqcHd3f/r0KbLItGnT AAIMALPoCVsKZW5kc3RyZWFtDWVuZG9iag0xNTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAxMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJSk1NFRMT27dv3/Hjx3/+/KmlpSUqKrpq1arm5mYxGJg2bRpAgAEAXkMPuAplbmRzdHJl YW0NZW5kb2JqDTE1NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDEzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBS IC9MZW5ndGggMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaNm2aGBjk5eX9 /Plz1apVoqKiYkigqakJKA4QYAASng4yCmVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTUgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCA0NSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifr5EwRiYmLExMTOnTsXGBh48uRJMTDYsmWLt7e3GAzMnDkT IMAAFVsS9wplbmRzdHJlYW0NZW5kb2JqDTE1OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIk6e/asGCr4+fMnhNHR0XH27FkgFyDAAMxjDgsKZW5kc3RyZWFtDWVuZG9iag0xNjAgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlauxYEAAIMAA43BA8KZW5kc3RyZWFtDWVuZG9i ag0xNjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGgg MjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fPn6dOnxcBg+vTpP3/+BAgw AGaQCoEKZW5kc3RyZWFtDWVuZG9iag0xNjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIm6dOmSurq6GBiIi4tDGEZGRj9//gQIMABllAe6CmVuZHN0cmVhbQ1lbmRvYmoNMTYzIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNSAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vnzp76+vhgYTJkyBSDAADXKBbkKZW5kc3RyZWFt DWVuZG9iag0xNjQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9M ZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlatGiRGBg4OjqePXsW wl60aBFAgAEAYYkH/wplbmRzdHJlYW0NZW5kb2JqDTE2NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiVq7dq0YGKxduxYgwAAdwQSTCmVuZHN0cmVhbQ1lbmRvYmoNMTY2IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTIgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzOCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp8+bKWllZbW9vPnz/FkEBQUNDChQsfPHgAFAcIMAAf mhDhCmVuZHN0cmVhbQ1lbmRvYmoNMTY3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDExOSAwIFIgL0xlbmd0aCAzNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI ibp06ZKqqqoYGCQnJ/8Eg2nTponBAFAQzgAIMACevQ/HCmVuZHN0cmVhbQ1lbmRvYmoNMTY4IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMiAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJKi4uXrt2LUCAAQAK0QNhCmVuZHN0cmVhbQ1l bmRvYmoNMTY5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVu Z3RoIDI2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJWrJkiZiYmLi4OJBcsmQJ QIABACUXBKIKZW5kc3RyZWFtDWVuZG9iag0xNzAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA3IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImaPXu2GBKwsbH5+fMnQIABADqnBnkKZW5kc3RyZWFtDWVuZG9iag0xNzEgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInKysoSExObN28eQIABAA73A1sKZW5kc3RyZWFtDWVuZG9i ag0xNzIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMyAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3Ro IDM4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vbt2/Tp08VgYNu2bYGBgXCu n5/f58+ff/78CRBgACxgD/cKZW5kc3RyZWFtDWVuZG9iag0xNzMgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJOnv2rBhu8PPnT4AAAwB6SQelCmVuZHN0cmVhbQ1lbmRvYmoNMTc0IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTAgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIierr6xODgVOnTgUFBQEZKioq58EAIMAAjw0L TQplbmRzdHJlYW0NZW5kb2JqDTE3NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMTkgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIk6 f/68rKysGBjEx8eLoYLe3l6AAAMAi/4HVwplbmRzdHJlYW0NZW5kb2JqDTE3NiAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIicrKyhITE5s3bx5AgAEADvcDWwplbmRzdHJlYW0NZW5kb2Jq DTE3NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAx NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr58ydAgAEABdkC7AplbmRzdHJl YW0NZW5kb2JqDTE3OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIg L0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIierv7xcTE0tKStqz Z48YDPT39wMEGABnswe9CmVuZHN0cmVhbQ1lbmRvYmoNMTc5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiZoyZYoYDpCcnIzMnTJlCkCAAQCsYge6CmVuZHN0cmVhbQ1lbmRvYmoNMTgw IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIyIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ6ujoiAEDMVTQ0dEBEGAAaUUGowplbmRz dHJlYW0NZW5kb2JqDTE4MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAxOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVq4cOGdO3cA AgwADp0EeAplbmRzdHJlYW0NZW5kb2JqDTE4MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiTp79qwYGMTExAAEGAAf+wQACmVuZHN0cmVhbQ1lbmRvYmoNMTgzIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTMgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWpubhYjBJqbmwECDAB2RwXpCmVuZHN0cmVhbQ1lbmRvYmoNMTg0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNiAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vnz57Jly8RgYNKkSQABBgBWhQdaCmVu ZHN0cmVhbQ1lbmRvYmoNMTg1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5 IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vnzp5iY WExMDECAAQAa0wRCCmVuZHN0cmVhbQ1lbmRvYmoNMTg2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJOnDggLi4+IEDBwACDAAX4gTGCmVuZHN0cmVhbQ1lbmRvYmoNMTg3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMiAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJEhMTW7t2LUCAAQAFXgJKCmVuZHN0cmVhbQ1lbmRvYmoN MTg4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTEgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAz NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTp//vzXr1+1tbXFxMTCw8MPHz4s hgTi4+MBAgwA+08LgwplbmRzdHJlYW0NZW5kb2JqDTE4OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIlKS0sTQwVtbW3Hjx8HMuzs7BYuXHj58mWAAAMAnd0LvAplbmRzdHJlYW0NZW5k b2JqDTE5MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEz IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5n dGggMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImKiYlZuHChGF7Q0dEBEGAA ngoHJAplbmRzdHJlYW0NZW5kb2JqDTE5MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI icrKyhITE8vKygIIMAANvwK/CmVuZHN0cmVhbQ1lbmRvYmoNMTkyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzNiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIibp06ZKKioq5ufm9e/e+ffsWFxcnhhtMnjwZIMAAtswOKQplbmRzdHJl YW0NZW5kb2JqDTE5MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBS IC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQg4GYmBgI owMMgIyzZ88CBBgAiSsJ0AplbmRzdHJlYW0NZW5kb2JqDTE5NCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiTpw4EBMTMzjx48BAgwAHL8F/gplbmRzdHJlYW0NZW5kb2JqDTE5NSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMzAgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQQwU/f/6MiYkBMjo6OoBsgAADAJVbC6cK ZW5kc3RyZWFtDWVuZG9iag0xOTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx MTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+RMK AAIMACvOCMIKZW5kc3RyZWFtDWVuZG9iag0xOTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSInq6AABgAADAAsuAzEKZW5kc3RyZWFtDWVuZG9iag0xOTggMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIk6e/asGAzExMRAGD9//gQIMABZiwexCmVuZHN0cmVhbQ1lbmRvYmoNMTk5 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ6ujoEAODs2fPAgQYABm8BIQKZW5kc3Ry ZWFtDWVuZG9iag0yMDAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAxMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAg UiAvTGVuZ3RoIDQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJunz5soaGhhgM uLm5bdmyBcJ+//79o0eP4uLifv78CRBgAAllEKIKZW5kc3RyZWFtDWVuZG9iag0yMDEgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjMgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OiIiYn5+fNnDBgABBgAQR8HwAplbmRzdHJlYW0N ZW5kb2JqDTIwMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDExIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9M ZW5ndGggMzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaOXOmlZXVpEmTxGBA SUmpt7cXwp45cyZAgAEAp9wJUgplbmRzdHJlYW0NZW5kb2JqDTIwMyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifr582dbW5uYmNiMGTMAAgwAMY8GiAplbmRzdHJlYW0NZW5kb2JqDTIw NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo3b56YmNi8efMAAgwAE9cD9wplbmRz dHJlYW0NZW5kb2JqDTIwNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVq7dq0YGKxd uxYgwAAdwQSTCmVuZHN0cmVhbQ1lbmRvYmoNMjA2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJmjZtmpiYWEpKCpDs6Oi4ceOGgYEBkD1t2jSAAAMAiwUKJwplbmRzdHJlYW0NZW5kb2Jq DTIwNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo3b56YmNi8efMAAgwAE9cD9wpl bmRzdHJlYW0NZW5kb2JqDTIwOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEx OSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibpz546r q2tSUtLPnz8BAgwALnQHdQplbmRzdHJlYW0NZW5kb2JqDTIwOSAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiVq7dq0YGBQXFwMEGAAcZQPlCmVuZHN0cmVhbQ1lbmRvYmoNMjEwIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjdvnpGR0bVr1wACDAAWywTzCmVuZHN0cmVhbQ1l bmRvYmoNMjExIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVu Z3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjdvnpiYWFZWFkCAAQAS nwNbCmVuZHN0cmVhbQ1lbmRvYmoNMjEyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ Onv2rJiYWEdHB0CAAQAXuwRCCmVuZHN0cmVhbQ1lbmRvYmoNMjEzIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ+vkTBAACDAAUcwXXCmVuZHN0cmVhbQ1lbmRvYmoNMjE0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjFjhhgYzJgxAyDAABqOBBUKZW5kc3RyZWFtDWVuZG9i ag0yMTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGgg MzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaNGmSmJiYjY3Nw4cPT548+fPn T4AAAwBPNQqWCmVuZHN0cmVhbQ1lbmRvYmoNMjE2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJmj17tpiYmKam5s+fP4EkkJ2eng4QYABXKgdsCmVuZHN0cmVhbQ1lbmRvYmoNMjE3IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTAgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp06ZKqqqoYNjBlyhSAAAMAb34GcAplbmRz dHJlYW0NZW5kb2JqDTIxOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr58+fZs2cf P34MEGAAKLYH/AplbmRzdHJlYW0NZW5kb2JqDTIxOSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiZoxY4aYmJiWltbly5cBAgwAHRwFAgplbmRzdHJlYW0NZW5kb2JqDTIyMCAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiero6BATE+vo6Dh79mxMTIwYDAC5AAEGAJJGChsKZW5k c3RyZWFtDWVuZG9iag0yMjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+RMEAAIM ABRzBdcKZW5kc3RyZWFtDWVuZG9iag0yMjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIn6+RMEAAIMABRzBdcKZW5kc3RyZWFtDWVuZG9iag0yMjMgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSInq6OgQExM7e/YsQIABABLhBEIKZW5kc3RyZWFtDWVuZG9iag0yMjQgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+RMEAAIMABRzBdcKZW5kc3RyZWFtDWVuZG9iag0y MjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjEg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fPnkSNHfv78CRBgACizCCMKZW5k c3RyZWFtDWVuZG9iag0yMjYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6Og4e/Ys QIABAAzMBAAKZW5kc3RyZWFtDWVuZG9iag0yMjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIn6+fNnUlKSmJjY2rVrAQIMAC6tBlsKZW5kc3RyZWFtDWVuZG9iag0yMjggMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+RMEAAIMABRzBdcKZW5kc3RyZWFtDWVuZG9iag0yMjkg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQExOLiYkBCDAAEDsC7wplbmRzdHJl YW0NZW5kb2JqDTIzMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIg L0xlbmd0aCAxNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr58ydAgAEABdkC 7AplbmRzdHJlYW0NZW5kb2JqDTIzMSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibpz 546rq6uYmFhxcTFAgAEAJtwE/wplbmRzdHJlYW0NZW5kb2JqDTIzMiAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAxNSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifr5Ex0ABBgApmURgwplbmRzdHJlYW0NZW5kb2JqDTIzMyAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp27Zqfn9+1a9cAAgwAHa8F7wplbmRzdHJlYW0NZW5k b2JqDTIzNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0 aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr582dhYeHPnz8BAgwAI9YH KgplbmRzdHJlYW0NZW5kb2JqDTIzNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp2 7ZqRkZEYGGRmZoohAYAAAwBwQQXgCmVuZHN0cmVhbQ1lbmRvYmoNMjM2IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDM1IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJSklJERMTO3DgQHZ2tri4uBgYqKurX7p0CSDAAHazCKQKZW5kc3Ry ZWFtDWVuZG9iag0yMzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBS IC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm6fPmylpaWmJhY WloaQIABACLdBGwKZW5kc3RyZWFtDWVuZG9iag0yMzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIlKSkoSQwKTJk0CCDAAINAD5QplbmRzdHJlYW0NZW5kb2JqDTIzOSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiZo3b56YmFhWVhZAgAEAEp8DWwplbmRzdHJlYW0NZW5kb2Jq DTI0MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo3b56YmNi8efMAAgwAE9cD9wpl bmRzdHJlYW0NZW5kb2JqDTI0MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEx OSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVq0aJEY Bli0aBFAgAEAQuQFWQplbmRzdHJlYW0NZW5kb2JqDTI0MiAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIierr6xODgalTp0ZEREDYCQkJAAEGAGQ7BtwKZW5kc3RyZWFtDWVuZG9iag0yNDMg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQA4OOjg6AAAMAGB4DtQplbmRzdHJl YW0NZW5kb2JqDTI0NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIg L0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiero6BATE+vo6AAI MAARQwNzCmVuZHN0cmVhbQ1lbmRvYmoNMjQ1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJiomJEQODnz9/AgQYABUYBIQKZW5kc3RyZWFtDWVuZG9iag0yNDYgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSInq6OgQQwIdHR0AAQYAKCYEOQplbmRzdHJlYW0NZW5kb2JqDTI0NyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwIC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMzIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6+sTExPbtGlTc3OzGAwsXbr0JxgABBgA tHsOFwplbmRzdHJlYW0NZW5kb2JqDTI0OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iZoxY4YYGKSlpQEEGAAZYgN/CmVuZHN0cmVhbQ1lbmRvYmoNMjQ5IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJmjRpkhgSmDRpEkCAAQAqYAR1CmVuZHN0cmVhbQ1lbmRvYmoNMjUwIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjFjhhgYzJgxAyDAABqOBBUKZW5kc3RyZWFt DWVuZG9iag0yNTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAxMCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAv TGVuZ3RoIDI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmj17to+Pz+vXr8Uw wOzZswECDACiQgjUCmVuZHN0cmVhbQ1lbmRvYmoNMjUyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJunMHBAACDAASEgUpCmVuZHN0cmVhbQ1lbmRvYmoNMjUzIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJWrt2rZiYmKur6507dwACDAAhnAWtCmVuZHN0cmVhbQ1lbmRvYmoN MjU0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTEgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr586eurq4YDjB58mSAAAMAkDYH PAplbmRzdHJlYW0NZW5kb2JqDTI1NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDcgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTp7 9qwYKoiJiQEIMABAdwTGCmVuZHN0cmVhbQ1lbmRvYmoNMjU2IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vnzp5iY2NmzZwECDAAdeQWVCmVuZHN0cmVhbQ1lbmRvYmoNMjU3IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNyAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ6ujoEAODhQsXQhg/f/4ECDAAReQHbwplbmRzdHJl YW0NZW5kb2JqDTI1OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIg L0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiUpISPD3979w4YK+ vr4YEujr6wMIMAB54we9CmVuZHN0cmVhbQ1lbmRvYmoNMjU5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ6ugAAYAAAwALLgMxCmVuZHN0cmVhbQ1lbmRvYmoNMjYwIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJSktLEwODGTNmAAQYABQcA38KZW5kc3RyZWFtDWVuZG9iag0y NjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJOnv2rBgqiImJWbhwIZDR0dEBEGAA fv8IgwplbmRzdHJlYW0NZW5kb2JqDTI2MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDE1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImaMmWKGHFgypQpAAEGAJ0LBtMKZW5kc3RyZWFtDWVuZG9iag0yNjMgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIlasmSJmJiYuLg4kFyyZAlAgAEAJRcEogplbmRzdHJlYW0NZW5kb2Jq DTI2NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibp+/bqZmZkYEujp6bl+/TpAgAEA YNUIWQplbmRzdHJlYW0NZW5kb2JqDTI2NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI ifr58+f+/ftdXV3v3LkDEGAAO0AIjAplbmRzdHJlYW0NZW5kb2JqDTI2NiAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIifr58+f+/ft/ggFAgAEARnoK/wplbmRzdHJlYW0NZW5kb2JqDTI2 NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIierr6xPDBvr6+gACDABH9wUjCmVuZHN0 cmVhbQ1lbmRvYmoNMjY4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAg UiAvTGVuZ3RoIDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ6ujoEBMT6wAD IOPs2bMAAQYAQyYHtAplbmRzdHJlYW0NZW5kb2JqDTI2OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIifr58+fKlSurq6vFxMSUlZUvXrwIEGAAZkUJdgplbmRzdHJlYW0NZW5kb2JqDTI3 MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIierv7xdDBfLy8hcuXAAIMAA/YAXFCmVu ZHN0cmVhbQ1lbmRvYmoNMjcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5 IDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJunjxorKy ckhIyE8YAAgwAGYMDJoKZW5kc3RyZWFtDWVuZG9iag0yNzIgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIn6+fPnQjD4+fMnQIABAD6CCZ0KZW5kc3RyZWFtDWVuZG9iag0yNzMgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fOnGRj8/PkTIMAALjUHGwplbmRzdHJlYW0NZW5k b2JqDTI3NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1 MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTIwIDAgUiAvTGVu Z3RoIDcxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhMGHDYAwDARA20nove0/ KvA2BCIk7ogME6eEJeHEffMq+GAyk0MBpaqgVg20h+7Uw3AZo+k2vyzR+rD92gUYAESoCwgKZW5k c3RyZWFtDWVuZG9iag0yNzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+RMKAAIM ACvOCMIKZW5kc3RyZWFtDWVuZG9iag0yNzYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIn6+fOnmZmZlpbW5cuXAQIMACydBoUKZW5kc3RyZWFtDWVuZG9iag0yNzcgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fPn2rVrxcTEVFVVL126BBBgAEhdCBoKZW5kc3RyZWFtDWVu ZG9iag0yNzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5n dGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fPngwcP7Ozs0tLSAAIM ADsrB3gKZW5kc3RyZWFtDWVuZG9iag0yNzkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIn6+fPnkSNHfv78CRBgACizCCMKZW5kc3RyZWFtDWVuZG9iag0yODAgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIm6du3a5s2bf/78CRBgACRsB4cKZW5kc3RyZWFtDWVuZG9iag0yODEg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaMWOGmJiYmZnZz58/AQIMAB60BZgKZW5k c3RyZWFtDWVuZG9iag0yODIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fOnGAx0 dHQABBgAMkkFSgplbmRzdHJlYW0NZW5kb2JqDTI4MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiYqJiREDgxgYAwh+/vwJEGAAPYwGXgplbmRzdHJlYW0NZW5kb2JqDTI4NCAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiRITQwBxcXEvL6/Lly87OjpOmzYNIMAAPrIHKgplbmRz dHJlYW0NZW5kb2JqDTI4NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYqJiRETEzt7 9ixAgAEADsEDvgplbmRzdHJlYW0NZW5kb2JqDTI4NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiUpOThYTEzt+/PhPMAAIMAA6OAmXCmVuZHN0cmVhbQ1lbmRvYmoNMjg3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJiomJEUMFP3/+BAgwACmpBUoKZW5kc3RyZWFtDWVuZG9i ag0yODggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGgg MTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkSE4OCjo4OgAADAAlsAl8KZW5k c3RyZWFtDWVuZG9iag0yODkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQA4Oz Z88CBBgAGbwEhAplbmRzdHJlYW0NZW5kb2JqDTI5MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIibp27ZqRkdG8efMAAgwAGrsE8wplbmRzdHJlYW0NZW5kb2JqDTI5MSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzNSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIierr6xMTE3N3d1+4cGFjY6MYGMjJyV24cAEgwACCtgl2CmVu ZHN0cmVhbQ1lbmRvYmoNMjkyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEx OSAwIFIgL0xlbmd0aCAyNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo9e7YY NmBnZ/fz50+AAAMAXPEHRQplbmRzdHJlYW0NZW5kb2JqDTI5MyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIibpw4YK8vLwYDNTV1f0EA4AAAwBqfQrkCmVuZHN0cmVhbQ1lbmRvYmoNMjk0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjFjhpiYmJaW1uXLlwECDAAdHAUCCmVu ZHN0cmVhbQ1lbmRvYmoNMjk1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5 IDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJOnv2rBgY xMTEnD17FiDAADDJBmcKZW5kc3RyZWFtDWVuZG9iag0yOTYgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIkqLi4WA4O1a9cCBBgAFkcD5QplbmRzdHJlYW0NZW5kb2JqDTI5NyAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo9e7YYKpg9ezZAgAEANjkE7QplbmRzdHJlYW0NZW5k b2JqDTI5OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0 aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibpz544rGNy5cwcgwAAsEwbH CmVuZHN0cmVhbQ1lbmRvYmoNMjk5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTE5IDAgUiAvTGVuZ3RoIDE3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJysrK EgMDgAADAAvHAcMKZW5kc3RyZWFtDWVuZG9iag0zMDAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInKysoSwwBGRkbXrl0DCDAAQFMF4wplbmRzdHJlYW0NZW5kb2JqDTMwMSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDIgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTIyIDAgUiAvTGVuZ3RoIDI1MCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiXyQ2XKEIBBFFcRBUVzQDDqbK+P/f+HcbpNKVR5y uH0bHg9RFEcgFlEco2MgBBeW4AUkJpFS8KH8IUkkDqOYVKWU9ELDaK0zJMtyJDc5BhSmYMqytIit Kkxd1RSiIdBtS3PiaE66vneuB13XM18/XJH/EV5AXHgv4e3JWeIOc5TgO7yp0H6Asx9gOnhaw3kH tGCu8JBK4RPgTr8A72SEdjqOqdaX8QZzfbtDO3s8MmPyew5t83yasixek7V2nqa5qu28QHudl6Vp tmWD/bauW9vu6w7xHTgX9j2g3wHCIYQD+kcH5+44F5nzH1y5vvuXjwADAL0NHGQKZW5kc3RyZWFt DWVuZG9iag0zMDIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCAyNTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDk0IDAgUiAv TGVuZ3RoIDE2NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYTPywJDQAxGYQbD iNZdaTH0+v5v2KRhmG58fzZZHsdFwvP8TcAkCmVoREQpFQNAcjp7KSgCCv8MskXKcjxW5AUqi6qs SI0admEt6doOXcmN9Ggg40qPmk16Mmba6k4zHkco3H0K4YulWwYy4KP0CJNfuF16TOHOOwHOpnCw s3/pVjiqTPinqf+6Kd0q77fywe6m9F37Lny2ww/TvwIMAHXnKnAKZW5kc3RyZWFtDWVuZG9iag0z MDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwMiAwIFIgL0xlbmd0aCAx MTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImExNsCgiAQBFANSd2le1qJZSL4 /5/YDsJzZy5FUZaFZKeqTFd6r6O6bloiaglP1AhmNupwPClj2DCfTXSJrvHghiX3Dvquf8ATXpsB 7GDFaEd4iw9M8IU5cbPbLG7JvNRLs+BDsob1n58AAwASuxcXCmVuZHN0cmVhbQ1lbmRvYmoNMzA0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWln aHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTAgMCBSIC9MZW5ndGggMjcy IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJfJDZQoMwFETZZGkDLUtKAdkpVkGg gf//NucGfPHBk7mT5zOKqmmIpim6YRhveKZhWqZF2MBxTufzCY9wAGO667n6hTHKzhXI8n1EEgSB LBDuRFHE+Y2I7yC+JzupJANe9k7keV4gRVmWVVnXNV3T0O209A66tn10oO87yccvT+R/FEVRYf75 pWmDcbjD3oS7bVnMtmG9c5g7TBlVSH/jmHRnJE0D+PTBGk0DXHd93w/DyZ9CHk3BNEU3PnGoD5wP SRIPcZqk7hC7aTa7M8y9efbyfPS8sSiWcYH9a1mquhavCtJo0bRCCEivQqxdu61b23XbtmGA/tFD Hd1DvSdzucHRzz9T/AgwABjoMSQKZW5kc3RyZWFtDWVuZG9iag0zMDUgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDk1IDAgUiAvTGVuZ3RoIDEwNCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiYTH2QJAIBRFUYlQIXPI+P8fqdvN8Gbt83ICQkhIKI1ixGIGEobS j8ziXABJ8yKkgnP/hZR2srypUqFKVV4NGtA2rdWh3hkcPWitR2tyZmBm4yxmQSvkbesOPY7X+esS YAD/VhQHCmVuZHN0cmVhbQ1lbmRvYmoNMzA2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMDAgMCBSIC9MZW5ndGggMTcwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJXIjbFoIgEEVJ7WIgieIFr6kIpKL//3eNueqhPWfPmjkIIXRCyEGuA3juzhnGhf/iXL/c AN+H3P1DADsu8TCUGO4A4wCkFAeUQh4QkNIwpCRkhEQRCeOYsJgzxnmS8ixJs5yLPBciL0RZFGVZ VXXdNHXbPNuq6/oeHKQcRinHUapBK6W1Mlobo1/GTLvTPE/Tsu9ltstq7fpx26z9czv88RZgAFV0 F8oKZW5kc3RyZWFtDWVuZG9iag0zMDcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDk2IDAgUiAvTGVuZ3RoIDI3OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iUzP6RaCIBCG4Ww1QsAlUsvSNEVRvP+76wNPy3tmzsDPZ7X65KH1Gou72e62u/3+sD988tHRP9oI 9oQ3od6GHJcIChghjOGwIOA8YJwzJATjQnAahpSGEY2jKI6T5BxLeb5ImSZZJtMsS/PrNctvt6K4 34tHWT6qsqyq57Oqm6Z+Nc3r1bY1tuvsKtX1SvWDUsOg9IC0Hkatp9GYaTIGZ57MPJu/nY2bX4t6 DbPLqsFGFv2Df+UnzEInG8/b4unjf3Ly4CNnYLPAyimjAiMoD0OxyBMrD2OZxImUF6tOs6uV5wXk uZXfrfxZPSB3amzdNrVTtwrytrPqHupe63508kmbEWqnN7Y/+fy7394CDACpCi9tCmVuZHN0cmVh bQ1lbmRvYmoNMzA4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5MyAwIFIg L0xlbmd0aCAyNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEz9lWgzAUheHK HCCEscwUJIRCjO37P53ngAX1xi/kX1nc7cvbi6bpumEY5smyLLw707Zs23EcuITA1V1Pd74Rsv3y qU8IpVg/COARsIBRysIQG0UxY3GSYNM0jd00y66ue83zwvPysoQWVVUXTdW2ddPUXXer+27o3vt+ HAY+jsM0QbkQE+ezEDPnd7GI+yyWZZ3ndZFYKeUHRMl1lUopuUceb7UFfcLmi4b0h4HMP9sPtr0t fz5xpw/D2YOcw/0dfQnwINgN4jiMUIJgd5rBt8l3JapAi26oQ8NugtkH8cPyizyp/3wJMAATaC3J CmVuZHN0cmVhbQ1lbmRvYmoNMzA5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA5MiAwIFIgL0xlbmd0aCAxNjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlM hokWgiAUBS21ImRRRFxSw9xA+f/f62nWac7cxfM87/TlfPYDPwjDy8H1nxuA0B0hjNGGH0U+OsCY gIRAMKWUEEYZBhkjjNM4jhlPEkGF4GmaCiGl5FKKLFN5rpSKlMqLoijLqqog5aOum6aGqtvmqXXb aa1fWnd93w8DVNeP7TRN8wg1wBo7WzsaY+xi1nXZdaBz1rlt9r9+/o+3AAMALv8W3AplbmRzdHJl YW0NZW5kb2JqDTMxMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDI1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTA5IDAg UiAvTGVuZ3RoIDE3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVyHWRKCMBAF QUWQTSaRNZAEQQh75P6Hcyh/LHu669UYpmEipzNyMQzraiH2gWM7zs11Pd/1fT84LnAD/MN7BMTz vG+EUJSSB0YpEApACQCBOAYshgRN0yTO8hTyPMmLIssYKxPGMlZVZcl5FXEeciGkFLWQ9VPWjWzb V9f2TdOrvlEKVcMwjqobR5xpnqdpwdB1WdZ1w5YNd9Navw/3XWO7/vGfjwADAEVEG5cKZW5kc3Ry ZWFtDWVuZG9iag0zMTEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwMyAw IFIgL0xlbmd0aCAxMTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImExdsWgiAU hOFErMAUsvJQgYKH93/EZm8X3vbNv9acMiFELmSRFwcpzxe4MqWUVlrr8sZKqKq6NsbYO7ImjeI7 NLbZPcgTvaCFru1h6Af23n3IlzjnvPPejzCNEwkBsRhiMse4zEuy0pLtr58AAwAUmxbRCmVuZHN0 cmVhbQ1lbmRvYmoNMzEyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMDUg MCBSIC9MZW5ndGggMTg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjM/ZEoIw DEBRhUJlL2Upmws74v//n0mBKs44epI85ekejppOCDH2TJOeLBzLlhzJ9dyFHwSUMhAyKk8OxWNM PgDnsCiKoxglKRJpJoTIclRIZVGB86W6gCu4oRo1qAVd2yl91ysDjjK+TOP0A9HvRJvnz3TDZNQC NqY7S7nnrOW+/4DyEJpxVbhq39LXcs7X9DjBeOwW+Xt6VWK6DN+nN/VWDunt1v01HNKHf7un6SnA AGmwMD8KZW5kc3RyZWFtDWVuZG9iag0zMTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDEwNiAwIFIgL0xlbmd0aCAzMDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIlckGF3giAUhtmydC0h1FBT0SxRREXc9v//2i5W2zk93Pu+HL49IPT2vtk42832hd3Odb2P /ed+f7DH4h98z7d4ACZHiumREIoxJgQCU3un5JEEXoNgzdBuGEYkiE4nFrE4iRmL0nOWsCTLsjxN 86LgOS/LknOOqkvN6+vtVqG6ahpRibZtOyE6KXvRK6l6QKmhH0bIaRq0nodZaz3O82wM5GigzLIs 0GbN5Zn/fH0Lx3HA+0Xd3bqui0Hdcrjj//gPcR9Tb1W8L6aQ8A9Q0OsLmBMawEYBTBgQFoYEdJlV j+MkSs4wWWLN06JIuVUvS5RfLry8XhGYV+jW1ALUrbmQUrSg3kspO6X6wUorNU9aTyOog/k4GAMF 8jDL3XaddZ/3P34FGABajjU1CmVuZHN0cmVhbQ1lbmRvYmoNMzE0IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMDcgMCBSIC9MZW5ndGggMTQ3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJfMfbFoIgFATQsosBJaEkKmFIBgXq/39eB62XHtozzFms1skm2e72 v9L0gDAh5BidZhmlNJt7xhgjxlgOkzOEGAShz8QPWxQLXnB+4WWMEKISZVXVTV03EnKVUkl4SrXq prXuWt11xph7Dx69tdbZp3PuBY1gPRwfJd6H4AeYEIYQRjjj1zRB/3oLMADt6RohCmVuZHN0cmVh bQ1lbmRvYmoNMzE1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMDQgMCBS IC9MZW5ndGggMTg5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhM/JFoIwDEBR RAu1UGQoBRVERgf+//9MUqjsuEl6un3OwT2eGPN8HxYxxp0zEmchRCACEIYyAjKSFxTHSZKkRgaz vMvHUkaulNa51oUuCs55yUtwJTfjblSoBg/UgCdpUdd2Vm8N/bA1bkx73NfLgzXVVM/YW5lwSqfy IJQgklAuTTlVgzSz8XTZ2q5wCHUD7Mb0svyY7uvS/cXuuZrX8HoNb2x4a8P7TTil/+PHf/q0X/4T YAD5CTDpCmVuZHN0cmVhbQ1lbmRvYmoNMzE2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTQgMCBSIC9MZW5ndGggMjYzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJXM9te0MwGIZhiYWOWSpR8R6KFl0V+///bY/IzLH7yJXk62kgjJGJTIzNN4Jglm3Z9gn2 rmY57oee57mu56FPRB3qOHTrTH1KfR1bg4sx6sPLOGeME8aDgJMgIORyISQMhQgjIaJIxEkSQ2ma ZXGeFXleFDIvSykrea1lU7dN07a35n6/dfe+6/p+gLrh8fj67Tk+ns9xVL3GcZrmeXpB07zAWWbV rH//ZhgGhiHMQc0QR7baSQ/ouxyGPPebus5BvqtVm/hPvRYwBnIuhJILLTejyDRBnibZKk/TYpWX uSwhWV3rqtLy20E+KDm8q1q1q6FZyVXL7tXyZeuwHwEGAFS8NTgKZW5kc3RyZWFtDWVuZG9iag0z MTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMyAwIFIgL0xlbmd0aCAx NzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlcxokSgiAUhWEDl1KTAPcFywUU JfX9Xy7Mmmn65v5nrmF8nAA0LdOyTJ1mW7bmOM754noH/+qZvusGbrBDKLghHCCM0U8YEYLwEcEQ EgIpISGlMNQTRZTGMQBJCkCagiTLkr28KPK8KKuqLFlV14yx+6NhbdO1bdf1Pee94FyIYRDjIPfG UcpxknKalZxnpd49lVoWtS7LuurTtu3o+/15CTAANm4ZfgplbmRzdHJlYW0NZW5kb2JqDTMxOCAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTA4IDAgUiAvTGVuZ3RoIDE3MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVTGiQ6CMAyAYUUdKPcxnTiugTJgwBjv /252kJj4pf3bw9EwjNPuDHsxkLmzTAtcwc12XEdzXc+DsTU/CIIw1PHhoO1HIUD6RwAaRRFCcZzo JjiJY3x/YCh5EoxJmhL8IjRLSU6zguY5LcqC0rKqWF1XTcPqN/u0nHV9O/Cu48PQci6Gsed8Gsex 1xHTJOZZCiG3LkqpRSq1KinVuq5K568/XwEGAJPRGo0KZW5kc3RyZWFtDWVuZG9iag0zMTkgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAy IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExMiAwIFIgL0xlbmd0aCAyOTcgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlk0OtygyAUBGAlFxsDATGiUWO8SyRg27z/ u/WAybQz3dk9/P7wfM+HwoF4aLPZvrLb7mz2++Dj8JvwGIZhEGAoxgEhJ0wIfo8QijGlBAZlhDJG 7SKEWIR4xOI44ucz5+eE8yThIk2FSLOLyLJLXmR5XhRlfr3mVVXe6rKp26Zp267p+27ox2EYxwk2 TFJOdylneO+zVPOs1j2U0toY/YAZs0Dfs3f5l09vRfv+l41A6GXfOfoe6N/h4bi6gb3KTyAnGAZ4 pyYnJ7fHsTEFNGGMYZAzFDGGEKccRXHs5CISgidOnqbPPH1mWWHlxaWoLP7WlHVdW3lbtS3gnbzv xrGTo5xAPU4Wr6RVq7vWszLKqs3DddEWq5cX28nN8vcLfgQYAIJqMSUKZW5kc3RyZWFtDWVuZG9i ag0zMjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAg L0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwMSAwIFIgL0xlbmd0 aCAyOTEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlk0OtygyAQBeBoRAXxitEY 7wqKmqbJ+79cF6xpOz1zdhb493E6HTEgpmkaZ/NsGNYJ6cCCV9t2HD3Od/aza1nI0HdXBWPsEgIl GHsewdQjsHyfUD+gNAhCGkU0iOIwjOM4TBIoS2PG2IVlKcuy/FoURX675beyrOqyKaumqZu27bq2 bft2gA7jOPCh43wUnIuJz3yScpq5kFLMUi7zuq6L7gbdtlX3z/mdw303foLQhwpClvqLx+PTftj2 Ln8C83ngXQtZrvOmA1zJMcgJATmwIT4lnu97IAd9RMM4UvIXsF+XJLmkjKVpxtI8y1heFFeQX6td XgO77nd51w9DP2o5DMgnzielF1xOQij5IuUM8hnYsLX23/yWfwkwAA4jK3sKZW5kc3RyZWFtDWVu ZG9iag0zMjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy NTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNyAwIFIgL0xl bmd0aCAxMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEzwkWgyAMRVGEQFW0 Toj732kzAKL2HG9+FvCUyhrV0PiFlrsx2jwAjlmccNaxj2tZR3rie88GNg4j+aKJzGQR67KKDZeF LRQ73SnuMTni8UapKv2MlvA6HviBsrV51APkdFvSU3sdntIl3N/CuXye6vKSjuGlPYRL+p9uSn/1 E2AA9/sXAwplbmRzdHJlYW0NZW5kb2JqDTMyMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTMwIDAgUiAvTGVuZ3RoIDkwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJhMNJEoAgDERRJAwKOACi97+pCYGSKhe+/i3EYKINJCVBynpFaUxjH0orBgqIAcOssdVM Fuac8xgJPoSwYmhDOztY7FJMTaY1Zy4Fe13d/esRYABLvAs1CmVuZHN0cmVhbQ1lbmRvYmoNMzIz IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzIgMCBSIC9MZW5ndGggMTEw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJfMXbEsIgEANQbmJFBaGwbf//R03Y dsYnzyZZY6why1hnLNeCc/zOO/DagPMh4F1u4YdXMcY5d0Qt8FhSSuhzetFb5ZzRkkvJn6nW2pDW VoS4HaF19DE6qkRYkW0T2Xmn42D/+gowAJ75DE4KZW5kc3RyZWFtDWVuZG9iag0zMjQgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAyIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyOSAwIFIgL0xlbmd0aCAxNDEgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEzwsSgyAMRVEIH8XagiDuf6kSkkIrznhesoAr RCOFHIBUEqAc6PoGypmRNpoprYhVlkzVjNzsnFvcgl5sRW/0qbz3wQe0dXGLLOHYXpb2LjdHPp6I f5d6oIECbr/NpnRjLulcPtlejuEt/Ru/tnbsxnJP5aU9jOmxhScK/2nPPf6x/BRgAEz9FfoKZW5k c3RyZWFtDWVuZG9iag0zMjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEy MyAwIFIgL0xlbmd0aCAxNzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlMydsW giAQhWEOA5paeAoTCRFFfP8nbGh10Vx8+19rCKWEMU4pZ4xQCowTCoRzwOacCEFIbhwQ+JAiNwAV AJA7DyJRIaUUIItCYhY4srzdslVVl2XVNGh9vzdl/VBKtQ/Vdapt+2Ho+nF4Pod+1NM0aT29ZqO1 mefFmNna5W0Wa926Wu9R5zfvXNi24PYN3fdwHDGEeBxnOM+U0hmRFGO8riulL7+5/u8jwADzlxIF CmVuZHN0cmVhbQ1lbmRvYmoNMzI2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMjEgMCBSIC9MZW5ndGggMTcwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ PMaBEoIgEEVRwGVBU8wslcQQUPz/P2yzqZ3zdi7jnDFRMFYIwQCE4BQFF+Lb/IODpH0aKCUHKE7U cIYERJCIKJWSqBSi0gq1xlLrsqyqqqwupG6auq5N2xpjrqYjnbn1fXfvH/d+eIzjMAzjNI2Ttc+n tXZ2brbOLYtz7uU88evqvV9CWGNc6YeQYkwp0OKW0r7lnPacyUGOI5/O/fp/bwEGABQzEiAKZW5k c3RyZWFtDWVuZG9iag0zMjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEx OCAwIFIgL0xlbmd0aCAyNTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlkz9d2 wyAMgGGEWB71ilfs4G3n/d+wAk6atNXRj7j9GABjwBnjyASAEMCF4CgEogD0fwB0SQVcIl0EKRHp j/KdolXoUlorZVxG6choHUWxTpI4TZI0/aKJsjzPsrygLfK8LKsbVdR107Rt2XRd03f3vr+7hn4c hseDGq0dJ2unaXbN07TQu6zztq7btlPrvm3Hfp6+47zO8/rf9THMyykOgiFnAuElBxdIrw5JScf3 V07oINfSy7UJcmPimOQmesudmiqK7EZyUudVWVcVycu2fT4/5GOQj07+sEOQ2yBf7OLls5OvQX7u h1dTBD1+i1/9zLcAAwDmFCMZCmVuZHN0cmVhbQ1lbmRvYmoNMzI4IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTYgMCBSIC9MZW5ndGggMjg3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJbNDRdoMgDAZgIxEQbcVqtVVahCp17/+CC3i29WKc/Ml/+5EBZBnk WZYDyxAYg5wx6gyRAeYMCgTAgpIDp45FQcmR7mc4InKOheAFF4JzITmXkpdSiVIpWaqqrKuqrk/0 zo3Wp0a350vb6kvXUfrr0PdDN4634X4fpvk+TTOt2UwPYx4xT2ufi7XLEbd4vzj38s55v64p2xq2 dzgS9hDCvn9mD2n+XlKzqGUZUaMcIj7Kjw6kJj2QNk+/gLHESWr8Sp2TnhP7Ry5KpCulFEKpmitV Vr9ypbWutW7atr3otuvOXUf4fhjGcbyOI+HnKJ9vcaLaGDMZQ/iktk/rH84u3i0uqmm9to3w65vU 4Z0myfft0P4r/xZgAE5GJL4KZW5kc3RyZWFtDWVuZG9iag0zMjkgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xlbmd0aCAxNjIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIlUxocOwyAMRVEMZmVBm73JIv//h4VWVdUnH10TAEKAEkKBMADGEBmj +CkihB8AIw5AeSwC54g04F+IgnMhQiSilEJESgmplJRaJ0mqkyxNsywP04UxRWHsI7f2aWxZVWVZ 2bpumrYtm65r6q4fhj4ah2kc5zlalilYVxe5dd0257bdHft+HGewn6HX4a/LR7f395/bv++3lwAD AAf3EfgKZW5kc3RyZWFtDWVuZG9iag0zMzAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyNTAgL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDEzMSAwIFIgL0xlbmd0aCAzMDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIlUkNmWgyAQRMEGFBcS9z1qRHH+/wenSGbtU9zqw9ttxjkLAuYBcgoE4ySEIOmLODHBiHPJ QKkYvrkkEPi/Y5QiSaFSSpIKfUdRhAq1juJIJ0kax2mWJanOjLml95vJza3Iy7wqiqqsm6qp27Zp mq7v224Yx3HohmGa5mGewMdjXpZ1XpdtWTHb9lzX577Zp9333Vp77Pt5nM6583iXu64L7V68vvk7 PAi4gDQTgXjt0GUC+kJwfBIxhrPgGoxJyQin8IGoVyb6kO8dyt5XEZyVDEMk8uahSlMVaR3HOtFx ksRJlqV3AxhzN3le4OVFWRZlXedN29ZV2zdt3w8w77tp6kZIe/PHtCCQXpZl3rbVWsgjkIYynj3R UN4P5w7nvmxfuf7uP/MpwACDCCQtCmVuZHN0cmVhbQ1lbmRvYmoNMzMxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTEgMCBSIC9MZW5ndGggMTc4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJlNDHEoIwEIBhShBIAUEiEpoU4f3f0GzaCB4cv53JHvb0x/M8 3w+CEKEIReACA+IkSSWM09DC8BBACWVUbqzoC9EnkpHMyrWrVkhlUYKbUmm84tId1NIDNIpohNGK VutgnL7rPwzOOIy/QDhhCJh0GW/qYxMP+VCcMfac5mV9bdu+r8s6TxPFtj10v+La81N6odLLj3TT zrlNr8/p4iu9PYQf2of+j/S3AAMAqsMmGgplbmRzdHJlYW0NZW5kb2JqDTMzMiAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTggMCBSIC9MZW5ndGggMTMwIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhMTbEoIgFEDR4hKhgIARphje+/8/7ADN+NiaPftyRZgQ Qm+UUkYZuzPGOMjjvKrqWgipEG60NsZY2z5aa7RzjdNOa/wUhZRSSZUhhX488lnnu+SV9cnQDyAE KIQxjOCdxRinOIE5WealWFeo2Dao2KHTsR+nz19fAQYApTEYEwplbmRzdHJlYW0NZW5kb2JqDTMz MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgOTkgMCBSIC9MZW5ndGggMTgw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJRIkLDoIwEAUpCLRYFimIBYpU+Vag 3P92LhrjJDvzknUchBx34BLXO3mI6xGPEN8JAt8PQkIJpYxFDB2xM8MZoZgb8pAeg+KDxhBjYwCg AEkCuJILHLpw4Gmacs5Flgkh8jy/CnEtivwmy7KUUlZ1rWTVNI2qlLq3Wun28dBPrbuu132HHoZ+ HKd+GtHIPJvJzOjXyyyLMWZdlm3drLXb+o3d9x1rP95//vMWYAAFrBdHCmVuZHN0cmVhbQ1lbmRv YmoNMzM0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUw IC9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA5NyAwIFIgL0xlbmd0 aCAxOTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImE0NkagiAQhuGCUUEMLLf2 tMX7v8TmHyQPe4fxgcPPzVYppTFAOqOM5VlOlAMVRtvSuWrHqsqVpfXWRNa6ku+FPEIIng/UfKJ9 vReHqGmatmlFF/ViiI7sxM5wEdef2+q+emCTERNN4/TPUwmtnxJOlL24G4gIP8MpxzjZWu+RWCTG eOtSeQgG3Sm9TunS/uZBONrbFttJfN9L+xDbjwPCeRF+uqzp+Nx+7dy6xH/uM6fPiJ7nJT6Z/rZ/ BRgAdb4n+AplbmRzdHJlYW0NZW5kb2JqDTMzNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMTI2IDAgUiAvTGVuZ3RoIDk3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJhMnZDoAgDERRWQStiDu4/f932tKgMTHx3HmbokBCCCmV0rpEpjTW2ipRlXrR1Be+awY1 kAYcONYi33rSJT0bkjGZ0EwWFJZAYrbG9bY99m2nsYPKzl+XAAMA/GMPYAplbmRzdHJlYW0NZW5k b2JqDTMzNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1 MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI0IDAgUiAvTGVu Z3RoIDE3MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWTG6Q6DIBBGUZZhFDeq VlxQXBB8/zcsmv5o0knOfJdQShil7EY4JcA5i4BwHpsBMCYEYwQwLoAgAOS7IsbTDwQBiBAhJAlg kiCmqYxQZpmUeVbIPJdFWVZZqV6VUlVZ16qpW9W0bfNuO627Xut+0N0wdOM0jeNkxtmYeTFmma2d V2vXdbttq93j3w+3HYdzj9O7EJwPp/chXN776/pz/dxHgAEA9NYRyAplbmRzdHJlYW0NZW5kb2Jq DTMzNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAv SGVpZ2h0IDIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI4IDAgUiAvTGVuZ3Ro IDI2NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiVzP23KEIAyAYSCygK4u4gpa z6eq7/+Cjeh0bZn8EyZ3H6GUEUoJBoQGjAQBMAwCwoHgnxDghHCOywfAbj3wcNwwwbkQAEKCOJJS CKWEVEqGURSq6Kni5zOMkyR6JTpNtX6lxmSZMW+d55mx1jhbOFcW7qssq6quq6qpq7Zpuu6ob9qh 7wffOA7TNI8jtszzsszfZ+u6bb5t23E+7Z9+H7nkgLGAMlQzVKM4YCgGOOXM61HIUMv85hzpj1N9 huQjAHnJpZJSxbiiEPVxeMrjKEm8PNEGx+gM5e/cOpTnriicLUvr5XVzyNtT3rfdTT700yFfRi+f /8nXbV/v8ov9R/4jwADRtyWUCmVuZHN0cmVhbQ1lbmRvYmoNMzM4IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjUwIC9IZWlnaHQgMiAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMjcgMCBSIC9MZW5ndGggMjgwIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJRI9REoIgAESBABVF0bKyMBVRvP8JW2gqZ3m7DP48QimhlDJyOjHO YhghABeCC8bkdzOBLTCkRCSJ+G4pJH4GskzgZBLJ8zzL8kJlRYGUSpVlqcpKVVqXtda61k3dNEa3 xpjOmPZ8vvTXy+2Cc73f78Pj+Xw+YqwdR2vtgH69XtMEYMzLMqW4dXXOb96jnN9dCHvK4cNxHP44 YoWEz/59lJATpYKjoMgJE4RzLggI0Q9xA2TccP2Ip0qIjM9JPDKHfxTHvSjgD+nEqlaqqjTY6UZ3 XWMM2JqzaaM42EO9728Q7/shqg8Qnx/DbO00jpBOXOC/LvDeovi2RfV19c7t6w7nsHsgeP93DuG3 //ZvAQYADa8kcQplbmRzdHJlYW0NZW5kb2JqDTMzOSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTI1IDAgUiAvTGVuZ3RoIDE2NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiVzJ2RKDIAwF0IiB4lYtKoqoiAv+/x826kNnmsm5ySQQRYxd4hghjoExhhRwQcY4 3ARwRA4P2jlQwIsm58/9+qMQiEIil5KGFCJJbmmWpUmWJ2mep1lRvMui+ryrqiyUqmvVVHXT1Kpt lG47rbtem743ZhiINaO142Wa7eTm2bl5cW5ZnF8pV79s3m/bTvyxheMI4dhJOM/w5wx3/+orwAD6 vRHsCmVuZHN0cmVhbQ1lbmRvYmoNMzQwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ +vnzZ0dHhxgSOHv2LECAAQBkIwfzCmVuZHN0cmVhbQ1lbmRvYmoNMzQxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJ6ujoEBMT6+joAAgwABFDA3MKZW5kc3RyZWFtDWVuZG9iag0zNDIg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjUgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImKiYkRQwJnz54Fkh0dHQABBgBAkgZeCmVu ZHN0cmVhbQ1lbmRvYmoNMzQzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5 IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJiomJERMT i4mJAQgwAAwbAmsKZW5kc3RyZWFtDWVuZG9iag0zNDQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIkSExPr6OgACDAABIAB2wplbmRzdHJlYW0NZW5kb2JqDTM0NSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIierv7xcTE3N1dX3+/PncuXPFwKC/vx8gwAB6YQl8CmVuZHN0cmVh bQ1lbmRvYmoNMzQ2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAv TGVuZ3RoIDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJWrJkiZiYmLi4OJDM zc0FCDAAI80D/QplbmRzdHJlYW0NZW5kb2JqDTM0NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiaqrqxMXFz9w4ABAgAEAEbIEAAplbmRzdHJlYW0NZW5kb2JqDTM0OCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiUpKShITE7MBAyBj0qRJAAEGAClGBMkKZW5kc3RyZWFtDWVu ZG9iag0zNDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5n dGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq6OgQA4OYmBiAAAMAFxYD MQplbmRzdHJlYW0NZW5kb2JqDTM1MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiUpL SxPDADNmzAAIMAAyfASHCmVuZHN0cmVhbQ1lbmRvYmoNMzUxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJunz5spaWlpiY2IwZMwACDAAkCQUCCmVuZHN0cmVhbQ1lbmRvYmoNMzUyIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDMyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJSklJEYOBmJiYL1++ODo6qqurX7p0CSDAAGnk CZEKZW5kc3RyZWFtDWVuZG9iag0zNTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA4IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInq 7+8XwwD9/f0AAQYAPVME5wplbmRzdHJlYW0NZW5kb2JqDTM1NCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIicrKyjIyMrp27RpAgAEAEesEVwplbmRzdHJlYW0NZW5kb2JqDTM1NSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZo3b54YDGRmZsLZ8+bNAwgwAFrVBnwKZW5kc3Ry ZWFtDWVuZG9iag0zNTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBS IC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaMmWKmJjYtGnT foIBQIABAD2qCZcKZW5kc3RyZWFtDWVuZG9iag0zNTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInq6OgQg4GzZ88CBBgAIV0ExgplbmRzdHJlYW0NZW5kb2JqDTM1OCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiZoyZYoYDEyZMgUgwAAh/wQ/CmVuZHN0cmVhbQ1lbmRvYmoN MzU5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNiAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI2 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJEhMDgQULFoSEhAAZkyZNAggwAClG BVkKZW5kc3RyZWFtDWVuZG9iag0zNjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMTkgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIma N2+eGBhcu3Zt4cKFQBIgwABIgQlGCmVuZHN0cmVhbQ1lbmRvYmoNMzYxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJmjdvnpiYWFZWFkCAAQASnwNbCmVuZHN0cmVhbQ1lbmRvYmoNMzYy IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTAgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyOSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZoyZYoYGKxdu7a6uloMCSQnJwMEGACM NwfqCmVuZHN0cmVhbQ1lbmRvYmoNMzYzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMTE5IDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ mjZtmpiYmKOj45cvX2JiYsSQAECAAQCJYQfACmVuZHN0cmVhbQ1lbmRvYmoNMzY0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTAgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicrIyBCDgcjIyHv37sG5s2fPBggwAHU5CDsKZW5kc3Ry ZWFtDWVuZG9iag0zNjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA2IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBS IC9MZW5ndGggMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImKiYkRg4GOjo6f P38CBBgAKLYGXgplbmRzdHJlYW0NZW5kb2JqDTM2NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIlqbm4Wg4FmJPb58+ctLCzg4gABBgC6OQnBCmVuZHN0cmVhbQ1lbmRvYmoNMzY3IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTEgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzOSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTp//nxaWpoYGGzdutXc3BzIMDMze/z4MZAR Hx8PEGAA1cwL1AplbmRzdHJlYW0NZW5kb2JqDTM2OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInq6ekRQwJWYIAs0tPTAxBgAHwmBrUKZW5kc3RyZWFtDWVuZG9iag0zNjkgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMTcgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaN2+eGBgABBgAEKcCXwplbmRzdHJlYW0NZW5kb2Jq DTM3MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGgg MzQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlKS0sTExObMWOGGCooLy/fsWMH kJGWlgYQYACj7wmICmVuZHN0cmVhbQ1lbmRvYmoNMzcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJSkpKEkMCSUlJAAEGAB+wA1UKZW5kc3RyZWFtDWVuZG9iag0zNzIgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm6dAkETE1NxcTEpkyZAhBgAEdPB4oKZW5kc3RyZWFtDWVu ZG9iag0zNzMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5n dGggMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaPXu2GBi0t7f/hAGAAAMA aZMMrAplbmRzdHJlYW0NZW5kb2JqDTM3NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iUpLSxMDg7S0NIAAAwAS8ALpCmVuZHN0cmVhbQ1lbmRvYmoNMzc1IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ+vnzp5mZmZiY2IwZMwACDAAqDwWYCmVuZHN0cmVhbQ1lbmRvYmoNMzc2 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDE1IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vkTCgACDAArzgjCCmVuZHN0cmVhbQ1l bmRvYmoNMzc3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVu Z3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjRpkhgMKCsrX7x4ESDA ACydBVkKZW5kc3RyZWFtDWVuZG9iag0zNzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIk6cOCAuLh4XV0dQIABABZWBAAKZW5kc3RyZWFtDWVuZG9iag0zNzkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIm6dOmSqqqqmJgYkLx06RJAgAEAMG8GDQplbmRzdHJlYW0NZW5kb2Jq DTM4MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDcgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZowYYIYEtDQ0Pj58ydAgAEANucG HAplbmRzdHJlYW0NZW5kb2JqDTM4MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAxNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiTp7 FgQAAgwAENcEzwplbmRzdHJlYW0NZW5kb2JqDTM4MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiero6BDDAD9//gQIMAA97AYQCmVuZHN0cmVhbQ1lbmRvYmoNMzgzIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMyAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIwIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJiomJERMT6+joAAgwAA0jAu8KZW5kc3RyZWFtDWVuZG9iag0z ODQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNyAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDQ0 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJSkpKEkMC3d3dcnJyQIanp+fq1ash gjNmzNDR0YGwJ02aBBBgACSADFIKZW5kc3RyZWFtDWVuZG9iag0zODUgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImKiYkRg4GzZ88CBBgAGiUEQgplbmRzdHJlYW0NZW5kb2JqDTM4NiAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiUpJSRGDAXFxcTh72rRpAAEGADuFBMAKZW5k c3RyZWFtDWVuZG9iag0zODcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAzIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkg MCBSIC9MZW5ndGggMTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkSEwOBefPm AQQYAAcXAl8KZW5kc3RyZWFtDWVuZG9iag0zODggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImaNm2aGAyIi4tDGOrq6pcuXQIIMABNKAY9CmVuZHN0cmVhbQ1lbmRvYmoNMzg5IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNiAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjdvnhgMGBkZXbt2DSDAADAABbkKZW5kc3RyZWFt DWVuZG9iag0zOTAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9M ZW5ndGggMjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6+fNnR0eHmJgYkAQI MAAxXwZeCmVuZHN0cmVhbQ1lbmRvYmoNMzkxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMTEgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiero6BBDAmfPnkVmxMTEAAQYAJJYCUkKZW5kc3RyZWFtDWVuZG9iag0zOTIgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjYgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImKiYkRA4OOjg4xGPj58ydAgAEARMQG4gplbmRzdHJlYW0N ZW5kb2JqDTM5MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xl bmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr58+fdu3fFxcXFxMSW LFkCEGAATLAH9gplbmRzdHJlYW0NZW5kb2JqDTM5NCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiVq4cKGFhYW4uLiYmNiSJUsAAgwAKPsE/wplbmRzdHJlYW0NZW5kb2JqDTM5NSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMzkgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlKSkoSExObNGkSkFRWVr548eLPnz+1tbXFYAAo BRBgAOWYDCUKZW5kc3RyZWFtDWVuZG9iag0zOTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSInKzc0VExMTFxcHkkuWLAEIMAAcEQP9CmVuZHN0cmVhbQ1lbmRvYmoNMzk3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNyAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmj17tpiYmKam5s+fP4EkkD179myAAAMAWGIICAplbmRz dHJlYW0NZW5kb2JqDTM5OCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr586e+vr6Y mJiqquqlS5cAAgwAOB8GoAplbmRzdHJlYW0NZW5kb2JqDTM5OSAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiZo2bZoYGKiqqv78+RNIAtnq6uqXLl0CCDAAdygJPQplbmRzdHJlYW0NZW5k b2JqDTQwMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEw IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5n dGggMzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImaPXu2GBJQU1NbuHChnJwc kJ2RkQEQYABsfgcDCmVuZHN0cmVhbQ1lbmRvYmoNNDAxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTIgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCA0MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiUpKShITE9uxY4eNjY0YGCSBRS5cuLBgwQIgY9KkSQABBgDSJAx5CmVuZHN0cmVh bQ1lbmRvYmoNNDAyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggOSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAv TGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJSklJEQODJUuWdHR0 QNjq6uqXLl0CCDAAbMAIpAplbmRzdHJlYW0NZW5kb2JqDTQwMyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDkgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIicrKyhIDA19fXyMjIwgbyLh27RpAgAEAT+AG3AplbmRzdHJlYW0NZW5kb2Jq DTQwNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAy MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZoxY4YYGMyYMQMgwAAajgQVCmVu ZHN0cmVhbQ1lbmRvYmoNNDA1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNiAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5 IDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjRpkpiY 2IIFC0JCQoCMSZMmAQQYAEH6Bs0KZW5kc3RyZWFtDWVuZG9iag00MDYgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImaMWOGmJiYmZnZz58/AQIMAB60BZgKZW5kc3RyZWFtDWVuZG9iag00 MDcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjYg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImKiYkRExPr6OgQQwJnz54FCDAAR74G XgplbmRzdHJlYW0NZW5kb2JqDTQwOCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDUgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDExOSAwIFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibpx 48axY8fExcXFxMSWLFkCEGAARE8HTgplbmRzdHJlYW0NZW5kb2JqDTQwOSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExIC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIk6e/asGAx0gAGQERMTA2GcPXsWIMAAvmUL9QplbmRzdHJlYW0N ZW5kb2JqDTQxMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDEyIC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9M ZW5ndGggMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlKSkoSgwFtbe2TJ09C 2AsWLAgJCVFWVr548SJAgAEApOgLBQplbmRzdHJlYW0NZW5kb2JqDTQxMSAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDMgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAxOCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiRITA4F58+YBBBgABxcCXwplbmRzdHJlYW0NZW5kb2JqDTQxMiAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifr586eZmZmYmNiMGTMAAgwAKg8FmAplbmRz dHJlYW0NZW5kb2JqDTQxMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDggL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAw IFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYqJiRGDgbNn z0IYHR0dAAEGAEcBBl4KZW5kc3RyZWFtDWVuZG9iag00MTQgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGggMjMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSImaMmWKGBioqqpeunQJIMAAJFQFJgplbmRzdHJlYW0NZW5kb2JqDTQxNSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyMCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiSouLhYDg7Vr1wIEGAAWRwPlCmVuZHN0cmVhbQ1l bmRvYmoNNDE2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE5IDAgUiAvTGVu Z3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJmjJlihgYqKqqXrp0CSDA ACRUBSYKZW5kc3RyZWFtDWVuZG9iag00MTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA5IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxMTkgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SInKysoSAwNfX18jIyMxGJg3bx5AgAEATOwF4AplbmRzdHJlYW0NZW5kb2JqDTQxOCAwIG9iag02 ODAgDWVuZG9iag00MTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0MTgg MCBSID4+IA1zdHJlYW0NCkiJdJXdTttAEEbv/RRzVTkSHvZ3bFdVVRUQpRISRW5R1fTCMpvgKrap SUrF03fWCVDYrCLFiTx7djzHn50cnnVKF3A8JF+S34kAWeRoIRNIBAJ0gWSAJAopLDRdMpWXQblE Y7jcCBTF63IjYnQuzwO6kVG6QhnSVZSusAjpOko3qEK6idINliHdRumEOqRTlJ6jCOl5lF6gCelR q6ZEGdKjVq1AG9Bt1KqVqAK6jVq1CimkR61ajTqkR61ag3lIj1q11i97XR61agmLkB61avlPSI9a tQWWIT1q1ZZ7smqjVn1hQKeoVS4Ms0pRq6T3ZJWiVrk8zCpFrZLdk1WKWuXyMKsUtUr5nqxS1CoV e7JKUatU7skq7ax+rJLDqlIgoVrwSk2Qab+HEoW3JXONZcnLqo7P+s9d0yf80BVCQdUk2ePP+yQ9 db0b6xVcDpu1G+G87uul61y/hln1i9do5VtSQuZQHW8Z8plBE+NiHNZDM6xgnp5enl/MZ/DNjXft 0IP0EG7VPLbKkc+Uvz4tyOefQ4akt61ukdrTxcR9dz3Wi3V2X/fLbDGMjbvLlmN3mwmB67/r91OD IEt/+2fbA3O19WFTiiOa70bgsXbCPl33j/TKtV07syjTfglXvMUBfN/0C9fC6WY44K+671o+NTNo U39+9rP6/GLsklD46UwH/yIpkS1YmaMs/9vZPO1sd9NydzxfN74FgKmLXQPTxHkIxnDYMx+kUr4c uti2Pk/vOx4KN5+nyw9d3a7w5qFt0F1vsOnns6lTvnO0njhU8OPkkaOf5RVb2rG7XSMMCzjrFwPC GzhZuQbhxPPLdIkTLeMHpOZ37oST5HHZqxtK0pb3iS/l4YYXm3TYwNe+/TPRj4auc+zwAI5u2r6G CXtSJf8EGADqKNLLDWVuZHN0cmVhbQ1lbmRvYmoNNDIwIDAgb2JqDTw8IC9MZW5ndGggMTM4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHsAhP8ykMkpdaYvpOkznNs5hbg1eahG jLtQlsRemL5boM1mqdNoo8lur9h4ttx3rtGEveF5qceRx+iJttKf0O6WwNqq1/KjyuGz3fa94/rH 6f252OrK4vDS7v6w0OTW6PHF3evc8v/m9v/l7/bg6e7y+v/y9/rv9Pb6/f3///8CDACEIlwNCmVu ZHN0cmVhbQ1lbmRvYmoNNDIxIDAgb2JqDTw8IC9MZW5ndGggMTMyIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJAHUAiv+jyuGqusW558iW4KZi1YBm82dToqJOUedBQcs+Qaw+QYQl UXAzT04taZI1eag5hbhGjLsykMlQlsRboM1oo8lmqdNur9h3rtF4ttyEveGRx+if0O6q1/Kz3fa9 4/rH6f3S7v7c8v/m9v/y9/ry+v/6/f3///8CDADITk4OCmVuZHN0cmVhbQ1lbmRvYmoNNDIyIDAg b2JqDTw8IC9MZW5ndGggMTQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAH4A gf8vpOkykMkpdaYznNs5hbg1eahGjLtQlsRboM1emL5mqdNur9hoo8l4ttx3rtF5qceEveGRx+iJ ttKf0O6q1/KWwNqjyuGz3faw0OS94/q52OrH6f3S7v7K4vDF3evc8v/W6PHm9v/l7/bg6e7y+v/y 9/r6/f3v9Pb///8taZICDACZmF01CmVuZHN0cmVhbQ1lbmRvYmoNNDIzIDAgb2JqDTw8IC9MZW5n dGggMTc3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAKIAXf+jyuGUrZ54upWW 4Ka558hm82di1YBConstaZJZXaI+QaxBQcs+QYQlUXA1eahGjLsykMk5hbhQlsRboM1emL5mqdNo o8lur9h3rtF5qcd4ttyEveGJttKRx+iWwNqf0O652Oqq1/Kw0OSz3fa94/rH6f3F3evS7v7K4vDc 8v/W6PHm9v/l7/by9/rg6e7y+v/v9Pb6/f3///9tibGqusUzT04CDAAEom/kCmVuZHN0cmVhbQ1l bmRvYmoNNDI0IDAgb2JqDTw8IC9MZW5ndGggMTY1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJAJYAaf94upVToqJoo8lQlsRtibFOUedBQcs+Qaw+QYRZXaIlUXBLcmEzT05thIUt aZI1eagpdaY5hbhGjLtemL5boM1mqdNur9h3rtF4ttyEveGJttKRx+if0O6WwNqjyuGq1/Kw0OSz 3fa94/q52OrH6f3F3evS7v7K4vDc8v/W6PHm9v/g6e7l7/by+v/v9Pby9/r6/f3///8CDABFOGYD CmVuZHN0cmVhbQ1lbmRvYmoNNDI1IDAgb2JqDTw8IC9MZW5ndGggNzMgPj4gDXN0cmVhbQ0KL6Tp M5zbMpDJUJbERoy7OYW4W6DNZqnTbq/YeLbchL3hkcfon9Duqtfys932veP6x+n90u7+3PL/5vb/ 8vf68vr/+v39////CmVuZHN0cmVhbQ1lbmRvYmoNNDI2IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0 YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTQyNyAw IG9iag08PCAvTGVuZ3RoIDczID4+IA1zdHJlYW0NCi+k6TOc2zKQyTmFuEaMu1CWxFugzWijyWap 026v2Hi23IS94ZHH6J/Q7qrX8rPd9r3j+sfp/dLu/tzy/+b2//L6//r9/f///wplbmRzdHJlYW0N ZW5kb2JqDTQyOCAwIG9iag08PCAvTGVuZ3RoIDE0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiQCEAHv/sNDkg6C01ujxeLqVuefIZvNnYtWAOYW4TlHnQUHLPkGsPkGEJVFwM09O LWmSNXmoRoy7MpDJUJbEXpi+W6DNaKPJZqnTbq/Yd67ReLbchL3hlsDakcfoo8rhn9Duqtfys932 veP6x+n90u7+3PL/5vb/8vr/+v39////5e/2luCmKXWmAgwAnvVYDgplbmRzdHJlYW0NZW5kb2Jq DTQyOSAwIG9iag08PCAvTGVuZ3RoIDE3MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiQCcAGP/eLqVYtWAW6DNbYmxTlHnQUHLPkGsLWmSPkGES3JhJVFwM09ONXmoOYW4KXWmRoy7 UJbEXpi+aKPJZqnTbq/YeLbcd67RhL3hkcfoibbSlsDan9Duo8rhqtfysNDks932veP6udjqx+n9 xd3r0u7+yuLw3PL/1ujx5vb/4Onu5e/28vr/7/T28vf6+v39////g6C0ZvNnWV2ieanHAgwAfqtq LQplbmRzdHJlYW0NZW5kb2JqDTQzMCAwIG9iag08PCAvTGVuZ3RoIDEzNSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQB4AIf/L6TpMpDJM5zbKXWmOYW4NXmoRoy7UJbEW6DNXpi+ ZqnTbq/YeLbcaKPJhL3hd67ReanHkcfolsDan9DuibbSqtfys932o8rhveP6x+n9udjqsNDk0u7+ yuLwxd3r3PL/1ujx5vb/5e/28vr/8vf67/T2+v39////AgwAerhZVgplbmRzdHJlYW0NZW5kb2Jq DTQzMSAwIG9iag08PCAvTGVuZ3RoIDE3MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiQCcAGP/bYmxg6C0eLqVZvNnluCmYtWARoy7TlHnQUHLPkGsPkGELWmSS3JhM09OJVFwKXWm OYW4NXmoUJbEXpi+W6DNaKPJZqnTbq/Yd67ReLbchL3heanHlsDakcfoibbSn9Duqtfys932udjq o8rhveP6sNDkx+n90u7+yuLwxd3r1ujx3PL/5e/25vb/4Onu8vr/8vf67/T2+v39////AgwA+/pq 8QplbmRzdHJlYW0NZW5kb2JqDTQzMiAwIG9iag08PCAvTGVuZ3RoIDEzOCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiQB7AIT/L6TpM5zbMpDJOYW4Roy7UJbEW6DNZqnTbq/YeLbc hL3hkcfon9Duqtfys932veP6x+n90u7+3PL/5vb/8vf68vr/+v39////KXWmNXmoXpi+aKPJd67R eanHibbSlsDao8rhsNDkudjqxd3ryuLw1ujx5e/24Onu7/T2AgwA9IBcDQplbmRzdHJlYW0NZW5k b2JqDTQzMyAwIG9iag08PCAvTGVuZ3RoIDE0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiQCEAHv/bYmxeanHg6C0qrrFlK2eYtWAluCmZvNnZqnTTlHnQUHLPkGsPkGEM09OS3Jh JVFwLWmSNXmoOYW4Roy7UJbEXpi+W6DNaKPJbq/YeLbchL3hkcfon9Duqtfys932veP6x+n90u7+ 3PL/5vb/8vr/+v39////uefIU6Kid67RlsDao8rhAgwA+9ZV6AplbmRzdHJlYW0NZW5kb2JqDTQz NCAwIG9iag08PCAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvTGVuZ3RoIDI1NzUgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEd BFEISQgBEkJI2AVBRAUURUSEqpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPv H+/3Ofd37+/d3733nfMAoCelqrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuw WtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSx ap6953zmOdrECo1WgbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7 QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U 6RWYpFqjk2kbAZi/85w4ptpieJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgW r836t7bSLQCMrwTA8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/H dNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1 tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT 4T7To1atmouTZOVgcqO+bn7P9FkCAqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9 qActoB10gR6wHmwCw2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6Q K+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNh HmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKI lCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcE BsGW4EUII0gJiwgqQj2hizBI2En4iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvE WRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6U MEo6RUFppPRRxijHKBcp05RXVDZVQI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/T pmgv6By6J11CL6Ib6evoH9KP07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7 bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHi OQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G7 8aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2t M63rrbdZn7F+ZMOzCbeR23TbHLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9 p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAec TzrPuDi4pLm0uOx1uelKcRW7lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQ PcQelR5bPb70hD2DPMs9RzwvesFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs8 9nXxLfTd4HvW97VfkF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4 QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bv Cb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+ FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOS lyWfTqGnZKcMp3yT6pmqTz2WBqclp21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKs lqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2F s4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfL HyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtK NEe1HG2l9nS1fXVD9SWdl65LN1kTVrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWH GtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4 dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8X a0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5 lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopaj BqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+L sACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9 Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3 yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZ bNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy 6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4 Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7CmVuZHN0cmVhbQ1lbmRvYmoNNDM1 IDAgb2JqDTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ AHgAh/8vpOkykMkpdaYznNs5hbg1eahGjLtQlsRboM1mqdNemL5ur9hoo8l4ttx3rtGEveGRx+h5 qceJttKf0O6WwNqq1/KjyuGz3fa94/rH6f252OrS7v7F3evK4vDc8v/W6PHm9v/g6e7l7/by+v/v 9Pby9/r6/f3///8CDACEllmpCmVuZHN0cmVhbQ1lbmRvYmoNNDM2IDAgb2JqDTw8IC9MZW5ndGgg NzAgPj4gDXN0cmVhbQ0KL6TpM5zbMpDJOYW4Roy7UJbEW6DNZqnTbq/YeLbchL3hkcfon9Duqtfy s932veP6x+n90u7+3PL/5vb/8vr/+v39////CmVuZHN0cmVhbQ1lbmRvYmoNNDM3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTIgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExOSAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiRITQwHhYABkpKWlQUSADIAAAwBhvwZ/CmVuZHN0cmVh bQ1lbmRvYmoNNDM4IDAgb2JqDTw8IC9MZW5ndGggMTU2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJAI0Acv/K0dV5qcfl7/Z4upWW4Ka558hm82di1YBCons5hbg1eahBQcs+Qaw+ QYQzT04lUXAtaZJGjLsykMlQlsRboM1emL5oo8lmqdNur9h3rtF4ttyEveGJttKRx+ijyuGWwNqf 0O6q1/Kz3fa52Oq94/rF3evH6f3S7v7K4vDc8v/m9v/y+v/y9/r6/f3///8CDADW62CqCmVuZHN0 cmVhbQ1lbmRvYmoNNDM5IDAgb2JqDTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJAHgAh/8vpOkykMkpdaY5hbgznNs1eahGjLtQlsRboM1mqdNemL5ur9ho o8l4ttx3rtGEveGRx+if0O6WwNqJttKq1/KjyuGz3fa94/q52OrH6f3S7v7F3evK4vDc8v/W6PHm 9v/g6e7l7/by+v/v9Pby9/r6/f3///+w0OQCDAC1nVokCmVuZHN0cmVhbQ1lbmRvYmoNNDQwIDAg b2JqDTw8IC9MZW5ndGggNzkgPj4gDXN0cmVhbQ0KL6TpM5zbMpDJRoy7OYW4NXmoUJbEW6DNZqnT aKPJbq/YeLbchL3hkcfon9Duqtfys932veP6x+n90u7+3PL/5vb/8vr/8vf6+v39////CmVuZHN0 cmVhbQ1lbmRvYmoNNDQxIDAgb2JqDTw8IC9MZW5ndGggMTMyIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJAHUAiv8znNtToqKUrZ5thIVLcmE+QYQzT04taZI1eahtibFemL6DoLR5 qceJttJGjLs5hbhQlsRboM1mqdNur9h4ttyEveGRx+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m9v/y +v/6/f3///94upVZXaJoo8nl7/by9/oCDADLK05pCmVuZHN0cmVhbQ1lbmRvYmoNNDQyIDAgb2Jq DTw8IC9MZW5ndGggMTIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAGkAlv+q usWUrZ6DoLRtibFthIVZXaI+QYQ+QawzT04lUXAtaZI1eag5hbh5qceJttJGjLtQlsRboM1mqdNu r9h4ttyEveGRx+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m9v/y9/ry+v/6/f3///8CDABUsUYrCmVu ZHN0cmVhbQ1lbmRvYmoNNDQzIDAgb2JqDTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJAHgAh/8vpOkznNsykMk5hbhthIVLcmEzT04lUXAtaZIpdaY1eahG jLttibFemL5QlsRboM1mqdNur9h4ttyEveGRx+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m9v/y+v/6 /f3///95qceDoLSJttKWwNqqusWjyuHK0dWw0OQCDACcc1A8CmVuZHN0cmVhbQ1lbmRvYmoNNDQ0 IDAgb2JqDTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ AHgAh/8vpOkznNtQlsRemL6UrZ5thIV4upVLcmFZXaIzT04lUXAtaZI1eag5hbhGjLtoo8l5qceJ ttKWwNqqusWjyuGDoLRtibFboM1mqdNur9h4ttyEveGRx+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m 9v/y+v/6/f3///8CDAAvO09rCmVuZHN0cmVhbQ1lbmRvYmoNNDQ1IDAgb2JqDTw8IC9MZW5ndGgg MTU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJAAb/+UrZ5thIVLcmFZXaIz T06DoLSqusVtibE1eagtaZIlUXApdaZemL45hbhGjLtQlsRboM1mqdNoo8lur9h4ttx3rtGEveF5 qceJttKRx+iWwNqf0O6jyuGq1/Kz3fa94/q52OrH6f2w0OTS7v7K4vDF3evc8v/W6PHm9v/l7/bg 6e7y+v/v9Pby9/r6/f3///8CDAB/i2VsCmVuZHN0cmVhbQ1lbmRvYmoNNDQ2IDAgb2JqDTw8IC9M ZW5ndGggMTUzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAIoAdf+UrZ6qusWD oLRtibFthIVZXaI+QYQzT04lUXAtaZIpdaY1eah5qcc5hbhGjLtQlsRemL5boM1mqdNoo8lur9h4 ttyEveGRx+h3rtGf0O6WwNqq1/Kz3fa94/qw0OTK4vDH6f3S7v7F3eu52Orc8v/W6PHl7/bm9v/g 6e7y+v/y9/rv9Pb6/f3///8CDAB3VmDyCmVuZHN0cmVhbQ1lbmRvYmoNNDQ3IDAgb2JqDTw8IC9M ZW5ndGggMTU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJAAb/+UrZ6DoLSq usVtibFthIVZXaI+QYQzT04lUXAtaZI1eagpdaZemL45hbhGjLtQlsRboM1mqdNur9hoo8l4ttx5 qceEveF3rtGJttKRx+iWwNqf0O6q1/KjyuGz3faw0OS94/q52OrH6f3F3evS7v7K4vDc8v/W6PHm 9v/g6e7l7/by+v/v9Pby9/r6/f3///8CDACHO2VRCmVuZHN0cmVhbQ1lbmRvYmoNNDQ4IDAgb2Jq DTw8IC9MZW5ndGggMTU5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJAAb/+U rZ54upVthIWDoLRtibGqusVZXaIzT04lUXAtaZIpdaY1eahemL45hbhGjLtQlsRboM1oo8lmqdNu r9h4ttx5qcd3rtGEveGRx+iJttKf0O6WwNqq1/KjyuGz3faw0OS94/rH6f252OrF3evS7v7K4vDc 8v/W6PHm9v/g6e7l7/by+v/v9Pb6/f3y9/r///8CDADjo2YVCmVuZHN0cmVhbQ1lbmRvYmoNNDQ5 IDAgb2JqDTw8IC9MZW5ndGggMTYyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ AJMAbP+UrZ6qusWDoLRtibFZXaI+QYQzT04lUXAtaZI1eah5qceJttI5hbhGjLtQlsRemL5boM1m qdNoo8lur9h4ttyEveF3rtGRx+iWwNqf0O6q1/Kw0OSjyuGz3fbH6f294/q52OrS7v7K4vDF3evW 6PHc8v/m9v/l7/bg6e7y+v/y9/r6/f3v9Pb///+558hthIUpdaYCDACdhWe5CmVuZHN0cmVhbQ1l bmRvYmoNNDUwIDAgb2JqDTw8IC9MZW5ndGggMTY1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJAJYAaf+UrZ5thIVLcmFZXaJtibGDoLQlUXAtaZI1eag5hbhGjLtQlsRemL5boM1m qdNoo8lur9h4ttyEveGRx+iJttJ3rtGf0O6WwNqjyuGq1/Kz3fa94/qw0OS52OrH6f3S7v7K4vDF 3evc8v/W6PHm9v/l7/bg6e7y9/ry+v/v9Pb6/f3///94upWqusUzT04+QYQpdaZ5qccCDABF2Wg2 CmVuZHN0cmVhbQ1lbmRvYmoNNDUxIDAgb2JqDTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJAHgAh/+qusWUrZ5thIWDoLRZXaI+Qaw+QYQzT04lUXAtaZIp daY1eahemL6JttKWwNpGjLs5hbhQlsRboM1oo8lmqdNur9h4ttyEveGRx+if0O6q1/Kz3fa94/rH 6f3S7v7c8v/m9v/y+v/6/f3///94upVLcmF5qcd3rtECDABCzU14CmVuZHN0cmVhbQ1lbmRvYmoN NDUyIDAgb2JqDTw8IC9MZW5ndGggMTQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJAH4Agf8ykMkpdaYvpOk5hbgznNs1eahGjLtQlsRboM1mqdNemL5ur9hoo8l4ttyEveF3rtF5 qceRx+iJttKf0O6WwNqq1/KjyuGz3faw0OS94/q52OrH6f3S7v7K4vDF3evc8v/W6PHm9v/g6e7y +v/l7/bv9Pby9/r6/f3///8taZICDACXrF01CmVuZHN0cmVhbQ1lbmRvYmoNNDUzIDAgb2JqDTw8 IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHgAh/8pdaYv pOkykMkznNs5hbg1eahGjLtQlsRboM1emL5mqdNur9hoo8l4ttx5qceEveF3rtGRx+iJttKf0O6W wNqq1/KjyuGz3fa94/q52OrH6f3S7v7F3evK4vDc8v/W6PHm9v/g6e7l7/by+v/v9Pb6/f3y9/r/ //8CDACAGVmpCmVuZHN0cmVhbQ1lbmRvYmoNNDU0IDAgb2JqDTw8IC9MZW5ndGggMTY4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJkAZv9tibGDoLSUrZ54upVToqJOUedZXaJB Qcs+Qaw+QYQlUXAtaZJLcmEzT06JttKqusV5qcdGjLs1eag5hbgpdaZQlsRemL5boM1oo8lmqdNu r9h4ttx3rtGEveGRx+if0O6WwNqq1/Kz3fa52Oq94/qjyuHF3evH6f3S7v7K4vDc8v/m9v/W6PHl 7/by+v/y9/r6/f3v9Pb///8CDABjt2c6CmVuZHN0cmVhbQ1lbmRvYmoNNDU1IDAgb2JqDTw8IC9M ZW5ndGggNzAgPj4gDXN0cmVhbQ0KL6TpM5zbMpDJUJbERoy7OYW4W6DNZqnTbq/YeLbchL3hkcfo n9Duqtfys932veP6x+n90u7+3PL/5vb/8vr/+v39////CmVuZHN0cmVhbQ1lbmRvYmoNNDU2IDAg b2JqDTw8IC9MZW5ndGggMTcxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAJwA Y/94upVtibGDoLR5qcdToqJemL5ZXaJOUedBQcs+QawtaZIlUXBLcmEzT06qusU1eagpdaY5hbhG jLtQlsRboM1mqdNur9hoo8l4ttx3rtGEveGJttKRx+iWwNqf0O6jyuGq1/Kw0OSz3fa94/q52OrH 6f3F3evS7v7K4vDc8v/W6PHm9v/g6e7l7/by+v/v9Pby9/r6/f3///9thIUCDABLKWrpCmVuZHN0 cmVhbQ1lbmRvYmoNNDU3IDAgb2JqDTw8IC9MZW5ndGggMTc0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJAJ8AYP+DoLSUrZ54upVtibFZXaJOUedBQcs+Qaw+QYQlUXBLcmEzT04t aZKJttKjyuE1eag5hbhGjLtQlsRboM1mqdNoo8lur9h3rtF4ttyEveGRx+if0O6q1/Kz3fa94/rH 6f3K4vDS7v7c8v/m9v/y+v/v9Pby9/r6/f3///+W4KZi1YB5qcew0OQpdaZemL6WwNq52OrF3evW 6PHg6e7l7/YCDAAGXGxoCmVuZHN0cmVhbQ1lbmRvYmoNNDU4IDAgb2JqDTw8IC9MZW5ndGggMTM4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHsAhP8pdaYvpOkykMkznNstaZI5 hbg1eahGjLtQlsRboM1emL5mqdNur9h4ttxoo8mEveGRx+iJttJ5qcef0O6q1/KjyuGWwNqz3fa9 4/q52Oqw0OTH6f3S7v7F3evc8v/W6PHK4vDm9v/y+v/l7/by9/rg6e7v9Pb6/f3///8CDAA1v1s/ CmVuZHN0cmVhbQ1lbmRvYmoNNDU5IDAgb2JqDTw8IC9MZW5ndGggMTAyIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJAFcAqP8vpOkznNsykMk5hbg1eahLcmEzT04taZIpdaZGjLtQ lsRemL5boM1mqdNur9h4ttyEveGRx+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m9v/y+v/6/f3///8C DAB6lzrtCmVuZHN0cmVhbQ1lbmRvYmoNNDYwIDAgb2JqDTw8IC9MZW5ndGggMTMyIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHUAiv94upWUrZ5thIVtibFZXaI+QaxBQcs+QYQl UXBLcmEzT04taZI1eaiJttKWwNp5qccpdaY5hbhGjLtQlsRemL5boM1oo8lmqdNur9h4ttyEveGR x+if0O6q1/Kz3fa94/rH6f3S7v7c8v/m9v/y+v/6/f3///8CDABzkEp2CmVuZHN0cmVhbQ1lbmRv YmoNNDYxIDAgb2JqDTw8IC9MZW5ndGggMTQxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJAH4Agf8ykMkvpOkpdaY5hbgznNs1eagtaZJGjLtQlsRboM1emL5mqdNur9hoo8l4ttx5 qceEveF3rtGRx+iJttKWwNqf0O6q1/KjyuGz3fa94/qw0OS52OrH6f3S7v7F3evK4vDc8v/W6PHm 9v/g6e7l7/by+v/v9Pby9/r6/f3///8CDAAXil01CmVuZHN0cmVhbQ1lbmRvYmoNNDYyIDAgb2Jq DTw8IC9MZW5ndGggMTM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJAHgAh/8p daYvpOkykMkznNs5hbg1eahGjLstaZJQlsRboM1emL5mqdNur9h4ttxoo8l5qceEveF3rtGRx+iJ ttKf0O6q1/KjyuGz3fa94/q52OrH6f3S7v7K4vDF3evc8v/W6PHm9v/l7/bg6e7y+v/v9Pby9/r6 /f3///8CDAAkb1ihCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgODIgMCBSIA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29udGVudHMgMyAwIFIgDS9Sb3RhdGUg OTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBd IA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9J bWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAw IFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0v SW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAg MjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQg MjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTgg MjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIg MjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYg MjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAy NTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAy MDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAy NTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAy MzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAy MzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0 NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0 MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3 MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3 MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3 NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1 IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUx IDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYy IDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5 IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4 IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUg MCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYg MCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMg MCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAx ODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0x MDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAv SW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAw IFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAz NjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0x MjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAv SW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAw IFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAz NzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0x MzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAv SW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAw IFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAz NTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0x NTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAv SW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAw IFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0 MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0x NjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAv SW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAw IFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAz OTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0x ODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAv SW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAw IFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAy ODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0x OTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAv SW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAw IFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAy OTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0y MTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAv SW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAw IFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAy NzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0y MjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAv SW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAw IFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAz MjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0y NDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAv SW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAw IFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAz MDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0y NTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAv SW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAw IFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAz MTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiAN L0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0Nz MTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0Nz MTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0Nz MTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0Nz MjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3My NiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAx MDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAw IFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAg UiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAg UiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBS IA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCAzMDYwIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/cNOx8x43EgIJJNRD xKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5Gy99+vri4WJdSyXla UvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/8sufX7T8fXkRh/W0 th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmOFNjF1tqSW3WJfFq+ /3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoAYa6IcEXOZYAI8psb kd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4ea+/40VEbwHwXg0g F33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xcBAWJ8GFDhEkvPGUY Lwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL/SeQqnlnFGMW6fQQ YTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnVEskJzCFx6QFAI+dJ tW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8QuPEpHVEX+jgTLWnqb 05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgOWbM9vEPYJtXzC9R3 3O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG8AkEOIwzmzohpmIV 7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8IdhwY9WqDzhqrPmw00xs UL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWocw79DchdondZXZkjdUN8rNo9 HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXrshck6U1I99nqyugO pDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWozWcYj89Q6lq3Nyio E0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7CDSizjXADFE/6htz0 DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMuh8z9XU5l1jMPyCSx awWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3yyalNruCk1wrow+T H8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiCJl9xlsujx5j9q2bN Sxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUTY2yuWF9ssElSJjbx lnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OIDPLilifXs8cAwNe3r nn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt+blyLgiznnYSDFTD eJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsAY6raR60q3TLiytFGvJSv2kx9 ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7JNNVB3lbZJA1q7zJt +ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33eJNWgk2ixlI7AEy7 RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBBT+ykzV3O4sElHdUN rgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ZD21EketExzab0zFNE+m9gsT g0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39AKBagn/3iuILGC/X twhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0cFOJEUwcCFRVAuTCg sCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8eb2USoTWPIYwWHOmD txvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5Nuh0sUx868KgyGKe lPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQfpGDmY5XzCGKklmZmeWEgBdMu cUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLOknaEVUl5LscdgBLJ 4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovKyLM6OjB2bs4eFI7d +sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfELGYZJhAcpE6I6VoZ B+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyRzWzaOTFGNoWezeKE oGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFumSUn2bGKKXniGhui I79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mAqGJVCqGkVRyHXAFR y1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVNNbZjRAFJ561+8J6J BmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/MFYFDeexEQCbX4Nt aniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/CoPqCBL1XMJ+Nstk 1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8dkPXAyzPP2+JZ5jnV f2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ+wq1h0VxYczD26Re D4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg1KitkynqS8wsUUTM/azONNPL hYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6lraOnThRd3ToVg1Uw z6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c5ho4fjY6VimyTbry F33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4dUK5KejIK70tczgIR nxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+nhzW7Njw+nh5XmA1P j6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZX6k//ZHV/9NZ7jgI AzEQ7fcUKaEiv/EmLZ8iTSIhc4JIFEjQUHB9vIHOHq0UbTGZ5umtbfHBt1OqZT3x7ZSqxUffTqmW vdi3U6r29Ne+nVItz5pvp1TNbu9qT6miDlwFpYomcBWUKtrAVVCq6AJXQamiD1wFpQoEroJShQSu glJFDlwFpYohcBWUKsbAVVCqJejahVK1oHdVKFXpAleFUrW4d1UoVUHgqlCqFveuCqUqOXBVKFUZ AleFUpUxcFX+VI+aDqpt1VR6L8uLbYPdNl3zNtHanH+/6bMMeTvv9WU3Xcvnk3bTrNflfDvptMx7 faSLpq8AAwDdYXq4CmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgODIgMCBSIA0vUmVzb3VyY2VzIDUgMCBSIA0vQ29udGVudHMgNiAwIFIgDS9Sb3RhdGUg OTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBd IA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9J bWFnZUkgXSANL0ZvbnQgPDwgL1RUNCAxNDcgMCBSIC9UVDYgNzYgMCBSID4+IA0vWE9iamVjdCA8 PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0lt NSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIz MiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIy OSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIx MCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIx NyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0 IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUz IDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUw IDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYx IDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4 IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcg MCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUg MCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIg MCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAg MCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcg MCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAw IFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAw IFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAw IFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAw IFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAw IFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAg UiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAg UiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAg UiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAg UiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUg MCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0 MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0x MDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIg L0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkg MCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAz NjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0x MjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIg L0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQg MCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAz NDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0x MzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIg L0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkg MCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAz NTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0x NTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIg L0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAg MCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAz ODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0x NjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIg L0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQg MCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0 MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0x ODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIg L0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcg MCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAy ODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0x OTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIg L0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYg MCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAy OTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0y MTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIg L0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcg MCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAy NzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0y MjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIg L0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEg MCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAz MzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0y NDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIg L0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYg MCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAz MDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0y NTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIg L0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIg MCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5 IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEz IDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3 IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEg MTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUg MTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAx IDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAg UiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIg L0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiAN L0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAv Q3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xl bmd0aCAzMzUxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/ cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5G y99+vri4WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/ 8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmO FNjF1tqSW3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoA Ya6IcEXOZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4 ea+/40VEbwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xc BAWJ8GFDhEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL /SeQqnlnFGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnV EskJzCFx6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8Qu PEpHVEX+jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgO WbM9vEPYJtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG 8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8Idhw Y9WqDzhqrPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWocw79Dchd ondZXZkjdUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXr shck6U1I99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWo zWcYj89Q6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7C DSizjXADFE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMu h8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3 yyalNruCk1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiC Jl9xlsujx5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUT Y2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OID PLilifXs8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt +blyLgiznnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsAY6raR60q 3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7J NNVB3lbZJA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33 eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBB T+ykzV3O4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ZD21Eket Exzab0zFNE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39 AKBagn/3iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0c FOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8e b2USoTWPIYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5 Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQfpGDmY5Xz CGKklmZmeWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLO knaEVUl5LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovK yLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfE LGYZJhAcpE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyR zWzaOTFGNoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFu mSUn2bGKKXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mA qGJVCqGkVRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVN NbZjRAFJ561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/ MFYFDeexEQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/ CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8d kPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ +wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg1Kitkynq S8wsUUTM/azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6l raOnThRd3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c 5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4d UK5KejIK70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+n hzW7Njw+nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZ X6k//ZHV//NeBrttwzAYvvspeHSAtnPaUHGO25IOGFBgQHQbdpATpdVgW56lrOiL7HlHKXGLVuJl wIoAjhNRv0l+/i2ZwutUnaUatiepOkuVwlepOks17ItTdZYqPfqrVJ2lGh5rqTpLldydenXBUsUq 41VkqeI841VkqeJ1xqvIUsWbjFeRpYqLjFeRpYqY8SqyVFFkvIosVVxmvIosVawzXkWWKq4yXkWW aghM1AVLlQJTrwqWqrjJeFWwVCk89apgqQrMeFWwVCk89apgqYplxquCpSrqjFcFS1WsMl4VZ6qf ZPFBSgFzkIciLqrhPer0RUKClkEaJMvE/Zfs4lKPYTAe3a6nf+QuHB6L8s9M/gx6i0kvfGLMVU3v pxS0LqiKqqIfNOl0Woep38vtsemM93oPyoGCYbSDdaqFgx3h1o6fN9vZJbn6alHSkLc7285+yK+v sn+b2eXpsrERtAeki/9Trss4ic5owxJTlRY6rT2otn2VWl2O+tfRjLrTvXfvlZ54aWXMr/wY+tco p2Hq1AU8Gv8Atxvo7F63ocPTEITrVCEJ2vnPn1VDPpMqRtW18gruwvRzZv+7Lnxb11r/1q0d6A5x elCj8rp9gsNoO/iyvft2Ac3RwwOVlq+oWk0Yz3KN1j3sbO/MXo+mvwfjqS3WOdO0mga6QXnTmNb4 p1P7nnWvK3rDDWWdb9+ptpBGCNrI4q8AAwDmWz3KCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODIgMCBSIA0vUmVzb3VyY2VzIDggMCBSIA0vQ29udGVu dHMgOSAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5kb2JqDTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSID4+IA0vWE9i amVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAw IFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAv SW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9J bTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9J bTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9J bTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0lt MjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0lt MjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0lt MzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0lt MzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0lt NDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00 NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00 OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01 MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01 NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02 MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1 IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5 IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTcz IDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3 IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgx IDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUg MTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkg MTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMg MjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcg MjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEw MSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9J bTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAg UiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4 OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTEx NiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9J bTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAg UiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3 OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEz MSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9J bTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAg UiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0 MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0 NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9J bTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAg UiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQx MyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2 MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9J bTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAg UiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4 MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3 NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9J bTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAg UiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5 NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5 MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9J bTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAg UiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5 NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIw NiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9J bTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAg UiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2 MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIy MSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9J bTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAg UiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMy NyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIz NiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9J bTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAg UiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMz MiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1 MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9J bTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAg UiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMx OSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2 NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAg UiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBS IC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIg DS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIg L0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIg L0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0Nz MjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMz IDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDEx MCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEy IDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1 IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTkgMCBvYmoN PDwgL0xlbmd0aCAzMDc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7 DZzvr1g/cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9 X68vv/5Gy99+vri4WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F /PK75Y9/8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pd fvEuRfmOFNjF1tqSW3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsF CPqKGMoAYa6IcEXOZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vl Cm8TGvZ4ea+/40VEbwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9S ii0Pt6xcBAWJ8GFDhEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGA yDe5dCeL/SeQqnlnFGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpb OEwgYsnVEskJzCFx6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C 8gKBN8QuPEpHVEX+jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1 SO9fYtgOWbM9vEPYJtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw8 0dUBMRTG8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1 Q/c8IdhwY9WqDzhqrPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWo cw79DchdondZXZkjdUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929Z CSQavqXrshck6U1I99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8 AhS9ReWozWcYj89Q6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZ l94cNz7CDSizjXADFE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwG gUROeEMuh8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopX EHTswKP3yyalNruCk1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWG yooT/BiCJl9xlsujx5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJ K7/3mEUTY2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSO DxNX3OIDPLilifXs8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7 Aw0vQadt+blyLgiznnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsA Y6raR60q3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSg g/oyLX7JNNVB3lbZJA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUql iUBe0C33eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2 Bs6pjBBBT+ykzV3O4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ ZD21EketExzab0zFNE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGM YPRe1L39AKBagn/3iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6q doRoSm0cFOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAm vRX8JI8eb2USoTWPIYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7 FmVnEKK5Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQf pGDmY5XzCGKklmZmeWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6 wlEn+oLOknaEVUl5LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF 4i37rovKyLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4B FCFO6CfELGYZJhAcpE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT /MQmLoyRzWzaOTFGNoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqi n89uXeFumSUn2bGKKXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZ rUB6K3mAqGJVCqGkVRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl /8Ag/zVNNbZjRAFJ561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQ qILGEys/MFYFDeexEQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oH mAgp0Na/CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPU Ffswqd8dkPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6 VCQHDJoJ+wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg 1KitkynqS8wsUUTM/azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbL DYMCah6lraOnThRd3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NV Mz839S1c5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt 2E3u3J4dUK5KejIK70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpv u6QJD4+nhzW7Njw+nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv 3enxkVXZX6k//ZHV/9Nd9ioIA0EQ7u8prtRCzd9sklIhBIuImHuDgIWgjYWv756Kze6QIimGab58 u3ca72w7pZqPJ7adUtV4b9sp1Xwutu2Uqo7+wrZTqnms2XZKVe22rjaUKgrHVVCqKB1XQamiclwF pYracRWUKhrHVVCqgOMqKFWI4yooVbSOq6BU0TmuglJF77gKSjUHTbtQqhq0rgqlKrXjqlCqGreu CqUqcFwVSlXj1lWhVKV1XBVKVTrHVaFUpXdclR/VQwq7lKpYxnQNnz2mf8Dm+9Kl2RZ6c4u6PLZl Plmke171+jyXR9DRW+ilKy3/r1dYTcM878dhjsdTHC/TeZ1uYUjhLcAAem5+hgplbmRzdHJlYW0N ZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4MiAwIFIgDS9SZXNvdXJj ZXMgMTEgMCBSIA0vQ29udGVudHMgMTIgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAg NTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0xMSAwIG9i ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAv VFQyIDE0NSAwIFIgL1RUNCAxNDcgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0lt MiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIy MiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAg UiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAg UiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAg UiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAg UiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAg UiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBS IA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBS IC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBS IC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBS IC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBS IC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIg DS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIg L0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIg L0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIg L0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIg L0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiAN L0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAv SW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAv SW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAv SW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAv SW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0v SW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9J bTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9J bTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBS IC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2 IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAg MTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0lt MTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBS IC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0 IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUg Mzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0lt MTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBS IC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5 IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAg MzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0lt MTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBS IC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0 IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUg NDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0lt MTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBS IC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3 IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAg MzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0lt MTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBS IC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2 IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUg Mzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0lt MTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBS IC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2 IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAg Mjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0lt MjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBS IC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgx IDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUg MjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0lt MjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBS IC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcy IDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAg MzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0lt MjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBS IC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2 IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUg MzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0lt MjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBS IC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAy IDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAg MzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0lt MjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBS IC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9y U3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIx IDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIz IDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMy IDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1 IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAw IFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBS IC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0Nz MzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3Mz OSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0 MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0 NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTEyIDAgb2JqDTw8IC9MZW5ndGggMzkxMiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhE g6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F /fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP 8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnN D1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSR H+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8o Rsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk 9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNh zWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVE Uq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72 veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM 3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpG t1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgc gKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX 5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HP u5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53 QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H +gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgj TBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq 4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9Q WcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73Y P3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917D cXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnD Ntt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNj qCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zB F8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0 N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiB EYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5o WRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcm PtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TCh pJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qs xVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4 V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul +EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG69 6dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+ mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPII A8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X +aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrs QCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17f ojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/Ml DzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFA S7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2f aHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUow Uu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae 1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJ pzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJs khn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPz OBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo 17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30 p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f9TXja9beNAGL7r V/CYLmCvKGpI6dqmORT9Aqxb0IOQqkl2E7uwDQTtr+87IiVSFLnOooCssJzhkO8znBGmN2vvWVW5 PVl7z6qK6e3ae1ZV7ovX3rOq4uov196zqvK1tvaeVRXZvc7VOqsqlYlcpayqJBO5SllVqUrkKmVV JZXIVcqqSnUiVymrKlEiVymrKulErlJWVTKJXKWsqtQkcpWyqlKbyFXKqsoTV951VlVMXOeqzqqq VSJXdVZVTF/nqs6qqimRqzqrKqavc1VnVdUmkas6q6puErmqs6rqNpGr2qn6tiv+7rpKSNH9KMai yt9R9geOSs0iSPSqY//VPXOpx7/T3b5AOGUJuzv7hs+x7qW4+nK87/ePvx/39+LTcDr198PpTfdP 8b4r0Ds0lZiehFLNXmRLHB6+ZhCfFM8F+GTGp4GnApfcVgqJVr5q+W/ZVFujg4Eff8E3tVpMTwXE A9/UKLiC62ithCs3gMY89G10K6ZnTW3Ctx6bVoXG+DgUOEg0dWj/3JNwW+zefS6k+IDWCgf7Il6x 7R0vPNrbZ40OkL1EE2dLF4k1bBTHap+EFQPD+DQWdqkFL57ijili6oAcN734zNpCh6pFH7KiZkQl oEaO1Ny8F5/6PWB5HvbnBTigs7Z0bgBhA8zBdVPit7v2Lu4KByN8bbr+30H04uXh8DQIeO5Pot+L w8/h2J+ZSyzxeP4lZiwZRWy61A5ODlNJu0n01PaUlbabcgNPhcJNj7Ij0adbVFTpYKpCdpjFcvyE sHQGzpVRk/PlaglfbkDpBZgMIy4FWTk8E85RHGsWBgnv0GQcMV0pByhrfHm7TAcTAXujHCOj5XLi bDmtby2ZQQRqpKMysFydwtIyuebF89vFF9sMp1I2XtlsDb0Ozo83bwM6GRu5bUv+aEPjwb8gsRwZ HKevrj1Pln0PVWpldGytXPKlTBMhYBb3nifLvgfOqWltxkaLJVy5ATI69O3Bsu9r3xNd7UyX58q+ h3rlNzsyMmts30NGYku3vDX0WNn3wDA+goVdcsFLRxdfdo6nupSJEnl7dd2f+5/9+eHNpuKu9irg 6Fv3oai27QKjGB7emGJtx+DKsYDgrF/ELeJCAzP2Gd9K8b2Q6FMRqGymk3IDuiK748q4CWaqG2Y5 QeF/Fh7cwDxhV4QU+xJeq+jyqJvo8qhNdFfWVequ9BT7Gu6cz4JEiyVcuYGIZU+xr+FL345lhWNd FHFLdKKI344Hf3n3vrBa4qbCGk2cLReQeqx9JV/Oe4728R8LXjrLGO6abIT4mDTydZfl1+PhfLg7 PImP/a/hiML7XXw5P+AtqO8MNz5P6RUXKIJpmfiN/cGfkFVxS9r4fOPSX/lAaGop3h3642mwkVhn G70dG9VrG30Td68wunncOxMh/ncWkrRJZiZJ3YCWszT2hJebqmWZ2hS6/Ck+3t/6dP3xnqZY/wwA JRblzgplbmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4 MiAwIFIgDS9SZXNvdXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vUm90YXRlIDkwIA0v TWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4g DWVuZG9iag0xNCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdl SSBdIA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RUNCAxNDcgMCBSIC9UVDggNzcgMCBSID4+IA0v WE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIy MyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAg UiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBS IC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBS IC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIg DS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIg L0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIg L0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIg L0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIg L0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiAN L0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAv SW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAv SW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAv SW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAv SW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0v SW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9J bTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9J bTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9J bTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9J bTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9J bTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0lt ODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0lt ODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0lt OTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0lt OTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9J bTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBS IC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkx IDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEy IDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9J bTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBS IC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcw IDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3 IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9J bTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBS IC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1 IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQy IDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9J bTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBS IC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUw IDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3 IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9J bTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBS IC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzky IDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcy IDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9J bTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBS IC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0 IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3 IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9J bTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBS IC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgz IDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAy IDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9J bTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBS IC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4 IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3 IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9J bTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBS IC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1 IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMy IDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9J bTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBS IC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5 IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3 IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9J bTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBS IC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0 IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYy IDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9J bTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIw IDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUg MCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAw IFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAw IFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAw IFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIg L0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9D czMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3 IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEg MTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUg MTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTE1IDAg b2JqDTw8IC9MZW5ndGggMzk0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxX y65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60 /fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk 0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/k Uu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRy XOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1d OLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClE rqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHr BQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYf JlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnn kPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZsl DxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkX BBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qW mDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0A PC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0 tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnO sB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/ LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0Rp J2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45 IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2x lsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ct YcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbP RUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwoj CFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+A k5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Os n0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcU kiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhu GJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxK mN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis1 7rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GV NpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbt IY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++ IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Y o7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6 ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7 l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08T wbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUa XWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9Nc APSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0R QkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESw S9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNv A4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY 7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnE s4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQK POwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSY CPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG 8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHi tMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK 0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p /Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enx kVUJL93p8ZFV2V+pP/2R1f8zXzU9biJB9O5f0UesHQiN6TZYyiHxZDaT7ESjCcol2gPGbZuNDbOA MxopvyO/d6ubxkB/jK09RLElg0VT9bpevapqWB7p1q2s8vFEt25lFZbHunUrq3wu1q1bWYXS7+vW razysqZbt7IK6ta1GlpZJb5Bq8TKKsEGrRIrqyQwaJVYWSUzg1aJlVUSGrRKrKwSYtAqsbJKqEGr xMoqmRu0SqysksigVWJllcQGrRIrq3yhZp1aWYWFulaplVU6M2iVWlmF5bpWqZVVSgxapVZWYbmu VWpllc4NWqVWVmlk0Cq1skpjg1apZPVtMnmVJAHCKNlMRFPl56j2AoZ8yknAMKuK+Ss58FYP3zor JgDH9+FQlWTyNkbJ08S5Y3Wdbhm6KatD2kyTf7iDsHOAY55ibnuBv0QMSooDj3Dv4pc78rkLXxj/ ye31EOBEQOCwAc+uJwIC7tFE4oVleXis8pqtUblBHbQdS9esujr9X5Xr5yuUFrDoscnLIt3vn9Hy YYmyHcu+1ceDJ90qwFzpn19xNBMoLsLq9mD5HVSvYeTeC3gLGbroFDoquGkvPJJzXgtGoZMsdAj+ cM98uQugIoKjQwvMueQNt3uF75vXh27fzg9hECIUyE1DrOI46AnCYs/OF1bVEOdxgKAd+rRfGsSt SaTahGrvB0OboVj4+bgCs2OT/IwHwrjMJlVhCpbwOKuT50c29gGdEAeqizb+F2N/YPVx37yMHc67 p9wOpHn5Ub2QMSSZaFIPawV/7HHTvkKiC4NYSKMxx6f0+pWZ1W9z+NECC009wHOVQnHXVoKkSos6 zbi+0e2aFU2+ydV8CWAUDmk4iIYk8vcKyQVic+7HOxPPZPUxvUn97uHy/754q754enQqyBbt4Tgi A+ZmnSZY9Z2t1SIRQbx1QRusRj4ZKk3I5ysvE3dsO3VJTL3Y+XQ8TP9OPgwcQFHFwTCPol52dCw7 3Sn1KA6DU/rA4r9YsW12SicY5apNczH9NQn2QneGhuUBDAxz4Znu3DY7hVU+rdmSkRCq58YC3Vd5 WeXNM9rs06216dIIoieChPumewaCltaUDqsrL6mS5pkgboGWsvmj+ilvst3LkOZxEL00B1hxaaqZ wUcPzZWWazA4jWQzmMR4rj9NZKojnuMjHwTG9mAU/pna7hZoU1boIJtezbYHKJg1ysqiqcq9JQpz UDxoRCXmgigoDOC+YHvo9nqB1Bowo344xB+qQyhHfyzyf48MJrl1Xjd5sT3m9Q4uCFUsYzlUlm5/ tRCftKqibwGJhvvVucmrukGrvEGvffRz6sKh1Iucw9T3sCNjtWUFq9IGrK9ghnwnq8sgM0ZW8CVW bjorhrwTMRxjPhfsNk7EOngEFnWeT0E53ekzRuBhHA657hOOp61IuKey+obSfQkMgd526M+Hu3v0 ZvnxlIVNiR6r8nu+ZihFq2O+b9y8EJhc4mFZN/2Ig7ju56Ss3y+4YVUFmSHTWOQ4mGzKDP5wQ++S yX8DAOheXmQKZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl bnQgODIgMCBSIA0vUmVzb3VyY2VzIDE3IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL1JvdGF0ZSA5 MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYxIF0g DT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9J bWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSIC9UVDQgMTQ3IDAgUiA+PiANL1hPYmplY3Qg PDwgL0ltMSAyMjQgMCBSIC9JbTIgMjI1IDAgUiAvSW0zIDIyNiAwIFIgL0ltNCAyMjMgMCBSIC9J bTUgMjIxIDAgUiANL0ltNiAyMjIgMCBSIC9JbTcgMjI3IDAgUiAvSW04IDIzMSAwIFIgL0ltOSAy MzIgMCBSIC9JbTEwIDIzMyAwIFIgDS9JbTExIDIzMCAwIFIgL0ltMTIgMjI4IDAgUiAvSW0xMyAy MjkgMCBSIC9JbTE0IDIyMCAwIFIgL0ltMTUgMjExIDAgUiANL0ltMTYgMjEyIDAgUiAvSW0xNyAy MTAgMCBSIC9JbTE4IDIwOCAwIFIgL0ltMTkgMjA5IDAgUiAvSW0yMCAyMTMgMCBSIA0vSW0yMSAy MTcgMCBSIC9JbTIyIDIxOCAwIFIgL0ltMjMgMjE5IDAgUiAvSW0yNCAyMTYgMCBSIC9JbTI1IDIx NCAwIFIgDS9JbTI2IDIxNSAwIFIgL0ltMjcgMjM0IDAgUiAvSW0yOCAyNTIgMCBSIC9JbTI5IDI1 MyAwIFIgL0ltMzAgMjU0IDAgUiANL0ltMzEgMjUxIDAgUiAvSW0zMiAyNDkgMCBSIC9JbTMzIDI1 MCAwIFIgL0ltMzQgMjA3IDAgUiAvSW0zNSAyNTkgMCBSIA0vSW0zNiAyNjAgMCBSIC9JbTM3IDI2 MSAwIFIgL0ltMzggMjU4IDAgUiAvSW0zOSAyNTYgMCBSIC9JbTQwIDI1NyAwIFIgDS9JbTQxIDI0 OCAwIFIgL0ltNDIgMjM4IDAgUiAvSW00MyAyMzkgMCBSIC9JbTQ0IDI0MCAwIFIgL0ltNDUgMjM3 IDAgUiANL0ltNDYgMjM1IDAgUiAvSW00NyAyMzYgMCBSIC9JbTQ4IDI0MSAwIFIgL0ltNDkgMjQ1 IDAgUiAvSW01MCAyNDYgMCBSIA0vSW01MSAyNDcgMCBSIC9JbTUyIDI0NCAwIFIgL0ltNTMgMjQy IDAgUiAvSW01NCAyNDMgMCBSIC9JbTU1IDI1NSAwIFIgDS9JbTU2IDE2OSAwIFIgL0ltNTcgMTcw IDAgUiAvSW01OCAxNzEgMCBSIC9JbTU5IDE2NSAwIFIgL0ltNjAgMTY2IDAgUiANL0ltNjEgMTY3 IDAgUiAvSW02MiAxNzIgMCBSIC9JbTYzIDE3NiAwIFIgL0ltNjQgMTc3IDAgUiAvSW02NSAxNzgg MCBSIA0vSW02NiAxNzUgMCBSIC9JbTY3IDE3MyAwIFIgL0ltNjggMTc0IDAgUiAvSW02OSAxNjgg MCBSIC9JbTcwIDE1NSAwIFIgDS9JbTcxIDE1NiAwIFIgL0ltNzIgMTU3IDAgUiAvSW03MyAxNTQg MCBSIC9JbTc0IDE1MSAwIFIgL0ltNzUgMTUyIDAgUiANL0ltNzYgMTUzIDAgUiAvSW03NyAxNTgg MCBSIC9JbTc4IDE2MiAwIFIgL0ltNzkgMTYzIDAgUiAvSW04MCAxNjQgMCBSIA0vSW04MSAxNjEg MCBSIC9JbTgyIDE1OSAwIFIgL0ltODMgMTYwIDAgUiAvSW04NCAxOTAgMCBSIC9JbTg1IDE5NyAw IFIgDS9JbTg2IDE5OCAwIFIgL0ltODcgMTk5IDAgUiAvSW04OCAxOTYgMCBSIC9JbTg5IDE5NCAw IFIgL0ltOTAgMTk1IDAgUiANL0ltOTEgMjAwIDAgUiAvSW05MiAyNjIgMCBSIC9JbTkzIDIwNSAw IFIgL0ltOTQgMjA2IDAgUiAvSW05NSAyMDMgMCBSIA0vSW05NiAyMDEgMCBSIC9JbTk3IDIwMiAw IFIgL0ltOTggMTkzIDAgUiAvSW05OSAxODMgMCBSIC9JbTEwMCAxODQgMCBSIA0vSW0xMDEgMTg1 IDAgUiAvSW0xMDIgMTgyIDAgUiAvSW0xMDMgMTgwIDAgUiAvSW0xMDQgMTgxIDAgUiAvSW0xMDUg NDM3IDAgUiANL0ltMTA2IDE4NiAwIFIgL0ltMTA3IDE3OSAwIFIgL0ltMTA4IDE5MSAwIFIgL0lt MTA5IDE5MiAwIFIgL0ltMTEwIDE4OSAwIFIgDS9JbTExMSAxODcgMCBSIC9JbTExMiAxODggMCBS IC9JbTExMyAyMDQgMCBSIC9JbTExNCAzNjYgMCBSIC9JbTExNSAzNjcgMCBSIA0vSW0xMTYgMzY5 IDAgUiAvSW0xMTcgMzY4IDAgUiAvSW0xMTggMzY1IDAgUiAvSW0xMTkgMzYxIDAgUiAvSW0xMjAg MzYyIDAgUiANL0ltMTIxIDM2NCAwIFIgL0ltMTIyIDM2MyAwIFIgL0ltMTIzIDM3MCAwIFIgL0lt MTI0IDM3NiAwIFIgL0ltMTI1IDM3NyAwIFIgDS9JbTEyNiAzNzkgMCBSIC9JbTEyNyAzNzggMCBS IC9JbTEyOCAzNzUgMCBSIC9JbTEyOSAzNzEgMCBSIC9JbTEzMCAzNzIgMCBSIA0vSW0xMzEgMzc0 IDAgUiAvSW0xMzIgMzczIDAgUiAvSW0xMzMgMzYwIDAgUiAvSW0xMzQgMzQ2IDAgUiAvSW0xMzUg MzQ3IDAgUiANL0ltMTM2IDM0OSAwIFIgL0ltMTM3IDM0OCAwIFIgL0ltMTM4IDM0NSAwIFIgL0lt MTM5IDM0MSAwIFIgL0ltMTQwIDM0MiAwIFIgDS9JbTE0MSAzNDQgMCBSIC9JbTE0MiAzNDMgMCBS IC9JbTE0MyAzODAgMCBSIC9JbTE0NCAzNTYgMCBSIC9JbTE0NSAzNTcgMCBSIA0vSW0xNDYgMzU5 IDAgUiAvSW0xNDcgMzU4IDAgUiAvSW0xNDggMzU1IDAgUiAvSW0xNDkgMzUxIDAgUiAvSW0xNTAg MzUyIDAgUiANL0ltMTUxIDM1NCAwIFIgL0ltMTUyIDM1MyAwIFIgL0ltMTUzIDM1MCAwIFIgL0lt MTU0IDQxNiAwIFIgL0ltMTU1IDQwOSAwIFIgDS9JbTE1NiA0MTIgMCBSIC9JbTE1NyA0MTMgMCBS IC9JbTE1OCA0MTQgMCBSIC9JbTE1OSA0MTEgMCBSIC9JbTE2MCA0MTUgMCBSIA0vSW0xNjEgNDEw IDAgUiAvSW0xNjIgNDA4IDAgUiAvSW0xNjMgNDE3IDAgUiAvSW0xNjQgMzg2IDAgUiAvSW0xNjUg Mzg4IDAgUiANL0ltMTY2IDM4NyAwIFIgL0ltMTY3IDM4OSAwIFIgL0ltMTY4IDM5MiAwIFIgL0lt MTY5IDM5MSAwIFIgL0ltMTcwIDM5MCAwIFIgDS9JbTE3MSA0MDcgMCBSIC9JbTE3MiAzODIgMCBS IC9JbTE3MyAzODEgMCBSIC9JbTE3NCAzODMgMCBSIC9JbTE3NSAzODUgMCBSIA0vSW0xNzYgMzg0 IDAgUiAvSW0xNzcgMzkzIDAgUiAvSW0xNzggNDAyIDAgUiAvSW0xNzkgNDAxIDAgUiAvSW0xODAg NDAzIDAgUiANL0ltMTgxIDQwNiAwIFIgL0ltMTgyIDQwNSAwIFIgL0ltMTgzIDQwNCAwIFIgL0lt MTg0IDQwMCAwIFIgL0ltMTg1IDM5NSAwIFIgDS9JbTE4NiAzOTQgMCBSIC9JbTE4NyAzOTYgMCBS IC9JbTE4OCAzOTkgMCBSIC9JbTE4OSAzOTggMCBSIC9JbTE5MCAzOTcgMCBSIA0vSW0xOTEgMjY3 IDAgUiAvSW0xOTIgMjg3IDAgUiAvSW0xOTMgMjg4IDAgUiAvSW0xOTQgMjkwIDAgUiAvSW0xOTUg Mjg5IDAgUiANL0ltMTk2IDI4NiAwIFIgL0ltMTk3IDI4MiAwIFIgL0ltMTk4IDI4MyAwIFIgL0lt MTk5IDI4NSAwIFIgL0ltMjAwIDI4NCAwIFIgDS9JbTIwMSAyOTEgMCBSIC9JbTIwMiAyOTcgMCBS IC9JbTIwMyAyOTggMCBSIC9JbTIwNCAzMDAgMCBSIC9JbTIwNSAyOTkgMCBSIA0vSW0yMDYgMjk2 IDAgUiAvSW0yMDcgMjkyIDAgUiAvSW0yMDggMjkzIDAgUiAvSW0yMDkgMjk1IDAgUiAvSW0yMTAg Mjk0IDAgUiANL0ltMjExIDI4MSAwIFIgL0ltMjEyIDM0MCAwIFIgL0ltMjEzIDI2OCAwIFIgL0lt MjE0IDI3MCAwIFIgL0ltMjE1IDI2OSAwIFIgDS9JbTIxNiAyNjYgMCBSIC9JbTIxNyAyNjMgMCBS IC9JbTIxOCAyNjQgMCBSIC9JbTIxOSAyNjUgMCBSIC9JbTIyMCAyNzEgMCBSIA0vSW0yMjEgMjc3 IDAgUiAvSW0yMjIgMjc4IDAgUiAvSW0yMjMgMjgwIDAgUiAvSW0yMjQgMjc5IDAgUiAvSW0yMjUg Mjc2IDAgUiANL0ltMjI2IDI3MiAwIFIgL0ltMjI3IDI3MyAwIFIgL0ltMjI4IDI3NSAwIFIgL0lt MjI5IDI3NCAwIFIgL0ltMjMwIDMwMSAwIFIgDS9JbTIzMSAzMjYgMCBSIC9JbTIzMiAzMjcgMCBS IC9JbTIzMyAzMjkgMCBSIC9JbTIzNCAzMjggMCBSIC9JbTIzNSAzMjUgMCBSIA0vSW0yMzYgMzIx IDAgUiAvSW0yMzcgMzIyIDAgUiAvSW0yMzggMzI0IDAgUiAvSW0yMzkgMzIzIDAgUiAvSW0yNDAg MzMwIDAgUiANL0ltMjQxIDMzNiAwIFIgL0ltMjQyIDMzNyAwIFIgL0ltMjQzIDMzOSAwIFIgL0lt MjQ0IDMzOCAwIFIgL0ltMjQ1IDMzNSAwIFIgDS9JbTI0NiAzMzEgMCBSIC9JbTI0NyAzMzIgMCBS IC9JbTI0OCAzMzQgMCBSIC9JbTI0OSAzMzMgMCBSIC9JbTI1MCAzMjAgMCBSIA0vSW0yNTEgMzA2 IDAgUiAvSW0yNTIgMzA3IDAgUiAvSW0yNTMgMzA5IDAgUiAvSW0yNTQgMzA4IDAgUiAvSW0yNTUg MzA1IDAgUiANL0ltMjU2IDMwMiAwIFIgL0ltMjU3IDMwMyAwIFIgL0ltMjU4IDMwNCAwIFIgL0lt MjU5IDMxMCAwIFIgL0ltMjYwIDMxNiAwIFIgDS9JbTI2MSAzMTcgMCBSIC9JbTI2MiAzMTkgMCBS IC9JbTI2MyAzMTggMCBSIC9JbTI2NCAzMTUgMCBSIC9JbTI2NSAzMTEgMCBSIA0vSW0yNjYgMzEy IDAgUiAvSW0yNjcgMzE0IDAgUiAvSW0yNjggMzEzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDQyNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTE5IDAgUiAvQ3M4IDEyMCAwIFIgL0Nz OSAxMjIgMCBSIC9DczEwIDEyMSAwIFIgL0NzMTEgMTE4IDAgUiANL0NzMTIgMTE1IDAgUiAvQ3Mx MyAxMTYgMCBSIC9DczE0IDEyMyAwIFIgL0NzMTUgMTE3IDAgUiAvQ3MxNiAxMzAgMCBSIA0vQ3Mx NyAxMjkgMCBSIC9DczE4IDEzMiAwIFIgL0NzMTkgMTMxIDAgUiAvQ3MyMCAxMjQgMCBSIC9DczIx IDEyOCAwIFIgDS9DczIyIDEyNSAwIFIgL0NzMjMgMTI3IDAgUiAvQ3MyNCAxMjYgMCBSIC9DczI1 IDExMSAwIFIgL0NzMjYgOTggMCBSIA0vQ3MyNyA5NyAwIFIgL0NzMjggOTkgMCBSIC9DczI5IDEw MSAwIFIgL0NzMzAgMTAwIDAgUiAvQ3MzMSA5NiAwIFIgDS9DczMyIDkyIDAgUiAvQ3MzMyA5MyAw IFIgL0NzMzQgOTUgMCBSIC9DczM1IDk0IDAgUiAvQ3MzNiAxMDIgMCBSIA0vQ3MzNyAxMTAgMCBS IC9DczM4IDEwOSAwIFIgL0NzMzkgMTE0IDAgUiAvQ3M0MCAxMTMgMCBSIC9DczQxIDExMiAwIFIg DS9DczQyIDEwOCAwIFIgL0NzNDMgMTA0IDAgUiAvQ3M0NCAxMDMgMCBSIC9DczQ1IDEwNSAwIFIg L0NzNDYgMTA3IDAgUiANL0NzNDcgMTA2IDAgUiA+PiANPj4gDWVuZG9iag0xOCAwIG9iag08PCAv TGVuZ3RoIDM0NDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV8uuZTsNnO+v WD9w07HzHjcSAgkk1EPEqHkIRIOgB/w+Xm+Xk5W91ZPT57iSFVe5bH/5+jMv338utP37+f1fry+/ /kbL336+uLhYl1LJeVpS9Msvhf3y37+8/vr6soK+fhOAd3Xxy7evv3/55bfy/38s5NLyv4X88rvl j3/yy59ftPx9eRGH9bS2HkbLj/P/JbT19H++vr2Os1z2cTuvtTWAKJ2IFPQvVsh/5FLvSl1+8S5F +Y4U2MXW2pJbdYl8Wr7/eH35zQ9afvXv1x+2eHbUYuoRheRLwoXgG0Eu8waI9QC0clzh2wUI+ooY ygBhrohwRc5lgAjymxuR3n5UkR/qDcj6o2qlot4dXGJ5RHHhzlN5F2+eUO/46EJtXTizS+UKbxMa 9nh5r7/jRURvAfBeDSAXfei/KEbHN2vEExKCa7uWggtpREJH9IWArJLShmiceAApRK6q71KKLQ+3 rFwEBYnwYUOESS88ZRgvB6l35Pc3xOCqugEE1VLKio/oUtiSJX9RFNaJBi8I5rcB6wUM4YDIN7l0 J4v9J5CqeWcUYxbp9BBhMSkTYc1i4BJGEGCRaaLgE8JobuqW5MiXQZIN8wxaaRRGHyZUqls4TCBi ydUSyQnMIXHpAUAj50m1b4CVRFKvKBMSDwBSONPWDjAEKmWJ28fcfxJVl+83BK8Z55D7T0LyAoE3 xC48SkdURf6OBMtaepvTmF0e9r3guCbth1JBqS/YEDTPzTcaQYDpwM9GciAM1QGbJQ8RwHVI719i 2A5Zsz28Q9gm1fML1Hfc7c1ADN/1yXPPeJmImopvuriHmULGo59IJMvE0jMYaVKpFwQYjDzR1QEx FMbwCQQ4jDObOiGmYhXt2aUaRrdQ0W0t5onlnhAWV0xDy5VbYqYRBIiP5YO3CPfqlpg09zVD9zwh 2HBj1aoPOGqs+bDTTGxQvThoHICsJ5Pkn2t3ize002xeOgBAeppZ0A54LtuVWKo9ADwuBahzDv0N yF2id1ldmSN1Q3ys2j0cazaBV+VCug0URzSYQrO+wTT9C4LMlUkBHhBDXpo1zAuC9LX3b1kJJBq+ peuyFyTpTUj32erK6A6kMOuBz7uWPQ8wAZ6SCTA5sVZWkXlySzK5cic5T1rbgTA5zrAdhDwCFL1F 5ajNZxiPz1DqWrc3KKgTQlHed0MyQLDfnhBJsHKeXCZFdUJMfuuk0k+IjCes5oCgPyymppmX3hw3 PsINKLONcAMUT/qG3PQNibmPB/oKvYvH1BYG5ebUfxAmtgRNt+loOwDTWmZdcwdEaSdqLAaBRE54 Qy6HzP1dTmXWMw/IJLFrBYZII0wUhd7XlIn/nBBxBrXaaP+R6vA1jiAwxhWlw27+OSFCilcQdOzA o/fLJqU2u4KTXCujD5Mfyv2W6uHD6uiSCOqqoMaKnUpaVOqprKypFH2FHmKorAGNsZbBNYbKihP8 GIImX3GWy6PHmP2rZs1LGL7fUFnLs2OfiMDOqyRDVzQjzQWR8Vz1XpXkNooG3pvXLWHMYokrv/eY RRNjbK5YX2ywSVImNvGWclO92D93QNBMNJBVLKXaeCSbPZCNI/UeD0w3dLkEw/EWz0VK5I4PE1fc 4gM8uKWJ9ezxwDA17eueffdew3F5lx8kWOdHKSh6aUb9GNIqVJsW0IkwBIcEBBcKIwhSDLsDDS9B p235uXIuCLOedhIMVMN4mHLJwzbbfKMBJnjdM8h7bRvDh4iZ63Lz6rOKGz8ECScfgJOcywBjqtpH rSrdMuLK0Ua8lK/aTH16LuwTY6gnnyfFfYOAfFk5ngvkwlBxVdV4g2+DDeSCsAfjrJ9ApKCD+jIt fsk01UHeVtkkDWrvMm35JP9cwRfGujTYNM7iUUjp6CTcJ0y0JZLCpIh3AJJI8c33FJIhSqWJQF7Q Lfd4k1aCTaLGUjsATLtEBco39DdYGiZbxA6QEYlvRQUsw9pfIJypuU1PIZJSTbJYbhiUoHYGzqmM EEFP7KTNXc7iwSUd1Q2uCXmIgRGMmHSqsmwmA4xUDN0KSfmxLC4AKoRxX4FGfmGMSpjfvz9kPbUS R60THNpvTMU0T6b2CxODS/oeaFkc4ygFqBhisEacNaIcUjfJKMuKNHnMAciaFkIrNe67IYxg9F7U vf0AoFqCf/eK4gsYL9e3CFGXJj7Qo7yO+GdxPTwbpZVg65KmlTuAmQUCAxe1z5NRlTaUrqp2hGhK bRwU4kRTBwIVFUC5MKCwK+kwoaSfkcFHcQy6MCiqgKsQeu+BsbJ6HM+ueEm7/q6m7SGPACa9Ffwk jx5vZRKhNY8hjBYc6YO3G9uKrMVVeJ+1DMbIKwbNi29liMEURPA6Gj5Hfsj6mkmfviBN17sWZWcQ ork26HSxTHzrwqDIYp6U8IGZeFfnKxcEB/QIOks1pBHG5Bmlhq3rxBipJWzdOKCeGKO1RB+kYOZj lfMIYqSWZmZ5YSAF0y5xQoybpfhBBlBrWtB6mQ3rfGVWWUppUpkbYuJJ3UR4AFAsespBUzrCUSf6 gs6SdoRVSXkuxx2AEsnhbTxuvenRVo/w5vLDCx5yaoTBE9vaAVYW9akzHOEVNpGA+5dPWkXiLfuu i8rIszo6MHZuzh4Ujt36wkTovpknXnJhUCN5NgafGKOSPKukE4NCwSw/QYxW6INPE8GwTgEUIU7o J8QsZhkmEBykTojpWhkH55TyCAPCaSrP4jFYi1Hkcugm6GvaxCAOTPHe1TvPOOQFGl1jZVP8xCYu jJHNbNo5MUY2hZ7N4oSganSvl/mojiGomhI++DKurqpEl5nNnJiZ0YzzbFRT0pPTXAD0mqKfz25d 4W6ZJSfZsYopeeIaG6Ijv0yK7EAg9aWCA+bUfVVH/GzG2RGGkDrb6XaEmT3rbDXdEUJHUNmtQHor eYCoYlUKoaRVHIdcAVHLUcNe36I47AaiC1OxJc02tQNjeax5mrED85wzucczDTBEsEvUMmX/wCD/ NU01tmNEAUnnrX7wnokGZJvzJQ8wkcAuGvbZFke5jsVF/W1N6yDEpOeYLJ800EGDbwODuRCogsYT Kz8wVgUN57ERAJtfg21qeIURQEu60MyEdWFQAC0/m+UJYXSyViY2fmFQM61ObPzEmO7f2geYCCnQ 1r8Kg+oIEvVcwn42y2TX6YW9n2h5B4Bc2INczEq0AlatqN2GosqwX0ddG94cqfDJxLOFE9QV+zCp 3x2Q9cDLM8/b4lnmOdV/YRVKMFLv4aAN9jizcvdc1AX79O7BIgrSF2QwBc9dvFEECjzsCTpUJAcM mgn7CrWHRXFhzMPbpF4PjJWGnta7wfPEGP6IPsAIh0lj/KMpXgh8DcHY1cIQY6gkmAjzACDUqK2T KepLzCxRRMz9rM4008uFgSmHCac17L8HxlDDBKuH2SVPjKGmfQCxzLSJm1yYptMGhvKUNssNgwJq HqWto6dOFF3dOhWDVTDPpLkCbJIZ9wEbbdKrrUuWMWxvGwC3mmmlbPHBO68vAG3h4rTHg1UzPzf1 LVzmGjh+NjpWKbJNuvIXfcVz8zgQcoFLajR5G29mBr35xTJESJqqotm/vULylNLoCtFLJu3YTe7c nh1Qrkp6MgrvS1zOAhGfEtvI6Ne68o5wecx6g5SOmKwJD/7pdHkpd6cHejo9kMv96fx4Om+7pAkP j6eHNbs2PD6eHleYDU+Pp4sN9Kfnx9PXaaoLL4+ni6f0pz+yKm6V+9MfWY1St93p8ZFVCS/d6fGR VdlfqT/9kdX/s142u23DMBy/+yl0bNGlk+1QiY9r1su+Dq1vww6eoyTabGmQnRV7kO15R8ppklYi tgFDgdoBSIrUT39aRPNlHJ2lSteTODpLFc2rODpLle7FcXSWKrZ+GUdnqVJbi6OzVFHdsVbnLFWQ Ca0CSxXyhFaBpQpFQqvAUoUyoVVgqcI8oVVgqQIktAosVVAJrQJLFRYJrQJLFZYJrQJLFaqEVoGl SoZRdMVSRcNYq4qlqsqEVhVLFc1jrSqWqoKEVhVLFc1jrSqWqloktKpYqmqZ0KpiqaoqoVV1oHpT Zy/ruhC5qDdZ+KjSHDU9MJBUBCHHu2q4f9U9ferxb2hthulIiVNn3WbhbSnqh+ziTnem+Ww6M/4Q K2cHs9a+GY2zl/UXWmr+uBRqnNYI/ymcxGVxTMT2Wr/GHxQ1BPxJjqdV5XWlStoFtJoyWBwzgOBw szfdODNW3HrvPCUxeteJ97rdNdYM/RQPO8asCBcDid9ugRPYeYlRbsd0fkXp0Eh0lg6QbXgtgsMH 5/umE+/0d90F38MYiXTI8+iXH/0Q7rSTw74bX2ABay3ElXi1eit6PQzNVk855BXJdTY9sBA8dQSr mv9dJfHGShxdZSqjPGT08WKD+6nDrraHXXWbx5zEN+9afDV2K5pBPOiuo+flp/oNscUeLfPiFLyi 4Bejb+zQG/RyVoxOGNt63VBiOLVAKOsp5ykdFQoYwpqjazEPfzp2188Al0Xo4P+P8OnIl8HhfvTa bsedtnr9Z87TIV3drWZ4P2x3uv067HtxdX5MxKGCp2Isq9AmnonxX/iywplO6r3rtXBYh0emyIX8 b+vstwADANZsbKAKZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgODIgMCBSIA0vUmVzb3VyY2VzIDIwIDAgUiANL0NvbnRlbnRzIDIxIDAgUiANL1JvdGF0 ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYx IF0gDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VD IC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSIC9UVDQgMTQ3IDAgUiA+PiANL1hPYmpl Y3QgPDwgL0ltMSAyMjQgMCBSIC9JbTIgMjI1IDAgUiAvSW0zIDIyNiAwIFIgL0ltNCAyMjMgMCBS IC9JbTUgMjIxIDAgUiANL0ltNiAyMjIgMCBSIC9JbTcgMjI3IDAgUiAvSW04IDIzMSAwIFIgL0lt OSAyMzIgMCBSIC9JbTEwIDIzMyAwIFIgDS9JbTExIDIzMCAwIFIgL0ltMTIgMjI4IDAgUiAvSW0x MyAyMjkgMCBSIC9JbTE0IDIyMCAwIFIgL0ltMTUgMjExIDAgUiANL0ltMTYgMjEyIDAgUiAvSW0x NyAyMTAgMCBSIC9JbTE4IDIwOCAwIFIgL0ltMTkgMjA5IDAgUiAvSW0yMCAyMTMgMCBSIA0vSW0y MSAyMTcgMCBSIC9JbTIyIDIxOCAwIFIgL0ltMjMgMjE5IDAgUiAvSW0yNCAyMTYgMCBSIC9JbTI1 IDIxNCAwIFIgDS9JbTI2IDIxNSAwIFIgL0ltMjcgMjM0IDAgUiAvSW0yOCAyNTIgMCBSIC9JbTI5 IDI1MyAwIFIgL0ltMzAgMjU0IDAgUiANL0ltMzEgMjUxIDAgUiAvSW0zMiAyNDkgMCBSIC9JbTMz IDI1MCAwIFIgL0ltMzQgMjA3IDAgUiAvSW0zNSAyNTkgMCBSIA0vSW0zNiAyNjAgMCBSIC9JbTM3 IDI2MSAwIFIgL0ltMzggMjU4IDAgUiAvSW0zOSAyNTYgMCBSIC9JbTQwIDI1NyAwIFIgDS9JbTQx IDI0OCAwIFIgL0ltNDIgMjM4IDAgUiAvSW00MyAyMzkgMCBSIC9JbTQ0IDI0MCAwIFIgL0ltNDUg MjM3IDAgUiANL0ltNDYgMjM1IDAgUiAvSW00NyAyMzYgMCBSIC9JbTQ4IDI0MSAwIFIgL0ltNDkg MjQ1IDAgUiAvSW01MCAyNDYgMCBSIA0vSW01MSAyNDcgMCBSIC9JbTUyIDI0NCAwIFIgL0ltNTMg MjQyIDAgUiAvSW01NCAyNDMgMCBSIC9JbTU1IDI1NSAwIFIgDS9JbTU2IDE2OSAwIFIgL0ltNTcg MTcwIDAgUiAvSW01OCAxNzEgMCBSIC9JbTU5IDE2NSAwIFIgL0ltNjAgMTY2IDAgUiANL0ltNjEg MTY3IDAgUiAvSW02MiAxNzIgMCBSIC9JbTYzIDE3NiAwIFIgL0ltNjQgMTc3IDAgUiAvSW02NSAx NzggMCBSIA0vSW02NiAxNzUgMCBSIC9JbTY3IDE3MyAwIFIgL0ltNjggMTc0IDAgUiAvSW02OSAx NjggMCBSIC9JbTcwIDE1NSAwIFIgDS9JbTcxIDE1NiAwIFIgL0ltNzIgMTU3IDAgUiAvSW03MyAx NTQgMCBSIC9JbTc0IDE1MSAwIFIgL0ltNzUgMTUyIDAgUiANL0ltNzYgMTUzIDAgUiAvSW03NyAx NTggMCBSIC9JbTc4IDE2MiAwIFIgL0ltNzkgMTYzIDAgUiAvSW04MCAxNjQgMCBSIA0vSW04MSAx NjEgMCBSIC9JbTgyIDE1OSAwIFIgL0ltODMgMTYwIDAgUiAvSW04NCAxOTAgMCBSIC9JbTg1IDE5 NyAwIFIgDS9JbTg2IDE5OCAwIFIgL0ltODcgMTk5IDAgUiAvSW04OCAxOTYgMCBSIC9JbTg5IDE5 NCAwIFIgL0ltOTAgMTk1IDAgUiANL0ltOTEgMjAwIDAgUiAvSW05MiAyNjIgMCBSIC9JbTkzIDIw NSAwIFIgL0ltOTQgMjA2IDAgUiAvSW05NSAyMDMgMCBSIA0vSW05NiAyMDEgMCBSIC9JbTk3IDIw MiAwIFIgL0ltOTggMTkzIDAgUiAvSW05OSAxODMgMCBSIC9JbTEwMCAxODQgMCBSIA0vSW0xMDEg MTg1IDAgUiAvSW0xMDIgMTgyIDAgUiAvSW0xMDMgMTgwIDAgUiAvSW0xMDQgMTgxIDAgUiAvSW0x MDUgNDM3IDAgUiANL0ltMTA2IDE4NiAwIFIgL0ltMTA3IDE3OSAwIFIgL0ltMTA4IDE5MSAwIFIg L0ltMTA5IDE5MiAwIFIgL0ltMTEwIDE4OSAwIFIgDS9JbTExMSAxODcgMCBSIC9JbTExMiAxODgg MCBSIC9JbTExMyAyMDQgMCBSIC9JbTExNCAzNjYgMCBSIC9JbTExNSAzNjcgMCBSIA0vSW0xMTYg MzY5IDAgUiAvSW0xMTcgMzY4IDAgUiAvSW0xMTggMzY1IDAgUiAvSW0xMTkgMzYxIDAgUiAvSW0x MjAgMzYyIDAgUiANL0ltMTIxIDM2NCAwIFIgL0ltMTIyIDM2MyAwIFIgL0ltMTIzIDM3MCAwIFIg L0ltMTI0IDM3NiAwIFIgL0ltMTI1IDM3NyAwIFIgDS9JbTEyNiAzNzkgMCBSIC9JbTEyNyAzNzgg MCBSIC9JbTEyOCAzNzUgMCBSIC9JbTEyOSAzNzEgMCBSIC9JbTEzMCAzNzIgMCBSIA0vSW0xMzEg Mzc0IDAgUiAvSW0xMzIgMzczIDAgUiAvSW0xMzMgMzYwIDAgUiAvSW0xMzQgMzQ2IDAgUiAvSW0x MzUgMzQ3IDAgUiANL0ltMTM2IDM0OSAwIFIgL0ltMTM3IDM0OCAwIFIgL0ltMTM4IDM0NSAwIFIg L0ltMTM5IDM0MSAwIFIgL0ltMTQwIDM0MiAwIFIgDS9JbTE0MSAzNDQgMCBSIC9JbTE0MiAzNDMg MCBSIC9JbTE0MyAzODAgMCBSIC9JbTE0NCAzNTYgMCBSIC9JbTE0NSAzNTcgMCBSIA0vSW0xNDYg MzU5IDAgUiAvSW0xNDcgMzU4IDAgUiAvSW0xNDggMzU1IDAgUiAvSW0xNDkgMzUxIDAgUiAvSW0x NTAgMzUyIDAgUiANL0ltMTUxIDM1NCAwIFIgL0ltMTUyIDM1MyAwIFIgL0ltMTUzIDM1MCAwIFIg L0ltMTU0IDQxNiAwIFIgL0ltMTU1IDQwOSAwIFIgDS9JbTE1NiA0MTIgMCBSIC9JbTE1NyA0MTMg MCBSIC9JbTE1OCA0MTQgMCBSIC9JbTE1OSA0MTEgMCBSIC9JbTE2MCA0MTUgMCBSIA0vSW0xNjEg NDEwIDAgUiAvSW0xNjIgNDA4IDAgUiAvSW0xNjMgNDE3IDAgUiAvSW0xNjQgMzg2IDAgUiAvSW0x NjUgMzg4IDAgUiANL0ltMTY2IDM4NyAwIFIgL0ltMTY3IDM4OSAwIFIgL0ltMTY4IDM5MiAwIFIg L0ltMTY5IDM5MSAwIFIgL0ltMTcwIDM5MCAwIFIgDS9JbTE3MSA0MDcgMCBSIC9JbTE3MiAzODIg MCBSIC9JbTE3MyAzODEgMCBSIC9JbTE3NCAzODMgMCBSIC9JbTE3NSAzODUgMCBSIA0vSW0xNzYg Mzg0IDAgUiAvSW0xNzcgMzkzIDAgUiAvSW0xNzggNDAyIDAgUiAvSW0xNzkgNDAxIDAgUiAvSW0x ODAgNDAzIDAgUiANL0ltMTgxIDQwNiAwIFIgL0ltMTgyIDQwNSAwIFIgL0ltMTgzIDQwNCAwIFIg L0ltMTg0IDQwMCAwIFIgL0ltMTg1IDM5NSAwIFIgDS9JbTE4NiAzOTQgMCBSIC9JbTE4NyAzOTYg MCBSIC9JbTE4OCAzOTkgMCBSIC9JbTE4OSAzOTggMCBSIC9JbTE5MCAzOTcgMCBSIA0vSW0xOTEg MjY3IDAgUiAvSW0xOTIgMjg3IDAgUiAvSW0xOTMgMjg4IDAgUiAvSW0xOTQgMjkwIDAgUiAvSW0x OTUgMjg5IDAgUiANL0ltMTk2IDI4NiAwIFIgL0ltMTk3IDI4MiAwIFIgL0ltMTk4IDI4MyAwIFIg L0ltMTk5IDI4NSAwIFIgL0ltMjAwIDI4NCAwIFIgDS9JbTIwMSAyOTEgMCBSIC9JbTIwMiAyOTcg MCBSIC9JbTIwMyAyOTggMCBSIC9JbTIwNCAzMDAgMCBSIC9JbTIwNSAyOTkgMCBSIA0vSW0yMDYg Mjk2IDAgUiAvSW0yMDcgMjkyIDAgUiAvSW0yMDggMjkzIDAgUiAvSW0yMDkgMjk1IDAgUiAvSW0y MTAgMjk0IDAgUiANL0ltMjExIDI4MSAwIFIgL0ltMjEyIDM0MCAwIFIgL0ltMjEzIDI2OCAwIFIg L0ltMjE0IDI3MCAwIFIgL0ltMjE1IDI2OSAwIFIgDS9JbTIxNiAyNjYgMCBSIC9JbTIxNyAyNjMg MCBSIC9JbTIxOCAyNjQgMCBSIC9JbTIxOSAyNjUgMCBSIC9JbTIyMCAyNzEgMCBSIA0vSW0yMjEg Mjc3IDAgUiAvSW0yMjIgMjc4IDAgUiAvSW0yMjMgMjgwIDAgUiAvSW0yMjQgMjc5IDAgUiAvSW0y MjUgMjc2IDAgUiANL0ltMjI2IDI3MiAwIFIgL0ltMjI3IDI3MyAwIFIgL0ltMjI4IDI3NSAwIFIg L0ltMjI5IDI3NCAwIFIgL0ltMjMwIDMwMSAwIFIgDS9JbTIzMSAzMjYgMCBSIC9JbTIzMiAzMjcg MCBSIC9JbTIzMyAzMjkgMCBSIC9JbTIzNCAzMjggMCBSIC9JbTIzNSAzMjUgMCBSIA0vSW0yMzYg MzIxIDAgUiAvSW0yMzcgMzIyIDAgUiAvSW0yMzggMzI0IDAgUiAvSW0yMzkgMzIzIDAgUiAvSW0y NDAgMzMwIDAgUiANL0ltMjQxIDMzNiAwIFIgL0ltMjQyIDMzNyAwIFIgL0ltMjQzIDMzOSAwIFIg L0ltMjQ0IDMzOCAwIFIgL0ltMjQ1IDMzNSAwIFIgDS9JbTI0NiAzMzEgMCBSIC9JbTI0NyAzMzIg MCBSIC9JbTI0OCAzMzQgMCBSIC9JbTI0OSAzMzMgMCBSIC9JbTI1MCAzMjAgMCBSIA0vSW0yNTEg MzA2IDAgUiAvSW0yNTIgMzA3IDAgUiAvSW0yNTMgMzA5IDAgUiAvSW0yNTQgMzA4IDAgUiAvSW0y NTUgMzA1IDAgUiANL0ltMjU2IDMwMiAwIFIgL0ltMjU3IDMwMyAwIFIgL0ltMjU4IDMwNCAwIFIg L0ltMjU5IDMxMCAwIFIgL0ltMjYwIDMxNiAwIFIgDS9JbTI2MSAzMTcgMCBSIC9JbTI2MiAzMTkg MCBSIC9JbTI2MyAzMTggMCBSIC9JbTI2NCAzMTUgMCBSIC9JbTI2NSAzMTEgMCBSIA0vSW0yNjYg MzEyIDAgUiAvSW0yNjcgMzE0IDAgUiAvSW0yNjggMzEzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv R1MxIDQyNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTE5IDAgUiAvQ3M4IDEyMCAwIFIg L0NzOSAxMjIgMCBSIC9DczEwIDEyMSAwIFIgL0NzMTEgMTE4IDAgUiANL0NzMTIgMTE1IDAgUiAv Q3MxMyAxMTYgMCBSIC9DczE0IDEyMyAwIFIgL0NzMTUgMTE3IDAgUiAvQ3MxNiAxMzAgMCBSIA0v Q3MxNyAxMjkgMCBSIC9DczE4IDEzMiAwIFIgL0NzMTkgMTMxIDAgUiAvQ3MyMCAxMjQgMCBSIC9D czIxIDEyOCAwIFIgDS9DczIyIDEyNSAwIFIgL0NzMjMgMTI3IDAgUiAvQ3MyNCAxMjYgMCBSIC9D czI1IDExMSAwIFIgL0NzMjYgOTggMCBSIA0vQ3MyNyA5NyAwIFIgL0NzMjggOTkgMCBSIC9DczI5 IDEwMSAwIFIgL0NzMzAgMTAwIDAgUiAvQ3MzMSA5NiAwIFIgDS9DczMyIDkyIDAgUiAvQ3MzMyA5 MyAwIFIgL0NzMzQgOTUgMCBSIC9DczM1IDk0IDAgUiAvQ3MzNiAxMDIgMCBSIA0vQ3MzNyAxMTAg MCBSIC9DczM4IDEwOSAwIFIgL0NzMzkgMTE0IDAgUiAvQ3M0MCAxMTMgMCBSIC9DczQxIDExMiAw IFIgDS9DczQyIDEwOCAwIFIgL0NzNDMgMTA0IDAgUiAvQ3M0NCAxMDMgMCBSIC9DczQ1IDEwNSAw IFIgL0NzNDYgMTA3IDAgUiANL0NzNDcgMTA2IDAgUiA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08 PCAvTGVuZ3RoIDM2MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV8uuZTsN nO+vWD9w07HzHjcSAgkk1EPEqHkIRIOgB/w+Xm+Xk5W91ZPT57iSFVe5bH/5+jMv338utP37+f1f ry+//kbL336+uLhYl1LJeVpS9Msvhf3y37+8/vr6soK+fhOAd3Xxy7evv3/55bfy/38s5NLyv4X8 8rvlj3/yy59ftPx9eRGH9bS2HkbLj/P/JbT19H++vr2Os1z2cTuvtTWAKJ2IFPQvVsh/5FLvSl1+ 8S5F+Y4U2MXW2pJbdYl8Wr7/eH35zQ9afvXv1x+2eHbUYuoRheRLwoXgG0Eu8waI9QC0clzh2wUI +ooYygBhrohwRc5lgAjymxuR3n5UkR/qDcj6o2qlot4dXGJ5RHHhzlN5F2+eUO/46EJtXTizS+UK bxMa9nh5r7/jRURvAfBeDSAXfei/KEbHN2vEExKCa7uWggtpREJH9IWArJLShmiceAApRK6q71KK LQ+3rFwEBYnwYUOESS88ZRgvB6l35Pc3xOCqugEE1VLKio/oUtiSJX9RFNaJBi8I5rcB6wUM4YDI N7l0J4v9J5CqeWcUYxbp9BBhMSkTYc1i4BJGEGCRaaLgE8JobuqW5MiXQZIN8wxaaRRGHyZUqls4 TCBiydUSyQnMIXHpAUAj50m1b4CVRFKvKBMSDwBSONPWDjAEKmWJ28fcfxJVl+83BK8Z55D7T0Ly AoE3xC48SkdURf6OBMtaepvTmF0e9r3guCbth1JBqS/YEDTPzTcaQYDpwM9GciAM1QGbJQ8RwHVI 719i2A5Zsz28Q9gm1fML1Hfc7c1ADN/1yXPPeJmImopvuriHmULGo59IJMvE0jMYaVKpFwQYjDzR 1QExFMbwCQQ4jDObOiGmYhXt2aUaRrdQ0W0t5onlnhAWV0xDy5VbYqYRBIiP5YO3CPfqlpg09zVD 9zwh2HBj1aoPOGqs+bDTTGxQvThoHICsJ5Pkn2t3ize002xeOgBAeppZ0A54LtuVWKo9ADwuBahz Dv0NyF2id1ldmSN1Q3ys2j0cazaBV+VCug0URzSYQrO+wTT9C4LMlUkBHhBDXpo1zAuC9LX3b1kJ JBq+peuyFyTpTUj32erK6A6kMOuBz7uWPQ8wAZ6SCTA5sVZWkXlySzK5cic5T1rbgTA5zrAdhDwC FL1F5ajNZxiPz1DqWrc3KKgTQlHed0MyQLDfnhBJsHKeXCZFdUJMfuuk0k+IjCes5oCgPyymppmX 3hw3PsINKLONcAMUT/qG3PQNibmPB/oKvYvH1BYG5ebUfxAmtgRNt+loOwDTWmZdcwdEaSdqLAaB RE54Qy6HzP1dTmXWMw/IJLFrBYZII0wUhd7XlIn/nBBxBrXaaP+R6vA1jiAwxhWlw27+OSFCilcQ dOzAo/fLJqU2u4KTXCujD5Mfyv2W6uHD6uiSCOqqoMaKnUpaVOqprKypFH2FHmKorAGNsZbBNYbK ihP8GIImX3GWy6PHmP2rZs1LGL7fUFnLs2OfiMDOqyRDVzQjzQWR8Vz1XpXkNooG3pvXLWHMYokr v/eYRRNjbK5YX2ywSVImNvGWclO92D93QNBMNJBVLKXaeCSbPZCNI/UeD0w3dLkEw/EWz0VK5I4P E1fc4gM8uKWJ9ezxwDA17eueffdew3F5lx8kWOdHKSh6aUb9GNIqVJsW0IkwBIcEBBcKIwhSDLsD DS9Bp235uXIuCLOedhIMVMN4mHLJwzbbfKMBJnjdM8h7bRvDh4iZ63Lz6rOKGz8ECScfgJOcywBj qtpHrSrdMuLK0Ua8lK/aTH16LuwTY6gnnyfFfYOAfFk5ngvkwlBxVdV4g2+DDeSCsAfjrJ9ApKCD +jItfsk01UHeVtkkDWrvMm35JP9cwRfGujTYNM7iUUjp6CTcJ0y0JZLCpIh3AJJI8c33FJIhSqWJ QF7QLfd4k1aCTaLGUjsATLtEBco39DdYGiZbxA6QEYlvRQUsw9pfIJypuU1PIZJSTbJYbhiUoHYG zqmMEEFP7KTNXc7iwSUd1Q2uCXmIgRGMmHSqsmwmA4xUDN0KSfmxLC4AKoRxX4FGfmGMSpjfvz9k PbUSR60THNpvTMU0T6b2CxODS/oeaFkc4ygFqBhisEacNaIcUjfJKMuKNHnMAciaFkIrNe67IYxg 9F7Uvf0AoFqCf/eK4gsYL9e3CFGXJj7Qo7yO+GdxPTwbpZVg65KmlTuAmQUCAxe1z5NRlTaUrqp2 hGhKbRwU4kRTBwIVFUC5MKCwK+kwoaSfkcFHcQy6MCiqgKsQeu+BsbJ6HM+ueEm7/q6m7SGPACa9 Ffwkjx5vZRKhNY8hjBYc6YO3G9uKrMVVeJ+1DMbIKwbNi29liMEURPA6Gj5Hfsj6mkmfviBN17sW ZWcQork26HSxTHzrwqDIYp6U8IGZeFfnKxcEB/QIOks1pBHG5Bmlhq3rxBipJWzdOKCeGKO1RB+k YOZjlfMIYqSWZmZ5YSAF0y5xQoybpfhBBlBrWtB6mQ3rfGVWWUppUpkbYuJJ3UR4AFAsespBUzrC USf6gs6SdoRVSXkuxx2AEsnhbTxuvenRVo/w5vLDCx5yaoTBE9vaAVYW9akzHOEVNpGA+5dPWkXi Lfuui8rIszo6MHZuzh4Ujt36wkTovpknXnJhUCN5NgafGKOSPKukE4NCwSw/QYxW6INPE8GwTgEU IU7oJ8QsZhkmEBykTojpWhkH55TyCAPCaSrP4jFYi1Hkcugm6GvaxCAOTPHe1TvPOOQFGl1jZVP8 xCYujJHNbNo5MUY2hZ7N4oSganSvl/mojiGomhI++DKurqpEl5nNnJiZ0YzzbFRT0pPTXAD0mqKf z25d4W6ZJSfZsYopeeIaG6Ijv0yK7EAg9aWCA+bUfVVH/GzG2RGGkDrb6XaEmT3rbDXdEUJHUNmt QHoreYCoYlUKoaRVHIdcAVHLUcNe36I47AaiC1OxJc02tQNjeax5mrED85wzucczDTBEsEvUMmX/ wCD/NU01tmNEAUnnrX7wnokGZJvzJQ8wkcAuGvbZFke5jsVF/W1N6yDEpOeYLJ800EGDbwODuRCo gsYTKz8wVgUN57ERAJtfg21qeIURQEu60MyEdWFQAC0/m+UJYXSyViY2fmFQM61ObPzEmO7f2geY CCnQ1r8Kg+oIEvVcwn42y2TX6YW9n2h5B4Bc2INczEq0AlatqN2GosqwX0ddG94cqfDJxLOFE9QV +zCp3x2Q9cDLM8/b4lnmOdV/YRVKMFLv4aAN9jizcvdc1AX79O7BIgrSF2QwBc9dvFEECjzsCTpU JAcMmgn7CrWHRXFhzMPbpF4PjJWGnta7wfPEGP6IPsAIh0lj/KMpXgh8DcHY1cIQY6gkmAjzACDU qK2TKepLzCxRRMz9rM4008uFgSmHCac17L8HxlDDBKuH2SVPjKGmfQCxzLSJm1yYptMGhvKUNssN gwJqHqWto6dOFF3dOhWDVTDPpLkCbJIZ9wEbbdKrrUuWMWxvGwC3mmmlbPHBO68vAG3h4rTHg1Uz Pzf1LVzmGjh+NjpWKbJNuvIXfcVz8zgQcoFLajR5G29mBr35xTJESJqqotm/vULylNLoCtFLJu3Y Te7cnh1Qrkp6MgrvS1zOAhGfEtvI6Ne68o5wecx6g5SOmKwJD/7pdHkpd6cHejo9kMv96fx4Om+7 pAkPj6eHNbs2PD6eHleYDU+Pp4sN9Kfnx9PXaaoLL4+ni6f0pz+yKm6V+9MfWY1St93p8ZFVCS/d 6fGRVdlfqT/9kdX/0141zWnDQPTOr9gjdGpqAxLh2oR00mk7mcS3TA/GXkCJLaWWyccPaX9vd22H pEiayYEOM2DG0tunffvWa1p+4qIHVeXxxEUPqkrLFy56UFWei130oKrU+mMXPagqtzUXPagqudv1 6iyoqog9XhVBVUXi8aoIqiomHq+KoKpi6vGqCKoqZh6viqCqQni8KoKqCunxqgiqKuYer4qgquLE 41URVFUsPF4VQVV5oYMug6rSQterMqiqnHq8KoOq0nLXqzKoqhQer8qgqrTc9aoMqirnHq/KoKry xONVGVRVLjxelb2qn9PBpzSdQALpetA+VPk9qvshoFiyCAnNqu38lVb8qKePzfWA6MQxLUvz7pIc nj4OhteY72rVPMOp0VYVWGeNMnqU3nKg2T4QzXgTZpfICbv3IMRYcPz2m0PFHCRu4X8z0isJeiWk cYtunfV8xJ4PX9KG1MB9jQ+oG6gyHSkdNVuMKlUUJULWNFl+BytsHhE1nC4h0wWcL7sgyYL9EHU/ /Ddh99HL2vuo/nGpUv22XA9SR6+MvOHL1fdLuMLcVBXqwsLFpcW8ZZR+u4bMgn3JLT7l20xvkI5m GpObErpYpPkkprnqJUSyD0HlyyHWpiZYWGUWC6iwULuqZ3lwjqiny1U0Jasw4vuP9ibunDfcDE8z TWmGUUSPsWGzqzXFN+s1MKGsLFkXozFamSfIiRyMfqZf/yOtuEvHD+Q0mBrh0dR3LRlD5VH3qbEd 3r5Yp+SHhTxesb7hMz8s1jNz3ZentxinNIfJo9SiQ0W2Ozg+Vxfm7F9KCFecstVhSuY0KR8vI9NX GslhRs6XcGuUBhKpxOwBYV0aU/izs1hwfz+aVWevXa6jdaGB3fqRW0Zh0II2DWyZVGPInfclAyY0 iIvpP+d70y47xVWumvIZarT31C/RPSQDRS9IYX93vG6GNf7aoW1GNIYMSTRrsw3aMaRbhP6WJYNp 4JSyIdVGU/kXsHrmo6g1qH5va8D0g8N70iVgrbhDWVNhs1V6A9mKcKqsHLeEl+ngrwADAG8L/h0K ZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODIgMCBS IA0vUmVzb3VyY2VzIDIzIDAgUiANL0NvbnRlbnRzIDI0IDAgUiANL1JvdGF0ZSA5MCANL01lZGlh Qm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYxIF0gDT4+IA1lbmRv YmoNMjMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSAN L0ZvbnQgPDwgL1RUMiAxNDUgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAy MjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAw IFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiAN L0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAv SW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAv SW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAv SW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAv SW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0v SW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9J bTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9J bTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9J bTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9J bTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9J bTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0lt NTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0lt NTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0lt NjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0lt NjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0lt NzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03 NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03 OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04 MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04 NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05 MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1 IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5 IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9J bTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAg UiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5 IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0 IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9J bTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAg UiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3 IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5 IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9J bTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAg UiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQy IDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0 IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9J bTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAg UiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5 IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5 IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9J bTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAg UiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkw IDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0 IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9J bTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAg UiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1 IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5 IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9J bTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAg UiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0 IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0 IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9J bTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAg UiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5 IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5 IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9J bTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAg UiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAx IDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0 IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9J bTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAg UiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1 IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5 IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9J bTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAg UiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2 IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0 IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9J bTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAg UiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAg UiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAg UiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAg UiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIg DS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9D czMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUg OTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAx MTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAx MDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAx MDYgMCBSID4+IA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IC9MZW5ndGggMzA3NSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH /D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLf v7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8l tPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+ 9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oN yPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3 a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE 4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLg EkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8o ExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4 Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJ c894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DR bS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwn k+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6 DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9 DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJA sN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9 i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF 3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq 6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuz Y5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA 0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmX HyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8 owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCef J8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6 NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1ga JlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyY dKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzj KAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCj vI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+R wUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4 n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+cr FwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEG UGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFW j/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSde cmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8Jp Ks/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiO IaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1 pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjs BqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCR wC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQ zIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkH gFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/h oA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB 88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXs vwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3 ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBy gUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ry jnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH 09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f/TXe44CAMxEO33FFtC gUhCxknaIIRA4iPwDSJRIEFDwfXxAp09SpEUo2nePntj8d63U6rleuLbKVWLD76dUi33Yt9Oqdro r3w7pVrGmm+nVM1u72pLqaIKXAWlijpwFZQqmsBVUKpYBa6CUkUbuApKFQhcBaUKCVwFpYoucBWU KvrAVVCqGAJXQamWoGsXStWC3lWhVGUVuCqUqsW9q0KpCgJXhVK1uHdVKFXpAleFUpU+cFUoVRkC V+VPddS0VG1ynfWWvnvMTsDi9yo7tvy5ZTsDv+uUPsqqt+c1PZON3sqA6pQW38826zvNTuN+s9Zr 3h3z9nI4z/WeNpo+AgwAech+cwplbmRzdHJlYW0NZW5kb2JqDTI1IDAgb2JqDTw8IA0vVHlwZSAv UGFnZSANL1BhcmVudCA4MiAwIFIgDS9SZXNvdXJjZXMgMjYgMCBSIA0vQ29udGVudHMgMjcgMCBS IA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgx IDU1MyA3NjEgXSANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0 IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RUNCAxNDcgMCBSID4+ IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00 IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMx IDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjgg MCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIg MCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAw IFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAw IFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAw IFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAw IFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAw IFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAg UiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAg UiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAg UiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAg UiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAg UiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBS IA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBS IC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBS IC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBS IC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBS IC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIg DS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIg L0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIg L0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIg L0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIg L0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIg DS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEg MCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDgg MTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0lt MTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIg DS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEg MCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMg MzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0lt MTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIg DS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYg MCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzgg MzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0lt MTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIg DS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEg MCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMg MzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0lt MTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIg DS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYg MCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjgg MzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0lt MTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIg DS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEg MCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMg NDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0lt MTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIg DS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAg MCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTgg MjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0lt MjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIg DS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUg MCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMg MjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0lt MjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIg DS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkg MCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjgg Mjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0lt MjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIg DS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMg MCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMg MzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0lt MjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIg DS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDgg MCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTgg MzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0lt MjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIg DS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0 YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9Dczgg MTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAx MTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEz MCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEy NCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEy NiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAw IFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBS IC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9D czM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0Nz NDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0Nz NDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTI3 IDAgb2JqDTw8IC9MZW5ndGggNDUzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/f fy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/ fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9W yH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1 ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/jo Qm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4 AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjm twHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFpp FEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcE rxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzV AZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhp UqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI 9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VY qj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXM C4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuB MDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zm gKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1z B0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXD bv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqis AY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbe m9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD 8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQE FwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJ Jx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKw B+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjx zfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJN slhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+ YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoW Qis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XP k1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+ rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqa SZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04 oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgA UCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2 kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbo g08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO884 5AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPS k9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPets Nd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMN MESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQ QYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s /MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp 8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128 UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBj qCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim 0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8A beHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU 0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Q y/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK3 3enxkVUJL93p8ZFV2V+pP/2R1f8TXzW9cdtA9L6/QkdvgU1EUqSkY+u4BQKkLmohl6IHf6yDNXY3 gb1t0N77vztDUiI54lBxGyMwsCutyeFw3pt5M7C8m1tnUcX2ZG6dRRWW93PrLKrYF8+ts6hC6a/n 1llUsazNrbOoQnbPc7VhUdV1Jlc1i6oWmVzVLKpaZnJVs6hqlclVzaKqm0yuahZVrTO5qllUtcnk qmZR1W0mVzWLqu4yuapZVHWfyVXNoooLZ9YNiyosnOeqYVE1KpOrhkUVls9z1bCoGp3JVcOiCsvn uWpYVE2byVXDomq6TK4aFlXTZ3LVeFRBueHv6vznlUDsP1erprPrRa1gg6gOKxgBMAPGH/arK7/r 6fZo/wm5I2qYGpRdXYt4+35c0YNLGt/vv1tBeoNQQy2GEQ46ik5aUw20RQqWuVOhfUA74w97+AF6 Kgkl3EAvhT80osEV4QdrWQG9a9uywSm9sZaJrcm4bEVqXMKM0eZPs8YbjW5j4wLOmz5nXBq87UbA ZR63q3u8a43LDViBu4KU2WBXb6HLgn9AwIkzBxuI4NoVnivxUrpVeC7QHE3Eqw5J8Nwere1qhZ99 tKcQYu6o5fhdrX4YVq+HAZhQDfdIQYO327gvEAAB/EB/oQvDlnM4RBwCXtc1MHq4dY9QzIfPq7P3 2+Pdx8fqzfZ+d9zerYeH1cWwwhRA18Knw6B9JWP/tCDkAW1O4FSdwhSl+DZoNXxa26mtyXhEHmc8 Ig89zXG+NVX8mTEOc0KbkscopE34tHCkDhz89VPKaGVxnD4djvG6Awmb22csw/1H2FSILXvaYuAs a2ZcUW1tuQIc63vKFeSHUMiP385+vKjefbxbQ2k+2643Er721fr34a1NVPAeCqCsYbIc3oABZBSl Uqg/7tkikrosKZEEJRL0w/MqFOqPe7aWJY2HpEQSlEj0NGs81B/3nDE+r0Kh/rhni5CkRCLwxIXA Pdttsz0pGULNcc/jnkJY2aMWY8ZwqHEc6vzAmqk3JtQbadnx06/vfqHVZlLH2hZsr5CN9aHTY+11 74D2K6GdTw20zvheq2iBqfEWqFzKujkusLC6W3Rwhc5277bB1tCrtiL4L6YcgO3gPj6BAfT+8uZh e3uqhr8+bZ+89w0kEjYK0GNKpCM0PBtRS2wJLSnSI0Uv7a0gacYKjeeo6Zz4mPP99dN4jOgbPEa0 HaAt/Dko95MAMmIPXTTREz02DaMeG5mKffhhSexnxoUknYSAmafNn7Yk9qPx/yz2ozNOuINrJbFP 94RYlcS+EOIFsS/EL59yXuKF0i8o8ZFXXkwCZbwKTyB6iaeo8hI/Mx5RxhmPKENPW5L40fizJD5A 7q6fEoWXeLovRZ2R+EJsFyS+ELiixAuoTN9I4iOXJSWSoERyEk+JxEv8zHhEJEGJRE9bkni+9hQk PiIEgYeX+HRPSgZO4gthXZD4QsyKEi8AnP8j8RgyhSC6cbbPxlgkikn8EM6PpgOkqFQ7P0Two7V+ AK2/P50edzd/nCa15nXS2E4jVGL/PumWQQFug0hO70saSQ1r3SeGNYxriUKmlgsC6S1/mT6mpzt5 m1wpKWKyY4pKSQ/ZUC6oIRupohZq076QFqrUKVd1Ay+cOE1oqQ7JRdHjhZAaDrxwhiNekJOWVNBb br5YASeI/Z0TXuQFUOX2JUBnBLAc0AX9Y+N1VVCgsEkS9ARBz8kPQY9XH2o4oCcoeiKDXkF62Kwu KE8AYoYeozvJjgQCTnXYUC5oDhupouJomM2+ouK0jnq9sIkB3SEOZLLmBUfCoIZudDAbtnnBmRWX 81hwKnQEQqJlFzdQm7HxcvOevwDsvPhzezwty5RuRFoj3XtQE10nMjW9L8kUNdwInU5yDcwciU6l pgs65U0/S6fG453sBGdKSpXumSJTkio2nAtSxUerqFWNVC84twWnfIWcuOEVZQTMD20EQF6qqOGI G85yxA1y1JJWedPPGtgCzu7eKTv4gY3uS8Bm5jU2pgtqxYesOKxB4L/VsBY8loQ9grDHSSVhDy+V 1HDEHkHZIzLsKWglW1kKWhmxgODCq2W6J+EAJ5dsOBfkko9WUS8b2Xz9Ca2p+1x4CwMaymbbU720 XrSTF0qPVF6D02fV+VrB1/UaqXv26fpmt9+ddjCyIatfD0MDVgYAtVKm2ihjk0Vg/QL2gnuzZLHa au/5D14OLMjRguys0+4LvAMDLZiXkEZe5KOI2awT1tDl44fr4+7v3fFDdXnzsL2dhDobNi1VFLa+ 0GX4qDVQNFuV7TIcYjbtsUNY67OTCwwc/u8AbdWPiAplbmRzdHJlYW0NZW5kb2JqDTI4IDAgb2Jq DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4NCAwIFIgDS9SZXNvdXJjZXMgMjkgMCBSIA0vQ29u dGVudHMgMzAgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3Jv cEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0yOSAwIG9iag08PCANL1Byb2NTZXQg WyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RU NCAxNDcgMCBSIC9UVDYgNzYgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAy MjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAw IFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiAN L0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAv SW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAv SW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAv SW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAv SW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0v SW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9J bTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9J bTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9J bTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9J bTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9J bTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0lt NTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0lt NTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0lt NjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0lt NjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0lt NzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03 NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03 OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04 MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04 NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05 MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1 IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5 IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9J bTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAg UiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5 IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0 IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9J bTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAg UiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3 IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5 IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9J bTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAg UiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQy IDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0 IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9J bTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAg UiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5 IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5 IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9J bTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAg UiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkw IDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0 IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9J bTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAg UiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1 IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5 IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9J bTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAg UiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0 IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0 IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9J bTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAg UiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5 IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5 IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9J bTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAg UiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAx IDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0 IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9J bTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAg UiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1 IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5 IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9J bTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAg UiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2 IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0 IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9J bTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAg UiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAg UiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAg UiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAg UiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIg DS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9D czMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUg OTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAx MTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAx MDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAx MDYgMCBSID4+IA0+PiANZW5kb2JqDTMwIDAgb2JqDTw8IC9MZW5ndGggMzYyNiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH /D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLf v7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8l tPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+ 9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oN yPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3 a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE 4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLg EkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8o ExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4 Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJ c894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DR bS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwn k+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6 DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9 DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJA sN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9 i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF 3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq 6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuz Y5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA 0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmX HyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8 owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCef J8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6 NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1ga JlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyY dKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzj KAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCj vI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+R wUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4 n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+cr FwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEG UGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFW j/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSde cmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8Jp Ks/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiO IaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1 pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjs BqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCR wC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQ zIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkH gFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/h oA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB 88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXs vwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3 ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBy gUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ry jnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH 09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f/TXj67bQJBGL/zFHvE Enb5413DMWkSqVFzaEpOTQ8bvE5IMbiwduQHaZ+3M4sxjdmJ5aiVJRuk8ezH/OabXSA8HmYnqeLx ZJidpArhyTA7SRXPxcPsJFUY/f4wO0kVx9owO0kV3D306pSkyn2LVzlJlQcWr3KSKg8tXuUkVR5Z vMpJqnxq8SonqXJu8SonqXJh8SonqfKZxaucpMpji1c5SZUnFq9ykioGDrILkioEDr0qSKoisnhV kFQhfOhVQVIV3OJVQVKF8KFXBUlVzCxeFSRVEVu8KkiqIrF4VeyonqfOhzQNWcDShWM2VXyPan8g kS8QQgBnVXP+Spe41cOnyUoH5Pg+CEkzx1wlLH1x3KtLdiNL+aiWqtSj9BnTiy59kGCDjdsfuIWG izB9/Hf6Cce1zTcu45sFTO7fu3zTLl8nBV4MsTUg6qLVEuCfxt1lK+u6ykuPfVZyo9it+rlWjWY3 qmlA66HOQw3j3QKmpDDJcJn3yDLFQi1ptaqK6nHLvqxVvWWynIOkZlWVjeo0NaeIiuJe1Al6wj08 jk/yDaV9lCv5kBe53rLRdMLdtxR+T6/fJfHUuoUdw7NM51WJHZav1oXUiiIYYJthj4UzM3YCMX27 xyD/L1LPYWeZK7Ev2dl87rELVSitPHZTzfPF1jPtxmr1rDLtsbsVBFQv0H/4BBsI+1TK9mo0hp1w krhKZ4N6HvglTJL/5Je+EcL+qbSu84c11Bj6IHT7mntvdu3gGToSUYjvm8dJZCfjODB6L1wimPkO zNKAOe6q1uVwGn/drcfkuGdFUb0wXbFl352N2qhaFgxUyU5Vw6AxqlKxZVsydmRKRrE/CY5APwE1 7ysWdRW73MCwBparqiZn4p7jFDYF2Fj/LcdZJ6XRWDdlBN27a/DN3PhmIfOigmJ6DIxyP4JBfnX+ KtjDIj8pWesHJcFyeIsr+8gz3MHE1s76AZc9yfJRmX9eVF/BiXjydOUIv7WW2Q8mC1Vrs+ak6+yQ 4MR935wUQ2ifoN8sg7Ye+9K7t0qv6xKlXaYO1MuciuJwwuHI6k8SwcawV8MmUytn4fwRYAA2CEox CmVuZHN0cmVhbQ1lbmRvYmoNMzEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg0IDAg UiANL1Jlc291cmNlcyAzMiAwIFIgDS9Db250ZW50cyAzMyAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRp YUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5k b2JqDTMyIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJIF0g DS9Gb250IDw8IC9UVDIgMTQ1IDAgUiAvVFQ0IDE0NyAwIFIgL1RUNiA3NiAwIFIgPj4gDS9YT2Jq ZWN0IDw8IC9JbTEgMjI0IDAgUiAvSW0yIDIyNSAwIFIgL0ltMyAyMjYgMCBSIC9JbTQgMjIzIDAg UiAvSW01IDIyMSAwIFIgDS9JbTYgMjIyIDAgUiAvSW03IDIyNyAwIFIgL0ltOCAyMzEgMCBSIC9J bTkgMjMyIDAgUiAvSW0xMCAyMzMgMCBSIA0vSW0xMSAyMzAgMCBSIC9JbTEyIDIyOCAwIFIgL0lt MTMgMjI5IDAgUiAvSW0xNCAyMjAgMCBSIC9JbTE1IDIxMSAwIFIgDS9JbTE2IDIxMiAwIFIgL0lt MTcgMjEwIDAgUiAvSW0xOCAyMDggMCBSIC9JbTE5IDIwOSAwIFIgL0ltMjAgMjEzIDAgUiANL0lt MjEgMjE3IDAgUiAvSW0yMiAyMTggMCBSIC9JbTIzIDIxOSAwIFIgL0ltMjQgMjE2IDAgUiAvSW0y NSAyMTQgMCBSIA0vSW0yNiAyMTUgMCBSIC9JbTI3IDIzNCAwIFIgL0ltMjggMjUyIDAgUiAvSW0y OSAyNTMgMCBSIC9JbTMwIDI1NCAwIFIgDS9JbTMxIDI1MSAwIFIgL0ltMzIgMjQ5IDAgUiAvSW0z MyAyNTAgMCBSIC9JbTM0IDIwNyAwIFIgL0ltMzUgMjU5IDAgUiANL0ltMzYgMjYwIDAgUiAvSW0z NyAyNjEgMCBSIC9JbTM4IDI1OCAwIFIgL0ltMzkgMjU2IDAgUiAvSW00MCAyNTcgMCBSIA0vSW00 MSAyNDggMCBSIC9JbTQyIDIzOCAwIFIgL0ltNDMgMjM5IDAgUiAvSW00NCAyNDAgMCBSIC9JbTQ1 IDIzNyAwIFIgDS9JbTQ2IDIzNSAwIFIgL0ltNDcgMjM2IDAgUiAvSW00OCAyNDEgMCBSIC9JbTQ5 IDI0NSAwIFIgL0ltNTAgMjQ2IDAgUiANL0ltNTEgMjQ3IDAgUiAvSW01MiAyNDQgMCBSIC9JbTUz IDI0MiAwIFIgL0ltNTQgMjQzIDAgUiAvSW01NSAyNTUgMCBSIA0vSW01NiAxNjkgMCBSIC9JbTU3 IDE3MCAwIFIgL0ltNTggMTcxIDAgUiAvSW01OSAxNjUgMCBSIC9JbTYwIDE2NiAwIFIgDS9JbTYx IDE2NyAwIFIgL0ltNjIgMTcyIDAgUiAvSW02MyAxNzYgMCBSIC9JbTY0IDE3NyAwIFIgL0ltNjUg MTc4IDAgUiANL0ltNjYgMTc1IDAgUiAvSW02NyAxNzMgMCBSIC9JbTY4IDE3NCAwIFIgL0ltNjkg MTY4IDAgUiAvSW03MCAxNTUgMCBSIA0vSW03MSAxNTYgMCBSIC9JbTcyIDE1NyAwIFIgL0ltNzMg MTU0IDAgUiAvSW03NCAxNTEgMCBSIC9JbTc1IDE1MiAwIFIgDS9JbTc2IDE1MyAwIFIgL0ltNzcg MTU4IDAgUiAvSW03OCAxNjIgMCBSIC9JbTc5IDE2MyAwIFIgL0ltODAgMTY0IDAgUiANL0ltODEg MTYxIDAgUiAvSW04MiAxNTkgMCBSIC9JbTgzIDE2MCAwIFIgL0ltODQgMTkwIDAgUiAvSW04NSAx OTcgMCBSIA0vSW04NiAxOTggMCBSIC9JbTg3IDE5OSAwIFIgL0ltODggMTk2IDAgUiAvSW04OSAx OTQgMCBSIC9JbTkwIDE5NSAwIFIgDS9JbTkxIDIwMCAwIFIgL0ltOTIgMjYyIDAgUiAvSW05MyAy MDUgMCBSIC9JbTk0IDIwNiAwIFIgL0ltOTUgMjAzIDAgUiANL0ltOTYgMjAxIDAgUiAvSW05NyAy MDIgMCBSIC9JbTk4IDE5MyAwIFIgL0ltOTkgMTgzIDAgUiAvSW0xMDAgMTg0IDAgUiANL0ltMTAx IDE4NSAwIFIgL0ltMTAyIDE4MiAwIFIgL0ltMTAzIDE4MCAwIFIgL0ltMTA0IDE4MSAwIFIgL0lt MTA1IDQzNyAwIFIgDS9JbTEwNiAxODYgMCBSIC9JbTEwNyAxNzkgMCBSIC9JbTEwOCAxOTEgMCBS IC9JbTEwOSAxOTIgMCBSIC9JbTExMCAxODkgMCBSIA0vSW0xMTEgMTg3IDAgUiAvSW0xMTIgMTg4 IDAgUiAvSW0xMTMgMjA0IDAgUiAvSW0xMTQgMzY2IDAgUiAvSW0xMTUgMzY3IDAgUiANL0ltMTE2 IDM2OSAwIFIgL0ltMTE3IDM2OCAwIFIgL0ltMTE4IDM2NSAwIFIgL0ltMTE5IDM2MSAwIFIgL0lt MTIwIDM2MiAwIFIgDS9JbTEyMSAzNjQgMCBSIC9JbTEyMiAzNjMgMCBSIC9JbTEyMyAzNzAgMCBS IC9JbTEyNCAzNzYgMCBSIC9JbTEyNSAzNzcgMCBSIA0vSW0xMjYgMzc5IDAgUiAvSW0xMjcgMzc4 IDAgUiAvSW0xMjggMzc1IDAgUiAvSW0xMjkgMzcxIDAgUiAvSW0xMzAgMzcyIDAgUiANL0ltMTMx IDM3NCAwIFIgL0ltMTMyIDM3MyAwIFIgL0ltMTMzIDM2MCAwIFIgL0ltMTM0IDM0NiAwIFIgL0lt MTM1IDM0NyAwIFIgDS9JbTEzNiAzNDkgMCBSIC9JbTEzNyAzNDggMCBSIC9JbTEzOCAzNDUgMCBS IC9JbTEzOSAzNDEgMCBSIC9JbTE0MCAzNDIgMCBSIA0vSW0xNDEgMzQ0IDAgUiAvSW0xNDIgMzQz IDAgUiAvSW0xNDMgMzgwIDAgUiAvSW0xNDQgMzU2IDAgUiAvSW0xNDUgMzU3IDAgUiANL0ltMTQ2 IDM1OSAwIFIgL0ltMTQ3IDM1OCAwIFIgL0ltMTQ4IDM1NSAwIFIgL0ltMTQ5IDM1MSAwIFIgL0lt MTUwIDM1MiAwIFIgDS9JbTE1MSAzNTQgMCBSIC9JbTE1MiAzNTMgMCBSIC9JbTE1MyAzNTAgMCBS IC9JbTE1NCA0MTYgMCBSIC9JbTE1NSA0MDkgMCBSIA0vSW0xNTYgNDEyIDAgUiAvSW0xNTcgNDEz IDAgUiAvSW0xNTggNDE0IDAgUiAvSW0xNTkgNDExIDAgUiAvSW0xNjAgNDE1IDAgUiANL0ltMTYx IDQxMCAwIFIgL0ltMTYyIDQwOCAwIFIgL0ltMTYzIDQxNyAwIFIgL0ltMTY0IDM4NiAwIFIgL0lt MTY1IDM4OCAwIFIgDS9JbTE2NiAzODcgMCBSIC9JbTE2NyAzODkgMCBSIC9JbTE2OCAzOTIgMCBS IC9JbTE2OSAzOTEgMCBSIC9JbTE3MCAzOTAgMCBSIA0vSW0xNzEgNDA3IDAgUiAvSW0xNzIgMzgy IDAgUiAvSW0xNzMgMzgxIDAgUiAvSW0xNzQgMzgzIDAgUiAvSW0xNzUgMzg1IDAgUiANL0ltMTc2 IDM4NCAwIFIgL0ltMTc3IDM5MyAwIFIgL0ltMTc4IDQwMiAwIFIgL0ltMTc5IDQwMSAwIFIgL0lt MTgwIDQwMyAwIFIgDS9JbTE4MSA0MDYgMCBSIC9JbTE4MiA0MDUgMCBSIC9JbTE4MyA0MDQgMCBS IC9JbTE4NCA0MDAgMCBSIC9JbTE4NSAzOTUgMCBSIA0vSW0xODYgMzk0IDAgUiAvSW0xODcgMzk2 IDAgUiAvSW0xODggMzk5IDAgUiAvSW0xODkgMzk4IDAgUiAvSW0xOTAgMzk3IDAgUiANL0ltMTkx IDI2NyAwIFIgL0ltMTkyIDI4NyAwIFIgL0ltMTkzIDI4OCAwIFIgL0ltMTk0IDI5MCAwIFIgL0lt MTk1IDI4OSAwIFIgDS9JbTE5NiAyODYgMCBSIC9JbTE5NyAyODIgMCBSIC9JbTE5OCAyODMgMCBS IC9JbTE5OSAyODUgMCBSIC9JbTIwMCAyODQgMCBSIA0vSW0yMDEgMjkxIDAgUiAvSW0yMDIgMjk3 IDAgUiAvSW0yMDMgMjk4IDAgUiAvSW0yMDQgMzAwIDAgUiAvSW0yMDUgMjk5IDAgUiANL0ltMjA2 IDI5NiAwIFIgL0ltMjA3IDI5MiAwIFIgL0ltMjA4IDI5MyAwIFIgL0ltMjA5IDI5NSAwIFIgL0lt MjEwIDI5NCAwIFIgDS9JbTIxMSAyODEgMCBSIC9JbTIxMiAzNDAgMCBSIC9JbTIxMyAyNjggMCBS IC9JbTIxNCAyNzAgMCBSIC9JbTIxNSAyNjkgMCBSIA0vSW0yMTYgMjY2IDAgUiAvSW0yMTcgMjYz IDAgUiAvSW0yMTggMjY0IDAgUiAvSW0yMTkgMjY1IDAgUiAvSW0yMjAgMjcxIDAgUiANL0ltMjIx IDI3NyAwIFIgL0ltMjIyIDI3OCAwIFIgL0ltMjIzIDI4MCAwIFIgL0ltMjI0IDI3OSAwIFIgL0lt MjI1IDI3NiAwIFIgDS9JbTIyNiAyNzIgMCBSIC9JbTIyNyAyNzMgMCBSIC9JbTIyOCAyNzUgMCBS IC9JbTIyOSAyNzQgMCBSIC9JbTIzMCAzMDEgMCBSIA0vSW0yMzEgMzI2IDAgUiAvSW0yMzIgMzI3 IDAgUiAvSW0yMzMgMzI5IDAgUiAvSW0yMzQgMzI4IDAgUiAvSW0yMzUgMzI1IDAgUiANL0ltMjM2 IDMyMSAwIFIgL0ltMjM3IDMyMiAwIFIgL0ltMjM4IDMyNCAwIFIgL0ltMjM5IDMyMyAwIFIgL0lt MjQwIDMzMCAwIFIgDS9JbTI0MSAzMzYgMCBSIC9JbTI0MiAzMzcgMCBSIC9JbTI0MyAzMzkgMCBS IC9JbTI0NCAzMzggMCBSIC9JbTI0NSAzMzUgMCBSIA0vSW0yNDYgMzMxIDAgUiAvSW0yNDcgMzMy IDAgUiAvSW0yNDggMzM0IDAgUiAvSW0yNDkgMzMzIDAgUiAvSW0yNTAgMzIwIDAgUiANL0ltMjUx IDMwNiAwIFIgL0ltMjUyIDMwNyAwIFIgL0ltMjUzIDMwOSAwIFIgL0ltMjU0IDMwOCAwIFIgL0lt MjU1IDMwNSAwIFIgDS9JbTI1NiAzMDIgMCBSIC9JbTI1NyAzMDMgMCBSIC9JbTI1OCAzMDQgMCBS IC9JbTI1OSAzMTAgMCBSIC9JbTI2MCAzMTYgMCBSIA0vSW0yNjEgMzE3IDAgUiAvSW0yNjIgMzE5 IDAgUiAvSW0yNjMgMzE4IDAgUiAvSW0yNjQgMzE1IDAgUiAvSW0yNjUgMzExIDAgUiANL0ltMjY2 IDMxMiAwIFIgL0ltMjY3IDMxNCAwIFIgL0ltMjY4IDMxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSA0MjYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDExOSAwIFIgL0NzOCAxMjAgMCBS IC9DczkgMTIyIDAgUiAvQ3MxMCAxMjEgMCBSIC9DczExIDExOCAwIFIgDS9DczEyIDExNSAwIFIg L0NzMTMgMTE2IDAgUiAvQ3MxNCAxMjMgMCBSIC9DczE1IDExNyAwIFIgL0NzMTYgMTMwIDAgUiAN L0NzMTcgMTI5IDAgUiAvQ3MxOCAxMzIgMCBSIC9DczE5IDEzMSAwIFIgL0NzMjAgMTI0IDAgUiAv Q3MyMSAxMjggMCBSIA0vQ3MyMiAxMjUgMCBSIC9DczIzIDEyNyAwIFIgL0NzMjQgMTI2IDAgUiAv Q3MyNSAxMTEgMCBSIC9DczI2IDk4IDAgUiANL0NzMjcgOTcgMCBSIC9DczI4IDk5IDAgUiAvQ3My OSAxMDEgMCBSIC9DczMwIDEwMCAwIFIgL0NzMzEgOTYgMCBSIA0vQ3MzMiA5MiAwIFIgL0NzMzMg OTMgMCBSIC9DczM0IDk1IDAgUiAvQ3MzNSA5NCAwIFIgL0NzMzYgMTAyIDAgUiANL0NzMzcgMTEw IDAgUiAvQ3MzOCAxMDkgMCBSIC9DczM5IDExNCAwIFIgL0NzNDAgMTEzIDAgUiAvQ3M0MSAxMTIg MCBSIA0vQ3M0MiAxMDggMCBSIC9DczQzIDEwNCAwIFIgL0NzNDQgMTAzIDAgUiAvQ3M0NSAxMDUg MCBSIC9DczQ2IDEwNyAwIFIgDS9DczQ3IDEwNiAwIFIgPj4gDT4+IA1lbmRvYmoNMzMgMCBvYmoN PDwgL0xlbmd0aCAzNTIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7 DZzvr1g/cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9 X68vv/5Gy99+vri4WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F /PK75Y9/8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pd fvEuRfmOFNjF1tqSW3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsF CPqKGMoAYa6IcEXOZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vl Cm8TGvZ4ea+/40VEbwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9S ii0Pt6xcBAWJ8GFDhEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGA yDe5dCeL/SeQqnlnFGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpb OEwgYsnVEskJzCFx6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C 8gKBN8QuPEpHVEX+jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1 SO9fYtgOWbM9vEPYJtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw8 0dUBMRTG8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1 Q/c8IdhwY9WqDzhqrPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWo cw79DchdondZXZkjdUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929Z CSQavqXrshck6U1I99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8 AhS9ReWozWcYj89Q6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZ l94cNz7CDSizjXADFE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwG gUROeEMuh8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopX EHTswKP3yyalNruCk1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWG yooT/BiCJl9xlsujx5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJ K7/3mEUTY2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSO DxNX3OIDPLilifXs8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7 Aw0vQadt+blyLgiznnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsA Y6raR60q3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSg g/oyLX7JNNVB3lbZJA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUql iUBe0C33eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2 Bs6pjBBBT+ykzV3O4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ ZD21EketExzab0zFNE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGM YPRe1L39AKBagn/3iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6q doRoSm0cFOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAm vRX8JI8eb2USoTWPIYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7 FmVnEKK5Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQf pGDmY5XzCGKklmZmeWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6 wlEn+oLOknaEVUl5LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF 4i37rovKyLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4B FCFO6CfELGYZJhAcpE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT /MQmLoyRzWzaOTFGNoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqi n89uXeFumSUn2bGKKXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZ rUB6K3mAqGJVCqGkVRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl /8Ag/zVNNbZjRAFJ561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQ qILGEys/MFYFDeexEQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oH mAgp0Na/CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPU Ffswqd8dkPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6 VCQHDJoJ+wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg 1KitkynqS8wsUUTM/azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbL DYMCah6lraOnThRd3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NV Mz839S1c5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt 2E3u3J4dUK5KejIK70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpv u6QJD4+nhzW7Njw+nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv 3enxkVXZX6k//ZHV/7Nedjtqw0AUvs9T+DJIQPM3hlxCaaWtitSu0qtuL1IwbFpIaBKK9kHa5+2M ExKKPVparZCAJd7jY39z/IPNp6Y6S5WOJ6Y6SxWbx6Y6S5XOxaY6SxWXfs9UZ6nSsmaqs1Qx3WZW I5YqeJasAksVfEtWgaUKgSWrwFKF0JJVYKlCZMkqsFQBLFkFlipIS1aBpQoTS1aBpQpTS1aBpQqx JavAUqWGhrpkqWJDM6uSpSpDS1YlSxWbm1mVLFUJlqxKlio2N7MqWapyYsmqZKnKqSWrkqUqY0tW ZUt1njivkiQQvkg2jt5U6R7VfKCQJwmCj2dVff5K9rTV46ta5Q7a8Ty8hCWr5itKnBz3/du5WKZ5 ulV7ldeD5Bvpy7O+H1OFjZoP/FNGFC68HF7qj4E61+/Uj0c9eFr8d6sXnfXOXvBmSLWBrRaOthV2 tiLt67M2NhjJse/OVnVW5OQyOxx3aa3EUlUVOh58Sd79bZe8aqMxnnyk9nuT0V+s0QuPfufxYu5m 67V4cE9Z/Sjq4lDsiu3Tw2AoFmqnajUUy2KdbZ6G4tMBfytO+VDQaH7ik7s8bb9R3x7hD6irpoNJ 703Vq/EzXALaKINbuPwDkki3pzEm7cDEx6Mqn0Sar8W9qg5FXnUoKsPhGQVWOi33N6B4loI7Tyu1 FlgLH75v7hZVN+OiVIdSVVjAKZXKtZfr3kZ+EzY8wZHq/8F/nebiRzMf4vRY7JSgqTo7GoqixAdV lm/bJxv8Iat7zzbqfk89y/Ef9tbhXMEPo5B26xeD31gBbYWWiaDP42wwAgxkXZfZ1yPlsIskVjGF 0ffGcRxdF1GjqHVcvoTYCgpxRXzBLDcj6caAAe7jum/jSpkTrU7AzDt4nj5pBFhKfr/Y+o2fbg7d e1UfSw3xTeKgX72rTgO8aKGhcSzFCNd6BFgqZ+P8EWAAzjbXwQplbmRzdHJlYW0NZW5kb2JqDTM0 IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4NCAwIFIgDS9SZXNvdXJjZXMgMzUgMCBS IA0vQ29udGVudHMgMzYgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL1By b2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0NSAw IFIgL1RUNCAxNDcgMCBSIC9UVDYgNzYgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIg L0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02 IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMz IDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIw IDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4 IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4 IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1 IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQg MCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcg MCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTgg MCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzgg MCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUg MCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAw IFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAw IFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAw IFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAw IFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAw IFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAg UiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAg UiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAg UiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAg UiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAg UiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBS IA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBS IC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBS IC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIg MCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYg MTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0x MTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIg L0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjgg MCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEg MzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0x MjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIg L0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMg MCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYg MzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0x NDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIg L0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTgg MCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEg MzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0x NTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIg L0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDgg MCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYg Mzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0x NzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIg L0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMg MCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEg NDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0x ODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIg L0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcg MCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYg Mjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0y MDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIg L0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIg MCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEg MjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0y MTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIg L0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzgg MCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYg MjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0y MzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIg L0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIg MCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEg MzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0y NDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIg L0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcg MCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYg MzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0y NjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIg L0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQg MCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0Nv bG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAg MTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQg MTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTgg MTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIg MTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5 OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAg MCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIg L0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAv Q3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAv Q3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0v Q3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTM2IDAgb2JqDTw8IC9MZW5ndGggMzQzNyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8So eQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0 yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYe RsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94 ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5He flSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd9 6L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8H qXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGEx KRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVv gJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OY XR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9zt zUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3Z pRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9 OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxr NoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw 64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNC Ud53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2J uY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsF hkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K /Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsY vt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZy U73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559 917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iY csnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou 7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk /1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QF yjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4J eYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL +h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cI UZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr 6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb 24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTw gZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFC jJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFt PG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frC ROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfn lPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBq dK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/ TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctR w17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZk m/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4 hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfp hb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9h FUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+M lYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WB KYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+k uQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9 xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S 28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+n iw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f9TXjY9agMx GL7nV/gYJEKTgAdy6KGIVmrVldpVbqseIjJZaLMJzQSt+CHt7609CYLtjLtUSHyMHPvFz7zzQeEr N7tIlY8nbnaRKoVnbnaRKp+L3ewiVVr6Yze7SJWXNTe7SJXc7Xp1IVLF2ONVFKli4vEqilQx9XgV Rao493gVRaq48HgVRaqIHq+iSBWVx6soUsWlx6soUsWVx6soUsXM41UUqXKgk12JVCnQ9aoSqaq5 x6tKpErhrleVSFWhx6tKpErhrleVSFUtPV5VIlW18nhViVRV5vGqGqmu8+BNnqeQQF4FdlPle9Tw QYlixRASOqva81f+xFs9vcy2CWjpjWN6bktj+XPwEG6KvjgU/W4SpXwACO+KpnjUT7rpJ9/yT1xH neskGc+0aPignzTzyGQJ7VxXdWbIIuy7rcelwt+T/DunWpxTneXQ5ZCnB0Vtgshqm/MDL2TRSpGw rP3hWBe95pGYR7QxpNRR+beCaKxhO0sLGlX6D1FWU8rxVl7iNI20qPDrUXcnKJoS7rU5tI3RMMoz bhe5hdw/unHRNStZxq+1z5IKf4lyr9s3oB2/0VPrwugS2ga+/Kg+bsyY4x/NGvpEx5pzn26rbpvj 6074riynsNG17vUU7tpyX52moPvt7AZygxhyySDmRh1DE6JLF17Ocpq+oelpJsFPiw1eFSI1RZ5B V2LmNnScIXUN5SjFQNV20O/0vgMrx8BbGMJoEJ53ba3h84c19O2hrdvH01gsFeyIcWz3vJSkJhfb Jxfb40X5ve6PXcMZ3+cB/U27yK/ocks7cDzL6HpJSw+ZpdNBFfwRYAD8YnoJCmVuZHN0cmVhbQ1l bmRvYmoNMzcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg0IDAgUiANL1Jlc291cmNl cyAzOCAwIFIgDS9Db250ZW50cyAzOSAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1 OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5kb2JqDTM4IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJIF0gDS9Gb250IDw8IC9U VDIgMTQ1IDAgUiAvVFQ0IDE0NyAwIFIgL1RUNiA3NiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEg MjI0IDAgUiAvSW0yIDIyNSAwIFIgL0ltMyAyMjYgMCBSIC9JbTQgMjIzIDAgUiAvSW01IDIyMSAw IFIgDS9JbTYgMjIyIDAgUiAvSW03IDIyNyAwIFIgL0ltOCAyMzEgMCBSIC9JbTkgMjMyIDAgUiAv SW0xMCAyMzMgMCBSIA0vSW0xMSAyMzAgMCBSIC9JbTEyIDIyOCAwIFIgL0ltMTMgMjI5IDAgUiAv SW0xNCAyMjAgMCBSIC9JbTE1IDIxMSAwIFIgDS9JbTE2IDIxMiAwIFIgL0ltMTcgMjEwIDAgUiAv SW0xOCAyMDggMCBSIC9JbTE5IDIwOSAwIFIgL0ltMjAgMjEzIDAgUiANL0ltMjEgMjE3IDAgUiAv SW0yMiAyMTggMCBSIC9JbTIzIDIxOSAwIFIgL0ltMjQgMjE2IDAgUiAvSW0yNSAyMTQgMCBSIA0v SW0yNiAyMTUgMCBSIC9JbTI3IDIzNCAwIFIgL0ltMjggMjUyIDAgUiAvSW0yOSAyNTMgMCBSIC9J bTMwIDI1NCAwIFIgDS9JbTMxIDI1MSAwIFIgL0ltMzIgMjQ5IDAgUiAvSW0zMyAyNTAgMCBSIC9J bTM0IDIwNyAwIFIgL0ltMzUgMjU5IDAgUiANL0ltMzYgMjYwIDAgUiAvSW0zNyAyNjEgMCBSIC9J bTM4IDI1OCAwIFIgL0ltMzkgMjU2IDAgUiAvSW00MCAyNTcgMCBSIA0vSW00MSAyNDggMCBSIC9J bTQyIDIzOCAwIFIgL0ltNDMgMjM5IDAgUiAvSW00NCAyNDAgMCBSIC9JbTQ1IDIzNyAwIFIgDS9J bTQ2IDIzNSAwIFIgL0ltNDcgMjM2IDAgUiAvSW00OCAyNDEgMCBSIC9JbTQ5IDI0NSAwIFIgL0lt NTAgMjQ2IDAgUiANL0ltNTEgMjQ3IDAgUiAvSW01MiAyNDQgMCBSIC9JbTUzIDI0MiAwIFIgL0lt NTQgMjQzIDAgUiAvSW01NSAyNTUgMCBSIA0vSW01NiAxNjkgMCBSIC9JbTU3IDE3MCAwIFIgL0lt NTggMTcxIDAgUiAvSW01OSAxNjUgMCBSIC9JbTYwIDE2NiAwIFIgDS9JbTYxIDE2NyAwIFIgL0lt NjIgMTcyIDAgUiAvSW02MyAxNzYgMCBSIC9JbTY0IDE3NyAwIFIgL0ltNjUgMTc4IDAgUiANL0lt NjYgMTc1IDAgUiAvSW02NyAxNzMgMCBSIC9JbTY4IDE3NCAwIFIgL0ltNjkgMTY4IDAgUiAvSW03 MCAxNTUgMCBSIA0vSW03MSAxNTYgMCBSIC9JbTcyIDE1NyAwIFIgL0ltNzMgMTU0IDAgUiAvSW03 NCAxNTEgMCBSIC9JbTc1IDE1MiAwIFIgDS9JbTc2IDE1MyAwIFIgL0ltNzcgMTU4IDAgUiAvSW03 OCAxNjIgMCBSIC9JbTc5IDE2MyAwIFIgL0ltODAgMTY0IDAgUiANL0ltODEgMTYxIDAgUiAvSW04 MiAxNTkgMCBSIC9JbTgzIDE2MCAwIFIgL0ltODQgMTkwIDAgUiAvSW04NSAxOTcgMCBSIA0vSW04 NiAxOTggMCBSIC9JbTg3IDE5OSAwIFIgL0ltODggMTk2IDAgUiAvSW04OSAxOTQgMCBSIC9JbTkw IDE5NSAwIFIgDS9JbTkxIDIwMCAwIFIgL0ltOTIgMjYyIDAgUiAvSW05MyAyMDUgMCBSIC9JbTk0 IDIwNiAwIFIgL0ltOTUgMjAzIDAgUiANL0ltOTYgMjAxIDAgUiAvSW05NyAyMDIgMCBSIC9JbTk4 IDE5MyAwIFIgL0ltOTkgMTgzIDAgUiAvSW0xMDAgMTg0IDAgUiANL0ltMTAxIDE4NSAwIFIgL0lt MTAyIDE4MiAwIFIgL0ltMTAzIDE4MCAwIFIgL0ltMTA0IDE4MSAwIFIgL0ltMTA1IDQzNyAwIFIg DS9JbTEwNiAxODYgMCBSIC9JbTEwNyAxNzkgMCBSIC9JbTEwOCAxOTEgMCBSIC9JbTEwOSAxOTIg MCBSIC9JbTExMCAxODkgMCBSIA0vSW0xMTEgMTg3IDAgUiAvSW0xMTIgMTg4IDAgUiAvSW0xMTMg MjA0IDAgUiAvSW0xMTQgMzY2IDAgUiAvSW0xMTUgMzY3IDAgUiANL0ltMTE2IDM2OSAwIFIgL0lt MTE3IDM2OCAwIFIgL0ltMTE4IDM2NSAwIFIgL0ltMTE5IDM2MSAwIFIgL0ltMTIwIDM2MiAwIFIg DS9JbTEyMSAzNjQgMCBSIC9JbTEyMiAzNjMgMCBSIC9JbTEyMyAzNzAgMCBSIC9JbTEyNCAzNzYg MCBSIC9JbTEyNSAzNzcgMCBSIA0vSW0xMjYgMzc5IDAgUiAvSW0xMjcgMzc4IDAgUiAvSW0xMjgg Mzc1IDAgUiAvSW0xMjkgMzcxIDAgUiAvSW0xMzAgMzcyIDAgUiANL0ltMTMxIDM3NCAwIFIgL0lt MTMyIDM3MyAwIFIgL0ltMTMzIDM2MCAwIFIgL0ltMTM0IDM0NiAwIFIgL0ltMTM1IDM0NyAwIFIg DS9JbTEzNiAzNDkgMCBSIC9JbTEzNyAzNDggMCBSIC9JbTEzOCAzNDUgMCBSIC9JbTEzOSAzNDEg MCBSIC9JbTE0MCAzNDIgMCBSIA0vSW0xNDEgMzQ0IDAgUiAvSW0xNDIgMzQzIDAgUiAvSW0xNDMg MzgwIDAgUiAvSW0xNDQgMzU2IDAgUiAvSW0xNDUgMzU3IDAgUiANL0ltMTQ2IDM1OSAwIFIgL0lt MTQ3IDM1OCAwIFIgL0ltMTQ4IDM1NSAwIFIgL0ltMTQ5IDM1MSAwIFIgL0ltMTUwIDM1MiAwIFIg DS9JbTE1MSAzNTQgMCBSIC9JbTE1MiAzNTMgMCBSIC9JbTE1MyAzNTAgMCBSIC9JbTE1NCA0MTYg MCBSIC9JbTE1NSA0MDkgMCBSIA0vSW0xNTYgNDEyIDAgUiAvSW0xNTcgNDEzIDAgUiAvSW0xNTgg NDE0IDAgUiAvSW0xNTkgNDExIDAgUiAvSW0xNjAgNDE1IDAgUiANL0ltMTYxIDQxMCAwIFIgL0lt MTYyIDQwOCAwIFIgL0ltMTYzIDQxNyAwIFIgL0ltMTY0IDM4NiAwIFIgL0ltMTY1IDM4OCAwIFIg DS9JbTE2NiAzODcgMCBSIC9JbTE2NyAzODkgMCBSIC9JbTE2OCAzOTIgMCBSIC9JbTE2OSAzOTEg MCBSIC9JbTE3MCAzOTAgMCBSIA0vSW0xNzEgNDA3IDAgUiAvSW0xNzIgMzgyIDAgUiAvSW0xNzMg MzgxIDAgUiAvSW0xNzQgMzgzIDAgUiAvSW0xNzUgMzg1IDAgUiANL0ltMTc2IDM4NCAwIFIgL0lt MTc3IDM5MyAwIFIgL0ltMTc4IDQwMiAwIFIgL0ltMTc5IDQwMSAwIFIgL0ltMTgwIDQwMyAwIFIg DS9JbTE4MSA0MDYgMCBSIC9JbTE4MiA0MDUgMCBSIC9JbTE4MyA0MDQgMCBSIC9JbTE4NCA0MDAg MCBSIC9JbTE4NSAzOTUgMCBSIA0vSW0xODYgMzk0IDAgUiAvSW0xODcgMzk2IDAgUiAvSW0xODgg Mzk5IDAgUiAvSW0xODkgMzk4IDAgUiAvSW0xOTAgMzk3IDAgUiANL0ltMTkxIDI2NyAwIFIgL0lt MTkyIDI4NyAwIFIgL0ltMTkzIDI4OCAwIFIgL0ltMTk0IDI5MCAwIFIgL0ltMTk1IDI4OSAwIFIg DS9JbTE5NiAyODYgMCBSIC9JbTE5NyAyODIgMCBSIC9JbTE5OCAyODMgMCBSIC9JbTE5OSAyODUg MCBSIC9JbTIwMCAyODQgMCBSIA0vSW0yMDEgMjkxIDAgUiAvSW0yMDIgMjk3IDAgUiAvSW0yMDMg Mjk4IDAgUiAvSW0yMDQgMzAwIDAgUiAvSW0yMDUgMjk5IDAgUiANL0ltMjA2IDI5NiAwIFIgL0lt MjA3IDI5MiAwIFIgL0ltMjA4IDI5MyAwIFIgL0ltMjA5IDI5NSAwIFIgL0ltMjEwIDI5NCAwIFIg DS9JbTIxMSAyODEgMCBSIC9JbTIxMiAzNDAgMCBSIC9JbTIxMyAyNjggMCBSIC9JbTIxNCAyNzAg MCBSIC9JbTIxNSAyNjkgMCBSIA0vSW0yMTYgMjY2IDAgUiAvSW0yMTcgMjYzIDAgUiAvSW0yMTgg MjY0IDAgUiAvSW0yMTkgMjY1IDAgUiAvSW0yMjAgMjcxIDAgUiANL0ltMjIxIDI3NyAwIFIgL0lt MjIyIDI3OCAwIFIgL0ltMjIzIDI4MCAwIFIgL0ltMjI0IDI3OSAwIFIgL0ltMjI1IDI3NiAwIFIg DS9JbTIyNiAyNzIgMCBSIC9JbTIyNyAyNzMgMCBSIC9JbTIyOCAyNzUgMCBSIC9JbTIyOSAyNzQg MCBSIC9JbTIzMCAzMDEgMCBSIA0vSW0yMzEgMzI2IDAgUiAvSW0yMzIgMzI3IDAgUiAvSW0yMzMg MzI5IDAgUiAvSW0yMzQgMzI4IDAgUiAvSW0yMzUgMzI1IDAgUiANL0ltMjM2IDMyMSAwIFIgL0lt MjM3IDMyMiAwIFIgL0ltMjM4IDMyNCAwIFIgL0ltMjM5IDMyMyAwIFIgL0ltMjQwIDMzMCAwIFIg DS9JbTI0MSAzMzYgMCBSIC9JbTI0MiAzMzcgMCBSIC9JbTI0MyAzMzkgMCBSIC9JbTI0NCAzMzgg MCBSIC9JbTI0NSAzMzUgMCBSIA0vSW0yNDYgMzMxIDAgUiAvSW0yNDcgMzMyIDAgUiAvSW0yNDgg MzM0IDAgUiAvSW0yNDkgMzMzIDAgUiAvSW0yNTAgMzIwIDAgUiANL0ltMjUxIDMwNiAwIFIgL0lt MjUyIDMwNyAwIFIgL0ltMjUzIDMwOSAwIFIgL0ltMjU0IDMwOCAwIFIgL0ltMjU1IDMwNSAwIFIg DS9JbTI1NiAzMDIgMCBSIC9JbTI1NyAzMDMgMCBSIC9JbTI1OCAzMDQgMCBSIC9JbTI1OSAzMTAg MCBSIC9JbTI2MCAzMTYgMCBSIA0vSW0yNjEgMzE3IDAgUiAvSW0yNjIgMzE5IDAgUiAvSW0yNjMg MzE4IDAgUiAvSW0yNjQgMzE1IDAgUiAvSW0yNjUgMzExIDAgUiANL0ltMjY2IDMxMiAwIFIgL0lt MjY3IDMxNCAwIFIgL0ltMjY4IDMxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MjYgMCBS ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDExOSAwIFIgL0NzOCAxMjAgMCBSIC9DczkgMTIyIDAg UiAvQ3MxMCAxMjEgMCBSIC9DczExIDExOCAwIFIgDS9DczEyIDExNSAwIFIgL0NzMTMgMTE2IDAg UiAvQ3MxNCAxMjMgMCBSIC9DczE1IDExNyAwIFIgL0NzMTYgMTMwIDAgUiANL0NzMTcgMTI5IDAg UiAvQ3MxOCAxMzIgMCBSIC9DczE5IDEzMSAwIFIgL0NzMjAgMTI0IDAgUiAvQ3MyMSAxMjggMCBS IA0vQ3MyMiAxMjUgMCBSIC9DczIzIDEyNyAwIFIgL0NzMjQgMTI2IDAgUiAvQ3MyNSAxMTEgMCBS IC9DczI2IDk4IDAgUiANL0NzMjcgOTcgMCBSIC9DczI4IDk5IDAgUiAvQ3MyOSAxMDEgMCBSIC9D czMwIDEwMCAwIFIgL0NzMzEgOTYgMCBSIA0vQ3MzMiA5MiAwIFIgL0NzMzMgOTMgMCBSIC9DczM0 IDk1IDAgUiAvQ3MzNSA5NCAwIFIgL0NzMzYgMTAyIDAgUiANL0NzMzcgMTEwIDAgUiAvQ3MzOCAx MDkgMCBSIC9DczM5IDExNCAwIFIgL0NzNDAgMTEzIDAgUiAvQ3M0MSAxMTIgMCBSIA0vQ3M0MiAx MDggMCBSIC9DczQzIDEwNCAwIFIgL0NzNDQgMTAzIDAgUiAvQ3M0NSAxMDUgMCBSIC9DczQ2IDEw NyAwIFIgDS9DczQ3IDEwNiAwIFIgPj4gDT4+IA1lbmRvYmoNMzkgMCBvYmoNPDwgL0xlbmd0aCAz NTY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/cNOx8x43 EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5Gy99+vri4 WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/8sufX7T8 fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmOFNjF1tqS W3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoAYa6IcEXO ZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4ea+/40VE bwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xcBAWJ8GFD hEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL/SeQqnln FGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnVEskJzCFx 6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8QuPEpHVEX+ jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgOWbM9vEPY JtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG8AkEOIwz mzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8IdhwY9WqDzhq rPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWocw79DchdondZXZkj dUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXrshck6U1I 99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWozWcYj89Q 6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7CDSizjXAD FE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMuh8z9XU5l 1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3yyalNruC k1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiCJl9xlsuj x5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUTY2yuWF9s sElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OIDPLilifXs 8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt+blyLgiz nnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsAY6raR60q3TLiytFG vJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7JNNVB3lbZ JA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33eJNWgk2i xlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBBT+ykzV3O 4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ZD21EketExzab0zF NE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39AKBagn/3 iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0cFOJEUwcC FRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8eb2USoTWP IYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5Nuh0sUx8 68KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQfpGDmY5XzCGKklmZm eWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLOknaEVUl5 LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovKyLM6OjB2 bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfELGYZJhAc pE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyRzWzaOTFG NoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFumSUn2bGK KXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mAqGJVCqGk VRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVNNbZjRAFJ 561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/MFYFDeex EQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/CoPqCBL1 XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8dkPXAyzPP 2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ+wq1h0Vx YczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg1KitkynqS8wsUUTM /azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6lraOnThRd 3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c5ho4fjY6 VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4dUK5KejIK 70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+nhzW7Njw+ nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZX6k//ZHV /xNfRb1pw0D4Pb/CjyAVloScIY9rhyZtomWQPY09pKlZKTShiSnaD1l/7852kjLsW7eKaarUBOly /nzf953PGD6ys5OsqvHEzk6yiuGxnZ1kVc3FdnaSVWz9vp2dZFW1NTs7ySq62/ZqRLIKvsOrQLIK gcOrQLIKocOrQLIKA4dXgWQVIodXgWQVwOFVIFkF7vAqkKzC0OFVIFmFkcOrQLIKscOrQLKqAq3s nGQVA22vcpJVPnB4lZOsYrjtVU6yysHhVU6yiuG2VznJKh86vMpJVvnI4VVOsspjh1d5zep54r1J kpAFLFl6+lBV9yjzwEQ+VyQEOKvq+Su5V0c9/lVZ7iEc38ewJKtfhyzZe51pWcgiKzYszW/YlbwV JZukefpN3ItcVt3kTi3ImwWDWEmuZx74EyWIblOPgwX7oNDo/2phXy3p68We6nxRk68Bh1dFJRaM eucpcIH+Rr0M9IfvZ5Mpe3vxkU1EVSG4Y1zHa/bqhLqo2MtU2lfA8AdtuXBGboFM02wtJJuJm1Up Mrkq8gaXVbDfARuMXg+Mt8DU7hpg56nMblss7D+A0XR96VyM2aedKL9jjR52opJaXTNRbYu8Ei2J X5MPv6pLSUvpKhzq5hPE0Z/p6gcJ1aA0gm9F5RsuF50a3aLLZMEeNGBEnkpZrq530mbzSP5hHP8b +atcjU2NARDW+BEdiUXcFqWkfNBWcBCq2+LpKtiZ71BZ6cuaqj2H07H6it5xnRb3VclUCib07kqz u0Xn8/YMO94+P2PLdLUpHkV5xoTMFt2XNf1XAA66YvNmqn0r0lJei1RaOz4SQYRNNzi1CI4FOzK2 Mp0Z+/T1HfYd1o36gCqeXGFZejig9Yed59793JJIm0V4sTmhRo5BmwNmvttqTi+F3Bfl+uB0YUlR bCq2Wa0Fm19OpnX6kCg0+L4e7UKkN3g+3QIDs3WNwToTclfmKuM48XAvepYZhXi9RbD9mLMenrBI Wym8pfdTgAEAMOYmmAplbmRzdHJlYW0NZW5kb2JqDTQwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN L1BhcmVudCA4NCAwIFIgDS9SZXNvdXJjZXMgNDEgMCBSIA0vQ29udGVudHMgNDIgMCBSIA0vUm90 YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3 NjEgXSANPj4gDWVuZG9iag00MSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFn ZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RUNCAxNDcgMCBSID4+IA0vWE9i amVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAw IFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAv SW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9J bTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9J bTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9J bTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0lt MjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0lt MjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0lt MzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0lt MzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0lt NDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00 NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00 OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01 MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01 NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02 MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1 IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5 IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTcz IDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3 IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgx IDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUg MTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkg MTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMg MjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcg MjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEw MSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9J bTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAg UiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4 OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTEx NiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9J bTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAg UiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3 OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEz MSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9J bTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAg UiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0 MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0 NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9J bTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAg UiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQx MyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2 MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9J bTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAg UiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4 MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3 NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9J bTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAg UiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5 NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5 MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9J bTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAg UiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5 NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIw NiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9J bTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAg UiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2 MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIy MSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9J bTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAg UiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMy NyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIz NiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9J bTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAg UiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMz MiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1 MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9J bTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAg UiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMx OSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2 NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAg UiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBS IC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIg DS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIg L0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIg L0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0Nz MjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMz IDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDEx MCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEy IDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1 IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTQyIDAgb2Jq DTw8IC9MZW5ndGggMzMyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65l Ow2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5 /V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/ hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9K XX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHb BQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL 5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrv UootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzh gMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSq WzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtP QvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHA dUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiM PNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3 NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4F qHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdv WQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2E PAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKam mZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2os BoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKK VxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1 hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxi iSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrk jg8TV9ziAzy4pYn17PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIM uwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zL AGOq2ketKt0y4srRRryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0Ck oIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFK pYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSg dgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/ P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rsh jGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSu qnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8A Jr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3X uxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VE H6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFT OsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09a ReIt+66LysizOjowdm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBO ARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNl U/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSa op/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ 2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9Qy Zf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5 EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/a B5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT 1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJ OlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMA INSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2 yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeD VTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm 7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6 b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJ L93p8ZFV2V+pP/2R1f/zXjY7CQNRFN7PU3TZLoql5U7bLQoLY2JiZmdcQFOTEiUEBo0PwCv4vJ6Z FqrO3EgTNSS0hJlzbvvNmR80L1x1lqrZnrjqLFU0L111lqrZF7vqLFVM/YmrzlI105qrzlJFut2s TliqlHiySixVGnuySixVSj1ZJZYqZZ6sEkuVJp6sEkuVyJNVYqmS9GSVWKqUe7JKLFUqPFklliqV nqwSS9U0dNQlSxUN3axKlqrMPFmVLFU0d7MqWaqSPFmVLFU0d7MqWaoy92RVslRl4cmqZKnK0pNV 2VGdKnGhVBqMA/Uo7DqGERC3FwglWGTxJ/aqdv+lns1Sj8+uWgtMvQnOYKpq74pAvYrwdrmqKx2o t029i9TKiE+O4uPSircX/MRwQ7LM5ZP4iHCQa7+tidW30u9Gr7fHYdAMB/x3JeK+lvY2tT3ms6Ba bBbL5qnRTVuP6xB3QvZ1YZaC3BDTtDeVpse9cV1ovY2wvw+bCGtxuIwgnod7jRoe1PUPRWTFgCKs MZ1qwMmre/D6pV7rMx55uFveu5HtcDOfBvoI/Bfd4m8Pl2QnO/OCm6V9of/ieTn7O0trU/YvNT86 notw0KgND4cul6fQI4q2GVKeEHZDsdkLpF9HV3hX6/12bbrOlEAVdi4vMMax0CajEqdIzDAoZFuL R/EhwADu52BtCmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDg0IDAgUiANL1Jlc291cmNlcyA0NCAwIFIgDS9Db250ZW50cyA0NSAwIFIgDS9Sb3RhdGUg OTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBd IA0+PiANZW5kb2JqDTQ0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAv SW1hZ2VJIF0gDS9Gb250IDw8IC9UVDIgMTQ1IDAgUiAvVFQ0IDE0NyAwIFIgL1RUOCA3NyAwIFIg Pj4gDS9YT2JqZWN0IDw8IC9JbTEgMjI0IDAgUiAvSW0yIDIyNSAwIFIgL0ltMyAyMjYgMCBSIC9J bTQgMjIzIDAgUiAvSW01IDIyMSAwIFIgDS9JbTYgMjIyIDAgUiAvSW03IDIyNyAwIFIgL0ltOCAy MzEgMCBSIC9JbTkgMjMyIDAgUiAvSW0xMCAyMzMgMCBSIA0vSW0xMSAyMzAgMCBSIC9JbTEyIDIy OCAwIFIgL0ltMTMgMjI5IDAgUiAvSW0xNCAyMjAgMCBSIC9JbTE1IDIxMSAwIFIgDS9JbTE2IDIx MiAwIFIgL0ltMTcgMjEwIDAgUiAvSW0xOCAyMDggMCBSIC9JbTE5IDIwOSAwIFIgL0ltMjAgMjEz IDAgUiANL0ltMjEgMjE3IDAgUiAvSW0yMiAyMTggMCBSIC9JbTIzIDIxOSAwIFIgL0ltMjQgMjE2 IDAgUiAvSW0yNSAyMTQgMCBSIA0vSW0yNiAyMTUgMCBSIC9JbTI3IDIzNCAwIFIgL0ltMjggMjUy IDAgUiAvSW0yOSAyNTMgMCBSIC9JbTMwIDI1NCAwIFIgDS9JbTMxIDI1MSAwIFIgL0ltMzIgMjQ5 IDAgUiAvSW0zMyAyNTAgMCBSIC9JbTM0IDIwNyAwIFIgL0ltMzUgMjU5IDAgUiANL0ltMzYgMjYw IDAgUiAvSW0zNyAyNjEgMCBSIC9JbTM4IDI1OCAwIFIgL0ltMzkgMjU2IDAgUiAvSW00MCAyNTcg MCBSIA0vSW00MSAyNDggMCBSIC9JbTQyIDIzOCAwIFIgL0ltNDMgMjM5IDAgUiAvSW00NCAyNDAg MCBSIC9JbTQ1IDIzNyAwIFIgDS9JbTQ2IDIzNSAwIFIgL0ltNDcgMjM2IDAgUiAvSW00OCAyNDEg MCBSIC9JbTQ5IDI0NSAwIFIgL0ltNTAgMjQ2IDAgUiANL0ltNTEgMjQ3IDAgUiAvSW01MiAyNDQg MCBSIC9JbTUzIDI0MiAwIFIgL0ltNTQgMjQzIDAgUiAvSW01NSAyNTUgMCBSIA0vSW01NiAxNjkg MCBSIC9JbTU3IDE3MCAwIFIgL0ltNTggMTcxIDAgUiAvSW01OSAxNjUgMCBSIC9JbTYwIDE2NiAw IFIgDS9JbTYxIDE2NyAwIFIgL0ltNjIgMTcyIDAgUiAvSW02MyAxNzYgMCBSIC9JbTY0IDE3NyAw IFIgL0ltNjUgMTc4IDAgUiANL0ltNjYgMTc1IDAgUiAvSW02NyAxNzMgMCBSIC9JbTY4IDE3NCAw IFIgL0ltNjkgMTY4IDAgUiAvSW03MCAxNTUgMCBSIA0vSW03MSAxNTYgMCBSIC9JbTcyIDE1NyAw IFIgL0ltNzMgMTU0IDAgUiAvSW03NCAxNTEgMCBSIC9JbTc1IDE1MiAwIFIgDS9JbTc2IDE1MyAw IFIgL0ltNzcgMTU4IDAgUiAvSW03OCAxNjIgMCBSIC9JbTc5IDE2MyAwIFIgL0ltODAgMTY0IDAg UiANL0ltODEgMTYxIDAgUiAvSW04MiAxNTkgMCBSIC9JbTgzIDE2MCAwIFIgL0ltODQgMTkwIDAg UiAvSW04NSAxOTcgMCBSIA0vSW04NiAxOTggMCBSIC9JbTg3IDE5OSAwIFIgL0ltODggMTk2IDAg UiAvSW04OSAxOTQgMCBSIC9JbTkwIDE5NSAwIFIgDS9JbTkxIDIwMCAwIFIgL0ltOTIgMjYyIDAg UiAvSW05MyAyMDUgMCBSIC9JbTk0IDIwNiAwIFIgL0ltOTUgMjAzIDAgUiANL0ltOTYgMjAxIDAg UiAvSW05NyAyMDIgMCBSIC9JbTk4IDE5MyAwIFIgL0ltOTkgMTgzIDAgUiAvSW0xMDAgMTg0IDAg UiANL0ltMTAxIDE4NSAwIFIgL0ltMTAyIDE4MiAwIFIgL0ltMTAzIDE4MCAwIFIgL0ltMTA0IDE4 MSAwIFIgL0ltMTA1IDQzNyAwIFIgDS9JbTEwNiAxODYgMCBSIC9JbTEwNyAxNzkgMCBSIC9JbTEw OCAxOTEgMCBSIC9JbTEwOSAxOTIgMCBSIC9JbTExMCAxODkgMCBSIA0vSW0xMTEgMTg3IDAgUiAv SW0xMTIgMTg4IDAgUiAvSW0xMTMgMjA0IDAgUiAvSW0xMTQgMzY2IDAgUiAvSW0xMTUgMzY3IDAg UiANL0ltMTE2IDM2OSAwIFIgL0ltMTE3IDM2OCAwIFIgL0ltMTE4IDM2NSAwIFIgL0ltMTE5IDM2 MSAwIFIgL0ltMTIwIDM2MiAwIFIgDS9JbTEyMSAzNjQgMCBSIC9JbTEyMiAzNjMgMCBSIC9JbTEy MyAzNzAgMCBSIC9JbTEyNCAzNzYgMCBSIC9JbTEyNSAzNzcgMCBSIA0vSW0xMjYgMzc5IDAgUiAv SW0xMjcgMzc4IDAgUiAvSW0xMjggMzc1IDAgUiAvSW0xMjkgMzcxIDAgUiAvSW0xMzAgMzcyIDAg UiANL0ltMTMxIDM3NCAwIFIgL0ltMTMyIDM3MyAwIFIgL0ltMTMzIDM2MCAwIFIgL0ltMTM0IDM0 NiAwIFIgL0ltMTM1IDM0NyAwIFIgDS9JbTEzNiAzNDkgMCBSIC9JbTEzNyAzNDggMCBSIC9JbTEz OCAzNDUgMCBSIC9JbTEzOSAzNDEgMCBSIC9JbTE0MCAzNDIgMCBSIA0vSW0xNDEgMzQ0IDAgUiAv SW0xNDIgMzQzIDAgUiAvSW0xNDMgMzgwIDAgUiAvSW0xNDQgMzU2IDAgUiAvSW0xNDUgMzU3IDAg UiANL0ltMTQ2IDM1OSAwIFIgL0ltMTQ3IDM1OCAwIFIgL0ltMTQ4IDM1NSAwIFIgL0ltMTQ5IDM1 MSAwIFIgL0ltMTUwIDM1MiAwIFIgDS9JbTE1MSAzNTQgMCBSIC9JbTE1MiAzNTMgMCBSIC9JbTE1 MyAzNTAgMCBSIC9JbTE1NCA0MTYgMCBSIC9JbTE1NSA0MDkgMCBSIA0vSW0xNTYgNDEyIDAgUiAv SW0xNTcgNDEzIDAgUiAvSW0xNTggNDE0IDAgUiAvSW0xNTkgNDExIDAgUiAvSW0xNjAgNDE1IDAg UiANL0ltMTYxIDQxMCAwIFIgL0ltMTYyIDQwOCAwIFIgL0ltMTYzIDQxNyAwIFIgL0ltMTY0IDM4 NiAwIFIgL0ltMTY1IDM4OCAwIFIgDS9JbTE2NiAzODcgMCBSIC9JbTE2NyAzODkgMCBSIC9JbTE2 OCAzOTIgMCBSIC9JbTE2OSAzOTEgMCBSIC9JbTE3MCAzOTAgMCBSIA0vSW0xNzEgNDA3IDAgUiAv SW0xNzIgMzgyIDAgUiAvSW0xNzMgMzgxIDAgUiAvSW0xNzQgMzgzIDAgUiAvSW0xNzUgMzg1IDAg UiANL0ltMTc2IDM4NCAwIFIgL0ltMTc3IDM5MyAwIFIgL0ltMTc4IDQwMiAwIFIgL0ltMTc5IDQw MSAwIFIgL0ltMTgwIDQwMyAwIFIgDS9JbTE4MSA0MDYgMCBSIC9JbTE4MiA0MDUgMCBSIC9JbTE4 MyA0MDQgMCBSIC9JbTE4NCA0MDAgMCBSIC9JbTE4NSAzOTUgMCBSIA0vSW0xODYgMzk0IDAgUiAv SW0xODcgMzk2IDAgUiAvSW0xODggMzk5IDAgUiAvSW0xODkgMzk4IDAgUiAvSW0xOTAgMzk3IDAg UiANL0ltMTkxIDI2NyAwIFIgL0ltMTkyIDI4NyAwIFIgL0ltMTkzIDI4OCAwIFIgL0ltMTk0IDI5 MCAwIFIgL0ltMTk1IDI4OSAwIFIgDS9JbTE5NiAyODYgMCBSIC9JbTE5NyAyODIgMCBSIC9JbTE5 OCAyODMgMCBSIC9JbTE5OSAyODUgMCBSIC9JbTIwMCAyODQgMCBSIA0vSW0yMDEgMjkxIDAgUiAv SW0yMDIgMjk3IDAgUiAvSW0yMDMgMjk4IDAgUiAvSW0yMDQgMzAwIDAgUiAvSW0yMDUgMjk5IDAg UiANL0ltMjA2IDI5NiAwIFIgL0ltMjA3IDI5MiAwIFIgL0ltMjA4IDI5MyAwIFIgL0ltMjA5IDI5 NSAwIFIgL0ltMjEwIDI5NCAwIFIgDS9JbTIxMSAyODEgMCBSIC9JbTIxMiAzNDAgMCBSIC9JbTIx MyAyNjggMCBSIC9JbTIxNCAyNzAgMCBSIC9JbTIxNSAyNjkgMCBSIA0vSW0yMTYgMjY2IDAgUiAv SW0yMTcgMjYzIDAgUiAvSW0yMTggMjY0IDAgUiAvSW0yMTkgMjY1IDAgUiAvSW0yMjAgMjcxIDAg UiANL0ltMjIxIDI3NyAwIFIgL0ltMjIyIDI3OCAwIFIgL0ltMjIzIDI4MCAwIFIgL0ltMjI0IDI3 OSAwIFIgL0ltMjI1IDI3NiAwIFIgDS9JbTIyNiAyNzIgMCBSIC9JbTIyNyAyNzMgMCBSIC9JbTIy OCAyNzUgMCBSIC9JbTIyOSAyNzQgMCBSIC9JbTIzMCAzMDEgMCBSIA0vSW0yMzEgMzI2IDAgUiAv SW0yMzIgMzI3IDAgUiAvSW0yMzMgMzI5IDAgUiAvSW0yMzQgMzI4IDAgUiAvSW0yMzUgMzI1IDAg UiANL0ltMjM2IDMyMSAwIFIgL0ltMjM3IDMyMiAwIFIgL0ltMjM4IDMyNCAwIFIgL0ltMjM5IDMy MyAwIFIgL0ltMjQwIDMzMCAwIFIgDS9JbTI0MSAzMzYgMCBSIC9JbTI0MiAzMzcgMCBSIC9JbTI0 MyAzMzkgMCBSIC9JbTI0NCAzMzggMCBSIC9JbTI0NSAzMzUgMCBSIA0vSW0yNDYgMzMxIDAgUiAv SW0yNDcgMzMyIDAgUiAvSW0yNDggMzM0IDAgUiAvSW0yNDkgMzMzIDAgUiAvSW0yNTAgMzIwIDAg UiANL0ltMjUxIDMwNiAwIFIgL0ltMjUyIDMwNyAwIFIgL0ltMjUzIDMwOSAwIFIgL0ltMjU0IDMw OCAwIFIgL0ltMjU1IDMwNSAwIFIgDS9JbTI1NiAzMDIgMCBSIC9JbTI1NyAzMDMgMCBSIC9JbTI1 OCAzMDQgMCBSIC9JbTI1OSAzMTAgMCBSIC9JbTI2MCAzMTYgMCBSIA0vSW0yNjEgMzE3IDAgUiAv SW0yNjIgMzE5IDAgUiAvSW0yNjMgMzE4IDAgUiAvSW0yNjQgMzE1IDAgUiAvSW0yNjUgMzExIDAg UiANL0ltMjY2IDMxMiAwIFIgL0ltMjY3IDMxNCAwIFIgL0ltMjY4IDMxMyAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSA0MjYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDExOSAwIFIgL0Nz OCAxMjAgMCBSIC9DczkgMTIyIDAgUiAvQ3MxMCAxMjEgMCBSIC9DczExIDExOCAwIFIgDS9DczEy IDExNSAwIFIgL0NzMTMgMTE2IDAgUiAvQ3MxNCAxMjMgMCBSIC9DczE1IDExNyAwIFIgL0NzMTYg MTMwIDAgUiANL0NzMTcgMTI5IDAgUiAvQ3MxOCAxMzIgMCBSIC9DczE5IDEzMSAwIFIgL0NzMjAg MTI0IDAgUiAvQ3MyMSAxMjggMCBSIA0vQ3MyMiAxMjUgMCBSIC9DczIzIDEyNyAwIFIgL0NzMjQg MTI2IDAgUiAvQ3MyNSAxMTEgMCBSIC9DczI2IDk4IDAgUiANL0NzMjcgOTcgMCBSIC9DczI4IDk5 IDAgUiAvQ3MyOSAxMDEgMCBSIC9DczMwIDEwMCAwIFIgL0NzMzEgOTYgMCBSIA0vQ3MzMiA5MiAw IFIgL0NzMzMgOTMgMCBSIC9DczM0IDk1IDAgUiAvQ3MzNSA5NCAwIFIgL0NzMzYgMTAyIDAgUiAN L0NzMzcgMTEwIDAgUiAvQ3MzOCAxMDkgMCBSIC9DczM5IDExNCAwIFIgL0NzNDAgMTEzIDAgUiAv Q3M0MSAxMTIgMCBSIA0vQ3M0MiAxMDggMCBSIC9DczQzIDEwNCAwIFIgL0NzNDQgMTAzIDAgUiAv Q3M0NSAxMDUgMCBSIC9DczQ2IDEwNyAwIFIgDS9DczQ3IDEwNiAwIFIgPj4gDT4+IA1lbmRvYmoN NDUgMCBvYmoNPDwgL0xlbmd0aCAzNjQ4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJjFfLrmU7DZzvr1g/cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+foz L99/LrT9+/n9X68vv/5Gy99+vri4WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW3 8v9/LOTS8r+F/PK75Y9/8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0 L1bIf+RS70pdfvEuRfmOFNjF1tqSW3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMG iPUAtHJc4dsFCPqKGMoAYa6IcEXOZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv +OhCbV04s0vlCm8TGvZ4ea+/40VEbwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZo nHgAKUSuqu9Sii0Pt6xcBAWJ8GFDhEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYv COa3AesFDOGAyDe5dCeL/SeQqnlnFGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMM WmkURh8mVKpbOEwgYsnVEskJzCFx6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfv NwSvGeeQ+09C8gKBN8QuPEpHVEX+jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIg DNUBmyUPEcB1SO9fYtgOWbM9vEPYJtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIz GGlSqRcEGIw80dUBMRTG8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WD twj36paYNPc1Q/c8IdhwY9WqDzhqrPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7b lViqPQA8LgWocw79DchdondZXZkjdUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16a NcwLgvS1929ZCSQavqXrshck6U1I99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a 24EwOc6wHYQ8AhS9ReWozWcYj89Q6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwn rOaAoD8spqaZl94cNz7CDSizjXADFE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pm XXMHRGknaiwGgUROeEMuh8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYV pcNu/jkhQopXEHTswKP3yyalNruCk1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5i qKwBjbGWwTWGyooT/BiCJl9xlsujx5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaK Bt6b1y1hzGKJK7/3mEUTY2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5 BMPxFs9FSuSODxNX3OIDPLilifXs8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASH BAQXCiMIUgy7Aw0vQadt+blyLgiznnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/ BAknH4CTnMsAY6raR60q3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3k grAH46yfQKSgg/oyLX7JNNVB3lbZJA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCS SPHN9xSSIUqliUBe0C33eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGS Uk2yWG4YlKB2Bs6pjBBBT+ykzV3O4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+B Rn5hjEqY378/ZD21EketExzab0zFNE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHI mhZCKzXuuyGMYPRe1L39AKBagn/3iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMX tc+TUZU2lK6qdoRoSm0cFOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJ u/6upu0hjwAmvRX8JI8eb2USoTWPIYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I +ppJn74gTde7FmVnEKK5Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs 3TignhijtUQfpGDmY5XzCGKklmZmeWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1E eABQLHrKQVM6wlEn+oLOknaEVUl5LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzh FTaRgPuXT1pF4i37rovKyLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GM VuiDTxPBsE4BFCFO6CfELGYZJhAcpE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7 zzjkBRpdY2VT/MQmLoyRzWzaOTFGNoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xU U9KT01wA9Jqin89uXeFumSUn2bGKKXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk9 62w13RFCR1DZrUB6K3mAqGJVCqGkVRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nH Mw0wRLBL1DJl/8Ag/zVNNbZjRAFJ561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyf NNBBg28Dg7kQqILGEys/MFYFDeexEQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOt Tmz8xJju39oHmAgp0Na/CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRve HKnwycSzhRPUFfswqd8dkPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXP XbxRBAo87Ak6VCQHDJoJ+wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXC EGOoJJgI8wAg1KitkynqS8wsUUTM/azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtc mKbTBobylDbLDYMCah6lraOnThRd3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuv LwBt4eK0x4NVMz839S1c5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C 8pTS6ArRSybt2E3u3J4dUK5KejIK70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6 PZDL/en8eDpvu6QJD4+nhzW7Njw+nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mN Urfd6fGRVQkv3enxkVXZX6k//ZHV/1NebbtNA0H03V+xj46ojW+zsV9pCxISAoEpD4iHXDaKq8Su bJcWqd/B93Jm14ndeldAIsVWPD47M2fO7gzM8zm6k1VuT+boTlZhXszRnaxyXzxHd7KKrT+aoztZ 5W1tju5kFeqeazVzskqRRavkZJVii1bJySolFq2Sk1VKLVolJ6uUWbRKTlaJLFolJ6skLVolJ6u0 tGiVnKxSbtEqOVmlwqJVcrLKhjN06WQVhnOtSierMrVoVTpZhflcq9LJqiSLVqWTVZjPtSqdrMql RavSyarMLVqVTlZlYdGqHFh9U3qvyzIRsSh3nj7HUAGBuQAowiGLh+hVdf9VHvmox7fb1B623ghD Z7nRd+ixygfP/7i+VZteXB5WXbcobxk8O4FDpEHCHsUoY9xgJpzChoQRzvxqeI2sQX8z0nRhPYbg 2ZUXPPeC7/BC2Yit6jZttVbiYd+I/arDH7uqVlvR75VotJcD6ot1gwGe08dXLPIfrpgsfO2UWAla V30n7los/Cj6RqhH3J/Tkp/SgjaMZ1dzQZbiDOShmw4jGnLDgRWjD6+Cv3yNj5p/jBXnLOUM4T8J fhwj4rSQQxhxGBf5EIaOQieUyTwTOcachTm8GW1jtjUrkPbvSejPfBkceBgexleNR/PqKX/dqRPC uG6BAj75OCbjiY2CuAjRbiUmZmxwpwV01v4tYdNKBRzLwFy41dTHXUwTGTD6GDlON3bmW9Xvh+IS PYK4ELumPXaohU2j08EjbJ5NS1eOGFJjHO8Oqj+VqKi2qu6rXaXa0AQ6IAToNZayOAeanDPyfaQt wKEZpv7N6nCvxOJH+Z6JXmY6TRRldH6bRicSgxEtAom5JIz9dwtYx/7nD5/OEjK+dRrR1FkKl05g 6QhmsGIRwBX0AKkfM1ji0yLIkiIPyX+7gIT8pr28/sI2yDP+QnCxfy2OzVYdxMtVL7SC6/vjWrUm KB5j0K8ysvb/asaOyexmVYtWsQaRU41iVvip2q5qapNgGS5Jc/88qAlN6RCVXAS05OPev1H1tmm7 l54a76bbKypLlzLGU+NyGs5oMGX9WfX3bc0eXZceJbrNXUZovYklBUWBHu6pWuXtvD8CDABA3cJ+ CmVuZHN0cmVhbQ1lbmRvYmoNNDYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg0IDAg UiANL1Jlc291cmNlcyA0NyAwIFIgDS9Db250ZW50cyA0OCAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRp YUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5k b2JqDTQ3IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJIF0g DS9Gb250IDw8IC9UVDIgMTQ1IDAgUiAvVFQ0IDE0NyAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEg MjI0IDAgUiAvSW0yIDIyNSAwIFIgL0ltMyAyMjYgMCBSIC9JbTQgMjIzIDAgUiAvSW01IDIyMSAw IFIgDS9JbTYgMjIyIDAgUiAvSW03IDIyNyAwIFIgL0ltOCAyMzEgMCBSIC9JbTkgMjMyIDAgUiAv SW0xMCAyMzMgMCBSIA0vSW0xMSAyMzAgMCBSIC9JbTEyIDIyOCAwIFIgL0ltMTMgMjI5IDAgUiAv SW0xNCAyMjAgMCBSIC9JbTE1IDIxMSAwIFIgDS9JbTE2IDIxMiAwIFIgL0ltMTcgMjEwIDAgUiAv SW0xOCAyMDggMCBSIC9JbTE5IDIwOSAwIFIgL0ltMjAgMjEzIDAgUiANL0ltMjEgMjE3IDAgUiAv SW0yMiAyMTggMCBSIC9JbTIzIDIxOSAwIFIgL0ltMjQgMjE2IDAgUiAvSW0yNSAyMTQgMCBSIA0v SW0yNiAyMTUgMCBSIC9JbTI3IDIzNCAwIFIgL0ltMjggMjUyIDAgUiAvSW0yOSAyNTMgMCBSIC9J bTMwIDI1NCAwIFIgDS9JbTMxIDI1MSAwIFIgL0ltMzIgMjQ5IDAgUiAvSW0zMyAyNTAgMCBSIC9J bTM0IDIwNyAwIFIgL0ltMzUgMjU5IDAgUiANL0ltMzYgMjYwIDAgUiAvSW0zNyAyNjEgMCBSIC9J bTM4IDI1OCAwIFIgL0ltMzkgMjU2IDAgUiAvSW00MCAyNTcgMCBSIA0vSW00MSAyNDggMCBSIC9J bTQyIDIzOCAwIFIgL0ltNDMgMjM5IDAgUiAvSW00NCAyNDAgMCBSIC9JbTQ1IDIzNyAwIFIgDS9J bTQ2IDIzNSAwIFIgL0ltNDcgMjM2IDAgUiAvSW00OCAyNDEgMCBSIC9JbTQ5IDI0NSAwIFIgL0lt NTAgMjQ2IDAgUiANL0ltNTEgMjQ3IDAgUiAvSW01MiAyNDQgMCBSIC9JbTUzIDI0MiAwIFIgL0lt NTQgMjQzIDAgUiAvSW01NSAyNTUgMCBSIA0vSW01NiAxNjkgMCBSIC9JbTU3IDE3MCAwIFIgL0lt NTggMTcxIDAgUiAvSW01OSAxNjUgMCBSIC9JbTYwIDE2NiAwIFIgDS9JbTYxIDE2NyAwIFIgL0lt NjIgMTcyIDAgUiAvSW02MyAxNzYgMCBSIC9JbTY0IDE3NyAwIFIgL0ltNjUgMTc4IDAgUiANL0lt NjYgMTc1IDAgUiAvSW02NyAxNzMgMCBSIC9JbTY4IDE3NCAwIFIgL0ltNjkgMTY4IDAgUiAvSW03 MCAxNTUgMCBSIA0vSW03MSAxNTYgMCBSIC9JbTcyIDE1NyAwIFIgL0ltNzMgMTU0IDAgUiAvSW03 NCAxNTEgMCBSIC9JbTc1IDE1MiAwIFIgDS9JbTc2IDE1MyAwIFIgL0ltNzcgMTU4IDAgUiAvSW03 OCAxNjIgMCBSIC9JbTc5IDE2MyAwIFIgL0ltODAgMTY0IDAgUiANL0ltODEgMTYxIDAgUiAvSW04 MiAxNTkgMCBSIC9JbTgzIDE2MCAwIFIgL0ltODQgMTkwIDAgUiAvSW04NSAxOTcgMCBSIA0vSW04 NiAxOTggMCBSIC9JbTg3IDE5OSAwIFIgL0ltODggMTk2IDAgUiAvSW04OSAxOTQgMCBSIC9JbTkw IDE5NSAwIFIgDS9JbTkxIDIwMCAwIFIgL0ltOTIgMjYyIDAgUiAvSW05MyAyMDUgMCBSIC9JbTk0 IDIwNiAwIFIgL0ltOTUgMjAzIDAgUiANL0ltOTYgMjAxIDAgUiAvSW05NyAyMDIgMCBSIC9JbTk4 IDE5MyAwIFIgL0ltOTkgMTgzIDAgUiAvSW0xMDAgMTg0IDAgUiANL0ltMTAxIDE4NSAwIFIgL0lt MTAyIDE4MiAwIFIgL0ltMTAzIDE4MCAwIFIgL0ltMTA0IDE4MSAwIFIgL0ltMTA1IDQzNyAwIFIg DS9JbTEwNiAxODYgMCBSIC9JbTEwNyAxNzkgMCBSIC9JbTEwOCAxOTEgMCBSIC9JbTEwOSAxOTIg MCBSIC9JbTExMCAxODkgMCBSIA0vSW0xMTEgMTg3IDAgUiAvSW0xMTIgMTg4IDAgUiAvSW0xMTMg MjA0IDAgUiAvSW0xMTQgMzY2IDAgUiAvSW0xMTUgMzY3IDAgUiANL0ltMTE2IDM2OSAwIFIgL0lt MTE3IDM2OCAwIFIgL0ltMTE4IDM2NSAwIFIgL0ltMTE5IDM2MSAwIFIgL0ltMTIwIDM2MiAwIFIg DS9JbTEyMSAzNjQgMCBSIC9JbTEyMiAzNjMgMCBSIC9JbTEyMyAzNzAgMCBSIC9JbTEyNCAzNzYg MCBSIC9JbTEyNSAzNzcgMCBSIA0vSW0xMjYgMzc5IDAgUiAvSW0xMjcgMzc4IDAgUiAvSW0xMjgg Mzc1IDAgUiAvSW0xMjkgMzcxIDAgUiAvSW0xMzAgMzcyIDAgUiANL0ltMTMxIDM3NCAwIFIgL0lt MTMyIDM3MyAwIFIgL0ltMTMzIDM2MCAwIFIgL0ltMTM0IDM0NiAwIFIgL0ltMTM1IDM0NyAwIFIg DS9JbTEzNiAzNDkgMCBSIC9JbTEzNyAzNDggMCBSIC9JbTEzOCAzNDUgMCBSIC9JbTEzOSAzNDEg MCBSIC9JbTE0MCAzNDIgMCBSIA0vSW0xNDEgMzQ0IDAgUiAvSW0xNDIgMzQzIDAgUiAvSW0xNDMg MzgwIDAgUiAvSW0xNDQgMzU2IDAgUiAvSW0xNDUgMzU3IDAgUiANL0ltMTQ2IDM1OSAwIFIgL0lt MTQ3IDM1OCAwIFIgL0ltMTQ4IDM1NSAwIFIgL0ltMTQ5IDM1MSAwIFIgL0ltMTUwIDM1MiAwIFIg DS9JbTE1MSAzNTQgMCBSIC9JbTE1MiAzNTMgMCBSIC9JbTE1MyAzNTAgMCBSIC9JbTE1NCA0MTYg MCBSIC9JbTE1NSA0MDkgMCBSIA0vSW0xNTYgNDEyIDAgUiAvSW0xNTcgNDEzIDAgUiAvSW0xNTgg NDE0IDAgUiAvSW0xNTkgNDExIDAgUiAvSW0xNjAgNDE1IDAgUiANL0ltMTYxIDQxMCAwIFIgL0lt MTYyIDQwOCAwIFIgL0ltMTYzIDQxNyAwIFIgL0ltMTY0IDM4NiAwIFIgL0ltMTY1IDM4OCAwIFIg DS9JbTE2NiAzODcgMCBSIC9JbTE2NyAzODkgMCBSIC9JbTE2OCAzOTIgMCBSIC9JbTE2OSAzOTEg MCBSIC9JbTE3MCAzOTAgMCBSIA0vSW0xNzEgNDA3IDAgUiAvSW0xNzIgMzgyIDAgUiAvSW0xNzMg MzgxIDAgUiAvSW0xNzQgMzgzIDAgUiAvSW0xNzUgMzg1IDAgUiANL0ltMTc2IDM4NCAwIFIgL0lt MTc3IDM5MyAwIFIgL0ltMTc4IDQwMiAwIFIgL0ltMTc5IDQwMSAwIFIgL0ltMTgwIDQwMyAwIFIg DS9JbTE4MSA0MDYgMCBSIC9JbTE4MiA0MDUgMCBSIC9JbTE4MyA0MDQgMCBSIC9JbTE4NCA0MDAg MCBSIC9JbTE4NSAzOTUgMCBSIA0vSW0xODYgMzk0IDAgUiAvSW0xODcgMzk2IDAgUiAvSW0xODgg Mzk5IDAgUiAvSW0xODkgMzk4IDAgUiAvSW0xOTAgMzk3IDAgUiANL0ltMTkxIDI2NyAwIFIgL0lt MTkyIDI4NyAwIFIgL0ltMTkzIDI4OCAwIFIgL0ltMTk0IDI5MCAwIFIgL0ltMTk1IDI4OSAwIFIg DS9JbTE5NiAyODYgMCBSIC9JbTE5NyAyODIgMCBSIC9JbTE5OCAyODMgMCBSIC9JbTE5OSAyODUg MCBSIC9JbTIwMCAyODQgMCBSIA0vSW0yMDEgMjkxIDAgUiAvSW0yMDIgMjk3IDAgUiAvSW0yMDMg Mjk4IDAgUiAvSW0yMDQgMzAwIDAgUiAvSW0yMDUgMjk5IDAgUiANL0ltMjA2IDI5NiAwIFIgL0lt MjA3IDI5MiAwIFIgL0ltMjA4IDI5MyAwIFIgL0ltMjA5IDI5NSAwIFIgL0ltMjEwIDI5NCAwIFIg DS9JbTIxMSAyODEgMCBSIC9JbTIxMiAzNDAgMCBSIC9JbTIxMyAyNjggMCBSIC9JbTIxNCAyNzAg MCBSIC9JbTIxNSAyNjkgMCBSIA0vSW0yMTYgMjY2IDAgUiAvSW0yMTcgMjYzIDAgUiAvSW0yMTgg MjY0IDAgUiAvSW0yMTkgMjY1IDAgUiAvSW0yMjAgMjcxIDAgUiANL0ltMjIxIDI3NyAwIFIgL0lt MjIyIDI3OCAwIFIgL0ltMjIzIDI4MCAwIFIgL0ltMjI0IDI3OSAwIFIgL0ltMjI1IDI3NiAwIFIg DS9JbTIyNiAyNzIgMCBSIC9JbTIyNyAyNzMgMCBSIC9JbTIyOCAyNzUgMCBSIC9JbTIyOSAyNzQg MCBSIC9JbTIzMCAzMDEgMCBSIA0vSW0yMzEgMzI2IDAgUiAvSW0yMzIgMzI3IDAgUiAvSW0yMzMg MzI5IDAgUiAvSW0yMzQgMzI4IDAgUiAvSW0yMzUgMzI1IDAgUiANL0ltMjM2IDMyMSAwIFIgL0lt MjM3IDMyMiAwIFIgL0ltMjM4IDMyNCAwIFIgL0ltMjM5IDMyMyAwIFIgL0ltMjQwIDMzMCAwIFIg DS9JbTI0MSAzMzYgMCBSIC9JbTI0MiAzMzcgMCBSIC9JbTI0MyAzMzkgMCBSIC9JbTI0NCAzMzgg MCBSIC9JbTI0NSAzMzUgMCBSIA0vSW0yNDYgMzMxIDAgUiAvSW0yNDcgMzMyIDAgUiAvSW0yNDgg MzM0IDAgUiAvSW0yNDkgMzMzIDAgUiAvSW0yNTAgMzIwIDAgUiANL0ltMjUxIDMwNiAwIFIgL0lt MjUyIDMwNyAwIFIgL0ltMjUzIDMwOSAwIFIgL0ltMjU0IDMwOCAwIFIgL0ltMjU1IDMwNSAwIFIg DS9JbTI1NiAzMDIgMCBSIC9JbTI1NyAzMDMgMCBSIC9JbTI1OCAzMDQgMCBSIC9JbTI1OSAzMTAg MCBSIC9JbTI2MCAzMTYgMCBSIA0vSW0yNjEgMzE3IDAgUiAvSW0yNjIgMzE5IDAgUiAvSW0yNjMg MzE4IDAgUiAvSW0yNjQgMzE1IDAgUiAvSW0yNjUgMzExIDAgUiANL0ltMjY2IDMxMiAwIFIgL0lt MjY3IDMxNCAwIFIgL0ltMjY4IDMxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MjYgMCBS ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDExOSAwIFIgL0NzOCAxMjAgMCBSIC9DczkgMTIyIDAg UiAvQ3MxMCAxMjEgMCBSIC9DczExIDExOCAwIFIgDS9DczEyIDExNSAwIFIgL0NzMTMgMTE2IDAg UiAvQ3MxNCAxMjMgMCBSIC9DczE1IDExNyAwIFIgL0NzMTYgMTMwIDAgUiANL0NzMTcgMTI5IDAg UiAvQ3MxOCAxMzIgMCBSIC9DczE5IDEzMSAwIFIgL0NzMjAgMTI0IDAgUiAvQ3MyMSAxMjggMCBS IA0vQ3MyMiAxMjUgMCBSIC9DczIzIDEyNyAwIFIgL0NzMjQgMTI2IDAgUiAvQ3MyNSAxMTEgMCBS IC9DczI2IDk4IDAgUiANL0NzMjcgOTcgMCBSIC9DczI4IDk5IDAgUiAvQ3MyOSAxMDEgMCBSIC9D czMwIDEwMCAwIFIgL0NzMzEgOTYgMCBSIA0vQ3MzMiA5MiAwIFIgL0NzMzMgOTMgMCBSIC9DczM0 IDk1IDAgUiAvQ3MzNSA5NCAwIFIgL0NzMzYgMTAyIDAgUiANL0NzMzcgMTEwIDAgUiAvQ3MzOCAx MDkgMCBSIC9DczM5IDExNCAwIFIgL0NzNDAgMTEzIDAgUiAvQ3M0MSAxMTIgMCBSIA0vQ3M0MiAx MDggMCBSIC9DczQzIDEwNCAwIFIgL0NzNDQgMTAzIDAgUiAvQ3M0NSAxMDUgMCBSIC9DczQ2IDEw NyAwIFIgDS9DczQ3IDEwNiAwIFIgPj4gDT4+IA1lbmRvYmoNNDggMCBvYmoNPDwgL0xlbmd0aCAz NDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/cNOx8x43 EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5Gy99+vri4 WJdSyXlaUvTLL4X98t+/vP76+rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/8sufX7T8 fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmOFNjF1tqS W3WJfFq+/3h9+c0PWn7179cftnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoAYa6IcEXO ZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4ea+/40VE bwHwXg0gF33ovyhGxzdrxBMSgmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xcBAWJ8GFD hEkvPGUYLwepd+T3N8TgqroBBNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL/SeQqnln FGMW6fQQYTEpE2HNYuASRhBgkWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnVEskJzCFx 6QFAI+dJtW+AlURSrygTEg8AUjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8QuPEpHVEX+ jgTLWnqb05hdHva94Lgm7YdSQakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgOWbM9vEPY JtXzC9R33O3NQAzf9clzz3iZiJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG8AkEOIwz mzohpmIV7dmlGka3UNFtLeaJ5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8IdhwY9WqDzhq rPmw00xsUL04aByArCeT5J9rd4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWocw79DchdondZXZkj dUN8rNo9HGs2gVflQroNFEc0mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXrshck6U1I 99nqyugOpDDrgc+7lj0PMAGekgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWozWcYj89Q 6lq3NyioE0JR3ndDMkCw354QSbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7CDSizjXAD FE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMuh8z9XU5l 1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3yyalNruC k1wrow+TH8r9lurhw+rokgjqqqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiCJl9xlsuj x5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUTY2yuWF9s sElSJjbxlnJTvdg/d0DQTDSQVSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OIDPLilifXs 8cAwNe3rnn33XsNxeZcfJFjnRykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt+blyLgiz nnYSDFTDeJhyycM223yjASZ43TPIe20bw4eImety8+qzihs/BAknH4CTnMsAY6raR60q3TLiytFG vJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7JNNVB3lbZ JA1q7zJt+ST/XMEXxro02DTO4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33eJNWgk2i xlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBBT+ykzV3O 4sElHdUNrgl5iIERjJh0qrJsJgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ZD21EketExzab0zF NE+m9gsTg0v6HmhZHOMoBagYYrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39AKBagn/3 iuILGC/XtwhRlyY+0KO8jvhncT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0cFOJEUwcC FRVAuTCgsCvpMKGkn5HBR3EMujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8eb2USoTWP IYwWHOmDtxvbiqzFVXiftQzGyCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5Nuh0sUx8 68KgyGKelPCBmXhX5ysXBAf0CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQfpGDmY5XzCGKklmZm eWEgBdMucUKMm6X4QQZQa1rQepkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLOknaEVUl5 LscdgBLJ4W08br3p0VaP8ObywwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovKyLM6OjB2 bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfELGYZJhAc pE6I6VoZB+eU8ggDwmkqz+IxWItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyRzWzaOTFG NoWezeKEoGp0r5f5qI4hqJoSPvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFumSUn2bGK KXniGhuiI79MiuxAIPWlggPm1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mAqGJVCqGk VRyHXAFRy1HDXt+iOOwGogtTsSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVNNbZjRAFJ 561+8J6JBmSb8yUPMJHALhr22RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/MFYFDeex EQCbX4NtaniFEUBLutDMhHVhUAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/CoPqCBL1 XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8dkPXAyzPP 2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ+wq1h0Vx YczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg1KitkynqS8wsUUTM /azONNPLhYEphwmnNey/B8ZQwwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6lraOnThRd 3ToVg1Uwz6S5AmySGfcBG23Sq61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c5ho4fjY6 VimyTbryF33Fc/M4EHKBS2o0eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4dUK5KejIK 70tczgIRnxLbyOjXuvKOcHnMeoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+nhzW7Njw+ nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZX6k//ZHV /1NeBbtpA0H07q/YI5YCtcGz2NeWtFIlpCixegk9OGYhTsG2dp1G/Ei/tzNrB4fuTpsKCQMe5r2Z t289i+Gpm51VlcYTNzurKoZnbnZWVZqL3eysqrj1R252VlXa1tzsrKrobterCasqRB6vAqsqxB6v AqsqzD1eBVZVWHi8CqyqkHi8CqyqAB6vAqsqSI9XgVUVlh6vAqsqpB6vAqsqZB6vAqsqBTrZJasq BrpelayqcuHxqmRVxXDXq5JVVYLHq5JVFcNdr0pWVbn0eFWyqsrU41XJqiozj1floOrHPPiQ53MR i3wX2IcqnaP6CyaKJIkQ46xq56/8SI96fJmyDpBOFGFYXuKP+Usw+XK7vhErtatqtRWfr8Wnoi0e qkPVVcqE+RMBJa9AcUZLbdpf8OtSksvo8gZoBsTCvhNgRFCTX5RqZIFnQloVeG8VWEJLirLccMsh Wsjk7rltG90hLcvxm9KmamoxZPoDZjqktP2jHKseuS/yX/DzMzw+/vEP95f4zcOTKjtRHgpjlBEb uht+z78GMc6NiW06ZupbG59TUVGIfWy26iBequ5RVJ0RP/syrvBDvW20uSJq09dESH8e4Yh1SV91 5SZ8R+GL1Bb+t3J7ZslI8tzuG6x1VP/0brT/aPMIi8P9ALtWx0afxF1blKpvhYtwKRHuGFaizWRd nET5WNR7JYqybPS2CpNZOqn3omtoLQ+tb/QP0epmr5Uxm9AK99Y+uJAtXeuXDKf6DA8D6eKMDGOB t6p71jXRvM4D7IndG1M8E+KDK5pleCpDx+Lq0yrYBb8FGAAiCkjeCmVuZHN0cmVhbQ1lbmRvYmoN NDkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg0IDAgUiANL1Jlc291cmNlcyA1MCAw IFIgDS9Db250ZW50cyA1MSAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQy IF0gDS9Dcm9wQm94IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5kb2JqDTUwIDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJIF0gDS9Gb250IDw8IC9UVDIgMTQ1 IDAgUiAvVFQ0IDE0NyAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgMjI0IDAgUiAvSW0yIDIyNSAw IFIgL0ltMyAyMjYgMCBSIC9JbTQgMjIzIDAgUiAvSW01IDIyMSAwIFIgDS9JbTYgMjIyIDAgUiAv SW03IDIyNyAwIFIgL0ltOCAyMzEgMCBSIC9JbTkgMjMyIDAgUiAvSW0xMCAyMzMgMCBSIA0vSW0x MSAyMzAgMCBSIC9JbTEyIDIyOCAwIFIgL0ltMTMgMjI5IDAgUiAvSW0xNCAyMjAgMCBSIC9JbTE1 IDIxMSAwIFIgDS9JbTE2IDIxMiAwIFIgL0ltMTcgMjEwIDAgUiAvSW0xOCAyMDggMCBSIC9JbTE5 IDIwOSAwIFIgL0ltMjAgMjEzIDAgUiANL0ltMjEgMjE3IDAgUiAvSW0yMiAyMTggMCBSIC9JbTIz IDIxOSAwIFIgL0ltMjQgMjE2IDAgUiAvSW0yNSAyMTQgMCBSIA0vSW0yNiAyMTUgMCBSIC9JbTI3 IDIzNCAwIFIgL0ltMjggMjUyIDAgUiAvSW0yOSAyNTMgMCBSIC9JbTMwIDI1NCAwIFIgDS9JbTMx IDI1MSAwIFIgL0ltMzIgMjQ5IDAgUiAvSW0zMyAyNTAgMCBSIC9JbTM0IDIwNyAwIFIgL0ltMzUg MjU5IDAgUiANL0ltMzYgMjYwIDAgUiAvSW0zNyAyNjEgMCBSIC9JbTM4IDI1OCAwIFIgL0ltMzkg MjU2IDAgUiAvSW00MCAyNTcgMCBSIA0vSW00MSAyNDggMCBSIC9JbTQyIDIzOCAwIFIgL0ltNDMg MjM5IDAgUiAvSW00NCAyNDAgMCBSIC9JbTQ1IDIzNyAwIFIgDS9JbTQ2IDIzNSAwIFIgL0ltNDcg MjM2IDAgUiAvSW00OCAyNDEgMCBSIC9JbTQ5IDI0NSAwIFIgL0ltNTAgMjQ2IDAgUiANL0ltNTEg MjQ3IDAgUiAvSW01MiAyNDQgMCBSIC9JbTUzIDI0MiAwIFIgL0ltNTQgMjQzIDAgUiAvSW01NSAy NTUgMCBSIA0vSW01NiAxNjkgMCBSIC9JbTU3IDE3MCAwIFIgL0ltNTggMTcxIDAgUiAvSW01OSAx NjUgMCBSIC9JbTYwIDE2NiAwIFIgDS9JbTYxIDE2NyAwIFIgL0ltNjIgMTcyIDAgUiAvSW02MyAx NzYgMCBSIC9JbTY0IDE3NyAwIFIgL0ltNjUgMTc4IDAgUiANL0ltNjYgMTc1IDAgUiAvSW02NyAx NzMgMCBSIC9JbTY4IDE3NCAwIFIgL0ltNjkgMTY4IDAgUiAvSW03MCAxNTUgMCBSIA0vSW03MSAx NTYgMCBSIC9JbTcyIDE1NyAwIFIgL0ltNzMgMTU0IDAgUiAvSW03NCAxNTEgMCBSIC9JbTc1IDE1 MiAwIFIgDS9JbTc2IDE1MyAwIFIgL0ltNzcgMTU4IDAgUiAvSW03OCAxNjIgMCBSIC9JbTc5IDE2 MyAwIFIgL0ltODAgMTY0IDAgUiANL0ltODEgMTYxIDAgUiAvSW04MiAxNTkgMCBSIC9JbTgzIDE2 MCAwIFIgL0ltODQgMTkwIDAgUiAvSW04NSAxOTcgMCBSIA0vSW04NiAxOTggMCBSIC9JbTg3IDE5 OSAwIFIgL0ltODggMTk2IDAgUiAvSW04OSAxOTQgMCBSIC9JbTkwIDE5NSAwIFIgDS9JbTkxIDIw MCAwIFIgL0ltOTIgMjYyIDAgUiAvSW05MyAyMDUgMCBSIC9JbTk0IDIwNiAwIFIgL0ltOTUgMjAz IDAgUiANL0ltOTYgMjAxIDAgUiAvSW05NyAyMDIgMCBSIC9JbTk4IDE5MyAwIFIgL0ltOTkgMTgz IDAgUiAvSW0xMDAgMTg0IDAgUiANL0ltMTAxIDE4NSAwIFIgL0ltMTAyIDE4MiAwIFIgL0ltMTAz IDE4MCAwIFIgL0ltMTA0IDE4MSAwIFIgL0ltMTA1IDQzNyAwIFIgDS9JbTEwNiAxODYgMCBSIC9J bTEwNyAxNzkgMCBSIC9JbTEwOCAxOTEgMCBSIC9JbTEwOSAxOTIgMCBSIC9JbTExMCAxODkgMCBS IA0vSW0xMTEgMTg3IDAgUiAvSW0xMTIgMTg4IDAgUiAvSW0xMTMgMjA0IDAgUiAvSW0xMTQgMzY2 IDAgUiAvSW0xMTUgMzY3IDAgUiANL0ltMTE2IDM2OSAwIFIgL0ltMTE3IDM2OCAwIFIgL0ltMTE4 IDM2NSAwIFIgL0ltMTE5IDM2MSAwIFIgL0ltMTIwIDM2MiAwIFIgDS9JbTEyMSAzNjQgMCBSIC9J bTEyMiAzNjMgMCBSIC9JbTEyMyAzNzAgMCBSIC9JbTEyNCAzNzYgMCBSIC9JbTEyNSAzNzcgMCBS IA0vSW0xMjYgMzc5IDAgUiAvSW0xMjcgMzc4IDAgUiAvSW0xMjggMzc1IDAgUiAvSW0xMjkgMzcx IDAgUiAvSW0xMzAgMzcyIDAgUiANL0ltMTMxIDM3NCAwIFIgL0ltMTMyIDM3MyAwIFIgL0ltMTMz IDM2MCAwIFIgL0ltMTM0IDM0NiAwIFIgL0ltMTM1IDM0NyAwIFIgDS9JbTEzNiAzNDkgMCBSIC9J bTEzNyAzNDggMCBSIC9JbTEzOCAzNDUgMCBSIC9JbTEzOSAzNDEgMCBSIC9JbTE0MCAzNDIgMCBS IA0vSW0xNDEgMzQ0IDAgUiAvSW0xNDIgMzQzIDAgUiAvSW0xNDMgMzgwIDAgUiAvSW0xNDQgMzU2 IDAgUiAvSW0xNDUgMzU3IDAgUiANL0ltMTQ2IDM1OSAwIFIgL0ltMTQ3IDM1OCAwIFIgL0ltMTQ4 IDM1NSAwIFIgL0ltMTQ5IDM1MSAwIFIgL0ltMTUwIDM1MiAwIFIgDS9JbTE1MSAzNTQgMCBSIC9J bTE1MiAzNTMgMCBSIC9JbTE1MyAzNTAgMCBSIC9JbTE1NCA0MTYgMCBSIC9JbTE1NSA0MDkgMCBS IA0vSW0xNTYgNDEyIDAgUiAvSW0xNTcgNDEzIDAgUiAvSW0xNTggNDE0IDAgUiAvSW0xNTkgNDEx IDAgUiAvSW0xNjAgNDE1IDAgUiANL0ltMTYxIDQxMCAwIFIgL0ltMTYyIDQwOCAwIFIgL0ltMTYz IDQxNyAwIFIgL0ltMTY0IDM4NiAwIFIgL0ltMTY1IDM4OCAwIFIgDS9JbTE2NiAzODcgMCBSIC9J bTE2NyAzODkgMCBSIC9JbTE2OCAzOTIgMCBSIC9JbTE2OSAzOTEgMCBSIC9JbTE3MCAzOTAgMCBS IA0vSW0xNzEgNDA3IDAgUiAvSW0xNzIgMzgyIDAgUiAvSW0xNzMgMzgxIDAgUiAvSW0xNzQgMzgz IDAgUiAvSW0xNzUgMzg1IDAgUiANL0ltMTc2IDM4NCAwIFIgL0ltMTc3IDM5MyAwIFIgL0ltMTc4 IDQwMiAwIFIgL0ltMTc5IDQwMSAwIFIgL0ltMTgwIDQwMyAwIFIgDS9JbTE4MSA0MDYgMCBSIC9J bTE4MiA0MDUgMCBSIC9JbTE4MyA0MDQgMCBSIC9JbTE4NCA0MDAgMCBSIC9JbTE4NSAzOTUgMCBS IA0vSW0xODYgMzk0IDAgUiAvSW0xODcgMzk2IDAgUiAvSW0xODggMzk5IDAgUiAvSW0xODkgMzk4 IDAgUiAvSW0xOTAgMzk3IDAgUiANL0ltMTkxIDI2NyAwIFIgL0ltMTkyIDI4NyAwIFIgL0ltMTkz IDI4OCAwIFIgL0ltMTk0IDI5MCAwIFIgL0ltMTk1IDI4OSAwIFIgDS9JbTE5NiAyODYgMCBSIC9J bTE5NyAyODIgMCBSIC9JbTE5OCAyODMgMCBSIC9JbTE5OSAyODUgMCBSIC9JbTIwMCAyODQgMCBS IA0vSW0yMDEgMjkxIDAgUiAvSW0yMDIgMjk3IDAgUiAvSW0yMDMgMjk4IDAgUiAvSW0yMDQgMzAw IDAgUiAvSW0yMDUgMjk5IDAgUiANL0ltMjA2IDI5NiAwIFIgL0ltMjA3IDI5MiAwIFIgL0ltMjA4 IDI5MyAwIFIgL0ltMjA5IDI5NSAwIFIgL0ltMjEwIDI5NCAwIFIgDS9JbTIxMSAyODEgMCBSIC9J bTIxMiAzNDAgMCBSIC9JbTIxMyAyNjggMCBSIC9JbTIxNCAyNzAgMCBSIC9JbTIxNSAyNjkgMCBS IA0vSW0yMTYgMjY2IDAgUiAvSW0yMTcgMjYzIDAgUiAvSW0yMTggMjY0IDAgUiAvSW0yMTkgMjY1 IDAgUiAvSW0yMjAgMjcxIDAgUiANL0ltMjIxIDI3NyAwIFIgL0ltMjIyIDI3OCAwIFIgL0ltMjIz IDI4MCAwIFIgL0ltMjI0IDI3OSAwIFIgL0ltMjI1IDI3NiAwIFIgDS9JbTIyNiAyNzIgMCBSIC9J bTIyNyAyNzMgMCBSIC9JbTIyOCAyNzUgMCBSIC9JbTIyOSAyNzQgMCBSIC9JbTIzMCAzMDEgMCBS IA0vSW0yMzEgMzI2IDAgUiAvSW0yMzIgMzI3IDAgUiAvSW0yMzMgMzI5IDAgUiAvSW0yMzQgMzI4 IDAgUiAvSW0yMzUgMzI1IDAgUiANL0ltMjM2IDMyMSAwIFIgL0ltMjM3IDMyMiAwIFIgL0ltMjM4 IDMyNCAwIFIgL0ltMjM5IDMyMyAwIFIgL0ltMjQwIDMzMCAwIFIgDS9JbTI0MSAzMzYgMCBSIC9J bTI0MiAzMzcgMCBSIC9JbTI0MyAzMzkgMCBSIC9JbTI0NCAzMzggMCBSIC9JbTI0NSAzMzUgMCBS IA0vSW0yNDYgMzMxIDAgUiAvSW0yNDcgMzMyIDAgUiAvSW0yNDggMzM0IDAgUiAvSW0yNDkgMzMz IDAgUiAvSW0yNTAgMzIwIDAgUiANL0ltMjUxIDMwNiAwIFIgL0ltMjUyIDMwNyAwIFIgL0ltMjUz IDMwOSAwIFIgL0ltMjU0IDMwOCAwIFIgL0ltMjU1IDMwNSAwIFIgDS9JbTI1NiAzMDIgMCBSIC9J bTI1NyAzMDMgMCBSIC9JbTI1OCAzMDQgMCBSIC9JbTI1OSAzMTAgMCBSIC9JbTI2MCAzMTYgMCBS IA0vSW0yNjEgMzE3IDAgUiAvSW0yNjIgMzE5IDAgUiAvSW0yNjMgMzE4IDAgUiAvSW0yNjQgMzE1 IDAgUiAvSW0yNjUgMzExIDAgUiANL0ltMjY2IDMxMiAwIFIgL0ltMjY3IDMxNCAwIFIgL0ltMjY4 IDMxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MjYgMCBSID4+IA0vQ29sb3JTcGFjZSA8 PCAvQ3M2IDExOSAwIFIgL0NzOCAxMjAgMCBSIC9DczkgMTIyIDAgUiAvQ3MxMCAxMjEgMCBSIC9D czExIDExOCAwIFIgDS9DczEyIDExNSAwIFIgL0NzMTMgMTE2IDAgUiAvQ3MxNCAxMjMgMCBSIC9D czE1IDExNyAwIFIgL0NzMTYgMTMwIDAgUiANL0NzMTcgMTI5IDAgUiAvQ3MxOCAxMzIgMCBSIC9D czE5IDEzMSAwIFIgL0NzMjAgMTI0IDAgUiAvQ3MyMSAxMjggMCBSIA0vQ3MyMiAxMjUgMCBSIC9D czIzIDEyNyAwIFIgL0NzMjQgMTI2IDAgUiAvQ3MyNSAxMTEgMCBSIC9DczI2IDk4IDAgUiANL0Nz MjcgOTcgMCBSIC9DczI4IDk5IDAgUiAvQ3MyOSAxMDEgMCBSIC9DczMwIDEwMCAwIFIgL0NzMzEg OTYgMCBSIA0vQ3MzMiA5MiAwIFIgL0NzMzMgOTMgMCBSIC9DczM0IDk1IDAgUiAvQ3MzNSA5NCAw IFIgL0NzMzYgMTAyIDAgUiANL0NzMzcgMTEwIDAgUiAvQ3MzOCAxMDkgMCBSIC9DczM5IDExNCAw IFIgL0NzNDAgMTEzIDAgUiAvQ3M0MSAxMTIgMCBSIA0vQ3M0MiAxMDggMCBSIC9DczQzIDEwNCAw IFIgL0NzNDQgMTAzIDAgUiAvQ3M0NSAxMDUgMCBSIC9DczQ2IDEwNyAwIFIgDS9DczQ3IDEwNiAw IFIgPj4gDT4+IA1lbmRvYmoNNTEgMCBvYmoNPDwgL0xlbmd0aCAzNDM1IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5v l5OVvdWT0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5Gy99+vri4WJdSyXlaUvTLL4X98t+/vP76 +rKCvn4TgHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/ vr69jrNc9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmOFNjF1tqSW3WJfFq+/3h9+c0PWn7179cf tnh21GLqEYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoAYa6IcEXOZYAI8psbkd5+VJEf6g3I+qNq paLeHVxieURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4ea+/40VEbwHwXg0gF33ovyhGxzdrxBMS gmu7loILaURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xcBAWJ8GFDhEkvPGUYLwepd+T3N8TgqroB BNVSyoqP6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL/SeQqnlnFGMW6fQQYTEpE2HNYuASRhBg kWmi4BPCaG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnVEskJzCFx6QFAI+dJtW+AlURSrygTEg8A UjjT1g4wBCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8QuPEpHVEX+jgTLWnqb05hdHva94Lgm7YdS Qakv2BA0z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgOWbM9vEPYJtXzC9R33O3NQAzf9clzz3iZ iJqKb7q4h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ 5Z4QFldMQ8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8IdhwY9WqDzhqrPmw00xsUL04aByArCeT5J9r d4s3tNNsXjoAQHqaWdAOeC7blViqPQA8LgWocw79DchdondZXZkjdUN8rNo9HGs2gVflQroNFEc0 mEKzvsE0/QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXrshck6U1I99nqyugOpDDrgc+7lj0PMAGe kgkwObFWVpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWozWcYj89Q6lq3NyioE0JR3ndDMkCw354Q SbBynlwmRXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7CDSizjXADFE/6htz0DYm5jwf6Cr2Lx9QW BuXm1H8QJrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMuh8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ /5wQcQa12mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3yyalNruCk1wrow+TH8r9lurhw+rokgjq qqDGip1KWlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiCJl9xlsujx5j9q2bNSxi+31BZy7Njn4jA zqskQ1c0I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUTY2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQ VSyl2ngkmz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OIDPLilifXs8cAwNe3rnn33XsNxeZcfJFjn RykoemlG/RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt+blyLgiznnYSDFTDeJhyycM223yjASZ4 3TPIe20bw4eImety8+qzihs/BAknH4CTnMsAY6raR60q3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2D gHxZOZ4L5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7JNNVB3lbZJA1q7zJt+ST/XMEXxro02DTO 4lFI6egk3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QO kBGJb0UFLMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBBT+ykzV3O4sElHdUNrgl5iIERjJh0qrJs JgOMVAzdCkn5sSwuACqEcV+BRn5hjEqY378/ZD21EketExzab0zFNE+m9gsTg0v6HmhZHOMoBagY YrBGnDWiHFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39AKBagn/3iuILGC/XtwhRlyY+0KO8jvhn cT08G6WVYOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0cFOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EM ujAoqoCrEHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8eb2USoTWPIYwWHOmDtxvbiqzFVXiftQzG yCsGzYtvZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0 CDpLNaQRxuQZpYat68QYqSVs3TignhijtUQfpGDmY5XzCGKklmZmeWEgBdMucUKMm6X4QQZQa1rQ epkN63xlVllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLOknaEVUl5LscdgBLJ4W08br3p0VaP8Oby wwsecmqEwRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovKyLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAj eTYGnxijkjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfELGYZJhAcpE6I6VoZB+eU8ggDwmkqz+Ix WItR5HLoJuhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyRzWzaOTFGNoWezeKEoGp0r5f5qI4hqJoS Pvgyrq6qRJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFumSUn2bGKKXniGhuiI79MiuxAIPWlggPm 1H1VR/xsxtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mAqGJVCqGkVRyHXAFRy1HDXt+iOOwGogtT sSXNNrUDY3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVNNbZjRAFJ561+8J6JBmSb8yUPMJHALhr2 2RZHuY7FRf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/MFYFDeexEQCbX4NtaniFEUBLutDMhHVh UAAtP5vlCWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiD XMxKtAJWrajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8dkPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4 s3L3XNQF+/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ+wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+ iD7ACIdJY/yjKV4IfA3B2NXCEGOoJJgI8wAg1KitkynqS8wsUUTM/azONNPLhYEphwmnNey/B8ZQ wwSrh9klT4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6lraOnThRd3ToVg1Uwz6S5AmySGfcBG23S q61LljFsbxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0 eRtvZga9+cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4dUK5KejIK70tczgIRnxLbyOjXuvKOcHnM eoOUjpisCQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+nhzW7Njw+nh5XmA1Pj6eLDfSn58fT12mq Cy+Pp4un9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZX6k//ZHV/9NeBbttwzD07q/Q0Qaazk5C 2b4WSQcMGzB0vi07aK6yeIvtwlYc7Ef2vSPluMkqse2ADQHiRKbIJz4+SUTzzPXOskrXE9c7yyqa 5653llW6F7veWVZx649d7yyrtK253llWUd2uVpcsqxB7tAosq5B4tAosqzD3aBVYVmHh0SqwrMLS o1VgWQXwaBVYVkF6tAosq5B6tAosq5B5tAosq5B7tAosq2ToeJcsq2joalWyrMqFR6uSZRXNXa1K llUJHq1KllU0d7UqWVZl6tGqZFmVmUerkmVV5h6tyhOrN0XwpijmIhHFNrCHKvVR4wMdxZJISPCu au9fRU1HPX76sgkQThxj11mUgf2FLo5B+Pbuw0ex0tuq0ffidi3Wg25MHxXfKc5yipPkVGmz8YF/ 05hElsAfca6BQNhvihfbSDbIL/J3RoJ9IVUGvluNqLABQbPPIcbvjTIRXmfDQy80YREbGj48XIn7 9tiIthN7rQZ9JVRpKms5RJg6CHGoamiQXm5VtW8H3W2i6EvxzoNudgJhs46bHUJ5EeuUtvKEem4n vL+9sagvANPQhHgEOnDoxmDPgFtkE7hXZPMJQmxtaQLmb6dVZ75qzO2/DTh7GjGdIj60nRHlTjXf 9P9Y5OJMwxSx1nXb/XxtTElt3t/FnJOprdJV+yma4QGKZaciah5CY1T5Q6i9xlVHy3ATHiuzE31r yy9JsL1Jl5cpS8/4wQavtVDWie6wUrZtVytTtc1YIpeaR/mN8OLrPMfOKMdeJUseQcJ5PXfaHLqG 5q+LAFNg9/MM+1g8bHEydpK4y2DtdzrYBr8FGAAayHOPCmVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg0IDAgUiANL1Jlc291cmNlcyA1MyAwIFIgDS9D b250ZW50cyA1NCAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9D cm9wQm94IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5kb2JqDTUzIDAgb2JqDTw8IA0vUHJvY1Nl dCBbIC9QREYgL1RleHQgL0ltYWdlQyAvSW1hZ2VJIF0gDS9Gb250IDw8IC9UVDIgMTQ1IDAgUiAv VFQ0IDE0NyAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgMjI0IDAgUiAvSW0yIDIyNSAwIFIgL0lt MyAyMjYgMCBSIC9JbTQgMjIzIDAgUiAvSW01IDIyMSAwIFIgDS9JbTYgMjIyIDAgUiAvSW03IDIy NyAwIFIgL0ltOCAyMzEgMCBSIC9JbTkgMjMyIDAgUiAvSW0xMCAyMzMgMCBSIA0vSW0xMSAyMzAg MCBSIC9JbTEyIDIyOCAwIFIgL0ltMTMgMjI5IDAgUiAvSW0xNCAyMjAgMCBSIC9JbTE1IDIxMSAw IFIgDS9JbTE2IDIxMiAwIFIgL0ltMTcgMjEwIDAgUiAvSW0xOCAyMDggMCBSIC9JbTE5IDIwOSAw IFIgL0ltMjAgMjEzIDAgUiANL0ltMjEgMjE3IDAgUiAvSW0yMiAyMTggMCBSIC9JbTIzIDIxOSAw IFIgL0ltMjQgMjE2IDAgUiAvSW0yNSAyMTQgMCBSIA0vSW0yNiAyMTUgMCBSIC9JbTI3IDIzNCAw IFIgL0ltMjggMjUyIDAgUiAvSW0yOSAyNTMgMCBSIC9JbTMwIDI1NCAwIFIgDS9JbTMxIDI1MSAw IFIgL0ltMzIgMjQ5IDAgUiAvSW0zMyAyNTAgMCBSIC9JbTM0IDIwNyAwIFIgL0ltMzUgMjU5IDAg UiANL0ltMzYgMjYwIDAgUiAvSW0zNyAyNjEgMCBSIC9JbTM4IDI1OCAwIFIgL0ltMzkgMjU2IDAg UiAvSW00MCAyNTcgMCBSIA0vSW00MSAyNDggMCBSIC9JbTQyIDIzOCAwIFIgL0ltNDMgMjM5IDAg UiAvSW00NCAyNDAgMCBSIC9JbTQ1IDIzNyAwIFIgDS9JbTQ2IDIzNSAwIFIgL0ltNDcgMjM2IDAg UiAvSW00OCAyNDEgMCBSIC9JbTQ5IDI0NSAwIFIgL0ltNTAgMjQ2IDAgUiANL0ltNTEgMjQ3IDAg UiAvSW01MiAyNDQgMCBSIC9JbTUzIDI0MiAwIFIgL0ltNTQgMjQzIDAgUiAvSW01NSAyNTUgMCBS IA0vSW01NiAxNjkgMCBSIC9JbTU3IDE3MCAwIFIgL0ltNTggMTcxIDAgUiAvSW01OSAxNjUgMCBS IC9JbTYwIDE2NiAwIFIgDS9JbTYxIDE2NyAwIFIgL0ltNjIgMTcyIDAgUiAvSW02MyAxNzYgMCBS IC9JbTY0IDE3NyAwIFIgL0ltNjUgMTc4IDAgUiANL0ltNjYgMTc1IDAgUiAvSW02NyAxNzMgMCBS IC9JbTY4IDE3NCAwIFIgL0ltNjkgMTY4IDAgUiAvSW03MCAxNTUgMCBSIA0vSW03MSAxNTYgMCBS IC9JbTcyIDE1NyAwIFIgL0ltNzMgMTU0IDAgUiAvSW03NCAxNTEgMCBSIC9JbTc1IDE1MiAwIFIg DS9JbTc2IDE1MyAwIFIgL0ltNzcgMTU4IDAgUiAvSW03OCAxNjIgMCBSIC9JbTc5IDE2MyAwIFIg L0ltODAgMTY0IDAgUiANL0ltODEgMTYxIDAgUiAvSW04MiAxNTkgMCBSIC9JbTgzIDE2MCAwIFIg L0ltODQgMTkwIDAgUiAvSW04NSAxOTcgMCBSIA0vSW04NiAxOTggMCBSIC9JbTg3IDE5OSAwIFIg L0ltODggMTk2IDAgUiAvSW04OSAxOTQgMCBSIC9JbTkwIDE5NSAwIFIgDS9JbTkxIDIwMCAwIFIg L0ltOTIgMjYyIDAgUiAvSW05MyAyMDUgMCBSIC9JbTk0IDIwNiAwIFIgL0ltOTUgMjAzIDAgUiAN L0ltOTYgMjAxIDAgUiAvSW05NyAyMDIgMCBSIC9JbTk4IDE5MyAwIFIgL0ltOTkgMTgzIDAgUiAv SW0xMDAgMTg0IDAgUiANL0ltMTAxIDE4NSAwIFIgL0ltMTAyIDE4MiAwIFIgL0ltMTAzIDE4MCAw IFIgL0ltMTA0IDE4MSAwIFIgL0ltMTA1IDQzNyAwIFIgDS9JbTEwNiAxODYgMCBSIC9JbTEwNyAx NzkgMCBSIC9JbTEwOCAxOTEgMCBSIC9JbTEwOSAxOTIgMCBSIC9JbTExMCAxODkgMCBSIA0vSW0x MTEgMTg3IDAgUiAvSW0xMTIgMTg4IDAgUiAvSW0xMTMgMjA0IDAgUiAvSW0xMTQgMzY2IDAgUiAv SW0xMTUgMzY3IDAgUiANL0ltMTE2IDM2OSAwIFIgL0ltMTE3IDM2OCAwIFIgL0ltMTE4IDM2NSAw IFIgL0ltMTE5IDM2MSAwIFIgL0ltMTIwIDM2MiAwIFIgDS9JbTEyMSAzNjQgMCBSIC9JbTEyMiAz NjMgMCBSIC9JbTEyMyAzNzAgMCBSIC9JbTEyNCAzNzYgMCBSIC9JbTEyNSAzNzcgMCBSIA0vSW0x MjYgMzc5IDAgUiAvSW0xMjcgMzc4IDAgUiAvSW0xMjggMzc1IDAgUiAvSW0xMjkgMzcxIDAgUiAv SW0xMzAgMzcyIDAgUiANL0ltMTMxIDM3NCAwIFIgL0ltMTMyIDM3MyAwIFIgL0ltMTMzIDM2MCAw IFIgL0ltMTM0IDM0NiAwIFIgL0ltMTM1IDM0NyAwIFIgDS9JbTEzNiAzNDkgMCBSIC9JbTEzNyAz NDggMCBSIC9JbTEzOCAzNDUgMCBSIC9JbTEzOSAzNDEgMCBSIC9JbTE0MCAzNDIgMCBSIA0vSW0x NDEgMzQ0IDAgUiAvSW0xNDIgMzQzIDAgUiAvSW0xNDMgMzgwIDAgUiAvSW0xNDQgMzU2IDAgUiAv SW0xNDUgMzU3IDAgUiANL0ltMTQ2IDM1OSAwIFIgL0ltMTQ3IDM1OCAwIFIgL0ltMTQ4IDM1NSAw IFIgL0ltMTQ5IDM1MSAwIFIgL0ltMTUwIDM1MiAwIFIgDS9JbTE1MSAzNTQgMCBSIC9JbTE1MiAz NTMgMCBSIC9JbTE1MyAzNTAgMCBSIC9JbTE1NCA0MTYgMCBSIC9JbTE1NSA0MDkgMCBSIA0vSW0x NTYgNDEyIDAgUiAvSW0xNTcgNDEzIDAgUiAvSW0xNTggNDE0IDAgUiAvSW0xNTkgNDExIDAgUiAv SW0xNjAgNDE1IDAgUiANL0ltMTYxIDQxMCAwIFIgL0ltMTYyIDQwOCAwIFIgL0ltMTYzIDQxNyAw IFIgL0ltMTY0IDM4NiAwIFIgL0ltMTY1IDM4OCAwIFIgDS9JbTE2NiAzODcgMCBSIC9JbTE2NyAz ODkgMCBSIC9JbTE2OCAzOTIgMCBSIC9JbTE2OSAzOTEgMCBSIC9JbTE3MCAzOTAgMCBSIA0vSW0x NzEgNDA3IDAgUiAvSW0xNzIgMzgyIDAgUiAvSW0xNzMgMzgxIDAgUiAvSW0xNzQgMzgzIDAgUiAv SW0xNzUgMzg1IDAgUiANL0ltMTc2IDM4NCAwIFIgL0ltMTc3IDM5MyAwIFIgL0ltMTc4IDQwMiAw IFIgL0ltMTc5IDQwMSAwIFIgL0ltMTgwIDQwMyAwIFIgDS9JbTE4MSA0MDYgMCBSIC9JbTE4MiA0 MDUgMCBSIC9JbTE4MyA0MDQgMCBSIC9JbTE4NCA0MDAgMCBSIC9JbTE4NSAzOTUgMCBSIA0vSW0x ODYgMzk0IDAgUiAvSW0xODcgMzk2IDAgUiAvSW0xODggMzk5IDAgUiAvSW0xODkgMzk4IDAgUiAv SW0xOTAgMzk3IDAgUiANL0ltMTkxIDI2NyAwIFIgL0ltMTkyIDI4NyAwIFIgL0ltMTkzIDI4OCAw IFIgL0ltMTk0IDI5MCAwIFIgL0ltMTk1IDI4OSAwIFIgDS9JbTE5NiAyODYgMCBSIC9JbTE5NyAy ODIgMCBSIC9JbTE5OCAyODMgMCBSIC9JbTE5OSAyODUgMCBSIC9JbTIwMCAyODQgMCBSIA0vSW0y MDEgMjkxIDAgUiAvSW0yMDIgMjk3IDAgUiAvSW0yMDMgMjk4IDAgUiAvSW0yMDQgMzAwIDAgUiAv SW0yMDUgMjk5IDAgUiANL0ltMjA2IDI5NiAwIFIgL0ltMjA3IDI5MiAwIFIgL0ltMjA4IDI5MyAw IFIgL0ltMjA5IDI5NSAwIFIgL0ltMjEwIDI5NCAwIFIgDS9JbTIxMSAyODEgMCBSIC9JbTIxMiAz NDAgMCBSIC9JbTIxMyAyNjggMCBSIC9JbTIxNCAyNzAgMCBSIC9JbTIxNSAyNjkgMCBSIA0vSW0y MTYgMjY2IDAgUiAvSW0yMTcgMjYzIDAgUiAvSW0yMTggMjY0IDAgUiAvSW0yMTkgMjY1IDAgUiAv SW0yMjAgMjcxIDAgUiANL0ltMjIxIDI3NyAwIFIgL0ltMjIyIDI3OCAwIFIgL0ltMjIzIDI4MCAw IFIgL0ltMjI0IDI3OSAwIFIgL0ltMjI1IDI3NiAwIFIgDS9JbTIyNiAyNzIgMCBSIC9JbTIyNyAy NzMgMCBSIC9JbTIyOCAyNzUgMCBSIC9JbTIyOSAyNzQgMCBSIC9JbTIzMCAzMDEgMCBSIA0vSW0y MzEgMzI2IDAgUiAvSW0yMzIgMzI3IDAgUiAvSW0yMzMgMzI5IDAgUiAvSW0yMzQgMzI4IDAgUiAv SW0yMzUgMzI1IDAgUiANL0ltMjM2IDMyMSAwIFIgL0ltMjM3IDMyMiAwIFIgL0ltMjM4IDMyNCAw IFIgL0ltMjM5IDMyMyAwIFIgL0ltMjQwIDMzMCAwIFIgDS9JbTI0MSAzMzYgMCBSIC9JbTI0MiAz MzcgMCBSIC9JbTI0MyAzMzkgMCBSIC9JbTI0NCAzMzggMCBSIC9JbTI0NSAzMzUgMCBSIA0vSW0y NDYgMzMxIDAgUiAvSW0yNDcgMzMyIDAgUiAvSW0yNDggMzM0IDAgUiAvSW0yNDkgMzMzIDAgUiAv SW0yNTAgMzIwIDAgUiANL0ltMjUxIDMwNiAwIFIgL0ltMjUyIDMwNyAwIFIgL0ltMjUzIDMwOSAw IFIgL0ltMjU0IDMwOCAwIFIgL0ltMjU1IDMwNSAwIFIgDS9JbTI1NiAzMDIgMCBSIC9JbTI1NyAz MDMgMCBSIC9JbTI1OCAzMDQgMCBSIC9JbTI1OSAzMTAgMCBSIC9JbTI2MCAzMTYgMCBSIA0vSW0y NjEgMzE3IDAgUiAvSW0yNjIgMzE5IDAgUiAvSW0yNjMgMzE4IDAgUiAvSW0yNjQgMzE1IDAgUiAv SW0yNjUgMzExIDAgUiANL0ltMjY2IDMxMiAwIFIgL0ltMjY3IDMxNCAwIFIgL0ltMjY4IDMxMyAw IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MjYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2 IDExOSAwIFIgL0NzOCAxMjAgMCBSIC9DczkgMTIyIDAgUiAvQ3MxMCAxMjEgMCBSIC9DczExIDEx OCAwIFIgDS9DczEyIDExNSAwIFIgL0NzMTMgMTE2IDAgUiAvQ3MxNCAxMjMgMCBSIC9DczE1IDEx NyAwIFIgL0NzMTYgMTMwIDAgUiANL0NzMTcgMTI5IDAgUiAvQ3MxOCAxMzIgMCBSIC9DczE5IDEz MSAwIFIgL0NzMjAgMTI0IDAgUiAvQ3MyMSAxMjggMCBSIA0vQ3MyMiAxMjUgMCBSIC9DczIzIDEy NyAwIFIgL0NzMjQgMTI2IDAgUiAvQ3MyNSAxMTEgMCBSIC9DczI2IDk4IDAgUiANL0NzMjcgOTcg MCBSIC9DczI4IDk5IDAgUiAvQ3MyOSAxMDEgMCBSIC9DczMwIDEwMCAwIFIgL0NzMzEgOTYgMCBS IA0vQ3MzMiA5MiAwIFIgL0NzMzMgOTMgMCBSIC9DczM0IDk1IDAgUiAvQ3MzNSA5NCAwIFIgL0Nz MzYgMTAyIDAgUiANL0NzMzcgMTEwIDAgUiAvQ3MzOCAxMDkgMCBSIC9DczM5IDExNCAwIFIgL0Nz NDAgMTEzIDAgUiAvQ3M0MSAxMTIgMCBSIA0vQ3M0MiAxMDggMCBSIC9DczQzIDEwNCAwIFIgL0Nz NDQgMTAzIDAgUiAvQ3M0NSAxMDUgMCBSIC9DczQ2IDEwNyAwIFIgDS9DczQ3IDEwNiAwIFIgPj4g DT4+IA1lbmRvYmoNNTQgMCBvYmoNPDwgL0xlbmd0aCAzNDA5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJjFfLrmU7DZzvr1g/cNOx8x43EgIJJNRDxKh5CESDoAf8Pl5vl5OVvdWT 0+e4khVXuWx/+fozL99/LrT9+/n9X68vv/5Gy99+vri4WJdSyXlaUvTLL4X98t+/vP76+rKCvn4T gHd18cu3r79/+eW38v9/LOTS8r+F/PK75Y9/8sufX7T8fXkRh/W0th5Gy4/z/yW09fR/vr69jrNc 9nE7r7U1gCidiBT0L1bIf+RS70pdfvEuRfmOFNjF1tqSW3WJfFq+/3h9+c0PWn7179cftnh21GLq EYXkS8KF4BtBLvMGiPUAtHJc4dsFCPqKGMoAYa6IcEXOZYAI8psbkd5+VJEf6g3I+qNqpaLeHVxi eURx4c5TeRdvnlDv+OhCbV04s0vlCm8TGvZ4ea+/40VEbwHwXg0gF33ovyhGxzdrxBMSgmu7loIL aURCR/SFgKyS0oZonHgAKUSuqu9Sii0Pt6xcBAWJ8GFDhEkvPGUYLwepd+T3N8TgqroBBNVSyoqP 6FLYkiV/URTWiQYvCOa3AesFDOGAyDe5dCeL/SeQqnlnFGMW6fQQYTEpE2HNYuASRhBgkWmi4BPC aG7qluTIl0GSDfMMWmkURh8mVKpbOEwgYsnVEskJzCFx6QFAI+dJtW+AlURSrygTEg8AUjjT1g4w BCplidvH3H8SVZfvNwSvGeeQ+09C8gKBN8QuPEpHVEX+jgTLWnqb05hdHva94Lgm7YdSQakv2BA0 z803GkGA6cDPRnIgDNUBmyUPEcB1SO9fYtgOWbM9vEPYJtXzC9R33O3NQAzf9clzz3iZiJqKb7q4 h5lCxqOfSCTLxNIzGGlSqRcEGIw80dUBMRTG8AkEOIwzmzohpmIV7dmlGka3UNFtLeaJ5Z4QFldM Q8uVW2KmEQSIj+WDtwj36paYNPc1Q/c8IdhwY9WqDzhqrPmw00xsUL04aByArCeT5J9rd4s3tNNs XjoAQHqaWdAOeC7blViqPQA8LgWocw79DchdondZXZkjdUN8rNo9HGs2gVflQroNFEc0mEKzvsE0 /QuCzJVJAR4QQ16aNcwLgvS1929ZCSQavqXrshck6U1I99nqyugOpDDrgc+7lj0PMAGekgkwObFW VpF5cksyuXInOU9a24EwOc6wHYQ8AhS9ReWozWcYj89Q6lq3NyioE0JR3ndDMkCw354QSbBynlwm RXVCTH7rpNJPiIwnrOaAoD8spqaZl94cNz7CDSizjXADFE/6htz0DYm5jwf6Cr2Lx9QWBuXm1H8Q JrYETbfpaDsA01pmXXMHRGknaiwGgUROeEMuh8z9XU5l1jMPyCSxawWGSCNMFIXe15SJ/5wQcQa1 2mj/kerwNY4gMMYVpcNu/jkhQopXEHTswKP3yyalNruCk1wrow+TH8r9lurhw+rokgjqqqDGip1K WlTqqaysqRR9hR5iqKwBjbGWwTWGyooT/BiCJl9xlsujx5j9q2bNSxi+31BZy7Njn4jAzqskQ1c0 I80FkfFc9V6V5DaKBt6b1y1hzGKJK7/3mEUTY2yuWF9ssElSJjbxlnJTvdg/d0DQTDSQVSyl2ngk mz2QjSP1Hg9MN3S5BMPxFs9FSuSODxNX3OIDPLilifXs8cAwNe3rnn33XsNxeZcfJFjnRykoemlG /RjSKlSbFtCJMASHBAQXCiMIUgy7Aw0vQadt+blyLgiznnYSDFTDeJhyycM223yjASZ43TPIe20b w4eImety8+qzihs/BAknH4CTnMsAY6raR60q3TLiytFGvJSv2kx9ei7sE2OoJ58nxX2DgHxZOZ4L 5MJQcVXVeINvgw3kgrAH46yfQKSgg/oyLX7JNNVB3lbZJA1q7zJt+ST/XMEXxro02DTO4lFI6egk 3CdMtCWSwqSIdwCSSPHN9xSSIUqliUBe0C33eJNWgk2ixlI7AEy7RAXKN/Q3WBomW8QOkBGJb0UF LMPaXyCcqblNTyGSUk2yWG4YlKB2Bs6pjBBBT+ykzV3O4sElHdUNrgl5iIERjJh0qrJsJgOMVAzd Ckn5sSwuACqEcV+BRn5hjEqY378/ZD21EketExzab0zFNE+m9gsTg0v6HmhZHOMoBagYYrBGnDWi HFI3ySjLijR5zAHImhZCKzXuuyGMYPRe1L39AKBagn/3iuILGC/XtwhRlyY+0KO8jvhncT08G6WV YOuSppU7gJkFAgMXtc+TUZU2lK6qdoRoSm0cFOJEUwcCFRVAuTCgsCvpMKGkn5HBR3EMujAoqoCr EHrvgbGyehzPrnhJu/6upu0hjwAmvRX8JI8eb2USoTWPIYwWHOmDtxvbiqzFVXiftQzGyCsGzYtv ZYjBFETwOho+R37I+ppJn74gTde7FmVnEKK5Nuh0sUx868KgyGKelPCBmXhX5ysXBAf0CDpLNaQR xuQZpYat68QYqSVs3TignhijtUQfpGDmY5XzCGKklmZmeWEgBdMucUKMm6X4QQZQa1rQepkN63xl VllKaVKZG2LiSd1EeABQLHrKQVM6wlEn+oLOknaEVUl5LscdgBLJ4W08br3p0VaP8ObywwsecmqE wRPb2gFWFvWpMxzhFTaRgPuXT1pF4i37rovKyLM6OjB2bs4eFI7d+sJE6L6ZJ15yYVAjeTYGnxij kjyrpBODQsEsP0GMVuiDTxPBsE4BFCFO6CfELGYZJhAcpE6I6VoZB+eU8ggDwmkqz+IxWItR5HLo Juhr2sQgDkzx3tU7zzjkBRpdY2VT/MQmLoyRzWzaOTFGNoWezeKEoGp0r5f5qI4hqJoSPvgyrq6q RJeZzZyYmdGM82xUU9KT01wA9Jqin89uXeFumSUn2bGKKXniGhuiI79MiuxAIPWlggPm1H1VR/xs xtkRhpA62+l2hJk962w13RFCR1DZrUB6K3mAqGJVCqGkVRyHXAFRy1HDXt+iOOwGogtTsSXNNrUD Y3mseZqxA/OcM7nHMw0wRLBL1DJl/8Ag/zVNNbZjRAFJ561+8J6JBmSb8yUPMJHALhr22RZHuY7F Rf1tTesgxKTnmCyfNNBBg28Dg7kQqILGEys/MFYFDeexEQCbX4NtaniFEUBLutDMhHVhUAAtP5vl CWF0slYmNn5hUDOtTmz8xJju39oHmAgp0Na/CoPqCBL1XMJ+Nstk1+mFvZ9oeQeAXNiDXMxKtAJW rajdhqLKsF9HXRveHKnwycSzhRPUFfswqd8dkPXAyzPP2+JZ5jnVf2EVSjBS7+GgDfY4s3L3XNQF +/TuwSIK0hdkMAXPXbxRBAo87Ak6VCQHDJoJ+wq1h0VxYczD26ReD4yVhp7Wu8HzxBj+iD7ACIdJ Y/yjKV4IfA3B2NXCEGOoJJgI8wAg1KitkynqS8wsUUTM/azONNPLhYEphwmnNey/B8ZQwwSrh9kl T4yhpn0Ascy0iZtcmKbTBobylDbLDYMCah6lraOnThRd3ToVg1Uwz6S5AmySGfcBG23Sq61LljFs bxsAt5pppWzxwTuvLwBt4eK0x4NVMz839S1c5ho4fjY6VimyTbryF33Fc/M4EHKBS2o0eRtvZga9 +cUyREiaqqLZv71C8pTS6ArRSybt2E3u3J4dUK5KejIK70tczgIRnxLbyOjXuvKOcHnMeoOUjpis CQ/+6XR5KXenB3o6PZDL/en8eDpvu6QJD4+nhzW7Njw+nh5XmA1Pj6eLDfSn58fT12mqCy+Pp4un 9Kc/sipulfvTH1mNUrfd6fGRVQkv3enxkVXZX6k//ZHV/3NedjtOw0AUvs9T+LKRNpBsM27CHexW SEhIaOU7lou0dUVRSVHidMWDwPNyJm6z3dojEKrUpKlzZjyfj3/QvArVRaq8PQnVRapoXofqIlXe F4fqIlVM/XmoLlLlaS1UF6nC3aFXS5Eq5RGvkkiViohXSaRKtxGvkkiV5hGvkkiVyohXSaRKFPEq iVRJR7xKIlVaRLxKIlWqIl4lkSrVEa+SSJUbBupapIqGoVe1SFXPI17VIlU0D72qRaqaIl7VIlU0 D72qRap6EfGqFqnqKuJVLVLVdcSr+kT1nUleG3OrCmW2ybio8jnKXyCUa4ZQYK867r/Md17q8enX Le7MOkFOeY6jp3lKZu8fPn5S93a7a+1G3S3VW+e63WpwtldNu1HLo21dn5pvHLE8R4TVOdT47VUz Pi1iljX3HAK6v/idi7ivaj3nOqCBD19xJnxX+EQQu5li+5eLmod25i/803cMI/6iY0EqLDsq/n6Z Ag6iPBTHFMa4UykwBrm9OaiVVZtDa/2LV3XFaszEr+oqh/9bBYpiqoA+V8BO5Q56j6GInf+L3vtC ls9IS9b5PLsbug46+59qA7AplqxZa/s36RfzIQ4Pg24OZ3l4/1i+y/qd4y5V7xo39L4f6pGfDD9u UNOnVh06tbfN0d6oZu04q8XsmHLoGR7tWn7If26b3f5wtN1jKuSbnTL5v6z1Vdac4lfbdG5lG6fU aaRP3gKGUQfQc8KmI8PZlKp6kqPnyA/WDV3LAkuTINlx4qxwYMSqxvBVBjsjaGeTbfJHgAEAA6lJ ygplbmRzdHJlYW0NZW5kb2JqDTU1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4NCAw IFIgDS9SZXNvdXJjZXMgNTYgMCBSIA0vQ29udGVudHMgNTcgMCBSIA0vUm90YXRlIDkwIA0vTWVk aWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVu ZG9iag01NiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBd IA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RUNCAxNDcgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0x IDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEg MCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIg L0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIg L0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIg L0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIg L0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiAN L0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAv SW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAv SW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAv SW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAv SW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0v SW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9J bTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9J bTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9J bTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9J bTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9J bTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0lt NzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0lt NzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0lt NzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0lt ODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0lt ODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05 MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05 NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05 OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9J bTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBS IA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTky IDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEz IDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9J bTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBS IA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2 IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4 IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9J bTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBS IA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQx IDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQz IDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9J bTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBS IA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2 IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4 IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9J bTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBS IA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkx IDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTcz IDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9J bTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBS IA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAw IDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4 IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9J bTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBS IA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1 IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAz IDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9J bTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBS IA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcw IDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4 IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9J bTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBS IA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0 IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMz IDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9J bTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBS IA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4 IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4 IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9J bTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBS IA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEw IDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYz IDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9J bTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAg UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAw IFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAw IFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAw IFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAg UiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAg UiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAv Q3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3Mz NCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzgg MTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIg MTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAx MDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTU3IDAgb2JqDTw8IC9MZW5ndGgg MzU3NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMe NxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64 uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0 /H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdba klt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBF zmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NF RG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBh Q4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5 ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwh cekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF /o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD 2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiM M5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84 aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2Z I3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlN SPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/P UOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41w AxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1O ZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7 gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbL o8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2Nsrlhf bLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn1 7PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4I s552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srR RryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W 2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJN osZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1d zuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9M xTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/ 94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMH AhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1 jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFM fOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZm ZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJ eS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjow dm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQ HKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkx RjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mx iil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqh pFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QB SeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3n sREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS 9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMsz z9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdF cWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFE zP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04U Xd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42 OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoy Cu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8 Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R 1f/zXi27cQJB8M5XzBEOS3j1LBwTP6JEchR5uUU5YHbWwcGwAmwrP5LvTTWPBZkZxY7kaKWFWWa6 a6mumh5Mj9fRjaxye7KObmQV05N1dCOr3BevoxtZhfV76+hGVtnW1tGNrELda61GRlbJ02iVjKyS r9EqGVmlQKNVMrJKoUarZGSVIo1WycgqkUarZGSVpEarZGSVthqtkpFVijVaJSOrlGi0SkZWeeIq ujSyiolrrUojqzLUaFUaWcX0tValkVVJGq1KI6uYvtaqNLIqtxqtSiOrMtZoVRpZlYlGq3Jk9UNq vUvTQPgiPVj9psrnqOGCQJ5kEnz0qn3/ld7zVo9Pm1cW4HgepqX5eBuK9MmyP15ffRXiXB2KSu3F 5YV433VNcfPQqdZJ7zhbNGXzE663zXDBcOux1HwZLbO5xFD6b87qcT6vz/Sb4814cDrk+sCz8xGQ nLEFvOKbfV47G3J9e+ds4D9uaB9xg3FTdyrviroSx7os8l/O9/SzJvlmzNG/WjgaMr0GD+nxTGgC O3M4g911Wf5TZKVquhGPeAGgMH41IH8GJAdAZxfikBVl/aiaAdTWrh0EtxtRquxR/Tc82wHP5RoP XhK2cbvai0bd1YUTuWRX/OKk/VbonlU6GnxeAGw/VNZ0NyqbeRpivC1Ng8aOKNo6r0uBd9Ny6WZt W9xW96rq3gRFOKOI+hXX6rZoO9WIQ92w0NUjUoOUY928AME/6KdnYCYA1frQNJwzbbKqzQYBOxIK +rTHz8WhgOdwKVykWAaLcdnUdmdfEBvBnoTlw6lhjhEM08Mp8f70Q+K7SeL3lgSbjxKJ5xhtp9vc wpnVTeQ0LjGGnwTTOOAmPEYnA7jhYkjj4uePk0UabtPmNIxkmSaJF2lCL1zCnYbj38mtHRv8ymhx 7mGjpQB/zh+NdqR14uISlI52fdocfA6xXM+t0WjU/om2ntChQnclO8ZVvX8o1V+8H9tdHxKX2LDT 9Cqwr7Iqu1VTkYPYPwIMAGaa9RwKZW5kc3RyZWFtDWVuZG9iag01OCAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgODUgMCBSIA0vUmVzb3VyY2VzIDU5IDAgUiANL0NvbnRlbnRzIDYwIDAg UiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0MiA4 MSA1NTMgNzYxIF0gDT4+IA1lbmRvYmoNNTkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4 dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSID4+IA0vWE9iamVjdCA8 PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0lt NSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIz MiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIy OSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIx MCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIx NyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0 IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUz IDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUw IDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYx IDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4 IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcg MCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUg MCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIg MCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAg MCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcg MCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAw IFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAw IFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAw IFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAw IFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAw IFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAg UiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAg UiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAg UiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAg UiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUg MCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0 MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0x MDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIg L0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkg MCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAz NjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0x MjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIg L0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQg MCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAz NDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0x MzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIg L0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkg MCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAz NTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0x NTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIg L0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAg MCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAz ODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0x NjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIg L0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQg MCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0 MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0x ODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIg L0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcg MCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAy ODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0x OTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIg L0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYg MCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAy OTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0y MTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIg L0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcg MCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAy NzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0y MjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIg L0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEg MCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAz MzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0y NDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIg L0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYg MCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAz MDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0y NTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIg L0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIg MCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5 IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEz IDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3 IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEg MTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUg MTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAx IDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAg UiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIg L0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiAN L0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAv Q3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5kb2JqDTYwIDAgb2JqDTw8IC9M ZW5ndGggNDAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769Y P3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+ Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WP f/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5 jhTYxdbaklt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjK AGGuiHBFzmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2 eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7es XAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQn i/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ 1RLJCcwhcekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfE LjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LY DlmzPbxD2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEU xvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHY cGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3I XaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l 67IXJOlNSPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXl qM1nGI/PUOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+ wg0os41wAxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhD LofM/V1OZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj 98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wY giZfcZbLo8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hF E2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9zi Azy4pYn17PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gn bfm5ci4Is552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ket Kt0y4srRRryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+ yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt 93iTVoJNosZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQ QU/spM1dzuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJH rRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9 /QCgWoJ/94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEpt HBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSP Hm9lEqE1jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCi uTbodLFMfOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV 8whipJZmZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qC zpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66L ysizOjowdm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugn xCxmGSYQHKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6M kc1s2jkxRjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3h bpklJ9mxiil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5 gKhiVQqhpFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81 TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMr PzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDW vwqD6ggS9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnf HZD1wMszz9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwya CfsKtYdFcWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp 6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoe pa2jp04UXd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/Ut XOYaOH42OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tye HVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+P p4c1uzY8Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV 2V+pP/2R1f9TXi29bRtB+M5fwVMhFwi7y32R1zhO0ABpg4g3IwdBpmMHlFTIao3++34z+yBFcpEU OlAczs5+O9+8FurN0nqWVRpPltazrEK9XVrPskpz8dJ6llWUfrG0nmWVytrSepZVZPcyV3WWVSNW ctVkWTVyJVdNllVTr+SqybJq1EqumiyrRq/kqsmyasxKrposq8au5KrJsmrcSq6aLKumWclVk2XV tCu5arKskuLCus2yCsVlrtosq1at5KrNsgr1Za7aLKvWrOSqzbIK9WWu2iyr1q3kqs2yapuVXLVZ Vm27kqs2sAqTsIW2XsryZX8sas3adBcVsqT7whuDCDj3xWPxtit+67oamt1jwQ2Y7lz+gU2FJcIk 5lqe1boDjQX4kVlAFwIbdXv/F62/ey02n04P/VCeHssPXz59LrfD7p++hOzvob/pvhd3XbCwvf2j kOVH/PuO2QQh+loWtVMEFF4FUImuhJ0F4dwSTsCxjM4/qP0rqim4D+LW49F5TJIwCUaz3T/1tPc5 bB620OwLSSXSYReY+9EuWoVJLO1iaZcNn5KMgxqhUf/wrAVm3+5dwV5J/qG/r8X9xrvk842p5OZ0 g4lwMzzv/7352n0kgKplgAo9dgIQlTYLUEsGqFC/I8CRGf5n2BW3l/NQ/lL+eXnqz4wYbnPXeNOK 1lP58q380B+r4LsArRbmf0LD3aFqIzS2/KV/eD73+8vz6RigKIncnfluhFFNcQQOjTIczzg29m1+ yCDNo/XUQS4dN0Ru//Ky+9aXvx8v/fmvc39JUSMQqBKBGrdWtXfBoZANj31RMAACidB6FMZNo1jH yemiIWlImqRJ8PgrlJxPaUWHOhSocxVKXXgnuyQxpRWOFx0ilqQRvsuGt2WjkTHTeqPKTt+H2Xv6 roQMSGcCaNSCz5s0tiyi06BW+PMq0c6seI26NeN5Y5y3ybK9Egxzwaih1UwjCEZ0SWNEp5sZutFK 0FBuRFe3chJih/SOQG6cZ6Ph6DIojQipUUPKwEbr4sepxVh40gIFpzROTm2qFg8z1Wli5JDV+JnN iqq1KJ33juafmgaJr6J8wCFTbLSOLBkhcDtLgmHUqMNeSaMO1rcsoq4EZoGEdOR1yEUFBLJrYyD7 Yn7POMKCWNEPhTacL1FAu5CIosPFfNFaThcNScNM8iXgN056hrSUk/dh9p6+ayuTu7Vgd2sbXRB1 TAxBLV36zLvCzy1Ip0mAz8n/+KQSPGKtrGO0BoGrY0Aoea0QBElBN3wiqWI0B4FTqQSsVjenK0yL EqCV9NVNph4dq1toQcp3IOpZN7pSm9CeufdIjPM40aQEv4nNIzbTsY0DRVuxNj+AAjMyeJWiqWo1 nxS4DzbcLt/fca+EBMyUCpMKunxslb6j3t6FHch8w3cB4R3jVvt8aq0wXh5o+ghV+/4qFXQorEb4 wqqTV0mCwqliYY1RrlOU83c9KayZtNPwAqW0u866KBiSgr1OujGlt6zSUqFQnFMpHchITAfWUJh7 6ph1IROjLB1iXBU0ol1etRZPSnE84bJVGTnplmqMg3e7y64MPDqHe9MiaDzZt0+749HTQXccmJ/r Sa93Ol7OpyGalKqxP2ESDP83AHxXp7AKZW5kc3RyZWFtDWVuZG9iag02MSAwIG9iag08PCANL1R5 cGUgL1BhZ2UgDS9QYXJlbnQgODUgMCBSIA0vUmVzb3VyY2VzIDYyIDAgUiANL0NvbnRlbnRzIDYz IDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0 MiA4MSA1NTMgNzYxIF0gDT4+IA1lbmRvYmoNNjIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSIC9UVDQgMTQ3IDAg UiA+PiANL1hPYmplY3QgPDwgL0ltMSAyMjQgMCBSIC9JbTIgMjI1IDAgUiAvSW0zIDIyNiAwIFIg L0ltNCAyMjMgMCBSIC9JbTUgMjIxIDAgUiANL0ltNiAyMjIgMCBSIC9JbTcgMjI3IDAgUiAvSW04 IDIzMSAwIFIgL0ltOSAyMzIgMCBSIC9JbTEwIDIzMyAwIFIgDS9JbTExIDIzMCAwIFIgL0ltMTIg MjI4IDAgUiAvSW0xMyAyMjkgMCBSIC9JbTE0IDIyMCAwIFIgL0ltMTUgMjExIDAgUiANL0ltMTYg MjEyIDAgUiAvSW0xNyAyMTAgMCBSIC9JbTE4IDIwOCAwIFIgL0ltMTkgMjA5IDAgUiAvSW0yMCAy MTMgMCBSIA0vSW0yMSAyMTcgMCBSIC9JbTIyIDIxOCAwIFIgL0ltMjMgMjE5IDAgUiAvSW0yNCAy MTYgMCBSIC9JbTI1IDIxNCAwIFIgDS9JbTI2IDIxNSAwIFIgL0ltMjcgMjM0IDAgUiAvSW0yOCAy NTIgMCBSIC9JbTI5IDI1MyAwIFIgL0ltMzAgMjU0IDAgUiANL0ltMzEgMjUxIDAgUiAvSW0zMiAy NDkgMCBSIC9JbTMzIDI1MCAwIFIgL0ltMzQgMjA3IDAgUiAvSW0zNSAyNTkgMCBSIA0vSW0zNiAy NjAgMCBSIC9JbTM3IDI2MSAwIFIgL0ltMzggMjU4IDAgUiAvSW0zOSAyNTYgMCBSIC9JbTQwIDI1 NyAwIFIgDS9JbTQxIDI0OCAwIFIgL0ltNDIgMjM4IDAgUiAvSW00MyAyMzkgMCBSIC9JbTQ0IDI0 MCAwIFIgL0ltNDUgMjM3IDAgUiANL0ltNDYgMjM1IDAgUiAvSW00NyAyMzYgMCBSIC9JbTQ4IDI0 MSAwIFIgL0ltNDkgMjQ1IDAgUiAvSW01MCAyNDYgMCBSIA0vSW01MSAyNDcgMCBSIC9JbTUyIDI0 NCAwIFIgL0ltNTMgMjQyIDAgUiAvSW01NCAyNDMgMCBSIC9JbTU1IDI1NSAwIFIgDS9JbTU2IDE2 OSAwIFIgL0ltNTcgMTcwIDAgUiAvSW01OCAxNzEgMCBSIC9JbTU5IDE2NSAwIFIgL0ltNjAgMTY2 IDAgUiANL0ltNjEgMTY3IDAgUiAvSW02MiAxNzIgMCBSIC9JbTYzIDE3NiAwIFIgL0ltNjQgMTc3 IDAgUiAvSW02NSAxNzggMCBSIA0vSW02NiAxNzUgMCBSIC9JbTY3IDE3MyAwIFIgL0ltNjggMTc0 IDAgUiAvSW02OSAxNjggMCBSIC9JbTcwIDE1NSAwIFIgDS9JbTcxIDE1NiAwIFIgL0ltNzIgMTU3 IDAgUiAvSW03MyAxNTQgMCBSIC9JbTc0IDE1MSAwIFIgL0ltNzUgMTUyIDAgUiANL0ltNzYgMTUz IDAgUiAvSW03NyAxNTggMCBSIC9JbTc4IDE2MiAwIFIgL0ltNzkgMTYzIDAgUiAvSW04MCAxNjQg MCBSIA0vSW04MSAxNjEgMCBSIC9JbTgyIDE1OSAwIFIgL0ltODMgMTYwIDAgUiAvSW04NCAxOTAg MCBSIC9JbTg1IDE5NyAwIFIgDS9JbTg2IDE5OCAwIFIgL0ltODcgMTk5IDAgUiAvSW04OCAxOTYg MCBSIC9JbTg5IDE5NCAwIFIgL0ltOTAgMTk1IDAgUiANL0ltOTEgMjAwIDAgUiAvSW05MiAyNjIg MCBSIC9JbTkzIDIwNSAwIFIgL0ltOTQgMjA2IDAgUiAvSW05NSAyMDMgMCBSIA0vSW05NiAyMDEg MCBSIC9JbTk3IDIwMiAwIFIgL0ltOTggMTkzIDAgUiAvSW05OSAxODMgMCBSIC9JbTEwMCAxODQg MCBSIA0vSW0xMDEgMTg1IDAgUiAvSW0xMDIgMTgyIDAgUiAvSW0xMDMgMTgwIDAgUiAvSW0xMDQg MTgxIDAgUiAvSW0xMDUgNDM3IDAgUiANL0ltMTA2IDE4NiAwIFIgL0ltMTA3IDE3OSAwIFIgL0lt MTA4IDE5MSAwIFIgL0ltMTA5IDE5MiAwIFIgL0ltMTEwIDE4OSAwIFIgDS9JbTExMSAxODcgMCBS IC9JbTExMiAxODggMCBSIC9JbTExMyAyMDQgMCBSIC9JbTExNCAzNjYgMCBSIC9JbTExNSAzNjcg MCBSIA0vSW0xMTYgMzY5IDAgUiAvSW0xMTcgMzY4IDAgUiAvSW0xMTggMzY1IDAgUiAvSW0xMTkg MzYxIDAgUiAvSW0xMjAgMzYyIDAgUiANL0ltMTIxIDM2NCAwIFIgL0ltMTIyIDM2MyAwIFIgL0lt MTIzIDM3MCAwIFIgL0ltMTI0IDM3NiAwIFIgL0ltMTI1IDM3NyAwIFIgDS9JbTEyNiAzNzkgMCBS IC9JbTEyNyAzNzggMCBSIC9JbTEyOCAzNzUgMCBSIC9JbTEyOSAzNzEgMCBSIC9JbTEzMCAzNzIg MCBSIA0vSW0xMzEgMzc0IDAgUiAvSW0xMzIgMzczIDAgUiAvSW0xMzMgMzYwIDAgUiAvSW0xMzQg MzQ2IDAgUiAvSW0xMzUgMzQ3IDAgUiANL0ltMTM2IDM0OSAwIFIgL0ltMTM3IDM0OCAwIFIgL0lt MTM4IDM0NSAwIFIgL0ltMTM5IDM0MSAwIFIgL0ltMTQwIDM0MiAwIFIgDS9JbTE0MSAzNDQgMCBS IC9JbTE0MiAzNDMgMCBSIC9JbTE0MyAzODAgMCBSIC9JbTE0NCAzNTYgMCBSIC9JbTE0NSAzNTcg MCBSIA0vSW0xNDYgMzU5IDAgUiAvSW0xNDcgMzU4IDAgUiAvSW0xNDggMzU1IDAgUiAvSW0xNDkg MzUxIDAgUiAvSW0xNTAgMzUyIDAgUiANL0ltMTUxIDM1NCAwIFIgL0ltMTUyIDM1MyAwIFIgL0lt MTUzIDM1MCAwIFIgL0ltMTU0IDQxNiAwIFIgL0ltMTU1IDQwOSAwIFIgDS9JbTE1NiA0MTIgMCBS IC9JbTE1NyA0MTMgMCBSIC9JbTE1OCA0MTQgMCBSIC9JbTE1OSA0MTEgMCBSIC9JbTE2MCA0MTUg MCBSIA0vSW0xNjEgNDEwIDAgUiAvSW0xNjIgNDA4IDAgUiAvSW0xNjMgNDE3IDAgUiAvSW0xNjQg Mzg2IDAgUiAvSW0xNjUgMzg4IDAgUiANL0ltMTY2IDM4NyAwIFIgL0ltMTY3IDM4OSAwIFIgL0lt MTY4IDM5MiAwIFIgL0ltMTY5IDM5MSAwIFIgL0ltMTcwIDM5MCAwIFIgDS9JbTE3MSA0MDcgMCBS IC9JbTE3MiAzODIgMCBSIC9JbTE3MyAzODEgMCBSIC9JbTE3NCAzODMgMCBSIC9JbTE3NSAzODUg MCBSIA0vSW0xNzYgMzg0IDAgUiAvSW0xNzcgMzkzIDAgUiAvSW0xNzggNDAyIDAgUiAvSW0xNzkg NDAxIDAgUiAvSW0xODAgNDAzIDAgUiANL0ltMTgxIDQwNiAwIFIgL0ltMTgyIDQwNSAwIFIgL0lt MTgzIDQwNCAwIFIgL0ltMTg0IDQwMCAwIFIgL0ltMTg1IDM5NSAwIFIgDS9JbTE4NiAzOTQgMCBS IC9JbTE4NyAzOTYgMCBSIC9JbTE4OCAzOTkgMCBSIC9JbTE4OSAzOTggMCBSIC9JbTE5MCAzOTcg MCBSIA0vSW0xOTEgMjY3IDAgUiAvSW0xOTIgMjg3IDAgUiAvSW0xOTMgMjg4IDAgUiAvSW0xOTQg MjkwIDAgUiAvSW0xOTUgMjg5IDAgUiANL0ltMTk2IDI4NiAwIFIgL0ltMTk3IDI4MiAwIFIgL0lt MTk4IDI4MyAwIFIgL0ltMTk5IDI4NSAwIFIgL0ltMjAwIDI4NCAwIFIgDS9JbTIwMSAyOTEgMCBS IC9JbTIwMiAyOTcgMCBSIC9JbTIwMyAyOTggMCBSIC9JbTIwNCAzMDAgMCBSIC9JbTIwNSAyOTkg MCBSIA0vSW0yMDYgMjk2IDAgUiAvSW0yMDcgMjkyIDAgUiAvSW0yMDggMjkzIDAgUiAvSW0yMDkg Mjk1IDAgUiAvSW0yMTAgMjk0IDAgUiANL0ltMjExIDI4MSAwIFIgL0ltMjEyIDM0MCAwIFIgL0lt MjEzIDI2OCAwIFIgL0ltMjE0IDI3MCAwIFIgL0ltMjE1IDI2OSAwIFIgDS9JbTIxNiAyNjYgMCBS IC9JbTIxNyAyNjMgMCBSIC9JbTIxOCAyNjQgMCBSIC9JbTIxOSAyNjUgMCBSIC9JbTIyMCAyNzEg MCBSIA0vSW0yMjEgMjc3IDAgUiAvSW0yMjIgMjc4IDAgUiAvSW0yMjMgMjgwIDAgUiAvSW0yMjQg Mjc5IDAgUiAvSW0yMjUgMjc2IDAgUiANL0ltMjI2IDI3MiAwIFIgL0ltMjI3IDI3MyAwIFIgL0lt MjI4IDI3NSAwIFIgL0ltMjI5IDI3NCAwIFIgL0ltMjMwIDMwMSAwIFIgDS9JbTIzMSAzMjYgMCBS IC9JbTIzMiAzMjcgMCBSIC9JbTIzMyAzMjkgMCBSIC9JbTIzNCAzMjggMCBSIC9JbTIzNSAzMjUg MCBSIA0vSW0yMzYgMzIxIDAgUiAvSW0yMzcgMzIyIDAgUiAvSW0yMzggMzI0IDAgUiAvSW0yMzkg MzIzIDAgUiAvSW0yNDAgMzMwIDAgUiANL0ltMjQxIDMzNiAwIFIgL0ltMjQyIDMzNyAwIFIgL0lt MjQzIDMzOSAwIFIgL0ltMjQ0IDMzOCAwIFIgL0ltMjQ1IDMzNSAwIFIgDS9JbTI0NiAzMzEgMCBS IC9JbTI0NyAzMzIgMCBSIC9JbTI0OCAzMzQgMCBSIC9JbTI0OSAzMzMgMCBSIC9JbTI1MCAzMjAg MCBSIA0vSW0yNTEgMzA2IDAgUiAvSW0yNTIgMzA3IDAgUiAvSW0yNTMgMzA5IDAgUiAvSW0yNTQg MzA4IDAgUiAvSW0yNTUgMzA1IDAgUiANL0ltMjU2IDMwMiAwIFIgL0ltMjU3IDMwMyAwIFIgL0lt MjU4IDMwNCAwIFIgL0ltMjU5IDMxMCAwIFIgL0ltMjYwIDMxNiAwIFIgDS9JbTI2MSAzMTcgMCBS IC9JbTI2MiAzMTkgMCBSIC9JbTI2MyAzMTggMCBSIC9JbTI2NCAzMTUgMCBSIC9JbTI2NSAzMTEg MCBSIA0vSW0yNjYgMzEyIDAgUiAvSW0yNjcgMzE0IDAgUiAvSW0yNjggMzEzIDAgUiA+PiANL0V4 dEdTdGF0ZSA8PCAvR1MxIDQyNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTE5IDAgUiAv Q3M4IDEyMCAwIFIgL0NzOSAxMjIgMCBSIC9DczEwIDEyMSAwIFIgL0NzMTEgMTE4IDAgUiANL0Nz MTIgMTE1IDAgUiAvQ3MxMyAxMTYgMCBSIC9DczE0IDEyMyAwIFIgL0NzMTUgMTE3IDAgUiAvQ3Mx NiAxMzAgMCBSIA0vQ3MxNyAxMjkgMCBSIC9DczE4IDEzMiAwIFIgL0NzMTkgMTMxIDAgUiAvQ3My MCAxMjQgMCBSIC9DczIxIDEyOCAwIFIgDS9DczIyIDEyNSAwIFIgL0NzMjMgMTI3IDAgUiAvQ3My NCAxMjYgMCBSIC9DczI1IDExMSAwIFIgL0NzMjYgOTggMCBSIA0vQ3MyNyA5NyAwIFIgL0NzMjgg OTkgMCBSIC9DczI5IDEwMSAwIFIgL0NzMzAgMTAwIDAgUiAvQ3MzMSA5NiAwIFIgDS9DczMyIDky IDAgUiAvQ3MzMyA5MyAwIFIgL0NzMzQgOTUgMCBSIC9DczM1IDk0IDAgUiAvQ3MzNiAxMDIgMCBS IA0vQ3MzNyAxMTAgMCBSIC9DczM4IDEwOSAwIFIgL0NzMzkgMTE0IDAgUiAvQ3M0MCAxMTMgMCBS IC9DczQxIDExMiAwIFIgDS9DczQyIDEwOCAwIFIgL0NzNDMgMTA0IDAgUiAvQ3M0NCAxMDMgMCBS IC9DczQ1IDEwNSAwIFIgL0NzNDYgMTA3IDAgUiANL0NzNDcgMTA2IDAgUiA+PiANPj4gDWVuZG9i ag02MyAwIG9iag08PCAvTGVuZ3RoIDMzODYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImMV8uuZTsNnO+vWD9w07HzHjcSAgkk1EPEqHkIRIOgB/w+Xm+Xk5W91ZPT57iSFVe5bH/5 +jMv338utP37+f1fry+//kbL336+uLhYl1LJeVpS9Msvhf3y37+8/vr6soK+fhOAd3Xxy7evv3/5 5bfy/38s5NLyv4X88rvlj3/yy59ftPx9eRGH9bS2HkbLj/P/JbT19H++vr2Os1z2cTuvtTWAKJ2I FPQvVsh/5FLvSl1+8S5F+Y4U2MXW2pJbdYl8Wr7/eH35zQ9afvXv1x+2eHbUYuoRheRLwoXgG0Eu 8waI9QC0clzh2wUI+ooYygBhrohwRc5lgAjymxuR3n5UkR/qDcj6o2qlot4dXGJ5RHHhzlN5F2+e UO/46EJtXTizS+UKbxMa9nh5r7/jRURvAfBeDSAXfei/KEbHN2vEExKCa7uWggtpREJH9IWArJLS hmiceAApRK6q71KKLQ+3rFwEBYnwYUOESS88ZRgvB6l35Pc3xOCqugEE1VLKio/oUtiSJX9RFNaJ Bi8I5rcB6wUM4YDIN7l0J4v9J5CqeWcUYxbp9BBhMSkTYc1i4BJGEGCRaaLgE8JobuqW5MiXQZIN 8wxaaRRGHyZUqls4TCBiydUSyQnMIXHpAUAj50m1b4CVRFKvKBMSDwBSONPWDjAEKmWJ28fcfxJV l+83BK8Z55D7T0LyAoE3xC48SkdURf6OBMtaepvTmF0e9r3guCbth1JBqS/YEDTPzTcaQYDpwM9G ciAM1QGbJQ8RwHVI719i2A5Zsz28Q9gm1fML1Hfc7c1ADN/1yXPPeJmImopvuriHmULGo59IJMvE 0jMYaVKpFwQYjDzR1QExFMbwCQQ4jDObOiGmYhXt2aUaRrdQ0W0t5onlnhAWV0xDy5VbYqYRBIiP 5YO3CPfqlpg09zVD9zwh2HBj1aoPOGqs+bDTTGxQvThoHICsJ5Pkn2t3ize002xeOgBAeppZ0A54 LtuVWKo9ADwuBahzDv0NyF2id1ldmSN1Q3ys2j0cazaBV+VCug0URzSYQrO+wTT9C4LMlUkBHhBD Xpo1zAuC9LX3b1kJJBq+peuyFyTpTUj32erK6A6kMOuBz7uWPQ8wAZ6SCTA5sVZWkXlySzK5cic5 T1rbgTA5zrAdhDwCFL1F5ajNZxiPz1DqWrc3KKgTQlHed0MyQLDfnhBJsHKeXCZFdUJMfuuk0k+I jCes5oCgPyymppmX3hw3PsINKLONcAMUT/qG3PQNibmPB/oKvYvH1BYG5ebUfxAmtgRNt+loOwDT WmZdcwdEaSdqLAaBRE54Qy6HzP1dTmXWMw/IJLFrBYZII0wUhd7XlIn/nBBxBrXaaP+R6vA1jiAw xhWlw27+OSFCilcQdOzAo/fLJqU2u4KTXCujD5Mfyv2W6uHD6uiSCOqqoMaKnUpaVOqprKypFH2F HmKorAGNsZbBNYbKihP8GIImX3GWy6PHmP2rZs1LGL7fUFnLs2OfiMDOqyRDVzQjzQWR8Vz1XpXk NooG3pvXLWHMYokrv/eYRRNjbK5YX2ywSVImNvGWclO92D93QNBMNJBVLKXaeCSbPZCNI/UeD0w3 dLkEw/EWz0VK5I4PE1fc4gM8uKWJ9ezxwDA17eueffdew3F5lx8kWOdHKSh6aUb9GNIqVJsW0Ikw BIcEBBcKIwhSDLsDDS9Bp235uXIuCLOedhIMVMN4mHLJwzbbfKMBJnjdM8h7bRvDh4iZ63Lz6rOK Gz8ECScfgJOcywBjqtpHrSrdMuLK0Ua8lK/aTH16LuwTY6gnnyfFfYOAfFk5ngvkwlBxVdV4g2+D DeSCsAfjrJ9ApKCD+jItfsk01UHeVtkkDWrvMm35JP9cwRfGujTYNM7iUUjp6CTcJ0y0JZLCpIh3 AJJI8c33FJIhSqWJQF7QLfd4k1aCTaLGUjsATLtEBco39DdYGiZbxA6QEYlvRQUsw9pfIJypuU1P IZJSTbJYbhiUoHYGzqmMEEFP7KTNXc7iwSUd1Q2uCXmIgRGMmHSqsmwmA4xUDN0KSfmxLC4AKoRx X4FGfmGMSpjfvz9kPbUSR60THNpvTMU0T6b2CxODS/oeaFkc4ygFqBhisEacNaIcUjfJKMuKNHnM AciaFkIrNe67IYxg9F7Uvf0AoFqCf/eK4gsYL9e3CFGXJj7Qo7yO+GdxPTwbpZVg65KmlTuAmQUC Axe1z5NRlTaUrqp2hGhKbRwU4kRTBwIVFUC5MKCwK+kwoaSfkcFHcQy6MCiqgKsQeu+BsbJ6HM+u eEm7/q6m7SGPACa9Ffwkjx5vZRKhNY8hjBYc6YO3G9uKrMVVeJ+1DMbIKwbNi29liMEURPA6Gj5H fsj6mkmfviBN17sWZWcQork26HSxTHzrwqDIYp6U8IGZeFfnKxcEB/QIOks1pBHG5Bmlhq3rxBip JWzdOKCeGKO1RB+kYOZjlfMIYqSWZmZ5YSAF0y5xQoybpfhBBlBrWtB6mQ3rfGVWWUppUpkbYuJJ 3UR4AFAsespBUzrCUSf6gs6SdoRVSXkuxx2AEsnhbTxuvenRVo/w5vLDCx5yaoTBE9vaAVYW9akz HOEVNpGA+5dPWkXiLfuui8rIszo6MHZuzh4Ujt36wkTovpknXnJhUCN5NgafGKOSPKukE4NCwSw/ QYxW6INPE8GwTgEUIU7oJ8QsZhkmEBykTojpWhkH55TyCAPCaSrP4jFYi1Hkcugm6GvaxCAOTPHe 1TvPOOQFGl1jZVP8xCYujJHNbNo5MUY2hZ7N4oSganSvl/mojiGomhI++DKurqpEl5nNnJiZ0Yzz bFRT0pPTXAD0mqKfz25d4W6ZJSfZsYopeeIaG6Ijv0yK7EAg9aWCA+bUfVVH/GzG2RGGkDrb6XaE mT3rbDXdEUJHUNmtQHoreYCoYlUKoaRVHIdcAVHLUcNe36I47AaiC1OxJc02tQNjeax5mrED85wz ucczDTBEsEvUMmX/wCD/NU01tmNEAUnnrX7wnokGZJvzJQ8wkcAuGvbZFke5jsVF/W1N6yDEpOeY LJ800EGDbwODuRCogsYTKz8wVgUN57ERAJtfg21qeIURQEu60MyEdWFQAC0/m+UJYXSyViY2fmFQ M61ObPzEmO7f2geYCCnQ1r8Kg+oIEvVcwn42y2TX6YW9n2h5B4Bc2INczEq0AlatqN2GosqwX0dd G94cqfDJxLOFE9QV+zCp3x2Q9cDLM8/b4lnmOdV/YRVKMFLv4aAN9jizcvdc1AX79O7BIgrSF2Qw Bc9dvFEECjzsCTpUJAcMmgn7CrWHRXFhzMPbpF4PjJWGnta7wfPEGP6IPsAIh0lj/KMpXgh8DcHY 1cIQY6gkmAjzACDUqK2TKepLzCxRRMz9rM4008uFgSmHCac17L8HxlDDBKuH2SVPjKGmfQCxzLSJ m1yYptMGhvKUNssNgwJqHqWto6dOFF3dOhWDVTDPpLkCbJIZ9wEbbdKrrUuWMWxvGwC3mmmlbPHB O68vAG3h4rTHg1UzPzf1LVzmGjh+NjpWKbJNuvIXfcVz8zgQcoFLajR5G29mBr35xTJESJqqotm/ vULylNLoCtFLJu3YTe7cnh1Qrkp6MgrvS1zOAhGfEtvI6Ne68o5wecx6g5SOmKwJD/7pdHkpd6cH ejo9kMv96fx4Om+7pAkPj6eHNbs2PD6eHleYDU+Pp4sN9Kfnx9PXaaoLL4+ni6f0pz+yKm6V+9Mf WY1St93p8ZFVCS/d6fGRVdlfqT/9kdX/U14GO27CQBi+8xQ+kgMpDowT9ribXnpaabmteqBgGlYE R+BolQdpn7czhmS3tWe1VaTEIsM/w3z+jY3hO1+dpUrbE1+dpYrhha/OUqV9sa/OUsWlP/XVWaq0 rPnqLFV0t+/VnKUKacCrwFIFGfAqsFRhE/AqsFQhC3gVWKqQB7wKLFWAgFeBpQoq4FVgqcI24FVg qcIu4FVgqUIR8CqwVCnQU1csVQz0vapYqioLeFWxVDHc96piqSoIeFWxVDHc96piqaptwKuKpap2 Aa8qlqoqAl5VC9X7MvpSlhshRdlG7qVK56j5B4VSRRAk7lXd/qs80qseP1M9RFhOmtLFOqIRKrxG z/HePK0SdN9axY+jsbq2nRnEo+m7+rL6Xn6jdPktHe70NlSj3Ln3LZ4S3ydaA1Xhvilh6lJRmvj3 qnx5V0o6H0zwv/1SVn4ta64rLo2YtD2fxGSOGu856Obcd8NP0XRT3Z1wqEVrRrGvbCXqQzUMuhdz EuyjLFD9pu0eeR5unXg1NOLBDHY0/e1ea0S9XCIZidtI+KvC7E2lcCp2rNq2q4VphT3oq9CEFTuF ZJHwysnmGiZKedIjPsUR2T6J06396+VJ/m1osvSNZko2S/53j91Qzk1+OI+jHmx/EY1usaNTuNGT +FFNuhFmuJtTyILWnWT+ob2XxIOJkCr/3GT45RVKLX0rVFIozsbOjJ29fNALus31ApeGay8+Un+O 7xH9KsnXEL92jT1MboZ/LaM/AgwA3d8/ZwplbmRzdHJlYW0NZW5kb2JqDTY0IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCA4NSAwIFIgDS9SZXNvdXJjZXMgNjUgMCBSIA0vQ29udGVudHMg NjYgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBb IDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag02NSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0NSAwIFIgL1RUNCAxNDcg MCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUgMCBSIC9JbTMgMjI2IDAg UiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIgL0ltNyAyMjcgMCBSIC9J bTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0ltMTEgMjMwIDAgUiAvSW0x MiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0xNSAyMTEgMCBSIA0vSW0x NiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0xOSAyMDkgMCBSIC9JbTIw IDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0yMyAyMTkgMCBSIC9JbTI0 IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0yNyAyMzQgMCBSIC9JbTI4 IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0zMSAyNTEgMCBSIC9JbTMy IDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1IDI1OSAwIFIgDS9JbTM2 IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5IDI1NiAwIFIgL0ltNDAg MjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQzIDIzOSAwIFIgL0ltNDQg MjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3IDIzNiAwIFIgL0ltNDgg MjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUxIDI0NyAwIFIgL0ltNTIg MjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUgMjU1IDAgUiANL0ltNTYg MTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkgMTY1IDAgUiAvSW02MCAx NjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMgMTc2IDAgUiAvSW02NCAx NzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcgMTczIDAgUiAvSW02OCAx NzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEgMTU2IDAgUiAvSW03MiAx NTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAxNTIgMCBSIA0vSW03NiAx NTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAxNjMgMCBSIC9JbTgwIDE2 NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAxNjAgMCBSIC9JbTg0IDE5 MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAxOTkgMCBSIC9JbTg4IDE5 NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAyMDAgMCBSIC9JbTkyIDI2 MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIwMyAwIFIgDS9JbTk2IDIw MSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4MyAwIFIgL0ltMTAwIDE4 NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEwMyAxODAgMCBSIC9JbTEw NCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAvSW0xMDcgMTc5IDAgUiAv SW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAgUiANL0ltMTExIDE4NyAw IFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2NiAwIFIgL0ltMTE1IDM2 NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTExOCAzNjUgMCBSIC9JbTEx OSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAvSW0xMjIgMzYzIDAgUiAv SW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAgUiANL0ltMTI2IDM3OSAw IFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3MSAwIFIgL0ltMTMwIDM3 MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEzMyAzNjAgMCBSIC9JbTEz NCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAvSW0xMzcgMzQ4IDAgUiAv SW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAgUiANL0ltMTQxIDM0NCAw IFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1NiAwIFIgL0ltMTQ1IDM1 NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0OCAzNTUgMCBSIC9JbTE0 OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAvSW0xNTIgMzUzIDAgUiAv SW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAgUiANL0ltMTU2IDQxMiAw IFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQxMSAwIFIgL0ltMTYwIDQx NSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2MyA0MTcgMCBSIC9JbTE2 NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAvSW0xNjcgMzg5IDAgUiAv SW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAgUiANL0ltMTcxIDQwNyAw IFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4MyAwIFIgL0ltMTc1IDM4 NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3OCA0MDIgMCBSIC9JbTE3 OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAvSW0xODIgNDA1IDAgUiAv SW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAgUiANL0ltMTg2IDM5NCAw IFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5OCAwIFIgL0ltMTkwIDM5 NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5MyAyODggMCBSIC9JbTE5 NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAvSW0xOTcgMjgyIDAgUiAv SW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAgUiANL0ltMjAxIDI5MSAw IFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMwMCAwIFIgL0ltMjA1IDI5 OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIwOCAyOTMgMCBSIC9JbTIw OSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAvSW0yMTIgMzQwIDAgUiAv SW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAgUiANL0ltMjE2IDI2NiAw IFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2NSAwIFIgL0ltMjIwIDI3 MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIyMyAyODAgMCBSIC9JbTIy NCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAvSW0yMjcgMjczIDAgUiAv SW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAgUiANL0ltMjMxIDMyNiAw IFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMyOCAwIFIgL0ltMjM1IDMy NSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIzOCAzMjQgMCBSIC9JbTIz OSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAvSW0yNDIgMzM3IDAgUiAv SW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAgUiANL0ltMjQ2IDMzMSAw IFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMzMyAwIFIgL0ltMjUwIDMy MCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1MyAzMDkgMCBSIC9JbTI1 NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAvSW0yNTcgMzAzIDAgUiAv SW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAgUiANL0ltMjYxIDMxNyAw IFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMxNSAwIFIgL0ltMjY1IDMx MSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2OCAzMTMgMCBSID4+IA0v RXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMTkgMCBS IC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAvQ3MxMSAxMTggMCBSIA0v Q3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAvQ3MxNSAxMTcgMCBSIC9D czE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAvQ3MxOSAxMzEgMCBSIC9D czIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAvQ3MyMyAxMjcgMCBSIC9D czI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9DczI3IDk3IDAgUiAvQ3My OCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMxIDk2IDAgUiANL0NzMzIg OTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQgMCBSIC9DczM2IDEwMiAw IFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQgMCBSIC9DczQwIDExMyAw IFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQgMCBSIC9DczQ0IDEwMyAw IFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYgMCBSID4+IA0+PiANZW5k b2JqDTY2IDAgb2JqDTw8IC9MZW5ndGggMzM5OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5eb5eTlb3Vk9PnuJIVV7ls f/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z++vqygr5+E4B3dfHLt6+/ f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0f76+vY6zXPZxO6+1NYAo nYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+9e/XH7Z4dtRi6hGF5EvCheAb QS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oNyPqjaqWi3h1cYnlEceHOU3kX b55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QTEoJru5aCC2lEQkf0hYCs ktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6AQTVUsqKj+hS2JIlf1EU 1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQYJFpouATwmhu6pbkyJdB kg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8oExIPAFI409YOMAQqZYnbx9x/ ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2HUkGpL9gQNM/NNxpBgOnA z0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJc894mYiaim+6uIeZQsajn0gk y8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3mieWeEBZXTEPLlVtiphEE iI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sfa3eLN7TTbF46AEB6mlnQ Dngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRHNJhCs77BNP0LgsyVSQEe EENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9DzABnpIJMDmxVlaReXJLMrly JzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJAsN+eEEmwcp5cJkV1Qkx+66TS T4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9i8fUFgbl5tR/ECa2BE236Wg7 ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF3teUif+cEHEGtdpo/5Hq8DWO IDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII6qqgxoqdSlpU6qmsrKkU fYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuzY5+IwM6rJENXNCPNBZHxXPVe leQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0kFUspdp4JJs9kI0j9R4P TDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmXHyRY50cpKHppRv0Y0ipUmxbQ iTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8owEmeN0zyHttG8OHiJnrcvPq s4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCefJ8V9g4B8WTmeC+TCUHFV1XiD b4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0zuJRSOnoJNwnTLQlksKk iHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1gaJlvEDpARiW9FBSzD2l8gnKm5 TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyYdKqybCYDjFQM3QpJ+bEsLgAq hHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWoGGKwRpw1ohxSN8koy4o0 ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCjvI74Z3E9PBullWDrkqaVO4CZ BQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdxDLowKKqAqxB674Gxsnoc z654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4n7UMxsgrBs2Lb2WIwRRE8Doa Pkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+crFwQH9Ag6SzWkEcbkGaWGrevE GKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEGUGta0HqZDet8ZVZZSmlSmRti 4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm8sMLHnJqhMET29oBVhb1 qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSdecmFQI3k2Bp8Yo5I8q6QTg0LB LD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8JpKs/iMViLUeRy6Cboa9rEIA5M 8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiOIaiaEj74Mq6uqkSXmc2cmJnR jPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1pYID5tR9VUf8bMbZEYaQOtvp doSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjsBqILU7ElzTa1A2N5rHmasQPz nDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a9tkWR7mOxUX9bU3rIMSk 55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1YVAALT+b5QlhdLJWJjZ+ YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkHgFzYg1zMSrQCVq2o3YaiyrBf R10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/hoA32OLNy91zUBfv07sEiCtIX ZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB88QY/og+wAiHSWP8oyleCHwN wdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfGUMMEq4fZJU+MoaZ9ALHM tImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3ARtt0qutS5YxbG8bALeaaaVs 8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBygUtqNHkbb2YGvfnFMkRImqqi 2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5zHqDlI6YrAkP/ul0eSl3 pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH09dpqgsvj6eLp/SnP7IqbpX7 0x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f9zXgY7TsNAGL73KebYIhqStuOm3BbKASQQ0vq24uBN nK0hjavEBe2DwPMydrItrD1CQpXaKB3//9hf/sSh8jJWZ6n67UmszlKl8l2szlL1++JYnaVKt/48 Vmep+ttarM5SpXTHWd2wVDFPZBVZqlgksoosVVwlsoosVVwnsoosVdwksoosVcREVpGliiKRVWSp 4jaRVWSpYpnIKrJUcZfIKrJUfWGkLliqVBhnVbBUxTqRVcFSpfI4q4KlKjCRVcFSpfI4q4KlKraJ rAqWqigTWRUsVbFLZFVMVN/I2SspV1CAbGbhoerfo8YfEsqFh1DQXjXsv+TRP+rpM1TdjNrJcyqT FZ2UP2bzvb2FG+dU9Q1uWt07+GxbUz0u5Ffvsbl40PZu5RsrSuGDW9Dz6g/1DL11+PYuudef//Ii V+t8fBGh//ZTG2tfdumImpEWjrYzzvbgDppGHXR9pq7AWXjQDlyvmsZUYLrG9kfljO1gsKAGGK1o 9YodeZBDUN141bs5ja7UyZ17DSc7DOa+1bSQt4sl3XCy7VwtaJyYh0XIYPFFfkhMaTm17wGtJ4vr Kv5zqhhqpyMa8Pbc97pz7SPUujGdfj0JPF/IDMPra9L053PTvy0319UtQ/0nWqmRtPKk047LIPP/ huGoCOUfR5Sme4C9cgqqg+o63cLglNMZvG/AODgQvHutu5jg5RohKftd961Vta6ByIOCU68Hf0GY IzHVvbH1S4/0aYJmvCLki0s/T3OobDeYWve6znzFOzn7LcAA5JQ/VwplbmRzdHJlYW0NZW5kb2Jq DTY3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4NSAwIFIgDS9SZXNvdXJjZXMgNjgg MCBSIA0vQ29udGVudHMgNjkgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag02OCAwIG9iag08PCAN L1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE0 NSAwIFIgL1RUNCAxNDcgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDIyNCAwIFIgL0ltMiAyMjUg MCBSIC9JbTMgMjI2IDAgUiAvSW00IDIyMyAwIFIgL0ltNSAyMjEgMCBSIA0vSW02IDIyMiAwIFIg L0ltNyAyMjcgMCBSIC9JbTggMjMxIDAgUiAvSW05IDIzMiAwIFIgL0ltMTAgMjMzIDAgUiANL0lt MTEgMjMwIDAgUiAvSW0xMiAyMjggMCBSIC9JbTEzIDIyOSAwIFIgL0ltMTQgMjIwIDAgUiAvSW0x NSAyMTEgMCBSIA0vSW0xNiAyMTIgMCBSIC9JbTE3IDIxMCAwIFIgL0ltMTggMjA4IDAgUiAvSW0x OSAyMDkgMCBSIC9JbTIwIDIxMyAwIFIgDS9JbTIxIDIxNyAwIFIgL0ltMjIgMjE4IDAgUiAvSW0y MyAyMTkgMCBSIC9JbTI0IDIxNiAwIFIgL0ltMjUgMjE0IDAgUiANL0ltMjYgMjE1IDAgUiAvSW0y NyAyMzQgMCBSIC9JbTI4IDI1MiAwIFIgL0ltMjkgMjUzIDAgUiAvSW0zMCAyNTQgMCBSIA0vSW0z MSAyNTEgMCBSIC9JbTMyIDI0OSAwIFIgL0ltMzMgMjUwIDAgUiAvSW0zNCAyMDcgMCBSIC9JbTM1 IDI1OSAwIFIgDS9JbTM2IDI2MCAwIFIgL0ltMzcgMjYxIDAgUiAvSW0zOCAyNTggMCBSIC9JbTM5 IDI1NiAwIFIgL0ltNDAgMjU3IDAgUiANL0ltNDEgMjQ4IDAgUiAvSW00MiAyMzggMCBSIC9JbTQz IDIzOSAwIFIgL0ltNDQgMjQwIDAgUiAvSW00NSAyMzcgMCBSIA0vSW00NiAyMzUgMCBSIC9JbTQ3 IDIzNiAwIFIgL0ltNDggMjQxIDAgUiAvSW00OSAyNDUgMCBSIC9JbTUwIDI0NiAwIFIgDS9JbTUx IDI0NyAwIFIgL0ltNTIgMjQ0IDAgUiAvSW01MyAyNDIgMCBSIC9JbTU0IDI0MyAwIFIgL0ltNTUg MjU1IDAgUiANL0ltNTYgMTY5IDAgUiAvSW01NyAxNzAgMCBSIC9JbTU4IDE3MSAwIFIgL0ltNTkg MTY1IDAgUiAvSW02MCAxNjYgMCBSIA0vSW02MSAxNjcgMCBSIC9JbTYyIDE3MiAwIFIgL0ltNjMg MTc2IDAgUiAvSW02NCAxNzcgMCBSIC9JbTY1IDE3OCAwIFIgDS9JbTY2IDE3NSAwIFIgL0ltNjcg MTczIDAgUiAvSW02OCAxNzQgMCBSIC9JbTY5IDE2OCAwIFIgL0ltNzAgMTU1IDAgUiANL0ltNzEg MTU2IDAgUiAvSW03MiAxNTcgMCBSIC9JbTczIDE1NCAwIFIgL0ltNzQgMTUxIDAgUiAvSW03NSAx NTIgMCBSIA0vSW03NiAxNTMgMCBSIC9JbTc3IDE1OCAwIFIgL0ltNzggMTYyIDAgUiAvSW03OSAx NjMgMCBSIC9JbTgwIDE2NCAwIFIgDS9JbTgxIDE2MSAwIFIgL0ltODIgMTU5IDAgUiAvSW04MyAx NjAgMCBSIC9JbTg0IDE5MCAwIFIgL0ltODUgMTk3IDAgUiANL0ltODYgMTk4IDAgUiAvSW04NyAx OTkgMCBSIC9JbTg4IDE5NiAwIFIgL0ltODkgMTk0IDAgUiAvSW05MCAxOTUgMCBSIA0vSW05MSAy MDAgMCBSIC9JbTkyIDI2MiAwIFIgL0ltOTMgMjA1IDAgUiAvSW05NCAyMDYgMCBSIC9JbTk1IDIw MyAwIFIgDS9JbTk2IDIwMSAwIFIgL0ltOTcgMjAyIDAgUiAvSW05OCAxOTMgMCBSIC9JbTk5IDE4 MyAwIFIgL0ltMTAwIDE4NCAwIFIgDS9JbTEwMSAxODUgMCBSIC9JbTEwMiAxODIgMCBSIC9JbTEw MyAxODAgMCBSIC9JbTEwNCAxODEgMCBSIC9JbTEwNSA0MzcgMCBSIA0vSW0xMDYgMTg2IDAgUiAv SW0xMDcgMTc5IDAgUiAvSW0xMDggMTkxIDAgUiAvSW0xMDkgMTkyIDAgUiAvSW0xMTAgMTg5IDAg UiANL0ltMTExIDE4NyAwIFIgL0ltMTEyIDE4OCAwIFIgL0ltMTEzIDIwNCAwIFIgL0ltMTE0IDM2 NiAwIFIgL0ltMTE1IDM2NyAwIFIgDS9JbTExNiAzNjkgMCBSIC9JbTExNyAzNjggMCBSIC9JbTEx OCAzNjUgMCBSIC9JbTExOSAzNjEgMCBSIC9JbTEyMCAzNjIgMCBSIA0vSW0xMjEgMzY0IDAgUiAv SW0xMjIgMzYzIDAgUiAvSW0xMjMgMzcwIDAgUiAvSW0xMjQgMzc2IDAgUiAvSW0xMjUgMzc3IDAg UiANL0ltMTI2IDM3OSAwIFIgL0ltMTI3IDM3OCAwIFIgL0ltMTI4IDM3NSAwIFIgL0ltMTI5IDM3 MSAwIFIgL0ltMTMwIDM3MiAwIFIgDS9JbTEzMSAzNzQgMCBSIC9JbTEzMiAzNzMgMCBSIC9JbTEz MyAzNjAgMCBSIC9JbTEzNCAzNDYgMCBSIC9JbTEzNSAzNDcgMCBSIA0vSW0xMzYgMzQ5IDAgUiAv SW0xMzcgMzQ4IDAgUiAvSW0xMzggMzQ1IDAgUiAvSW0xMzkgMzQxIDAgUiAvSW0xNDAgMzQyIDAg UiANL0ltMTQxIDM0NCAwIFIgL0ltMTQyIDM0MyAwIFIgL0ltMTQzIDM4MCAwIFIgL0ltMTQ0IDM1 NiAwIFIgL0ltMTQ1IDM1NyAwIFIgDS9JbTE0NiAzNTkgMCBSIC9JbTE0NyAzNTggMCBSIC9JbTE0 OCAzNTUgMCBSIC9JbTE0OSAzNTEgMCBSIC9JbTE1MCAzNTIgMCBSIA0vSW0xNTEgMzU0IDAgUiAv SW0xNTIgMzUzIDAgUiAvSW0xNTMgMzUwIDAgUiAvSW0xNTQgNDE2IDAgUiAvSW0xNTUgNDA5IDAg UiANL0ltMTU2IDQxMiAwIFIgL0ltMTU3IDQxMyAwIFIgL0ltMTU4IDQxNCAwIFIgL0ltMTU5IDQx MSAwIFIgL0ltMTYwIDQxNSAwIFIgDS9JbTE2MSA0MTAgMCBSIC9JbTE2MiA0MDggMCBSIC9JbTE2 MyA0MTcgMCBSIC9JbTE2NCAzODYgMCBSIC9JbTE2NSAzODggMCBSIA0vSW0xNjYgMzg3IDAgUiAv SW0xNjcgMzg5IDAgUiAvSW0xNjggMzkyIDAgUiAvSW0xNjkgMzkxIDAgUiAvSW0xNzAgMzkwIDAg UiANL0ltMTcxIDQwNyAwIFIgL0ltMTcyIDM4MiAwIFIgL0ltMTczIDM4MSAwIFIgL0ltMTc0IDM4 MyAwIFIgL0ltMTc1IDM4NSAwIFIgDS9JbTE3NiAzODQgMCBSIC9JbTE3NyAzOTMgMCBSIC9JbTE3 OCA0MDIgMCBSIC9JbTE3OSA0MDEgMCBSIC9JbTE4MCA0MDMgMCBSIA0vSW0xODEgNDA2IDAgUiAv SW0xODIgNDA1IDAgUiAvSW0xODMgNDA0IDAgUiAvSW0xODQgNDAwIDAgUiAvSW0xODUgMzk1IDAg UiANL0ltMTg2IDM5NCAwIFIgL0ltMTg3IDM5NiAwIFIgL0ltMTg4IDM5OSAwIFIgL0ltMTg5IDM5 OCAwIFIgL0ltMTkwIDM5NyAwIFIgDS9JbTE5MSAyNjcgMCBSIC9JbTE5MiAyODcgMCBSIC9JbTE5 MyAyODggMCBSIC9JbTE5NCAyOTAgMCBSIC9JbTE5NSAyODkgMCBSIA0vSW0xOTYgMjg2IDAgUiAv SW0xOTcgMjgyIDAgUiAvSW0xOTggMjgzIDAgUiAvSW0xOTkgMjg1IDAgUiAvSW0yMDAgMjg0IDAg UiANL0ltMjAxIDI5MSAwIFIgL0ltMjAyIDI5NyAwIFIgL0ltMjAzIDI5OCAwIFIgL0ltMjA0IDMw MCAwIFIgL0ltMjA1IDI5OSAwIFIgDS9JbTIwNiAyOTYgMCBSIC9JbTIwNyAyOTIgMCBSIC9JbTIw OCAyOTMgMCBSIC9JbTIwOSAyOTUgMCBSIC9JbTIxMCAyOTQgMCBSIA0vSW0yMTEgMjgxIDAgUiAv SW0yMTIgMzQwIDAgUiAvSW0yMTMgMjY4IDAgUiAvSW0yMTQgMjcwIDAgUiAvSW0yMTUgMjY5IDAg UiANL0ltMjE2IDI2NiAwIFIgL0ltMjE3IDI2MyAwIFIgL0ltMjE4IDI2NCAwIFIgL0ltMjE5IDI2 NSAwIFIgL0ltMjIwIDI3MSAwIFIgDS9JbTIyMSAyNzcgMCBSIC9JbTIyMiAyNzggMCBSIC9JbTIy MyAyODAgMCBSIC9JbTIyNCAyNzkgMCBSIC9JbTIyNSAyNzYgMCBSIA0vSW0yMjYgMjcyIDAgUiAv SW0yMjcgMjczIDAgUiAvSW0yMjggMjc1IDAgUiAvSW0yMjkgMjc0IDAgUiAvSW0yMzAgMzAxIDAg UiANL0ltMjMxIDMyNiAwIFIgL0ltMjMyIDMyNyAwIFIgL0ltMjMzIDMyOSAwIFIgL0ltMjM0IDMy OCAwIFIgL0ltMjM1IDMyNSAwIFIgDS9JbTIzNiAzMjEgMCBSIC9JbTIzNyAzMjIgMCBSIC9JbTIz OCAzMjQgMCBSIC9JbTIzOSAzMjMgMCBSIC9JbTI0MCAzMzAgMCBSIA0vSW0yNDEgMzM2IDAgUiAv SW0yNDIgMzM3IDAgUiAvSW0yNDMgMzM5IDAgUiAvSW0yNDQgMzM4IDAgUiAvSW0yNDUgMzM1IDAg UiANL0ltMjQ2IDMzMSAwIFIgL0ltMjQ3IDMzMiAwIFIgL0ltMjQ4IDMzNCAwIFIgL0ltMjQ5IDMz MyAwIFIgL0ltMjUwIDMyMCAwIFIgDS9JbTI1MSAzMDYgMCBSIC9JbTI1MiAzMDcgMCBSIC9JbTI1 MyAzMDkgMCBSIC9JbTI1NCAzMDggMCBSIC9JbTI1NSAzMDUgMCBSIA0vSW0yNTYgMzAyIDAgUiAv SW0yNTcgMzAzIDAgUiAvSW0yNTggMzA0IDAgUiAvSW0yNTkgMzEwIDAgUiAvSW0yNjAgMzE2IDAg UiANL0ltMjYxIDMxNyAwIFIgL0ltMjYyIDMxOSAwIFIgL0ltMjYzIDMxOCAwIFIgL0ltMjY0IDMx NSAwIFIgL0ltMjY1IDMxMSAwIFIgDS9JbTI2NiAzMTIgMCBSIC9JbTI2NyAzMTQgMCBSIC9JbTI2 OCAzMTMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDI2IDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiAxMTkgMCBSIC9DczggMTIwIDAgUiAvQ3M5IDEyMiAwIFIgL0NzMTAgMTIxIDAgUiAv Q3MxMSAxMTggMCBSIA0vQ3MxMiAxMTUgMCBSIC9DczEzIDExNiAwIFIgL0NzMTQgMTIzIDAgUiAv Q3MxNSAxMTcgMCBSIC9DczE2IDEzMCAwIFIgDS9DczE3IDEyOSAwIFIgL0NzMTggMTMyIDAgUiAv Q3MxOSAxMzEgMCBSIC9DczIwIDEyNCAwIFIgL0NzMjEgMTI4IDAgUiANL0NzMjIgMTI1IDAgUiAv Q3MyMyAxMjcgMCBSIC9DczI0IDEyNiAwIFIgL0NzMjUgMTExIDAgUiAvQ3MyNiA5OCAwIFIgDS9D czI3IDk3IDAgUiAvQ3MyOCA5OSAwIFIgL0NzMjkgMTAxIDAgUiAvQ3MzMCAxMDAgMCBSIC9DczMx IDk2IDAgUiANL0NzMzIgOTIgMCBSIC9DczMzIDkzIDAgUiAvQ3MzNCA5NSAwIFIgL0NzMzUgOTQg MCBSIC9DczM2IDEwMiAwIFIgDS9DczM3IDExMCAwIFIgL0NzMzggMTA5IDAgUiAvQ3MzOSAxMTQg MCBSIC9DczQwIDExMyAwIFIgL0NzNDEgMTEyIDAgUiANL0NzNDIgMTA4IDAgUiAvQ3M0MyAxMDQg MCBSIC9DczQ0IDEwMyAwIFIgL0NzNDUgMTA1IDAgUiAvQ3M0NiAxMDcgMCBSIA0vQ3M0NyAxMDYg MCBSID4+IA0+PiANZW5kb2JqDTY5IDAgb2JqDTw8IC9MZW5ndGggMzYxMyAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiYxXy65lOw2c769YP3DTsfMeNxICCSTUQ8SoeQhEg6AH/D5e b5eTlb3Vk9PnuJIVV7lsf/n6My/ffy60/fv5/V+vL7/+Rsvffr64uFiXUsl5WlL0yy+F/fLfv7z+ +vqygr5+E4B3dfHLt6+/f/nlt/L/fyzk0vK/hfzyu+WPf/LLn1+0/H15EYf1tLYeRsuP8/8ltPX0 f76+vY6zXPZxO6+1NYAonYgU9C9WyH/kUu9KXX7xLkX5jhTYxdbaklt1iXxavv94ffnND1p+9e/X H7Z4dtRi6hGF5EvCheAbQS7zBoj1ALRyXOHbBQj6ihjKAGGuiHBFzmWACPKbG5HeflSRH+oNyPqj aqWi3h1cYnlEceHOU3kXb55Q7/joQm1dOLNL5QpvExr2eHmvv+NFRG8B8F4NIBd96L8oRsc3a8QT EoJru5aCC2lEQkf0hYCsktKGaJx4AClErqrvUootD7esXAQFifBhQ4RJLzxlGC8HqXfk9zfE4Kq6 AQTVUsqKj+hS2JIlf1EU1okGLwjmtwHrBQzhgMg3uXQni/0nkKp5ZxRjFun0EGExKRNhzWLgEkYQ YJFpouATwmhu6pbkyJdBkg3zDFppFEYfJlSqWzhMIGLJ1RLJCcwhcekBQCPnSbVvgJVEUq8oExIP AFI409YOMAQqZYnbx9x/ElWX7zcErxnnkPtPQvICgTfELjxKR1RF/o4Ey1p6m9OYXR72veC4Ju2H UkGpL9gQNM/NNxpBgOnAz0ZyIAzVAZslDxHAdUjvX2LYDlmzPbxD2CbV8wvUd9ztzUAM3/XJc894 mYiaim+6uIeZQsajn0gky8TSMxhpUqkXBBiMPNHVATEUxvAJBDiMM5s6IaZiFe3ZpRpGt1DRbS3m ieWeEBZXTEPLlVtiphEEiI/lg7cI9+qWmDT3NUP3PCHYcGPVqg84aqz5sNNMbFC9OGgcgKwnk+Sf a3eLN7TTbF46AEB6mlnQDngu25VYqj0APC4FqHMO/Q3IXaJ3WV2ZI3VDfKzaPRxrNoFX5UK6DRRH NJhCs77BNP0LgsyVSQEeEENemjXMC4L0tfdvWQkkGr6l67IXJOlNSPfZ6sroDqQw64HPu5Y9DzAB npIJMDmxVlaReXJLMrlyJzlPWtuBMDnOsB2EPAIUvUXlqM1nGI/PUOpatzcoqBNCUd53QzJAsN+e EEmwcp5cJkV1Qkx+66TST4iMJ6zmgKA/LKammZfeHDc+wg0os41wAxRP+obc9A2JuY8H+gq9i8fU Fgbl5tR/ECa2BE236Wg7ANNaZl1zB0RpJ2osBoFETnhDLofM/V1OZdYzD8gksWsFhkgjTBSF3teU if+cEHEGtdpo/5Hq8DWOIDDGFaXDbv45IUKKVxB07MCj98smpTa7gpNcK6MPkx/K/Zbq4cPq6JII 6qqgxoqdSlpU6qmsrKkUfYUeYqisAY2xlsE1hsqKE/wYgiZfcZbLo8eY/atmzUsYvt9QWcuzY5+I wM6rJENXNCPNBZHxXPVeleQ2igbem9ctYcxiiSu/95hFE2NsrlhfbLBJUiY28ZZyU73YP3dA0Ew0 kFUspdp4JJs9kI0j9R4PTDd0uQTD8RbPRUrkjg8TV9ziAzy4pYn17PHAMDXt6559917DcXmXHyRY 50cpKHppRv0Y0ipUmxbQiTAEhwQEFwojCFIMuwMNL0Gnbfm5ci4Is552EgxUw3iYcsnDNtt8owEm eN0zyHttG8OHiJnrcvPqs4obPwQJJx+Ak5zLAGOq2ketKt0y4srRRryUr9pMfXou7BNjqCefJ8V9 g4B8WTmeC+TCUHFV1XiDb4MN5IKwB+Osn0CkoIP6Mi1+yTTVQd5W2SQNau8ybfkk/1zBF8a6NNg0 zuJRSOnoJNwnTLQlksKkiHcAkkjxzfcUkiFKpYlAXtAt93iTVoJNosZSOwBMu0QFyjf0N1gaJlvE DpARiW9FBSzD2l8gnKm5TU8hklJNslhuGJSgdgbOqYwQQU/spM1dzuLBJR3VDa4JeYiBEYyYdKqy bCYDjFQM3QpJ+bEsLgAqhHFfgUZ+YYxKmN+/P2Q9tRJHrRMc2m9MxTRPpvYLE4NL+h5oWRzjKAWo GGKwRpw1ohxSN8koy4o0ecwByJoWQis17rshjGD0XtS9/QCgWoJ/94riCxgv17cIUZcmPtCjvI74 Z3E9PBullWDrkqaVO4CZBQIDF7XPk1GVNpSuqnaEaEptHBTiRFMHAhUVQLkwoLAr6TChpJ+RwUdx DLowKKqAqxB674Gxsnocz654Sbv+rqbtIY8AJr0V/CSPHm9lEqE1jyGMFhzpg7cb24qsxVV4n7UM xsgrBs2Lb2WIwRRE8DoaPkd+yPqaSZ++IE3XuxZlZxCiuTbodLFMfOvCoMhinpTwgZl4V+crFwQH 9Ag6SzWkEcbkGaWGrevEGKklbN04oJ4Yo7VEH6Rg5mOV8whipJZmZnlhIAXTLnFCjJul+EEGUGta 0HqZDet8ZVZZSmlSmRti4kndRHgAUCx6ykFTOsJRJ/qCzpJ2hFVJeS7HHYASyeFtPG696dFWj/Dm 8sMLHnJqhMET29oBVhb1qTMc4RU2kYD7l09aReIt+66LysizOjowdm7OHhSO3frCROi+mSdecmFQ I3k2Bp8Yo5I8q6QTg0LBLD9BjFbog08TwbBOARQhTugnxCxmGSYQHKROiOlaGQfnlPIIA8JpKs/i MViLUeRy6Cboa9rEIA5M8d7VO8845AUaXWNlU/zEJi6Mkc1s2jkxRjaFns3ihKBqdK+X+aiOIaia Ej74Mq6uqkSXmc2cmJnRjPNsVFPSk9NcAPSaop/Pbl3hbpklJ9mxiil54hoboiO/TIrsQCD1pYID 5tR9VUf8bMbZEYaQOtvpdoSZPetsNd0RQkdQ2a1Aeit5gKhiVQqhpFUch1wBUctRw17fojjsBqIL U7ElzTa1A2N5rHmasQPznDO5xzMNMESwS9QyZf/AIP81TTW2Y0QBSeetfvCeiQZkm/MlDzCRwC4a 9tkWR7mOxUX9bU3rIMSk55gsnzTQQYNvA4O5EKiCxhMrPzBWBQ3nsREAm1+DbWp4hRFAS7rQzIR1 YVAALT+b5QlhdLJWJjZ+YVAzrU5s/MSY7t/aB5gIKdDWvwqD6ggS9VzCfjbLZNfphb2faHkHgFzY g1zMSrQCVq2o3YaiyrBfR10b3hyp8MnEs4UT1BX7MKnfHZD1wMszz9viWeY51X9hFUowUu/hoA32 OLNy91zUBfv07sEiCtIXZDAFz128UQQKPOwJOlQkBwyaCfsKtYdFcWHMw9ukXg+MlYae1rvB88QY /og+wAiHSWP8oyleCHwNwdjVwhBjqCSYCPMAINSorZMp6kvMLFFEzP2szjTTy4WBKYcJpzXsvwfG UMMEq4fZJU+MoaZ9ALHMtImbXJim0waG8pQ2yw2DAmoepa2jp04UXd06FYNVMM+kuQJskhn3ARtt 0qutS5YxbG8bALeaaaVs8cE7ry8AbeHitMeDVTM/N/UtXOYaOH42OlYpsk268hd9xXPzOBBygUtq NHkbb2YGvfnFMkRImqqi2b+9QvKU0ugK0Usm7dhN7tyeHVCuSnoyCu9LXM4CEZ8S28jo17ryjnB5 zHqDlI6YrAkP/ul0eSl3pwd6Oj2Qy/3p/Hg6b7ukCQ+Pp4c1uzY8Pp4eV5gNT4+niw30p+fH09dp qgsvj6eLp/SnP7IqbpX70x9ZjVK33enxkVUJL93p8ZFV2V+pP/2R1f/TXXW9bcJQ9J1f4UcyKRk2 XBOeJrVrJ1VbVS28TNUeIua06ShUhHXav9+55iMQbOUBcK4P5/rcY18Qvl2ie1Xl9mSJ7lUV4dkS 3asq98VLdK+q2PqjJbpXVd7WluheVeHupVcTr6oUObxKXlVJOrxKXlVJObxKXlUpdniVvKpS4vAq eVUlcniVvKqSdniVvKpS6vAqeVWlrcOr5FWVModXyasqBy7QtVdVBC69qr2q6tjhVe1VFeFLr2qv qpocXtVeVRG+9Kr2qqpTh1e1V1W9dXhVe1XVmcOrulf1Kg8+5rkSUuSHwB6q/B3VXQAUaRZBole1 /Vf+ykc9fqeiCkAnikAkLwJ7p0T+N3gMv3z/9iB2xbN5NeJQN3jNbrWGHTcUPjR1a4r2WFern/ld cJP3aLvr+0CKO9y9iEBi8cAXTR4IS3YrkGP0Co0Jdj3fZOALydeSGy1OWQkcLGinBqI9MYCAWHh9 I06mZTrizEM81OWx+Cf21S9LNH8JsE4RN2TYVPiaf+6ykwy3Hm6Bty9N04q3bn5biy7vcv9uxLES tzeMhQxjEON0ZGrT2Sb8FGd6TGeSRBJlnITCTp91STyGcrNaS+yVm4wzKJ731ZOxSTiyAIuTKf40 RrTPRtg1VtNEOvo0LAxqjhMp6qpt6tJiV6YUTHxt521n8+S4oNQprSw1bNaSqTUGQIfjE7/+cCxb 04ivt1fMqX/qCwFFHL6t1jxrX/w27Ul0TLEwWqSbVE7fqebVFd7ye97qptOxk4D5YktnB3Cu58na TrbzzLup2k+9JPgAsCKkXYW9BrGSVqOk06gMYkqnEeUQkWQZBvB8Au4dihD1ii+3OZpKbUN1nryz Q6lG64SelWzMnEI5RqRol2IeOHy4ZAGe+PcCmYdmyH29Taj3EVPkJJVz5CS74HMxMEZIfRExDCAn uoi4GBgjYgwkw8pofCnZEZVNQ84LwwWjxghLf+6aOFV2Ck7eJJ14P/zBemNdNCoDh3jcFVZ4Pzhz pulYBaR6jefPI7Xx//nzmfoWxThk15PHUOpJr8u/D7DZ/RdgAFqQpZcKZW5kc3RyZWFtDWVuZG9i ag03MCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODUgMCBSIA0vUmVzb3VyY2VzIDcx IDAgUiANL0NvbnRlbnRzIDcyIDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4 NDIgXSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYxIF0gDT4+IA1lbmRvYmoNNzEgMCBvYmoNPDwg DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAx NDUgMCBSIC9UVDQgMTQ3IDAgUiA+PiANL1hPYmplY3QgPDwgL0ltMSAyMjQgMCBSIC9JbTIgMjI1 IDAgUiAvSW0zIDIyNiAwIFIgL0ltNCAyMjMgMCBSIC9JbTUgMjIxIDAgUiANL0ltNiAyMjIgMCBS IC9JbTcgMjI3IDAgUiAvSW04IDIzMSAwIFIgL0ltOSAyMzIgMCBSIC9JbTEwIDIzMyAwIFIgDS9J bTExIDIzMCAwIFIgL0ltMTIgMjI4IDAgUiAvSW0xMyAyMjkgMCBSIC9JbTE0IDIyMCAwIFIgL0lt MTUgMjExIDAgUiANL0ltMTYgMjEyIDAgUiAvSW0xNyAyMTAgMCBSIC9JbTE4IDIwOCAwIFIgL0lt MTkgMjA5IDAgUiAvSW0yMCAyMTMgMCBSIA0vSW0yMSAyMTcgMCBSIC9JbTIyIDIxOCAwIFIgL0lt MjMgMjE5IDAgUiAvSW0yNCAyMTYgMCBSIC9JbTI1IDIxNCAwIFIgDS9JbTI2IDIxNSAwIFIgL0lt MjcgMjM0IDAgUiAvSW0yOCAyNTIgMCBSIC9JbTI5IDI1MyAwIFIgL0ltMzAgMjU0IDAgUiANL0lt MzEgMjUxIDAgUiAvSW0zMiAyNDkgMCBSIC9JbTMzIDI1MCAwIFIgL0ltMzQgMjA3IDAgUiAvSW0z NSAyNTkgMCBSIA0vSW0zNiAyNjAgMCBSIC9JbTM3IDI2MSAwIFIgL0ltMzggMjU4IDAgUiAvSW0z OSAyNTYgMCBSIC9JbTQwIDI1NyAwIFIgDS9JbTQxIDI0OCAwIFIgL0ltNDIgMjM4IDAgUiAvSW00 MyAyMzkgMCBSIC9JbTQ0IDI0MCAwIFIgL0ltNDUgMjM3IDAgUiANL0ltNDYgMjM1IDAgUiAvSW00 NyAyMzYgMCBSIC9JbTQ4IDI0MSAwIFIgL0ltNDkgMjQ1IDAgUiAvSW01MCAyNDYgMCBSIA0vSW01 MSAyNDcgMCBSIC9JbTUyIDI0NCAwIFIgL0ltNTMgMjQyIDAgUiAvSW01NCAyNDMgMCBSIC9JbTU1 IDI1NSAwIFIgDS9JbTU2IDE2OSAwIFIgL0ltNTcgMTcwIDAgUiAvSW01OCAxNzEgMCBSIC9JbTU5 IDE2NSAwIFIgL0ltNjAgMTY2IDAgUiANL0ltNjEgMTY3IDAgUiAvSW02MiAxNzIgMCBSIC9JbTYz IDE3NiAwIFIgL0ltNjQgMTc3IDAgUiAvSW02NSAxNzggMCBSIA0vSW02NiAxNzUgMCBSIC9JbTY3 IDE3MyAwIFIgL0ltNjggMTc0IDAgUiAvSW02OSAxNjggMCBSIC9JbTcwIDE1NSAwIFIgDS9JbTcx IDE1NiAwIFIgL0ltNzIgMTU3IDAgUiAvSW03MyAxNTQgMCBSIC9JbTc0IDE1MSAwIFIgL0ltNzUg MTUyIDAgUiANL0ltNzYgMTUzIDAgUiAvSW03NyAxNTggMCBSIC9JbTc4IDE2MiAwIFIgL0ltNzkg MTYzIDAgUiAvSW04MCAxNjQgMCBSIA0vSW04MSAxNjEgMCBSIC9JbTgyIDE1OSAwIFIgL0ltODMg MTYwIDAgUiAvSW04NCAxOTAgMCBSIC9JbTg1IDE5NyAwIFIgDS9JbTg2IDE5OCAwIFIgL0ltODcg MTk5IDAgUiAvSW04OCAxOTYgMCBSIC9JbTg5IDE5NCAwIFIgL0ltOTAgMTk1IDAgUiANL0ltOTEg MjAwIDAgUiAvSW05MiAyNjIgMCBSIC9JbTkzIDIwNSAwIFIgL0ltOTQgMjA2IDAgUiAvSW05NSAy MDMgMCBSIA0vSW05NiAyMDEgMCBSIC9JbTk3IDIwMiAwIFIgL0ltOTggMTkzIDAgUiAvSW05OSAx ODMgMCBSIC9JbTEwMCAxODQgMCBSIA0vSW0xMDEgMTg1IDAgUiAvSW0xMDIgMTgyIDAgUiAvSW0x MDMgMTgwIDAgUiAvSW0xMDQgMTgxIDAgUiAvSW0xMDUgNDM3IDAgUiANL0ltMTA2IDE4NiAwIFIg L0ltMTA3IDE3OSAwIFIgL0ltMTA4IDE5MSAwIFIgL0ltMTA5IDE5MiAwIFIgL0ltMTEwIDE4OSAw IFIgDS9JbTExMSAxODcgMCBSIC9JbTExMiAxODggMCBSIC9JbTExMyAyMDQgMCBSIC9JbTExNCAz NjYgMCBSIC9JbTExNSAzNjcgMCBSIA0vSW0xMTYgMzY5IDAgUiAvSW0xMTcgMzY4IDAgUiAvSW0x MTggMzY1IDAgUiAvSW0xMTkgMzYxIDAgUiAvSW0xMjAgMzYyIDAgUiANL0ltMTIxIDM2NCAwIFIg L0ltMTIyIDM2MyAwIFIgL0ltMTIzIDM3MCAwIFIgL0ltMTI0IDM3NiAwIFIgL0ltMTI1IDM3NyAw IFIgDS9JbTEyNiAzNzkgMCBSIC9JbTEyNyAzNzggMCBSIC9JbTEyOCAzNzUgMCBSIC9JbTEyOSAz NzEgMCBSIC9JbTEzMCAzNzIgMCBSIA0vSW0xMzEgMzc0IDAgUiAvSW0xMzIgMzczIDAgUiAvSW0x MzMgMzYwIDAgUiAvSW0xMzQgMzQ2IDAgUiAvSW0xMzUgMzQ3IDAgUiANL0ltMTM2IDM0OSAwIFIg L0ltMTM3IDM0OCAwIFIgL0ltMTM4IDM0NSAwIFIgL0ltMTM5IDM0MSAwIFIgL0ltMTQwIDM0MiAw IFIgDS9JbTE0MSAzNDQgMCBSIC9JbTE0MiAzNDMgMCBSIC9JbTE0MyAzODAgMCBSIC9JbTE0NCAz NTYgMCBSIC9JbTE0NSAzNTcgMCBSIA0vSW0xNDYgMzU5IDAgUiAvSW0xNDcgMzU4IDAgUiAvSW0x NDggMzU1IDAgUiAvSW0xNDkgMzUxIDAgUiAvSW0xNTAgMzUyIDAgUiANL0ltMTUxIDM1NCAwIFIg L0ltMTUyIDM1MyAwIFIgL0ltMTUzIDM1MCAwIFIgL0ltMTU0IDQxNiAwIFIgL0ltMTU1IDQwOSAw IFIgDS9JbTE1NiA0MTIgMCBSIC9JbTE1NyA0MTMgMCBSIC9JbTE1OCA0MTQgMCBSIC9JbTE1OSA0 MTEgMCBSIC9JbTE2MCA0MTUgMCBSIA0vSW0xNjEgNDEwIDAgUiAvSW0xNjIgNDA4IDAgUiAvSW0x NjMgNDE3IDAgUiAvSW0xNjQgMzg2IDAgUiAvSW0xNjUgMzg4IDAgUiANL0ltMTY2IDM4NyAwIFIg L0ltMTY3IDM4OSAwIFIgL0ltMTY4IDM5MiAwIFIgL0ltMTY5IDM5MSAwIFIgL0ltMTcwIDM5MCAw IFIgDS9JbTE3MSA0MDcgMCBSIC9JbTE3MiAzODIgMCBSIC9JbTE3MyAzODEgMCBSIC9JbTE3NCAz ODMgMCBSIC9JbTE3NSAzODUgMCBSIA0vSW0xNzYgMzg0IDAgUiAvSW0xNzcgMzkzIDAgUiAvSW0x NzggNDAyIDAgUiAvSW0xNzkgNDAxIDAgUiAvSW0xODAgNDAzIDAgUiANL0ltMTgxIDQwNiAwIFIg L0ltMTgyIDQwNSAwIFIgL0ltMTgzIDQwNCAwIFIgL0ltMTg0IDQwMCAwIFIgL0ltMTg1IDM5NSAw IFIgDS9JbTE4NiAzOTQgMCBSIC9JbTE4NyAzOTYgMCBSIC9JbTE4OCAzOTkgMCBSIC9JbTE4OSAz OTggMCBSIC9JbTE5MCAzOTcgMCBSIA0vSW0xOTEgMjY3IDAgUiAvSW0xOTIgMjg3IDAgUiAvSW0x OTMgMjg4IDAgUiAvSW0xOTQgMjkwIDAgUiAvSW0xOTUgMjg5IDAgUiANL0ltMTk2IDI4NiAwIFIg L0ltMTk3IDI4MiAwIFIgL0ltMTk4IDI4MyAwIFIgL0ltMTk5IDI4NSAwIFIgL0ltMjAwIDI4NCAw IFIgDS9JbTIwMSAyOTEgMCBSIC9JbTIwMiAyOTcgMCBSIC9JbTIwMyAyOTggMCBSIC9JbTIwNCAz MDAgMCBSIC9JbTIwNSAyOTkgMCBSIA0vSW0yMDYgMjk2IDAgUiAvSW0yMDcgMjkyIDAgUiAvSW0y MDggMjkzIDAgUiAvSW0yMDkgMjk1IDAgUiAvSW0yMTAgMjk0IDAgUiANL0ltMjExIDI4MSAwIFIg L0ltMjEyIDM0MCAwIFIgL0ltMjEzIDI2OCAwIFIgL0ltMjE0IDI3MCAwIFIgL0ltMjE1IDI2OSAw IFIgDS9JbTIxNiAyNjYgMCBSIC9JbTIxNyAyNjMgMCBSIC9JbTIxOCAyNjQgMCBSIC9JbTIxOSAy NjUgMCBSIC9JbTIyMCAyNzEgMCBSIA0vSW0yMjEgMjc3IDAgUiAvSW0yMjIgMjc4IDAgUiAvSW0y MjMgMjgwIDAgUiAvSW0yMjQgMjc5IDAgUiAvSW0yMjUgMjc2IDAgUiANL0ltMjI2IDI3MiAwIFIg L0ltMjI3IDI3MyAwIFIgL0ltMjI4IDI3NSAwIFIgL0ltMjI5IDI3NCAwIFIgL0ltMjMwIDMwMSAw IFIgDS9JbTIzMSAzMjYgMCBSIC9JbTIzMiAzMjcgMCBSIC9JbTIzMyAzMjkgMCBSIC9JbTIzNCAz MjggMCBSIC9JbTIzNSAzMjUgMCBSIA0vSW0yMzYgMzIxIDAgUiAvSW0yMzcgMzIyIDAgUiAvSW0y MzggMzI0IDAgUiAvSW0yMzkgMzIzIDAgUiAvSW0yNDAgMzMwIDAgUiANL0ltMjQxIDMzNiAwIFIg L0ltMjQyIDMzNyAwIFIgL0ltMjQzIDMzOSAwIFIgL0ltMjQ0IDMzOCAwIFIgL0ltMjQ1IDMzNSAw IFIgDS9JbTI0NiAzMzEgMCBSIC9JbTI0NyAzMzIgMCBSIC9JbTI0OCAzMzQgMCBSIC9JbTI0OSAz MzMgMCBSIC9JbTI1MCAzMjAgMCBSIA0vSW0yNTEgMzA2IDAgUiAvSW0yNTIgMzA3IDAgUiAvSW0y NTMgMzA5IDAgUiAvSW0yNTQgMzA4IDAgUiAvSW0yNTUgMzA1IDAgUiANL0ltMjU2IDMwMiAwIFIg L0ltMjU3IDMwMyAwIFIgL0ltMjU4IDMwNCAwIFIgL0ltMjU5IDMxMCAwIFIgL0ltMjYwIDMxNiAw IFIgDS9JbTI2MSAzMTcgMCBSIC9JbTI2MiAzMTkgMCBSIC9JbTI2MyAzMTggMCBSIC9JbTI2NCAz MTUgMCBSIC9JbTI2NSAzMTEgMCBSIA0vSW0yNjYgMzEyIDAgUiAvSW0yNjcgMzE0IDAgUiAvSW0y NjggMzEzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQyNiAwIFIgPj4gDS9Db2xvclNwYWNl IDw8IC9DczYgMTE5IDAgUiAvQ3M4IDEyMCAwIFIgL0NzOSAxMjIgMCBSIC9DczEwIDEyMSAwIFIg L0NzMTEgMTE4IDAgUiANL0NzMTIgMTE1IDAgUiAvQ3MxMyAxMTYgMCBSIC9DczE0IDEyMyAwIFIg L0NzMTUgMTE3IDAgUiAvQ3MxNiAxMzAgMCBSIA0vQ3MxNyAxMjkgMCBSIC9DczE4IDEzMiAwIFIg L0NzMTkgMTMxIDAgUiAvQ3MyMCAxMjQgMCBSIC9DczIxIDEyOCAwIFIgDS9DczIyIDEyNSAwIFIg L0NzMjMgMTI3IDAgUiAvQ3MyNCAxMjYgMCBSIC9DczI1IDExMSAwIFIgL0NzMjYgOTggMCBSIA0v Q3MyNyA5NyAwIFIgL0NzMjggOTkgMCBSIC9DczI5IDEwMSAwIFIgL0NzMzAgMTAwIDAgUiAvQ3Mz MSA5NiAwIFIgDS9DczMyIDkyIDAgUiAvQ3MzMyA5MyAwIFIgL0NzMzQgOTUgMCBSIC9DczM1IDk0 IDAgUiAvQ3MzNiAxMDIgMCBSIA0vQ3MzNyAxMTAgMCBSIC9DczM4IDEwOSAwIFIgL0NzMzkgMTE0 IDAgUiAvQ3M0MCAxMTMgMCBSIC9DczQxIDExMiAwIFIgDS9DczQyIDEwOCAwIFIgL0NzNDMgMTA0 IDAgUiAvQ3M0NCAxMDMgMCBSIC9DczQ1IDEwNSAwIFIgL0NzNDYgMTA3IDAgUiANL0NzNDcgMTA2 IDAgUiA+PiANPj4gDWVuZG9iag03MiAwIG9iag08PCAvTGVuZ3RoIDM1MjIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV8uuZTsNnO+vWD9w07HzHjcSAgkk1EPEqHkIRIOgB/w+ Xm+Xk5W91ZPT57iSFVe5bH/5+jMv338utP37+f1fry+//kbL336+uLhYl1LJeVpS9Msvhf3y37+8 /vr6soK+fhOAd3Xxy7evv3/55bfy/38s5NLyv4X88rvlj3/yy59ftPx9eRGH9bS2HkbLj/P/JbT1 9H++vr2Os1z2cTuvtTWAKJ2IFPQvVsh/5FLvSl1+8S5F+Y4U2MXW2pJbdYl8Wr7/eH35zQ9afvXv 1x+2eHbUYuoRheRLwoXgG0Eu8waI9QC0clzh2wUI+ooYygBhrohwRc5lgAjymxuR3n5UkR/qDcj6 o2qlot4dXGJ5RHHhzlN5F2+eUO/46EJtXTizS+UKbxMa9nh5r7/jRURvAfBeDSAXfei/KEbHN2vE ExKCa7uWggtpREJH9IWArJLShmiceAApRK6q71KKLQ+3rFwEBYnwYUOESS88ZRgvB6l35Pc3xOCq ugEE1VLKio/oUtiSJX9RFNaJBi8I5rcB6wUM4YDIN7l0J4v9J5CqeWcUYxbp9BBhMSkTYc1i4BJG EGCRaaLgE8JobuqW5MiXQZIN8wxaaRRGHyZUqls4TCBiydUSyQnMIXHpAUAj50m1b4CVRFKvKBMS DwBSONPWDjAEKmWJ28fcfxJVl+83BK8Z55D7T0LyAoE3xC48SkdURf6OBMtaepvTmF0e9r3guCbt h1JBqS/YEDTPzTcaQYDpwM9GciAM1QGbJQ8RwHVI719i2A5Zsz28Q9gm1fML1Hfc7c1ADN/1yXPP eJmImopvuriHmULGo59IJMvE0jMYaVKpFwQYjDzR1QExFMbwCQQ4jDObOiGmYhXt2aUaRrdQ0W0t 5onlnhAWV0xDy5VbYqYRBIiP5YO3CPfqlpg09zVD9zwh2HBj1aoPOGqs+bDTTGxQvThoHICsJ5Pk n2t3ize002xeOgBAeppZ0A54LtuVWKo9ADwuBahzDv0NyF2id1ldmSN1Q3ys2j0cazaBV+VCug0U RzSYQrO+wTT9C4LMlUkBHhBDXpo1zAuC9LX3b1kJJBq+peuyFyTpTUj32erK6A6kMOuBz7uWPQ8w AZ6SCTA5sVZWkXlySzK5cic5T1rbgTA5zrAdhDwCFL1F5ajNZxiPz1DqWrc3KKgTQlHed0MyQLDf nhBJsHKeXCZFdUJMfuuk0k+IjCes5oCgPyymppmX3hw3PsINKLONcAMUT/qG3PQNibmPB/oKvYvH 1BYG5ebUfxAmtgRNt+loOwDTWmZdcwdEaSdqLAaBRE54Qy6HzP1dTmXWMw/IJLFrBYZII0wUhd7X lIn/nBBxBrXaaP+R6vA1jiAwxhWlw27+OSFCilcQdOzAo/fLJqU2u4KTXCujD5Mfyv2W6uHD6uiS COqqoMaKnUpaVOqprKypFH2FHmKorAGNsZbBNYbKihP8GIImX3GWy6PHmP2rZs1LGL7fUFnLs2Of iMDOqyRDVzQjzQWR8Vz1XpXkNooG3pvXLWHMYokrv/eYRRNjbK5YX2ywSVImNvGWclO92D93QNBM NJBVLKXaeCSbPZCNI/UeD0w3dLkEw/EWz0VK5I4PE1fc4gM8uKWJ9ezxwDA17eueffdew3F5lx8k WOdHKSh6aUb9GNIqVJsW0IkwBIcEBBcKIwhSDLsDDS9Bp235uXIuCLOedhIMVMN4mHLJwzbbfKMB JnjdM8h7bRvDh4iZ63Lz6rOKGz8ECScfgJOcywBjqtpHrSrdMuLK0Ua8lK/aTH16LuwTY6gnnyfF fYOAfFk5ngvkwlBxVdV4g2+DDeSCsAfjrJ9ApKCD+jItfsk01UHeVtkkDWrvMm35JP9cwRfGujTY NM7iUUjp6CTcJ0y0JZLCpIh3AJJI8c33FJIhSqWJQF7QLfd4k1aCTaLGUjsATLtEBco39DdYGiZb xA6QEYlvRQUsw9pfIJypuU1PIZJSTbJYbhiUoHYGzqmMEEFP7KTNXc7iwSUd1Q2uCXmIgRGMmHSq smwmA4xUDN0KSfmxLC4AKoRxX4FGfmGMSpjfvz9kPbUSR60THNpvTMU0T6b2CxODS/oeaFkc4ygF qBhisEacNaIcUjfJKMuKNHnMAciaFkIrNe67IYxg9F7Uvf0AoFqCf/eK4gsYL9e3CFGXJj7Qo7yO +GdxPTwbpZVg65KmlTuAmQUCAxe1z5NRlTaUrqp2hGhKbRwU4kRTBwIVFUC5MKCwK+kwoaSfkcFH cQy6MCiqgKsQeu+BsbJ6HM+ueEm7/q6m7SGPACa9Ffwkjx5vZRKhNY8hjBYc6YO3G9uKrMVVeJ+1 DMbIKwbNi29liMEURPA6Gj5Hfsj6mkmfviBN17sWZWcQork26HSxTHzrwqDIYp6U8IGZeFfnKxcE B/QIOks1pBHG5Bmlhq3rxBipJWzdOKCeGKO1RB+kYOZjlfMIYqSWZmZ5YSAF0y5xQoybpfhBBlBr WtB6mQ3rfGVWWUppUpkbYuJJ3UR4AFAsespBUzrCUSf6gs6SdoRVSXkuxx2AEsnhbTxuvenRVo/w 5vLDCx5yaoTBE9vaAVYW9akzHOEVNpGA+5dPWkXiLfuui8rIszo6MHZuzh4Ujt36wkTovpknXnJh UCN5NgafGKOSPKukE4NCwSw/QYxW6INPE8GwTgEUIU7oJ8QsZhkmEBykTojpWhkH55TyCAPCaSrP 4jFYi1Hkcugm6GvaxCAOTPHe1TvPOOQFGl1jZVP8xCYujJHNbNo5MUY2hZ7N4oSganSvl/mojiGo mhI++DKurqpEl5nNnJiZ0YzzbFRT0pPTXAD0mqKfz25d4W6ZJSfZsYopeeIaG6Ijv0yK7EAg9aWC A+bUfVVH/GzG2RGGkDrb6XaEmT3rbDXdEUJHUNmtQHoreYCoYlUKoaRVHIdcAVHLUcNe36I47Aai C1OxJc02tQNjeax5mrED85wzucczDTBEsEvUMmX/wCD/NU01tmNEAUnnrX7wnokGZJvzJQ8wkcAu GvbZFke5jsVF/W1N6yDEpOeYLJ800EGDbwODuRCogsYTKz8wVgUN57ERAJtfg21qeIURQEu60MyE dWFQAC0/m+UJYXSyViY2fmFQM61ObPzEmO7f2geYCCnQ1r8Kg+oIEvVcwn42y2TX6YW9n2h5B4Bc 2INczEq0AlatqN2GosqwX0ddG94cqfDJxLOFE9QV+zCp3x2Q9cDLM8/b4lnmOdV/YRVKMFLv4aAN 9jizcvdc1AX79O7BIgrSF2QwBc9dvFEECjzsCTpUJAcMmgn7CrWHRXFhzMPbpF4PjJWGnta7wfPE GP6IPsAIh0lj/KMpXgh8DcHY1cIQY6gkmAjzACDUqK2TKepLzCxRRMz9rM4008uFgSmHCac17L8H xlDDBKuH2SVPjKGmfQCxzLSJm1yYptMGhvKUNssNgwJqHqWto6dOFF3dOhWDVTDPpLkCbJIZ9wEb bdKrrUuWMWxvGwC3mmmlbPHBO68vAG3h4rTHg1UzPzf1LVzmGjh+NjpWKbJNuvIXfcVz8zgQcoFL ajR5G29mBr35xTJESJqqotm/vULylNLoCtFLJu3YTe7cnh1Qrkp6MgrvS1zOAhGfEtvI6Ne68o5w ecx6g5SOmKwJD/7pdHkpd6cHejo9kMv96fx4Om+7pAkPj6eHNbs2PD6eHleYDU+Pp4sN9Kfnx9PX aaoLL4+ni6f0pz+yKm6V+9MfWY1St93p8ZFVCS/d6fGRVdlfqT/9kdX/814Gu20CQRi++ynm2B7c gvFucI5NnEPVQ6TyAltY7G0wGwEO8oO0z9uZBceY3YnaSq0ixSSa/Wf4P368i+Wpr85Spe2Jr85S xfKNr85SpX2xr85SxVd/5KuzVOm15quzVDHdflbXLFURBbIqWKoiDmRVsFTFKpBVwVIVSSCrgqUq 1oGsCpaqEIGsCpaqkIGsCpaquAlkVbBURRrIqmCpik0gq4KlSoWeumSpYqGfVclSlUkgq5KliuV+ ViVLVYpAViVLFcv9rEqWqrwJZFWyVGUayKpkqcpNIKtypPopW3zMshXEkJUL96VK56jhA4UiSRBi 3Ku6/Vd2oK96/GnzeoHjRBESzfLxcgVZv3h3t4UHZSr7ohuwDXzR6kXDo61Mfnqffadu63M3jDm1 cb9JMcLOeFLEN2x2j3+gcOQkf9LCS2PchOBhN6KiobFwpXQVu/pMVxU8bKHfqw46C4XFS10Djlbi aC3NVdFc7Sg8m2M5dEADE5kmfzjMxJBhmrtj0+i6q05Q6NLUuoVncsPgRWWe9O2gF28oe8vhA0Hg 9ybuj/BgOHXe8+t1qh/zqTYRnkMvY+HJh8rQlF2jcl0eK2h026mmgxLdUPCsG2ML6MinnQWSi3Fj EMt0qjIgLmxfgynJz71qobbdWUwX4NRo+fK8Hn1cuaX3AyR5cejG6dW6n2p90zhDaY918YHl426P nvAEY3wN6A0rXM9kDohMoYeEbupw0IVRna5O/6R3fOmdTnqbWuWdwZxcsbiGgZs6iSeLi9b6VSsW v4mFjB7QjGoTNFPA/w/GxJC1W/B4zgZZge5gfDE0xTh8b5snvL/b8CiTSdbxfBIvt7OE0Ovr7Kdb 8PnYdtArMyTEVgUZi+OMnv6NG2/MMBsB/00LvmrV5Pvx5rG9Oth6R88FqLa1OT2pbqzKtJ3js80W vwQYAPWw2ygKZW5kc3RyZWFtDWVuZG9iag03MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl bnQgODUgMCBSIA0vUmVzb3VyY2VzIDc0IDAgUiANL0NvbnRlbnRzIDc1IDAgUiANL1JvdGF0ZSA5 MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYxIF0g DT4+IA1lbmRvYmoNNzQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9J bWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNDUgMCBSIC9UVDQgMTQ3IDAgUiA+PiANL1hPYmplY3Qg PDwgL0ltMSAyMjQgMCBSIC9JbTIgMjI1IDAgUiAvSW0zIDIyNiAwIFIgL0ltNCAyMjMgMCBSIC9J bTUgMjIxIDAgUiANL0ltNiAyMjIgMCBSIC9JbTcgMjI3IDAgUiAvSW04IDIzMSAwIFIgL0ltOSAy MzIgMCBSIC9JbTEwIDIzMyAwIFIgDS9JbTExIDIzMCAwIFIgL0ltMTIgMjI4IDAgUiAvSW0xMyAy MjkgMCBSIC9JbTE0IDIyMCAwIFIgL0ltMTUgMjExIDAgUiANL0ltMTYgMjEyIDAgUiAvSW0xNyAy MTAgMCBSIC9JbTE4IDIwOCAwIFIgL0ltMTkgMjA5IDAgUiAvSW0yMCAyMTMgMCBSIA0vSW0yMSAy MTcgMCBSIC9JbTIyIDIxOCAwIFIgL0ltMjMgMjE5IDAgUiAvSW0yNCAyMTYgMCBSIC9JbTI1IDIx NCAwIFIgDS9JbTI2IDIxNSAwIFIgL0ltMjcgMjM0IDAgUiAvSW0yOCAyNTIgMCBSIC9JbTI5IDI1 MyAwIFIgL0ltMzAgMjU0IDAgUiANL0ltMzEgMjUxIDAgUiAvSW0zMiAyNDkgMCBSIC9JbTMzIDI1 MCAwIFIgL0ltMzQgMjA3IDAgUiAvSW0zNSAyNTkgMCBSIA0vSW0zNiAyNjAgMCBSIC9JbTM3IDI2 MSAwIFIgL0ltMzggMjU4IDAgUiAvSW0zOSAyNTYgMCBSIC9JbTQwIDI1NyAwIFIgDS9JbTQxIDI0 OCAwIFIgL0ltNDIgMjM4IDAgUiAvSW00MyAyMzkgMCBSIC9JbTQ0IDI0MCAwIFIgL0ltNDUgMjM3 IDAgUiANL0ltNDYgMjM1IDAgUiAvSW00NyAyMzYgMCBSIC9JbTQ4IDI0MSAwIFIgL0ltNDkgMjQ1 IDAgUiAvSW01MCAyNDYgMCBSIA0vSW01MSAyNDcgMCBSIC9JbTUyIDI0NCAwIFIgL0ltNTMgMjQy IDAgUiAvSW01NCAyNDMgMCBSIC9JbTU1IDI1NSAwIFIgDS9JbTU2IDE2OSAwIFIgL0ltNTcgMTcw IDAgUiAvSW01OCAxNzEgMCBSIC9JbTU5IDE2NSAwIFIgL0ltNjAgMTY2IDAgUiANL0ltNjEgMTY3 IDAgUiAvSW02MiAxNzIgMCBSIC9JbTYzIDE3NiAwIFIgL0ltNjQgMTc3IDAgUiAvSW02NSAxNzgg MCBSIA0vSW02NiAxNzUgMCBSIC9JbTY3IDE3MyAwIFIgL0ltNjggMTc0IDAgUiAvSW02OSAxNjgg MCBSIC9JbTcwIDE1NSAwIFIgDS9JbTcxIDE1NiAwIFIgL0ltNzIgMTU3IDAgUiAvSW03MyAxNTQg MCBSIC9JbTc0IDE1MSAwIFIgL0ltNzUgMTUyIDAgUiANL0ltNzYgMTUzIDAgUiAvSW03NyAxNTgg MCBSIC9JbTc4IDE2MiAwIFIgL0ltNzkgMTYzIDAgUiAvSW04MCAxNjQgMCBSIA0vSW04MSAxNjEg MCBSIC9JbTgyIDE1OSAwIFIgL0ltODMgMTYwIDAgUiAvSW04NCAxOTAgMCBSIC9JbTg1IDE5NyAw IFIgDS9JbTg2IDE5OCAwIFIgL0ltODcgMTk5IDAgUiAvSW04OCAxOTYgMCBSIC9JbTg5IDE5NCAw IFIgL0ltOTAgMTk1IDAgUiANL0ltOTEgMjAwIDAgUiAvSW05MiAyNjIgMCBSIC9JbTkzIDIwNSAw IFIgL0ltOTQgMjA2IDAgUiAvSW05NSAyMDMgMCBSIA0vSW05NiAyMDEgMCBSIC9JbTk3IDIwMiAw IFIgL0ltOTggMTkzIDAgUiAvSW05OSAxODMgMCBSIC9JbTEwMCAxODQgMCBSIA0vSW0xMDEgMTg1 IDAgUiAvSW0xMDIgMTgyIDAgUiAvSW0xMDMgMTgwIDAgUiAvSW0xMDQgMTgxIDAgUiAvSW0xMDUg NDM3IDAgUiANL0ltMTA2IDE4NiAwIFIgL0ltMTA3IDE3OSAwIFIgL0ltMTA4IDE5MSAwIFIgL0lt MTA5IDE5MiAwIFIgL0ltMTEwIDE4OSAwIFIgDS9JbTExMSAxODcgMCBSIC9JbTExMiAxODggMCBS IC9JbTExMyAyMDQgMCBSIC9JbTExNCAzNjYgMCBSIC9JbTExNSAzNjcgMCBSIA0vSW0xMTYgMzY5 IDAgUiAvSW0xMTcgMzY4IDAgUiAvSW0xMTggMzY1IDAgUiAvSW0xMTkgMzYxIDAgUiAvSW0xMjAg MzYyIDAgUiANL0ltMTIxIDM2NCAwIFIgL0ltMTIyIDM2MyAwIFIgL0ltMTIzIDM3MCAwIFIgL0lt MTI0IDM3NiAwIFIgL0ltMTI1IDM3NyAwIFIgDS9JbTEyNiAzNzkgMCBSIC9JbTEyNyAzNzggMCBS IC9JbTEyOCAzNzUgMCBSIC9JbTEyOSAzNzEgMCBSIC9JbTEzMCAzNzIgMCBSIA0vSW0xMzEgMzc0 IDAgUiAvSW0xMzIgMzczIDAgUiAvSW0xMzMgMzYwIDAgUiAvSW0xMzQgMzQ2IDAgUiAvSW0xMzUg MzQ3IDAgUiANL0ltMTM2IDM0OSAwIFIgL0ltMTM3IDM0OCAwIFIgL0ltMTM4IDM0NSAwIFIgL0lt MTM5IDM0MSAwIFIgL0ltMTQwIDM0MiAwIFIgDS9JbTE0MSAzNDQgMCBSIC9JbTE0MiAzNDMgMCBS IC9JbTE0MyAzODAgMCBSIC9JbTE0NCAzNTYgMCBSIC9JbTE0NSAzNTcgMCBSIA0vSW0xNDYgMzU5 IDAgUiAvSW0xNDcgMzU4IDAgUiAvSW0xNDggMzU1IDAgUiAvSW0xNDkgMzUxIDAgUiAvSW0xNTAg MzUyIDAgUiANL0ltMTUxIDM1NCAwIFIgL0ltMTUyIDM1MyAwIFIgL0ltMTUzIDM1MCAwIFIgL0lt MTU0IDQxNiAwIFIgL0ltMTU1IDQwOSAwIFIgDS9JbTE1NiA0MTIgMCBSIC9JbTE1NyA0MTMgMCBS IC9JbTE1OCA0MTQgMCBSIC9JbTE1OSA0MTEgMCBSIC9JbTE2MCA0MTUgMCBSIA0vSW0xNjEgNDEw IDAgUiAvSW0xNjIgNDA4IDAgUiAvSW0xNjMgNDE3IDAgUiAvSW0xNjQgMzg2IDAgUiAvSW0xNjUg Mzg4IDAgUiANL0ltMTY2IDM4NyAwIFIgL0ltMTY3IDM4OSAwIFIgL0ltMTY4IDM5MiAwIFIgL0lt MTY5IDM5MSAwIFIgL0ltMTcwIDM5MCAwIFIgDS9JbTE3MSA0MDcgMCBSIC9JbTE3MiAzODIgMCBS IC9JbTE3MyAzODEgMCBSIC9JbTE3NCAzODMgMCBSIC9JbTE3NSAzODUgMCBSIA0vSW0xNzYgMzg0 IDAgUiAvSW0xNzcgMzkzIDAgUiAvSW0xNzggNDAyIDAgUiAvSW0xNzkgNDAxIDAgUiAvSW0xODAg NDAzIDAgUiANL0ltMTgxIDQwNiAwIFIgL0ltMTgyIDQwNSAwIFIgL0ltMTgzIDQwNCAwIFIgL0lt MTg0IDQwMCAwIFIgL0ltMTg1IDM5NSAwIFIgDS9JbTE4NiAzOTQgMCBSIC9JbTE4NyAzOTYgMCBS IC9JbTE4OCAzOTkgMCBSIC9JbTE4OSAzOTggMCBSIC9JbTE5MCAzOTcgMCBSIA0vSW0xOTEgMjY3 IDAgUiAvSW0xOTIgMjg3IDAgUiAvSW0xOTMgMjg4IDAgUiAvSW0xOTQgMjkwIDAgUiAvSW0xOTUg Mjg5IDAgUiANL0ltMTk2IDI4NiAwIFIgL0ltMTk3IDI4MiAwIFIgL0ltMTk4IDI4MyAwIFIgL0lt MTk5IDI4NSAwIFIgL0ltMjAwIDI4NCAwIFIgDS9JbTIwMSAyOTEgMCBSIC9JbTIwMiAyOTcgMCBS IC9JbTIwMyAyOTggMCBSIC9JbTIwNCAzMDAgMCBSIC9JbTIwNSAyOTkgMCBSIA0vSW0yMDYgMjk2 IDAgUiAvSW0yMDcgMjkyIDAgUiAvSW0yMDggMjkzIDAgUiAvSW0yMDkgMjk1IDAgUiAvSW0yMTAg Mjk0IDAgUiANL0ltMjExIDI4MSAwIFIgL0ltMjEyIDM0MCAwIFIgL0ltMjEzIDI2OCAwIFIgL0lt MjE0IDI3MCAwIFIgL0ltMjE1IDI2OSAwIFIgDS9JbTIxNiAyNjYgMCBSIC9JbTIxNyAyNjMgMCBS IC9JbTIxOCAyNjQgMCBSIC9JbTIxOSAyNjUgMCBSIC9JbTIyMCAyNzEgMCBSIA0vSW0yMjEgMjc3 IDAgUiAvSW0yMjIgMjc4IDAgUiAvSW0yMjMgMjgwIDAgUiAvSW0yMjQgMjc5IDAgUiAvSW0yMjUg Mjc2IDAgUiANL0ltMjI2IDI3MiAwIFIgL0ltMjI3IDI3MyAwIFIgL0ltMjI4IDI3NSAwIFIgL0lt MjI5IDI3NCAwIFIgL0ltMjMwIDMwMSAwIFIgDS9JbTIzMSAzMjYgMCBSIC9JbTIzMiAzMjcgMCBS IC9JbTIzMyAzMjkgMCBSIC9JbTIzNCAzMjggMCBSIC9JbTIzNSAzMjUgMCBSIA0vSW0yMzYgMzIx IDAgUiAvSW0yMzcgMzIyIDAgUiAvSW0yMzggMzI0IDAgUiAvSW0yMzkgMzIzIDAgUiAvSW0yNDAg MzMwIDAgUiANL0ltMjQxIDMzNiAwIFIgL0ltMjQyIDMzNyAwIFIgL0ltMjQzIDMzOSAwIFIgL0lt MjQ0IDMzOCAwIFIgL0ltMjQ1IDMzNSAwIFIgDS9JbTI0NiAzMzEgMCBSIC9JbTI0NyAzMzIgMCBS IC9JbTI0OCAzMzQgMCBSIC9JbTI0OSAzMzMgMCBSIC9JbTI1MCAzMjAgMCBSIA0vSW0yNTEgMzA2 IDAgUiAvSW0yNTIgMzA3IDAgUiAvSW0yNTMgMzA5IDAgUiAvSW0yNTQgMzA4IDAgUiAvSW0yNTUg MzA1IDAgUiANL0ltMjU2IDMwMiAwIFIgL0ltMjU3IDMwMyAwIFIgL0ltMjU4IDMwNCAwIFIgL0lt MjU5IDMxMCAwIFIgL0ltMjYwIDMxNiAwIFIgDS9JbTI2MSAzMTcgMCBSIC9JbTI2MiAzMTkgMCBS IC9JbTI2MyAzMTggMCBSIC9JbTI2NCAzMTUgMCBSIC9JbTI2NSAzMTEgMCBSIA0vSW0yNjYgMzEy IDAgUiAvSW0yNjcgMzE0IDAgUiAvSW0yNjggMzEzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDQyNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTE5IDAgUiAvQ3M4IDEyMCAwIFIgL0Nz OSAxMjIgMCBSIC9DczEwIDEyMSAwIFIgL0NzMTEgMTE4IDAgUiANL0NzMTIgMTE1IDAgUiAvQ3Mx MyAxMTYgMCBSIC9DczE0IDEyMyAwIFIgL0NzMTUgMTE3IDAgUiAvQ3MxNiAxMzAgMCBSIA0vQ3Mx NyAxMjkgMCBSIC9DczE4IDEzMiAwIFIgL0NzMTkgMTMxIDAgUiAvQ3MyMCAxMjQgMCBSIC9DczIx IDEyOCAwIFIgDS9DczIyIDEyNSAwIFIgL0NzMjMgMTI3IDAgUiAvQ3MyNCAxMjYgMCBSIC9DczI1 IDExMSAwIFIgL0NzMjYgOTggMCBSIA0vQ3MyNyA5NyAwIFIgL0NzMjggOTkgMCBSIC9DczI5IDEw MSAwIFIgL0NzMzAgMTAwIDAgUiAvQ3MzMSA5NiAwIFIgDS9DczMyIDkyIDAgUiAvQ3MzMyA5MyAw IFIgL0NzMzQgOTUgMCBSIC9DczM1IDk0IDAgUiAvQ3MzNiAxMDIgMCBSIA0vQ3MzNyAxMTAgMCBS IC9DczM4IDEwOSAwIFIgL0NzMzkgMTE0IDAgUiAvQ3M0MCAxMTMgMCBSIC9DczQxIDExMiAwIFIg DS9DczQyIDEwOCAwIFIgL0NzNDMgMTA0IDAgUiAvQ3M0NCAxMDMgMCBSIC9DczQ1IDEwNSAwIFIg L0NzNDYgMTA3IDAgUiANL0NzNDcgMTA2IDAgUiA+PiANPj4gDWVuZG9iag03NSAwIG9iag08PCAv TGVuZ3RoIDM0MjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV8uuZTsNnO+v WD9w07HzHjcSAgkk1EPEqHkIRIOgB/w+Xm+Xk5W91ZPT57iSFVe5bH/5+jMv338utP37+f1fry+/ /kbL336+uLhYl1LJeVpS9Msvhf3y37+8/vr6soK+fhOAd3Xxy7evv3/55bfy/38s5NLyv4X88rvl j3/yy59ftPx9eRGH9bS2HkbLj/P/JbT19H++vr2Os1z2cTuvtTWAKJ2IFPQvVsh/5FLvSl1+8S5F +Y4U2MXW2pJbdYl8Wr7/eH35zQ9afvXv1x+2eHbUYuoRheRLwoXgG0Eu8waI9QC0clzh2wUI+ooY ygBhrohwRc5lgAjymxuR3n5UkR/qDcj6o2qlot4dXGJ5RHHhzlN5F2+eUO/46EJtXTizS+UKbxMa 9nh5r7/jRURvAfBeDSAXfei/KEbHN2vEExKCa7uWggtpREJH9IWArJLShmiceAApRK6q71KKLQ+3 rFwEBYnwYUOESS88ZRgvB6l35Pc3xOCqugEE1VLKio/oUtiSJX9RFNaJBi8I5rcB6wUM4YDIN7l0 J4v9J5CqeWcUYxbp9BBhMSkTYc1i4BJGEGCRaaLgE8JobuqW5MiXQZIN8wxaaRRGHyZUqls4TCBi ydUSyQnMIXHpAUAj50m1b4CVRFKvKBMSDwBSONPWDjAEKmWJ28fcfxJVl+83BK8Z55D7T0LyAoE3 xC48SkdURf6OBMtaepvTmF0e9r3guCbth1JBqS/YEDTPzTcaQYDpwM9GciAM1QGbJQ8RwHVI719i 2A5Zsz28Q9gm1fML1Hfc7c1ADN/1yXPPeJmImopvuriHmULGo59IJMvE0jMYaVKpFwQYjDzR1QEx FMbwCQQ4jDObOiGmYhXt2aUaRrdQ0W0t5onlnhAWV0xDy5VbYqYRBIiP5YO3CPfqlpg09zVD9zwh 2HBj1aoPOGqs+bDTTGxQvThoHICsJ5Pkn2t3ize002xeOgBAeppZ0A54LtuVWKo9ADwuBahzDv0N yF2id1ldmSN1Q3ys2j0cazaBV+VCug0URzSYQrO+wTT9C4LMlUkBHhBDXpo1zAuC9LX3b1kJJBq+ peuyFyTpTUj32erK6A6kMOuBz7uWPQ8wAZ6SCTA5sVZWkXlySzK5cic5T1rbgTA5zrAdhDwCFL1F 5ajNZxiPz1DqWrc3KKgTQlHed0MyQLDfnhBJsHKeXCZFdUJMfuuk0k+IjCes5oCgPyymppmX3hw3 PsINKLONcAMUT/qG3PQNibmPB/oKvYvH1BYG5ebUfxAmtgRNt+loOwDTWmZdcwdEaSdqLAaBRE54 Qy6HzP1dTmXWMw/IJLFrBYZII0wUhd7XlIn/nBBxBrXaaP+R6vA1jiAwxhWlw27+OSFCilcQdOzA o/fLJqU2u4KTXCujD5Mfyv2W6uHD6uiSCOqqoMaKnUpaVOqprKypFH2FHmKorAGNsZbBNYbKihP8 GIImX3GWy6PHmP2rZs1LGL7fUFnLs2OfiMDOqyRDVzQjzQWR8Vz1XpXkNooG3pvXLWHMYokrv/eY RRNjbK5YX2ywSVImNvGWclO92D93QNBMNJBVLKXaeCSbPZCNI/UeD0w3dLkEw/EWz0VK5I4PE1fc 4gM8uKWJ9ezxwDA17eueffdew3F5lx8kWOdHKSh6aUb9GNIqVJsW0IkwBIcEBBcKIwhSDLsDDS9B p235uXIuCLOedhIMVMN4mHLJwzbbfKMBJnjdM8h7bRvDh4iZ63Lz6rOKGz8ECScfgJOcywBjqtpH rSrdMuLK0Ua8lK/aTH16LuwTY6gnnyfFfYOAfFk5ngvkwlBxVdV4g2+DDeSCsAfjrJ9ApKCD+jIt fsk01UHeVtkkDWrvMm35JP9cwRfGujTYNM7iUUjp6CTcJ0y0JZLCpIh3AJJI8c33FJIhSqWJQF7Q Lfd4k1aCTaLGUjsATLtEBco39DdYGiZbxA6QEYlvRQUsw9pfIJypuU1PIZJSTbJYbhiUoHYGzqmM EEFP7KTNXc7iwSUd1Q2uCXmIgRGMmHSqsmwmA4xUDN0KSfmxLC4AKoRxX4FGfmGMSpjfvz9kPbUS R60THNpvTMU0T6b2CxODS/oeaFkc4ygFqBhisEacNaIcUjfJKMuKNHnMAciaFkIrNe67IYxg9F7U vf0AoFqCf/eK4gsYL9e3CFGXJj7Qo7yO+GdxPTwbpZVg65KmlTuAmQUCAxe1z5NRlTaUrqp2hGhK bRwU4kRTBwIVFUC5MKCwK+kwoaSfkcFHcQy6MCiqgKsQeu+BsbJ6HM+ueEm7/q6m7SGPACa9Ffwk jx5vZRKhNY8hjBYc6YO3G9uKrMVVeJ+1DMbIKwbNi29liMEURPA6Gj5Hfsj6mkmfviBN17sWZWcQ ork26HSxTHzrwqDIYp6U8IGZeFfnKxcEB/QIOks1pBHG5Bmlhq3rxBipJWzdOKCeGKO1RB+kYOZj lfMIYqSWZmZ5YSAF0y5xQoybpfhBBlBrWtB6mQ3rfGVWWUppUpkbYuJJ3UR4AFAsespBUzrCUSf6 gs6SdoRVSXkuxx2AEsnhbTxuvenRVo/w5vLDCx5yaoTBE9vaAVYW9akzHOEVNpGA+5dPWkXiLfuu i8rIszo6MHZuzh4Ujt36wkTovpknXnJhUCN5NgafGKOSPKukE4NCwSw/QYxW6INPE8GwTgEUIU7o J8QsZhkmEBykTojpWhkH55TyCAPCaSrP4jFYi1Hkcugm6GvaxCAOTPHe1TvPOOQFGl1jZVP8xCYu jJHNbNo5MUY2hZ7N4oSganSvl/mojiGomhI++DKurqpEl5nNnJiZ0YzzbFRT0pPTXAD0mqKfz25d 4W6ZJSfZsYopeeIaG6Ijv0yK7EAg9aWCA+bUfVVH/GzG2RGGkDrb6XaEmT3rbDXdEUJHUNmtQHor eYCoYlUKoaRVHIdcAVHLUcNe36I47AaiC1OxJc02tQNjeax5mrED85wzucczDTBEsEvUMmX/wCD/ NU01tmNEAUnnrX7wnokGZJvzJQ8wkcAuGvbZFke5jsVF/W1N6yDEpOeYLJ800EGDbwODuRCogsYT Kz8wVgUN57ERAJtfg21qeIURQEu60MyEdWFQAC0/m+UJYXSyViY2fmFQM61ObPzEmO7f2geYCCnQ 1r8Kg+oIEvVcwn42y2TX6YW9n2h5B4Bc2INczEq0AlatqN2GosqwX0ddG94cqfDJxLOFE9QV+zCp 3x2Q9cDLM8/b4lnmOdV/YRVKMFLv4aAN9jizcvdc1AX79O7BIgrSF2QwBc9dvFEECjzsCTpUJAcM mgn7CrWHRXFhzMPbpF4PjJWGnta7wfPEGP6IPsAIh0lj/KMpXgh8DcHY1cIQY6gkmAjzACDUqK2T KepLzCxRRMz9rM4008uFgSmHCac17L8HxlDDBKuH2SVPjKGmfQCxzLSJm1yYptMGhvKUNssNgwJq HqWto6dOFF3dOhWDVTDPpLkCbJIZ9wEbbdKrrUuWMWxvGwC3mmmlbPHBO68vAG3h4rTHg1UzPzf1 LVzmGjh+NjpWKbJNuvIXfcVz8zgQcoFLajR5G29mBr35xTJESJqqotm/vULylNLoCtFLJu3YTe7c nh1Qrkp6MgrvS1zOAhGfEtvI6Ne68o5wecx6g5SOmKwJD/7pdHkpd6cHejo9kMv96fx4Om+7pAkP j6eHNbs2PD6eHleYDU+Pp4sN9Kfnx9PXaaoLL4+ni6f0pz+yKm6V+9MfWY1St93p8ZFVCS/d6fGR VdlfqT/9kdX/U14Fu20CQfTOV+zRPtgFzKzhmLTOIYeqirg1PVC6CFIMFZBa+ZD2e/tmwTTt7kit LBmMZ+fNzNvHzsA8db2LrHJ74noXWYV55noXWeW+2PUusopXf+h6F1nl15rrXWQV6na1moisUujR KomsUuTRKomsUuzRKoms0sGjVRJZpcSjVRJZJfJolURWSXu0SiKrdPRolURWKfVolURWKfNolURW 2dDxrkVWYehqVYus6oNHq1pkFeauVrXIqiaPVrXIKsxdrWqRVX30aFWLrOrUo1Utsqozj1b1wupt HrzJ81hFKq8Ce6jyHDVf4CjUTEKEXtX2X/mZj3p8xrILEE4YYgjLy+B6dwk2dyd1VzRt/90Mqui+ qAfz1Ded+tC3TfmyzZ8YLlnh0OnFHGN0TFjDmBJfA+2Jo7DfDBhaKIvykz39DiWcBxP8924J68C2 821iV+SmbRWCq/uLmnpVlJMNz/6sjXp7UpcGFvwc4ZbFaOxzrJihUM0oA8aKEFm3FXIdrSdVF3yD 1ZPppqbvGGYw41QMk3rcDHMd2Of70+N2P3uNMlbcbr6gHmgMsGcjnfxbGX44ZQgxfb4qQ7yWATMI r7h/Hqc1qiXBaujPWD8UU1kvcf2NuVtc8546QDgA+I8w0Oix2c349QppS1MWXPBRnYvuxVY5guSz NHUS2MDoWz+OzefWoL5VP5wLW+FLbVDwyS7eXVcjxthCXtHXQD9ulszHLeS/2W8/5fd/bH8QYjOI o3125GzRLxCY4XQ5GrLRPJjpeegY85QHqJB9raUY53DmIHcMVBAbzrvBBFXwS4ABAPoyP18KZW5k c3RyZWFtDWVuZG9iag03NiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlw ZSANL0ZpcnN0Q2hhciAxNDkgDS9MYXN0Q2hhciAxNTAgDS9XaWR0aHMgWyAzNTAgNTU2IF0gDS9F bmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FyaWFsIA0vRm9udERlc2NyaXB0 b3IgNzggMCBSIA0+PiANZW5kb2JqDTc3IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTI0IA0vV2lkdGhzIFsgNjAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgNjAwIDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgDTAgMCAwIDAgMCA2MDAgMCAwIDAgMCAwIDYwMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAw IDYwMCA2MDAgNjAwIA0wIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCAwIDAgNjAwIDAgMCA2MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rpbmcg DS9CYXNlRm9udCAvQ291cmllck5ld1BTLUJvbGRNVCANL0ZvbnREZXNjcmlwdG9yIDc5IDAgUiAN Pj4gDWVuZG9iag03OCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkw NSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC02 NjUgLTMyNSAyMDI4IDEwMzcgXSANL0ZvbnROYW1lIC9BcmlhbCANL0l0YWxpY0FuZ2xlIDAgDS9T dGVtViAwIA0+PiANZW5kb2JqDTc5IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B c2NlbnQgODMyIA0vQ2FwSGVpZ2h0IDU5MyANL0Rlc2NlbnQgLTMwMCANL0ZsYWdzIDM0IA0vRm9u dEJCb3ggWyAtNDYgLTcxMCA3MDIgMTIyMSBdIA0vRm9udE5hbWUgL0NvdXJpZXJOZXdQUy1Cb2xk TVQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTAwIA0+PiANZW5kb2JqDTgwIDAgb2JqDTw8IA0v UyAvRCANPj4gDWVuZG9iag04MSAwIG9iag08PCANL051bXMgWyAwIDgwIDAgUiBdIA0+PiANZW5k b2JqDTgyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgOTAgMCBSIDEgMCBSIDQgMCBS IDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5IDAgUiAyMiAwIFIgMjUgMCBSIA1dIA0vQ291 bnQgMTAgDS9QYXJlbnQgODMgMCBSIA0+PiANZW5kb2JqDTgzIDAgb2JqDTw8IA0vVHlwZSAvUGFn ZXMgDS9LaWRzIFsgODIgMCBSIDg0IDAgUiA4NSAwIFIgXSANL0NvdW50IDI2IA0+PiANZW5kb2Jq DTg0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjggMCBSIDMxIDAgUiAzNCAwIFIg MzcgMCBSIDQwIDAgUiA0MyAwIFIgNDYgMCBSIDQ5IDAgUiA1MiAwIFIgNTUgMCBSIA1dIA0vQ291 bnQgMTAgDS9QYXJlbnQgODMgMCBSIA0+PiANZW5kb2JqDTg1IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZXMgDS9LaWRzIFsgNTggMCBSIDYxIDAgUiA2NCAwIFIgNjcgMCBSIDcwIDAgUiA3MyAwIFIgXSAN L0NvdW50IDYgDS9QYXJlbnQgODMgMCBSIA0+PiANZW5kb2JqDTg2IDAgb2JqDTw8IA0vQ3JlYXRp b25EYXRlIChEOjIwMDMxMTEyMjIwODAzKzA4JzAwJykNL01vZERhdGUgKEQ6MjAwMzExMTIyMjA4 MDMrMDgnMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDUuMC41IFwoV2luZG93c1wp KQ0+PiANZW5kb2JqDTg3IDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9M ZW5ndGggNjQ4ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1wQ2VoaUh6 cmVTek5UY3prYzlkJyBieXRlcz0nNjQ3Jz8+PHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFk b2JlLmNvbS9pWC8xLjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8v bnMuYWRvYmUuY29tL3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRm LzEuMy8nIHBkZjpDcmVhdGlvbkRhdGU9JzIwMDMtMTEtMTJUMTQ6MDg6MDNaJyBwZGY6TW9kRGF0 ZT0nMjAwMy0xMS0xMlQxNDowODowM1onIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIg NS4wLjUgKFdpbmRvd3MpJy8+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDMtMTEtMTJUMTQ6MDg6MDNaJyB4YXA6TW9kaWZ5 RGF0ZT0nMjAwMy0xMS0xMlQxNDowODowM1onIHhhcDpNZXRhZGF0YURhdGU9JzIwMDMtMTEtMTJU MTQ6MDg6MDNaJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVuZHN0cmVhbQ1lbmRv YmoNeHJlZg0wIDg4IA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwOTc3ODUgMDAwMDAgbg0KMDAw MDA5NzkzOSAwMDAwMCBuDQowMDAwMTAyNjMxIDAwMDAwIG4NCjAwMDAxMDU3NjUgMDAwMDAgbg0K MDAwMDEwNTkxOSAwMDAwMCBuDQowMDAwMTEwNjIzIDAwMDAwIG4NCjAwMDAxMTQwNDggMDAwMDAg bg0KMDAwMDExNDIwMiAwMDAwMCBuDQowMDAwMTE4ODk0IDAwMDAwIG4NCjAwMDAxMjIwNDQgMDAw MDAgbg0KMDAwMDEyMjIwMSAwMDAwMCBuDQowMDAwMTI2OTA3IDAwMDAwIG4NCjAwMDAxMzA4OTQg MDAwMDAgbg0KMDAwMDEzMTA1MSAwMDAwMCBuDQowMDAwMTM1NzY5IDAwMDAwIG4NCjAwMDAxMzk3 OTAgMDAwMDAgbg0KMDAwMDEzOTk0NyAwMDAwMCBuDQowMDAwMTQ0NjUzIDAwMDAwIG4NCjAwMDAx NDgxNzIgMDAwMDAgbg0KMDAwMDE0ODMyOSAwMDAwMCBuDQowMDAwMTUzMDM1IDAwMDAwIG4NCjAw MDAxNTY3MTAgMDAwMDAgbg0KMDAwMDE1Njg2NyAwMDAwMCBuDQowMDAwMTYxNTYwIDAwMDAwIG4N CjAwMDAxNjQ3MTAgMDAwMDAgbg0KMDAwMDE2NDg2NyAwMDAwMCBuDQowMDAwMTY5NTczIDAwMDAw IG4NCjAwMDAxNzQxODQgMDAwMDAgbg0KMDAwMDE3NDM0MSAwMDAwMCBuDQowMDAwMTc5MDU5IDAw MDAwIG4NCjAwMDAxODI3NjAgMDAwMDAgbg0KMDAwMDE4MjkxNyAwMDAwMCBuDQowMDAwMTg3NjM1 IDAwMDAwIG4NCjAwMDAxOTEyMzMgMDAwMDAgbg0KMDAwMDE5MTM5MCAwMDAwMCBuDQowMDAwMTk2 MTA4IDAwMDAwIG4NCjAwMDAxOTk2MjAgMDAwMDAgbg0KMDAwMDE5OTc3NyAwMDAwMCBuDQowMDAw MjA0NDk1IDAwMDAwIG4NCjAwMDAyMDgxMzggMDAwMDAgbg0KMDAwMDIwODI5NSAwMDAwMCBuDQow MDAwMjEzMDAxIDAwMDAwIG4NCjAwMDAyMTYzOTkgMDAwMDAgbg0KMDAwMDIxNjU1NiAwMDAwMCBu DQowMDAwMjIxMjc0IDAwMDAwIG4NCjAwMDAyMjQ5OTcgMDAwMDAgbg0KMDAwMDIyNTE1NCAwMDAw MCBuDQowMDAwMjI5ODYwIDAwMDAwIG4NCjAwMDAyMzMzNTggMDAwMDAgbg0KMDAwMDIzMzUxNSAw MDAwMCBuDQowMDAwMjM4MjIxIDAwMDAwIG4NCjAwMDAyNDE3MzEgMDAwMDAgbg0KMDAwMDI0MTg4 OCAwMDAwMCBuDQowMDAwMjQ2NTk0IDAwMDAwIG4NCjAwMDAyNTAwNzggMDAwMDAgbg0KMDAwMDI1 MDIzNSAwMDAwMCBuDQowMDAwMjU0OTQxIDAwMDAwIG4NCjAwMDAyNTg1OTAgMDAwMDAgbg0KMDAw MDI1ODc0NyAwMDAwMCBuDQowMDAwMjYzNDQwIDAwMDAwIG4NCjAwMDAyNjc1NDIgMDAwMDAgbg0K MDAwMDI2NzY5OSAwMDAwMCBuDQowMDAwMjcyNDA1IDAwMDAwIG4NCjAwMDAyNzU4NjYgMDAwMDAg bg0KMDAwMDI3NjAyMyAwMDAwMCBuDQowMDAwMjgwNzI5IDAwMDAwIG4NCjAwMDAyODQyMDMgMDAw MDAgbg0KMDAwMDI4NDM2MCAwMDAwMCBuDQowMDAwMjg5MDY2IDAwMDAwIG4NCjAwMDAyOTI3NTQg MDAwMDAgbg0KMDAwMDI5MjkxMSAwMDAwMCBuDQowMDAwMjk3NjE3IDAwMDAwIG4NCjAwMDAzMDEy MTQgMDAwMDAgbg0KMDAwMDMwMTM3MSAwMDAwMCBuDQowMDAwMzA2MDc3IDAwMDAwIG4NCjAwMDAz MDk1ODEgMDAwMDAgbg0KMDAwMDMwOTc2MCAwMDAwMCBuDQowMDAwMzEwMjA1IDAwMDAwIG4NCjAw MDAzMTAzODQgMDAwMDAgbg0KMDAwMDMxMDU3OSAwMDAwMCBuDQowMDAwMzEwNjEwIDAwMDAwIG4N CjAwMDAzMTA2NTQgMDAwMDAgbg0KMDAwMDMxMDc5OCAwMDAwMCBuDQowMDAwMzEwODc5IDAwMDAw IG4NCjAwMDAzMTEwMjYgMDAwMDAgbg0KMDAwMDMxMTE0MyAwMDAwMCBuDQowMDAwMzExMjkwIDAw MDAwIG4NCnRyYWlsZXINPDwNL1NpemUgODgNL0lEWzwzYjk3NThlNjUwY2ZhMmNkZWVkZjg5OWVl ZTE4YjU2ZD48MTkyYjIxYmQzODc5ODk5NTg3NWIxNTE2NWZkNmIwYzk+XQ0+Pg1zdGFydHhyZWYN MTczDSUlRU9GDQ== ------=_NextPart_000_0069_01C3AD1A.0F663FA0 Content-Type: application/pdf; name="TopologyPersentation.pdf" Content-Disposition: attachment; filename="TopologyPersentation.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjMxIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzMyANL0ggWyA3 MjAgMzAxIF0gDS9MIDI0NjMxIA0vRSA1NzQ3IA0vTiA2IA0vVCAyMzg5MyANPj4gDWVuZG9iag0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMxIDE0IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2MjcgMDAwMDAgbg0KMDAw MDAwMTAyMSAwMDAwMCBuDQowMDAwMDAxMTc4IDAwMDAwIG4NCjAwMDAwMDEzNDEgMDAwMDAgbg0K MDAwMDAwMTM4MCAwMDAwMCBuDQowMDAwMDAxOTA5IDAwMDAwIG4NCjAwMDAwMDIzNDAgMDAwMDAg bg0KMDAwMDAwMjU0MSAwMDAwMCBuDQowMDAwMDA1MjE4IDAwMDAwIG4NCjAwMDAwMDUzNTAgMDAw MDAgbg0KMDAwMDAwNTQyOCAwMDAwMCBuDQowMDAwMDAwNzIwIDAwMDAwIG4NCjAwMDAwMDEwMDAg MDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA0NQ0vSW5mbyAyOSAwIFIgDS9Sb290IDMyIDAgUiAN L1ByZXYgMjM4ODMgDS9JRFs8MzRkOTBkZDI5OGJlMTZjNzMwOTQyMTJmMTJhNDEyZjU+PGRlZDQy NzdlNmYxYTEwMzNhNTljYzcxYjVkNzUwZGRjPl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgICAN MzIgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMjggMCBSIA0vTWV0YWRhdGEgMzAg MCBSIA0vUGFnZUxhYmVscyAyNyAwIFIgDT4+IA1lbmRvYmoNNDMgMCBvYmoNPDwgL1MgMTQxIC9M IDIwMSAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ0IDAgUiA+PiANc3RyZWFtDQpIiWJg YGBmYGC6wMACZGxk4GFAAB6gGCsQcxQwMDzawKBzpMW6ObX6/l2QHJfwtBQ5fp8rGy0nzn7QMuec 0KydrhOs4pp9k4pmSsjqOy7baOnTwzd9wWVGiY4GBomOjg4GBmMg2cAgKGwB5rmAeSweQApuONBg AQYG0z6QBUAsAnaGOgMv8wZ5Bga5BUeYOj0PxDJayDfvYGt4x6YivGDt/gQtRyeeBIiDpRgYIoCe YWACYm+AAAMAU3Q2dQ1lbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqDTE4OCANZW5kb2JqDTMzIDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyOCAwIFIgDS9SZXNvdXJjZXMgMzQgMCBSIA0v Q29udGVudHMgMzYgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0v Q3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0zNCAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMzcgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgNDEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDM1IDAgUiA+PiANL1NoYWRpbmcg PDwgL1NoMSA0MiAwIFIgPj4gDT4+IA1lbmRvYmoNMzUgMCBvYmoNWyANL0lDQ0Jhc2VkIDM5IDAg UiANXQ1lbmRvYmoNMzYgMCBvYmoNPDwgL0xlbmd0aCA0NTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIm0k11r2zAUhu/1K86lc6GToy9/wOhF27QwGGyLIIV1F8Fx0pTE6mxDt3+/ Yyeu3TK8i60YW7b16uHRkfRDKNiDICQDqVWYpeAyh6RBnj+rQqygFDpBm0KSKiQFTjvMYpCJpr5/ frtUsKvF5R3Mlw8K6gdY3IkvYn5Vx5DXQJjxiNOTe/NhhHMGre3RitAN5C3rqXPexS8h07oMmUsv 5t5rzvmtILCm9ZanhkAlhJo7jcPYkQN/5Az/4jvtwDx54un7XMjuNQb/LCIfnsIh7H7B1+KpKuqi bNbNPpSwDRXcLGDmH3mgtVwohSrLNPjrE8kNpLQlfYs+hU1xgPtoXW7gJlRXi+VMapthHH2uQhPy cLifzb77j+ylLXAXWxtKUFnQZNGcrYdSyEGZOtkPm2q9bTonaK8+xKT2wWqjyMDRXMfEgexD1BIj OcmRrxGEJtFjRGtmO87zutxNovrAWEjTfxaSIyNeu7yoJ2lD5HWZ9DuUSXecY7s7JlkvibGSs/8s 9OciNeeNP0kbhwaoQZe9w+J1JyoiwuZnczGJG2VGpyVD6ra5wkRxOzqofHRWxf64L3ew+ttufRtc ePFbgAEAbiMu6QplbmRzdHJlYW0NZW5kb2JqDTM3IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1 YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIxIA0vV2lkdGhzIFsg MjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMgMjUwIDAgNTAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgDTAgNTY0IDAgNTY0IDAgMCAwIDAgNjY3IDAgNjExIDU1NiAwIDAgMCAwIDAgMCA4 ODkgMCAwIDU1NiAwIDY2NyANNTU2IDYxMSAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCAw IDQ0NCA1MDAgNDQ0IDMzMyA1MDAgMCAyNzggDTAgMCAyNzggNzc4IDUwMCA1MDAgNTAwIDAgMzMz IDM4OSAyNzggMCAwIDcyMiA1MDAgNTAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0v QmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4gDS9Gb250RGVzY3JpcHRvciAzOCAwIFIgDT4+IA1lbmRv YmoNMzggMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBI ZWlnaHQgNjU2IA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgMzQgDS9Gb250QkJveCBbIC01NjggLTMw NyAyMDI4IDEwMDcgXSANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuIA0vSXRhbGljQW5nbGUgMCAN L1N0ZW1WIDAgDS9YSGVpZ2h0IDAgDT4+IA1lbmRvYmoNMzkgMCBvYmoNPDwgL04gMyAvQWx0ZXJu YXRlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZt dEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TAL AI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kN AEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8Wmc V9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4b lA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0Wh wcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4d vvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqd TK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2Aew LvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKg AibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCM g4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt 0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNe Bw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gL lIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+Ihw hnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0 mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCN oOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9h MBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXl xpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcM d5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6L yxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL 23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaE ncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY9 6/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFe aq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs 6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7 ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk 8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fj v05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadt TLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP 5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62X Vi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj 6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1az qWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59s cWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal 77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdE bdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kb r5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfg qFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1 E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48Jf wtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQ utE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p 36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7iju tO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L /tz/bf//AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTQwIDAgb2JqDTw8IA0vRnVuY3Rpb25UeXBl IDIgDS9Eb21haW4gWyAwIDEgXSANL1JhbmdlIFsgMCAxIDAgMSAwIDEgXSANL0MwIFsgMC4zOTYg MC44IDEgXSANL0MxIFsgMC45OTYgMC45OTYgMSBdIA0vTiAxIA0+PiANZW5kb2JqDTQxIDAgb2Jq DTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0 IA0+PiANZW5kb2JqDTQyIDAgb2JqDTw8IA0vU2hhZGluZ1R5cGUgMiANL0NvbG9yU3BhY2UgMzUg MCBSIA0vQkJveCBbIDI3LjQ4IDYxLjAxMSA1NTMuNDQgNzgxLjAwOTk5IF0gDS9GdW5jdGlvbiA0 MCAwIFIgDS9Db29yZHMgWyAyNy40OCA3ODEuMDA5OTkgNTUzLjQ0IDc4MS4wMDk5OSBdIA0+PiAN ZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4IDAgUiANL1Jlc291cmNl cyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1 IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0yIDAgb2JqDTw8 IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUNCAxNiAwIFIgL1RUNSAxNyAw IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYg MzUgMCBSID4+IA0vU2hhZGluZyA8PCAvU2gxIDQyIDAgUiA+PiANPj4gDWVuZG9iag0zIDAgb2Jq DTw8IC9MZW5ndGggNTQ0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFRLj9Mw EL77V8wRDnE9fuQhIQ6FhQscYC2x1yR1t1llk9IEof57xnGTbLvdCBCoiuM24+/VmXxnCBUwwYWC VCPPUjCZ4UJCdPp6cOwbNEwmXKeQpMgFgpGGZzFEiRTj89XHW4T7jq3vYHW7Q+h2cHPHvrDVuy6G sgPBMzoRVnpazieMUVzrERoFNzPyluThqd7EU5HyWuaatWUrazXV2S0ToAbdUbgJQCO4IlJjOG0N 2EeqEVzSlQ7AEbkXIgZbhi1qsD/ZK9vu27q9P8JXtz+4zjV93ldt89o+eDYzsiFRoeeRmHCRAipN Jice+ngO4dGFx30jRKrfEgiSAOUzmURoGBb7fi566ktqiOgKTEoCxpJLFZjmmAYzOJkRoxmK6mQD cuhHb1VHe+jcY970VZnX9RHAO5yVnwv7Y6AzYWQASXJiBqiN68pDVTjodw6qpneHsm0aV/qUoaO0 HbRbaIsH+qmjgmVhf4X2srohOznHaIYYPfZomS/KeVZ5tWcUap7Ki575h52ikGY5XuqU4OtzfgSK rnFu4zawbQ/LWV8vP3NoyKHxCmj6iDChYUsmg8Fb4WULHg/IanovPPdXXPrDbJjwcAsckiYvU9yY qy715R/56cN67l3q2Wr/o57G+9y3yiCs3vniuesBJClP9WUC5f+IIcn8i3shhmQgPu1OKZT5Pi+q uuqPEEZo/5sxvHzwxrJfAgwA8OiPvgplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDI4IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYgMCBS IA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQyIDgx IDU1MyA3NjEgXSANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQg XSANL0ZvbnQgPDwgL1RUNCAxNiAwIFIgL1RUNSAxNyAwIFIgL1RUNyAxOCAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSA0MSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMzUgMCBSID4+IA0v U2hhZGluZyA8PCAvU2gxIDQyIDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGgg MTI0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaxX224iRxB9n6+oR1iFdt+n R8pGWtsbyysl2YiRspK9DxgGgw3DhoG1/Pep6u65YG5+iCzMFF1d59Slq2v+TQTMIeGMK3BasMyB yQzjEgZRXBfJP1AmMmXaQeoE4wKMNCyzMEglr9cvboYCHqvk8htcDGcCqhl8/pb8nVxcVRbGFXCW 4Y7wH1fH7Q5jFNO6Ni04M63lKdITUd/YRkkRl1bnMk8u8lyjXj5NOCjPexC+OFo0TFnIHJMpN5Av UYUziR/n7Q7QeY4O5+P4aCF/SXpfR+PnYgO/L1YvcDspys18Oi/WcN/7+jy9vb7vQz9/IlhTwwrE FB4wxQA6EIK8bRDxj9A44XBC+JVzp39DIwKpKApOQ0eD/5dft0pdB6WGAX4CkpIgFPqmAlIbr+CM 8nj0ZLxbtxWMoBwtCxhV1fyxLCawWeFP5E3LcpfEyU0toFcfCKSSGtpWo9ZxdZ5ANS8fFwWMV2VZ jDfzVXka+rD6CdAmvr373knLYblrSaXSwKBWCKQ12aOcD2+vT5prVVqTiok9g51CE4FmH1ZrDObj erX9Aavp6Xgc1O4kHY8GJy/epEG3qKlHbQNawZlA7at2DiWW+H7QTJsEDMvN+cjd7EdO2taqTyq6 fiYyR0+k4oK6SvdE/g+nj6y6c4cPQ5CvYFtOinW1GZUTmG9+geXo9XSWj285XvlHyuvnfL3ZjhaL V9jM5uUzGsNDfO7An9p05sDvVdrDdjrFxjmaTNZFRRW0ma22j7PTBE5tOk6gR1GalzBf/lgUS+zZ o/MN5viWAzi6cVO0bmrv5mL0ioTL1QYeCqi24xmMziAf3XEmwrI9XTE+8TY6irSr9jkPt/LVEMKO 4dWfiPkFn55A0N3/gpcm/AF33zlMwoAgUn//axwDuBAQpgGn6f4dxvs3bY6d9fND+EIxS5kArdL2 NkQvhKwvJhUupr8enrDJwKfIMAJaToD7eEdQrHBMpy0K3eXx+lNdlMuIwtFrgV4nwmWEYISfL5a1 bPGI21TAAlFFJqkA6CdjdnQ8xQXKlqWuUVgk0w+HqTpN3chI3UwkYidznGdNdYmMeN+FqaM/kEYy 0/vYxzbfA9X/nn/xwYrJS7QyPk3aHE7THhdtDCXHmEOjyjvSFAGtNO9LU8Czyr4/TZ3YGOYcWcOO rWmcuO6Gq7lvbq8/qkhPxvxi5qiqE2k9Qxo5fZqjbHUWUjgMFRHOQCKdnxxb7SA32oorqohmPcrt uhQMA9iuB7ldV1lnEYUOD2Jes1Zml3WUG+23Xu3qL954ub//cKqklb5MU9kdnDu1EbLWu/StuqKI Y4KkwEIhNzFQ1HrCqu87lDZ8ufD9jKNnuHzX+zSZ9C2TPepPvpyRh/Lze/hCHnhccPSnd46mZjyw CD0PzeHhD41O7hZM/iHpqd3OSD9p+okeTN1smjbYTb/G+CBNI2PYaln5WtdC0zuQ0eGNxHGW1sIY I6yYcc2ixHJHQbNU4duJpZndkLGMdIcdwgr7l6DMCZxJfKqE7JQYlgyiGtqdMhVbTFRpsxtl4wK2 Yxgca32TUtgYZCMhTyu6q6kLO2VXUrVulGVYRd9j59OYqbSRxolGSK6bVS2ZwmJDVi4jMfVnSGTM meC+Ntw37sw0UW46ygJlzRzBYoBN8Pi/AQCytUVcCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0vUmVzb3VyY2VzIDggMCBSIA0vQ29udGVu dHMgOSAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgNDIgODEgNTUzIDc2MSBdIA0+PiANZW5kb2JqDTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQ0IDE2IDAgUiAvVFQ1IDE3IDAgUiAvVFQ3IDE4IDAgUiAv VFQ5IDE5IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQxIDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiAzNSAwIFIgPj4gDS9TaGFkaW5nIDw8IC9TaDEgNDIgMCBSID4+IA0+PiANZW5kb2Jq DTkgMCBvYmoNPDwgL0xlbmd0aCAxNjc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJzFdbUxs3FH7fX6FHO1MLSUeXFWn6QCAZMqGTxu40M8CDBy/gxBiKTZP8jvYH9xxJq71gO7TN Q4cxu1odndt3bvq9kGzOCsEFsFJL7ktmvOFCsVFa3lfFb2xZKMd1yVwpuZDMKMO9ZSOnRL2/93os 2dWqOPjA9sbXkq2u2dGH4pdi7+XKsosVE9zjifgfdy+aE8YA17pmLQU3DedLVE8memMzEZAuDc3B pNibTDTSTS4LwSDoPYoPwUrPlWISGSsnDJvcIAm+468MfEdovKCNi/QKbPK5GBx9md7cLSp2e8km t3e3i9urr+x9dXdfrarlerqe3y7ZcPIReY0kV0KUbHKYzitiJYjJ6eBguqpmDGnffbo8PlwNR8qV vBzMh3gKBkv2+v3JOzY8n7zBA9IHveMDl8ZxKJm0CIeJijfOCIJkEIRvEqK0X1GA5npQsbevDtj0 Imh5M13O7x4W03XFzgbTIEsCl6VFFzRKl5mXDebHs+uvdxV7waaz2dmQ3VSr1fSqYtNVspz+ggeR n1KGXCrAE8//gXqNr0ZSYUBLAkoq0ioxVTVP0FG/6ZJVX4Yj4GaA2EddFwgZl4MqYZRNjqZmg59w GEPU1CEqCWcCWQnPHZOqxMSog7OOnh/RbP1TMEVwoOzJojUL/1BwJmpngNJshL/I3uNnY7mCfgyN GpRy4KJrxw93d7erir06YlfVmkEEazarHbxCD+/3AqCj0tM5oM4+u6Qb/Uor7uyu6NfZUYMef7nP +hHag2v7iQYZa8l1mNoZmp7rpAnCzwKzF+ykWlf38vlOz2yglZk2lBJQ1oUMyrDICMvx8gprz2qf Ksn4+FA+DwpPnmGlajZe48ap3Ffnz3s5QGXVI+dRrUp03Nlwt7ppu4cNaMGd3oWNqVNL+E0AqQ3x swuemj6DA1Zzr7aAUxfxi80wTe8/PR2nFvG/ASrgUaPRwwpBVH2YSg4O4PugpKHkTv0HlOAfogR9 lLRV3O8CSTe+s12QHr48FaGachs83RoXW9FjjOT5D11MEKyAbA8x+I6IYfVzufrZMHPFBxYfp2kM 8j5DR5z64T34czxfXuGMQtzQZmfxexhHcODJrbNpw7HLHS9n8z/ms4fpAuvyUA8O8JdGECx4UD7m UGb3xQjP89BfJPhoEoe8l2MWlRy//BnVfYNvH5kkez7jVMdO2Om5YLM4byrnaYSTHnCck+ym+YDI gWSqFBwHAOlF2Fdl835RKCSiKTJ9WOAH4NjDM7XXgVdZcutbS5fP9/ZNR5Z3LVkgbFcWiLItC0RH 77yEdH6cgoB8ItEnIvjEoEsKgDDGaiMDrbVMK5pnxzTPPooIMMFG7VAfaEKijvjcCmUeSstQ+TDa VAoP7QVO1oor63NqyBhIsR8lNJNi1hiatVEvsN/Uy1KqtyeY7YoIjkGmwoY3MueoiYpgOic1tDCk hinJl+SbXWpovJGgGsaLTWrQ5Ce0J+OlL02WmYyPRT6JfRzDhVbRIUARhMEKeAtp1oveutnXOOp7 Ihi30hdKzdGntOlcmzq6G7nhDQEagkVx+SxrgLU9SOhqtNjmFLBURayyzdWHWypErbJEsUdeSNWv jgEbBBgwHYFpveitm30Mz8cma1QATabNaHJNHaElboJMrgmCydEgiC0NUkvDwQNvgUZsMyigasme UzRoiHfWQd2DQ4VrLAMvU+lJH7TWm9CyQXXaTGjZTtYiXDboXlO0dO8nSklggFdPBiMnpA1VxQaV gw5h7dBrGzR2ijSmzVrjRF1HK5oEDcF2hW3oQXarwklL6E/ytSYj6fBaiOnmYunJ/QRyRzKxJb2d r9bxxsRuL9MLMj8+xAujclieB/MlSz0bbw+ZZn0drpLx0shLNDGUFXo+vjnSW1uYr4X5tjCL9zUU dtSVhSTpzPWQCtigkYv4pCZXKB08raWpu1qJlxiMNeO5cREo6mygQjRAogllDoypuxl6DCxWLJ/A Sb2xDrmb0JRwstPCcSMjWxAa6zp+wswwkSYeEtBqXHif0fg9c647kZGdZE7rdv0C069aple19OOq hVHVmXG6yQyYMZTMWO6+lcwiItfJaNlkdF99261VYxpsbDAUQ1qjD0J7DpRhbag+uZgbihvVJgjr hqBbGxxdg2jTmA1yCXZV1vtbixoQcypqYpcfTKuowaC56PVjMDVvo2oLsD/jLGcQfen7BiTHYdDI GDTGxQ/ZAk3xa+j2CAnUvwcALXBwKQplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAyOCAwIFIgDS9SZXNvdXJjZXMgMTEgMCBSIA0vQ29udGVudHMgMTIg MCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDQy IDgxIDU1MyA3NjEgXSANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gDS9Gb250IDw8IC9UVDQgMTYgMCBSIC9UVDUgMTcgMCBSIC9UVDcgMTggMCBSID4+IA0v RXh0R1N0YXRlIDw8IC9HUzEgNDEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDM1IDAgUiA+ PiANL1NoYWRpbmcgPDwgL1NoMSA0MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgL0xl bmd0aCAxNDc4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFfbbttGEH3nV8wj VVTrvfJSFAWaOA0S1EFbEWgAOQ+MTNlMZNox5dr9jvSDO7PLXZK6mG6BFoZFaXd25syZyw6/RAJq iDjjCjItWJ6ByQ3jEubdz7sq+h2aSKZMZ5BmgnEBRhqWJzBPJff7J68XAi7b6MV7OFlcCWiv4NX7 6Nfo5GWbwKoFznI84T5xd9WfMEYxrb1qwZnpNa8RnujkTRKEFGHpZV4U0UlRaJQr1hEHZXHP3YND zplKIM+YTLmB4holOJP4n1m1c/Sdcw3FKrLfJBQPUfzqsby+3VQt3Kzhl8/rN6fwW3V7V7VVsy23 9U0Di9VVdV3BeSzOZ7PiEwEwHoBA64JMCyOIylyi28E2/pFdbi2Sse85z/QPqEMgKEUsBWAa7Edx 2gsNPZUa5vjvDEkkVqJnylnqiXMeKrLnvibWxXfV4xZ+/ukFoHMfy7a6QGHyibzpYY5RPHloRIFB CgwhyxKiX8iMZYH/oecfySnOEmtFhezY9/7jrvcit3F2D2fJaEuFMYc5kD7KQpD5ZfzjZgN1c4mB bV2sS+tceVdB2bb1ZYMOzgwz8UO9vYKbpoLZh+LtDj0qB/eJQP+1yh6qJKex/oJOi10kgbUYE/L1 m9P9OA2BDIR61YoZpc1AtQ1FfB5P6HICvR4MVEq51+shdkVgV3mYC0wTmAYaxIZQU56luyxI1bNQ r6c0dxKDLKAulkjKTSY1pcPpbv132LdXFQasxgA2mz9tlOrm9n57PvsWyuYCcHvK+DM19OCEZkpk 6j8KvMQ2uxf4kwlVJ3thHwO01OVWlYvis0K9C00rs5dLWejHrln9UW7uhwX0tJ0D0sMkEEwoKfaT wLaHuHosV1sMWVtekw6MFAbRtTwGhQ+bZrk2aHMnhZYxFv79ZkuBx7MzzbK4bmy01/Xl/V1FKurd JkLaMgPjwP/PcAaJKDFb9uIs5M4V2ZLSiUAEmXENCpkco99jp+785b7eVhasd756pEu4pQt4U3+e zTVL42f05H+kaECEYYJToozLxtXi1wnXvz6nZdo0j4vpblLstQt58JZwOXNRbsvbEq+XCa0juV61 ZvKAblfo7mtqKVjdNE212mJO3jynIx4SH5clzpWj3mxbvgicL2PMe7w7dfw4GfKx5JA2lY7bjWXs rwnsdv9V4cbZlwtwoouX71D1W/z2CRA9POD4Cmew/MDhwg3Wys3NMqW5VUCSABKLQ+uiG1rTMMwk duh2D5xhdcqUBpknLO8Gulg4jMhPxnG2IliSlnBB59gn51i3SZ6GgrV3ZXxWbas70cHv4OjUeDg4 m3k4x0DobDi/ks6jSDg280zajdyIkObGIbl/DDjynHCoNLc4kJOncGgc8RCHwgHvAA40JrjOyX1B XdQb7dwv7z73/lPQhA0bx7AJDFukhaNEOSjXkUoUS8LvDWJyp+xlhXspCmuyZYXN6PQmSCiDFNDC +pt9E35BmGDjoN8qoZchLWX/7uIGZf8O0d+/RO5SfvD8Jo5frcYW/cJmd6GXSGUHfOi3xqGUkgU3 03QknQd9muZ8L2H9dj4pN6UrN6VrpRm+yCl6UznqkzgUu45qyY0PVLeQ6AOIVWIR06ZD7KW7SsRI GYvYSxxFrAwnxJInTyBW3XV7VmHXkTGWnH0K23168EbgS+kAjdHJcey0OcKOIxxi76F7gSnoRhxL oMGr4TI+vZnNUWH8MMPkiRv6oW0fnUt8p8riN7gSnwaPtLEZIHwCdQvDwjmISSY2AfJsgClMOzaN xXd9Io+VEhWCXD9SnobujlB8h8qzk+gK2DLHGb51PmCvNhnTemTLLSSIOHWnsSDlSMItBIkFBk+w 1B0yZoghNQEDjuNZkDgePZVNl4pvc5Y3z5qg/vEAS81wwsD4JGBvJKXUDpnY4FMkkwDtZ6HObfdB xnyvE/Y4+tM5gsGhG82gZ55Mdw26G9B3oT5Fxm2J7P09AJmFIrEKZW5kc3RyZWFtDWVuZG9iag0x MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0vUmVzb3VyY2VzIDE0IDAg UiANL0NvbnRlbnRzIDE1IDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIg XSANL0Nyb3BCb3ggWyA0MiA4MSA1NTMgNzYxIF0gDT4+IA1lbmRvYmoNMTQgMCBvYmoNPDwgDS9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQ0IDE2IDAgUiAvVFQ1IDE3IDAgUiAv VFQ3IDE4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQxIDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiAzNSAwIFIgPj4gDS9TaGFkaW5nIDw8IC9TaDEgNDIgMCBSID4+IA0+PiANZW5kb2Jq DTE1IDAgb2JqDTw8IC9MZW5ndGggMTM5NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIibxX227bRhB951fMI1VE670vtyj6YDsNHNRFC7FoANsPtE1ZSmTJEaXI/Y70gzu7y7sk022D wrZkLodnzpy57PJzxGAOESVUQCIZsQkoqwjlMC4v13n0BywjbohMwCSMUAaKK2I1jA2n1f2TdxMG D0V0+gFOJjMGxQzefoh+i07OCg13BVBi8YnwiXfvmieUEkTKCppRohrkKdJjpb3StZFwXBqb0zQ6 SVOJduk0oiA873H4ohgWEeiTacINVZA+ogklHP8SjzvG4CmGn95F/j9E2UXx5G6WP+ZwHfPr0Sj9 6ByoygFDdOagGWdOKssxrBoafxws9YAO6wdKE/kjYjD0KZwKtV8J/iM9b4zakXAJY/wLjjgGwZG4 CJ4aYRr+PhQmfQC/P8HPP53CxTncZkV+72JoyHV9H7LtxKswXuVoKO215AlJai3bYd66CCjRHlzU qd4P9bYfKrM+aeEreFJ4UzGiVD/gkDFZZyxx7q/iiylkiwXkD+u8KPICVnjt48rWOWRFMX9Y5vew GxnC4vmIExVvZrBa5jC6Sd/3xBEWwify/efIuoPcEMf0KeHUrLHHVcmVIsa/fpq+uzjfz1abUMuo wRaEq0S0oBvk+DperWEAs7ZpIFF7SffZGo+JHCavITrZJyo5tnKPaOJB59MhmqVFqxiwGJVmODOw RSR2Y82zaWnrpV0tF3/6rKy2m6ft5nr0BrLlPWxm+ZDTgSdbijEiDJd9yZDdt0mw6iTYS3YyAHXS RcG2ZPtlYv9zSoXaS6lqRlKYqV+yxTaHedG0zCu0P/5QqwZYQlii+X4NqP6QKDKc6l9GYxVnozHO 7dihZwWCooswBN8ANrKNdzncZUt4yDfY7NP5w9b3Otzmi9VIY6PvyPDg+PbeDs5lyXDLTv6Puew8 uY3o4FyuFHc6py5C/P28nW9ynzKvBYaUPz+5MTpfLWEx/zQaSxzEr5jB/wqw1ZkJbv+61z5Yk18H yu/rXvsc6O+yf9JZPoBWWrR2BNSe78H5qo3vs032lG1mA5htswZYEn4AmdUtSbUPHwWdrlePTs+h wdu1bA9gSbS1pt18zgNvdrWrGGt9pIiMnwfz3LVsKyVMd8Z4kf4aoO3vv03DOfRsAsF0cvYLQr/H /z4CVjLs8NwJl3B1Q+E+nIi5tO6QKaghbnxpDagmnjYn5WnT1A2i/Wk5fOGRTVsiJAiB3V6e1GIW OKI+CcV+dbS4W8IFaTEROBnwMVMJx/zGFV/mm3zNSvolHcX8+RfZ4DGsYnOMg8Kab86lDvIoEYoD PPHjM7GKdSd4fLl9rmgIPIciDSmsVwUleYmHwDcI5CGlPsQDnTEqrYue2UTVTsvos/WnJnyXM+az RjFrDLMWCeEVkVY4RR4jbk3retG7ru8rKjFGZzApUf0GRnE4an/TmLZ10Nuh+beIymARTb+rGRjl xXjsUVocU0Vx94ojE968kITJXNZwL3ZuQiVa1nVTLSz6Cw0RLMIDsUruYnU3Q6y1ta3x/DG/svDB hkhE2AxE2AwEHtLxJCf0sUiq15G6mq/4TTcqLivO1YI9lB+eeM7uZpmfUhRaaYDD3XGuLI5y5oY7 zly+yNmPrit8L8JpdOF2FB2f+3nUMFfSlIVVXiOBo8TdzQ5xPKqXhRV4VwYt3r2eNtJVjZLJC7z3 G5Zr0y2NcuFwGyByrw10rw30fhscVFlTp7IU8tWVwW6OUja9ekfKBM8wO5zSCU4urEBpK9tywclu gr74esDbFuVCbdFNlyAmPK7UQd8cu50ntcVxBaSvM9ciQ3VWK/B93R3MJX3X7EKmZo+jnbupK3Fo 7rEvlcN+ZCV7ERYa9pQYt6Ddi2hg//cAJSn/MAplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTw8 IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENo YXIgMTQ4IA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDAgMjc4 IDI3OCAwIDU1NiA1NTYgNTU2IDAgMCAwIDAgDTAgMCAyNzggMCAwIDU4NCAwIDAgMCA2NjcgNjY3 IDAgNzIyIDY2NyA2MTEgNzc4IDAgMjc4IDAgMCA1NTYgODMzIA03MjIgMCA2NjcgMCA3MjIgNjY3 IDYxMSA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTAwIDU1NiANNTU2IDI3OCA1 NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IA01 NTYgNTAwIDcyMiA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgDTAgMCAwIDMzMyAzMzMgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNl Rm9udCAvQXJpYWwgDS9Gb250RGVzY3JpcHRvciAyMCAwIFIgDT4+IA1lbmRvYmoNMTcgMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTAgDS9CYXNlRm9udCAvUFBJQkdMK1dpbmdk aW5ncy1SZWd1bGFyIA0vRW5jb2RpbmcgL0lkZW50aXR5LUggDS9EZXNjZW5kYW50Rm9udHMgWyAy NSAwIFIgXSANPj4gDWVuZG9iag0xOCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9U cnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE0OCANL1dpZHRocyBbIDI1MCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMCAwIDAgMCAz MzMgDTAgMCA1NzAgMCAwIDAgNzIyIDY2NyAwIDcyMiAwIDYxMSA3NzggMCAzODkgMCAwIDY2NyA5 NDQgMCA3NzggNjExIA0wIDAgNTU2IDY2NyA3MjIgMCAwIDAgMCAwIDMzMyAwIDMzMyAwIDAgMCA1 MDAgNTU2IDQ0NCA1NTYgNDQ0IDMzMyANNTAwIDAgMjc4IDMzMyA1NTYgMjc4IDAgNTU2IDUwMCA1 NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgDTUwMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1MDAgXSANL0VuY29kaW5nIC9XaW5B bnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbixCb2xkIA0vRm9udERlc2NyaXB0 b3IgMjMgMCBSIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIwIA0vV2lkdGhzIFsgMjc4IDAg MCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDAgMCAwIDAgNTU2IDU1NiA1NTYgMCAwIDAgMCAw IDAgDTMzMyAzMzMgMCA1ODQgMCAwIDAgMCA3MjIgMCA3MjIgNjY3IDYxMSA3NzggMCAyNzggMCAw IDYxMSA4MzMgMCANMCA2NjcgMCAwIDY2NyAwIDAgMCAwIDAgMCAwIDMzMyAwIDMzMyAwIDAgMCA1 NTYgMCAwIDYxMSA1NTYgMzMzIA02MTEgNjExIDI3OCAwIDU1NiAwIDg4OSA2MTEgNjExIDAgMCAz ODkgNTU2IDMzMyA2MTEgMCAwIDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jh c2VGb250IC9BcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMjQgMCBSIA0+PiANZW5kb2JqDTIw IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0 IDcxOCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjY1IC0zMjUgMjAy OCAxMDM3IF0gDS9Gb250TmFtZSAvQXJpYWwgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9Y SGVpZ2h0IDUxNSANPj4gDWVuZG9iag0yMSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9y IA0vQXNjZW50IDg5OCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjEwIA0vRmxhZ3MgNCANL0Zv bnRCQm94IFsgMCAtMjExIDEzNTkgODk5IF0gDS9Gb250TmFtZSAvUFBJQkdMK1dpbmdkaW5ncy1S ZWd1bGFyIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMjIgMCBSIA0+PiAN ZW5kb2JqDTIyIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNjA3MyAvTGVu Z3RoMSAxMDI4OCA+PiANc3RyZWFtDQpIidxXC1QTVxqePCFJeRnQ1aV4gSICIUzAoICoIQQcBYJJ iKlt1SRMyGheZAaQogLRImi1tFV8UlFbFcX6KD62p3XpsUeUCsVXRdaqK+tW6qPa4ht070ARtHX3 nD1n9+zZmXPPzP3v9//3u/8j/wRhIAjCR0oQFgKS1VjqFFP3LSipQxBfb2M+BT6Nqq2F718gCCfe 5Mixft2VsAdBhj9AEPasHEuhSTO18zSChOigzgEzrs8+vsSkQZBQuI7EmqFgiJC/AkEC6PXXzFZq Hpa0tALO5yMIq9xiN+pHhI7gIcgobwRhHLXq5zlYWm441G+DeOBw4g5lY+gsBAliQzy0izB6b/qJ CB/Cpy/SewnvoC7hTS4vvGxy2X0PhhuzxiW8CEXtTAZD4om+wnXvW2FyOAg6m8uP4DLYDNdYJoNd o0IzUdEgif/mgBJ/ZHzvrUQMCInYEQuCIxQcE+gbBc/bY3u7hu9ovhNWNlEk8lg9Om2qscblNRF1 MRvgCGP6CivqTy69tu3rL6WN65eXN41sUmvfRz2ecWWwIaXSjyQj0Ve5rCw2XzhUizsJNZFjAxpn HkmBDJwqsDvnSoahfjRAIPTsB4gAZjOKJSI0vG8heECTsOJATemtDsKWA9S4M58w4kBlt1OSMWh0 HzoiQwnSMFkSloZpXgcyuVyRqVEki8BoY1jcWPD8HmjAMI+4sahUEo2OReE1A07jJNExkl+n//sH KN042OcMDsIqXQ79XsEsLUVOi8Ft83xRpLjUfy933zbBQR+P6e3qtryO4zHh+87c470x5pfOyie8 V1r/8scZf2r+4V753uqGJSHXF+i8yTnzvsn16zmquxe2Uzezit0TafDRlfo35a48G6SLOnvCl7M4 9vOVO+rTp3TeSgjapV27MHCDpaxhSurqOfVbY8928yJP18etZ7JgUr+QEizIK95nwzucCac6Sx4X na3tqivs5nSvSswNro0YfeldIV7xRLSE8d6MdYYmn20lXQcP+x48qV07192gOLr5k3ZpMSfoojOS XcbZNp839ENf+e37Q9O/c1ux3tuie8KXrm6q2HiJ7dgQvkC/4qtrgtx12xtNhqTEVSuDotcEVSx9 lO3+2t1Tj2D+NsMRy/RDvvRZ1y6/Gfg4Rbe4oimlvDLklu/s/78krpOEoiF9hgP+OY3+kwpeetJ/ i2K/f/i/8Y8P6kUvuAndMRuFO204hZZW/yall8EoLKFTeqf+Zv2u5ZWplRfqfWYSF/jFhkqupLnl afn7Keew+JWdZ7gTq3dtnjfjxsNuo0J5SGBDf9ocuzOSd+mOPXSnx7TZHKmyuEWjbD0oSmoTtC4/ NPPpgZLWjqr64iAsydtyes0ehnbLkW/FG+O7irfrtp4Lwq++u3Pehi/OpyaZ34hc0LOfyWD9TkJb Zz9eO+tj4rPTRY4IQ3BAMpi2O9ivkWI+xH4OHfFmXVmu1D3i3nsXL++vurZs29QO8thkXvWe9mXt fh80sa7yQrTcHzI+Tv3k5PSUM+O0dwObj4xKiAyJbll/5c+TUn9ss6bmX21At3iVtBS3JSysebgq XBLh9+iY783v93RmyRwpkaKFqIu3FQ6vGhaTwWR6F5qqbIv2tB5gDLFVN9TjuYMZM2FC63/H6y+P UAwq6Qt4+LOMkNutVtxpJPQWoLabqAK9EweZeQYLQZpxJwnkst6UHIeOkcSi6LOUpKfRMdI4adwM 1MV46z9OQpKCJvcpJRYUFIjzoSIJFcVGuzUKdmA7SVB2Z2GUPFNN72F3OsTAUAhUuEksovNanKZJ pnM5VjIBHd9nR5pM5BAU3BBLBnKLniRBDIgE6YTRaSchhQEeWr2FyNZThN0G8qMlApRH63OFzCy1 RIj60BN3IX+6njTD0qPsNok36tnnCjcVnm2127IlAag/LWH5+g2Yl0OOdmev2f51wUvWoYPBi1Xk YnggUO7OdDEYSH3lqVHbs/9+3e/IU2uRTMl/aA/PbRH/Qb01OvbyGfNfpT3YkLaqbvxbtS84zD7+ 9t3jDuvKGyc+2x2OrovWzT9QOzckZ23DlYIfOVd/6qi6v0swfOun4xc7rjywv6lcYPdSKZb6ncMv JABOR+Imy+p4T0GI8GbgN2BF3NuGRZzjwSO6VdV11WlV58Zn6BJdRbd4Uu1+c0OSYnOCZMvjtlWP sxpF27ccCVO2dH14mzWy6I5ffO2DHZmLOFbD7WXC8nHnO/w9ya+4kz4ffeR68we5jYdN+zZpgr4T 5Mx/sKSwos7E3zHtUY8zsLvsraNdUzxv6PTB6a1747MvCz+aeewda9rQ3YlusJC3uDjfoy7O+d7o vCpkM1EEFdCvXmw2i8mpQUvL6RmDXVqCLizxLqr620l5j3nNL+NO2BJ+Frg2Gf8LheTiMOvhVyEa SDNhMxhP2cNQX5T+8hv4shvKYrqVIDDaEMJnc1FInjsJdbFjB2H4tKqLHQzFI2vCSkLNFOUg46Oi /kVhbHKxDpW6WPUaM0ECI+6kCBNh1FM4IHoLhk42nKSrxombcCduM+IioLdlA4IiQR4JYSQgKSdh pCyFfDLPMAc3UoCyiwBlxsGAE57Zpesl06k3UnRDhK2Jwq24jQKjIZMwPqRJ0gCJGIWb5OsJi95g oZk8b23gAEBPxfNfdtAEmrUi0grNQByAO0Q68dw8nKTISc/j7E4+hPYDn4+pCERL42JgGPWwQ8ry cShIt+fZKD1kpSXwAhEMIYgbg46J4WepZRDnKHQSOWaKbpKSuLjYF8wBILNYgIpGkPCHiIQ9Gc8W A7lCpZFhGfzpMpVKlqHBFGqQjKnlaTIsXZEMZBnJg/pwGpaOwTYs5tPoDCwjNR5oJitAlloBlCnw FVP3msNSMLlMowBwqtaoMLkm7XWgzkqaopBrgEZJq/C1ChUG/zhlDMJjygyQqZLJNZhcAfWggXRF hgbSprfA1OosuB+QZWkmK1WQC7+fpLr/BABLz0zDfuWs0GWqFP9gvuqjojqu+My8r2WBgCsgotEH GxAV1kVB/EQouysQRGBBQIMuy3dAFhfkiKQUkCCCoCLaSo2gqQa/4lLUIDVNxYIYzVFqMOJXqrVH a4XWRkWrht73VgFJc07/6sn+9u2buXPnzr137p25q9XyQ1aBE8ICQ6NVgpQhqhT0XqSODAyC7msr F0fymuCoMGG6BtoBfHgA6BgYHRoQyYdHR4Yv1qo9xEVigkND+bDFUdKfqUUnharFCYGLw7TqiGhQ Pjgg1AOmhAVHBS95Nee1sovBqkheFbAoYKFaq+C1arVUsFO4LwQZKjVwhWrB04EGyP0s2DJDyshY TE3PgWMhOYnPMmQJYZWSnpykNSdCQC5khn41JJA0eQ3MF4M7LyFzdTKfk5YAcZBlyOX1yXyiAYaS RCEJOXxCYuJqozkDUwzGlWLOSPPM1w1wQKQKGgQHKKQfzyzy/l/S/DU905BqUKSmpyiLjwgnCU8X f6IsUhaxlrqyIFz2VI05jIHgzkrgVGEYOEEdxv+ofHCSUj/ISZRLlPYOI85DJRQr2Gn+a+KkHNGz 6UM38eCZwmemJ+gVfGYu5MKb1SUSP0qHYSfdOFqiZOG0g++Iukeo1LaF7smPvpr7XqVr2z7+n5kt zQWagl31a1tXsUH2suTz8ZOfRszdsKrpkd2sNVc3fWpZNHNzfNAv29EsqfYLf9+BitGTVqKF3v1B oQrjvzouFb5UGVw2ddXU/6W29+4AOtvWZxzfs5PKOn4qsWD6GtXcXR9WPC8t83VX3N03y9ev9cV3 JXKvEnoCnMFOYLpy9f/h/vgvxaAVKzE7hTAMaihuVI4d9JIF5TX8YqGhxhjqWXqNuHaUE4cm0l4y 2jZ5qkPh18tXhG0+/WVhlc3F48rQYexWQhnVICuyRTEoHWWhVJRkfu92K3pHiKNXYbTydTkjxlFu frYh1ZiQnZY/spyhSzCy9A8JvmXVXrTxpkQxypinOxH5C9X9C+61648tnFw3LzWrV1bz5HlPUYt8 0vSGDP3Y3QZ93dglbWc+mewdVN00Zt+W7E1d69uPqK+956HfPuDot5OqX/5+e041+4/EBy9lTKuL viy3Oe+2dVB1t747teP0rQl/bHyx9p6NY+f8gSme1Xl42zPvvg3bNm/xzfjVNDfdheU164q/OOfu ZCyMc24s3/HNmGbXS2cP+Z7zW7HsxaWDl3X1Nyfm/mlM/rnC/Wklrd+/xe1v+ex3BVDN3Bi74s+l 8xYtfXBmU3jNsW8XSrZbZ8V2D9ygy991q73iK5vT55F9dmasdVX5qeruum1V+b1R+it2gWeMu0vw Rajozg/tA+tVgj8H0gkhwIpbfvL/XYk9+nxU3dXAXufnmtjSDV9qyje79tnpRgRpnNJxeIxaDnY4 DCE6OMJ42Yh/O3y9lF4+PtN9Zi39QYjWpLxU2BZV9M+O7Oq4ddt9+cigKi5yPlwW8cxi6o4X3KQj hm+kX992rer8d6ct+/zy32KOhwf3UNaufd+ftX7oqLP6arXd/C2hxc0Byk7Py/0Xs6Wq6tmzk7v7 U59VFI5SuLx9fesBZu7CfNLSQ1btlRx99PBjP32z/WNXvUuL7f2Q1o54x9KZmjCVzu15zR7/ljo3 q132Txj0E/x0/eiIFyARx5JishRav0Z6+K2DJwmeHagW1ZJmMw+aAY8JWiHoLtOJpiOjSJ+BPoBf FXqKG1GZSJmH9DCuB+52ePvBWCK8sSijFm8U3z9HpSD7IWkmbaRNHF0AckMEDjNIM9MJdEHeOvQp uon/ADwFaCuMnUBdwiyQXIsOo37sDqjEf8W9JByoWFgf5GQAdy3o+3vUg77DdtgPV+CTwCMjxaIu 5tWKgKcd0CVKEbAIZ2IDNuINIPMOoYgPSDWQctJATKSNiqP9mE5WxvpymSAFI4IoNAosFKSFIS2s rEerBqWacRETHIGjcBrejhtAh3bcC3hEPMkC8LqAbZSOtqLvMRnMHkAnG819JGFBNoNY5IR45Iq8 wSo1rBEBOieh99FaEQWAD8CXJageNaDdaD9qQq3olLAmuoZuon7wjg1AsMsXz8YxgDiAERfiUvBH 5TBU4Z24GbeCfudwN5kIVpuRCdabtVxH6shRco6cJ9+SO+Q+eUghyoJaQempHGovdYC6QF2gg+gG ejd9nb7OYMYkekrG2rHxbCVgI2fBZXCl3BbuI+64VIHGgF0eYFcI3CeJKB8s+QCVowpx15oAR9Ex QCe6L9gBGHhliYDZWIU1OBoQh5diHV6Jc/CaQYt+g/fhRnwUbOkGXMHX8C38d9wnop+wxIFMHbQv nGhJDMkg28kOspMchIhsJifJFXITbLxDHoONlpSMsqcmUGpKA4iillFrqHXUYaqNukb1wr5Z0fNp PzqajgfbO+g79D3YScJQjCvjw8wBpDFZTCFTyeyCiO5lelkr0SsydjQ7l13P1rPNbA/7krPnHDgX gILz4rRcJpfHHeDucHclhywCLNItjFIPdAAp0WcjsvcYRPdpEs9OQ074GkTDKsoGuHgh94gVl2mR TpoF7TgtdoeduoH6KQv0Lt2BYqhlKJPRU5bcA9SIc+hifJDSoENoL5eHT1I6qpfay7iyc83+JHXU AS6f03F3QdNH1FYmjVPgAKYSN5IFkNFGHIGe4MdoOaycS6agDrQBleM8JEG1kkPYGnKtnUzElcwe 6rd0A6VmCvFk2MFxTCf1IfJB9sgKuSMXiHUG2cGD/H1n+XrPmO6lnKbw9Jg6ZbL7JDfXd+QuzvzE CW+PH+c01nGMg73daNkoW5u3rK0spRYSjmVoqESRh1qu0fEmN52JdpMHBXkKfXkCEBKGEXQmHkia N3lMvE5k49/k9AfOlBGc/mZO/0FObMvPQ/M8PXi1nDd9pZLzLXhpRCy0q1TyON7UK7YXiW3aTexY Q8fZGWbwasc0FW/COl5t0uSlVah1KpDXZCkNlAcmSz09UJPUEpqW0DJp5NlNWOOHxQbRqOc0ESSx Bq1MIXKV2hQsVwkqmChXdUKSKTwiVq0a5+wc5+nxH/bLNrapKozjz7m37T3tJutgmw1FvfW6xdAt Y6AyULDsfWuM40XTCyR0b4YRo3zSTI2pUQLeDVN1xk/KDKKoVE83XzrEsERREj4YEsQoJhrFb+I3 TBRc/Z972rlORT/4xcR7+7v/c57nuee9PaeCtQ5Y/YKsFlERdUOo1a1G+FqF4VZjDsvu0KiZrZ9x xnJB6k9Gywetwb7tCaH32bKOyqjotNpE50PnQw31OfbKloTwt+YYbUlMU08+le1OtbXZsrbFrYm9 bvjVCL/6ofNh3WkPDZsy6zh7TTGxMTHfG5FP20ahDfXxTYkIWm21j5myG5sSbg9QKAs1opHSJrup OjxktUtLcpcp/FaLtdPZlcRkLXUEbRqJTC7tiU3nv6GedtPZkrAi4vawZfe1LctWkbNpZKo7ZnaX ehrqs8FKNdLZRRWFRPlV8xNDcz435YbLFFpdHGomW2R1Y4kIc8BESxKW0Gqb5WOomZyBZoThshlG dBjjl3SCa+VEeGuDlulcJCwE68IPpZa+gsVXG7xIMimXy9ySg7+YFtGoWL5crhSjFVOLlq138zc3 1D8g4tbuoCniGDLqTeAle20jhjwSkbM8motRPzIitTGh8ib1hycp1hi1hZaUnpmip/ou6UkVPXOv Jy0s57exHRJVC14396kI1ixp37lWsJoruIeUH1+fdjPr8dY6vYm6Pmc0XJd0xmxMTQe+io7TYZkd TtLpy+VT/ZYZtJxsPO7sbk8Wu5TLz4yGRWzM3skwqGKVGg2xpDWhhzVbpbSwbjeQbIfRNNtLVDZG lP808LXbsvnXtx7CHo7LB7hkPfX4b6TxwDCYoR6jjsb9xyijv04n+BHKGNdTxl9RYIeibC8Yoww/ QZnAccp4n1fIWM/94DR8OMEYz1EPn0CZTyAdUX4Xme6EHXimKONL4P0hhfGkwjOokPG+43R3Ef4d 4rpgO4U63oU/DMpguwm2x6DVNO7rpvFiXd6fC5wEaLNvG+zVhXYsV23xx1AW2m2gPD4NRf+MB8HT yK+C3qf6yvfg/XXQe2gqEKV9HoydpFgXxrNnAc0lPIyYhxeMxb8MzoAZ/TXVZ7eehRxQ/F2cR8ad nx/DggXfaaQr/rRsF9a/wLb3r2P/Gbx/ATjbc7V+m65EwIf16VNz7s57abmfz6XPFijkfTeXwh3F nP9SKXP2R+iERM6xm94AnYd+jgb0ahrgnTQYK6eODvRhcSWPdZk57ZbJrpWQx11hR5S8oeQ1JYeV vKrkoJKXlBxQ0q2kS0mnkhYlMSXrldymZI0SnxKPEl0Ji90J/QqcA1+Cs+BD8C54B7wFMuAIOAxe BQfAi+AFMAYeBwNgh1vmW6rojJLXlbyi5JCSl5W8qKRNyQYl65Q0KzGUeJVoSigWg34BPgMnwSfg Y3ACvAfeBlPgTTABngEjYLBrZZW/yr86nWMPxLqN9EtG+lkjvd9I32+k7zXS9xjpISO93UhvNdK2 kU4YN/Drucmv5cv4Uh7iNbyKL+ZBvoiX8wDn3Mc9XONYo2KJHtfim1tYXMwMULzfFD9ttnIssHGr 8FotTCyOU3xLS0g0R4W2zz155Fg+y9hTe8Ly0DFNjOX37A8X1LapJvrHK1SSi/eOHKPr2Goy8Fw1 ZVz3kSGtm2FNu9a0tKZda4hN9tLKeN9o8hr6k4J/v9gVvSWR7cOyu72JLKcWu3W70imtLID+JMMR u6UmuHu927lbI6FHw0c9xA5TGfbechzmrgLS1bChYYN0YceSrkXynFdwhR69NRI+yg4XXEGYKzGU +F+JvU1P4bdeRyetWIVxhnnOsINEnjx58/o0+56ocfZC8ALd/iOeTStWVUYqayOVkZROv6Y0miXv yV+aU56Tci/N0Lj3DuwrOlV9QEzDlko6u4QCLuDTtGI1Xs14JsY9E5eSMjp/wGj2LUf0skmNWI49 OaXrTJtm++Qba9a4j6YVS/xaRv7funxUOy+fl9939+W6/2/3Xldyb/tP3e75i75l5dRI+2kRVmMQ qTUw/+DZAR9z/VqKRkbrYjsqbrvIw9yd/EOZZ2elZk8ZZ4hmewNfG03IlhdPb78NACH4UXAKZW5k c3RyZWFtDWVuZG9iag0yMyAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50 IDg5MSANL0NhcEhlaWdodCA2NTYgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0ZvbnRCQm94 IFsgLTU1OCAtMzA3IDIwMzQgMTAyNiBdIA0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4sQm9sZCAN L0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxNjAgDS9YSGVpZ2h0IDAgDT4+IA1lbmRvYmoNMjQgMCBv YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCAN L0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDQ4 IF0gDS9Gb250TmFtZSAvQXJpYWwsQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxNDQgDS9Y SGVpZ2h0IDUxNSANPj4gDWVuZG9iag0yNSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBl IC9DSURGb250VHlwZTIgDS9CYXNlRm9udCAvUFBJQkdMK1dpbmdkaW5ncy1SZWd1bGFyIA0vRm9u dERlc2NyaXB0b3IgMjEgMCBSIA0vQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKS9P cmRlcmluZyAoSWRlbnRpdHkpL1N1cHBsZW1lbnQgMCA+PiANL0RXIDEwMDAgDS9XIFsgMTMyIFsg NzQ2IF0gMTM5IFsgOTg2IF0gXSANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1MgL0QgDT4+IA1l bmRvYmoNMjcgMCBvYmoNPDwgDS9OdW1zIFsgMCAyNiAwIFIgXSANPj4gDWVuZG9iag0yOCAwIG9i ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDMzIDAgUiAxIDAgUiA0IDAgUiA3IDAgUiAxMCAw IFIgMTMgMCBSIF0gDS9Db3VudCA2IA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vQ3JlYXRpb25E YXRlIChEOjIwMDMxMTEyMjIwNzM5KzA4JzAwJykNL01vZERhdGUgKEQ6MjAwMzExMTIyMjA3Mzkr MDgnMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDUuMC41IFwoV2luZG93c1wpKQ0+ PiANZW5kb2JqDTMwIDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5n dGggNjQ4ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1wQ2VoaUh6cmVT ek5UY3prYzlkJyBieXRlcz0nNjQ3Jz8+PHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3Lncz Lm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2Jl LmNvbS9pWC8xLjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMu YWRvYmUuY29tL3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEu My8nIHBkZjpDcmVhdGlvbkRhdGU9JzIwMDMtMTEtMTJUMTQ6MDc6MzlaJyBwZGY6TW9kRGF0ZT0n MjAwMy0xMS0xMlQxNDowNzozOVonIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNS4w LjUgKFdpbmRvd3MpJy8+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8nIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDMtMTEtMTJUMTQ6MDc6MzlaJyB4YXA6TW9kaWZ5RGF0 ZT0nMjAwMy0xMS0xMlQxNDowNzozOVonIHhhcDpNZXRhZGF0YURhdGU9JzIwMDMtMTEtMTJUMTQ6 MDc6MzlaJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVuZHN0cmVhbQ1lbmRvYmoN eHJlZg0wIDMxIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDU1OTMgMDAwMDAgbg0KMDAwMDAw NTc0NyAwMDAwMCBuDQowMDAwMDA1OTIxIDAwMDAwIG4NCjAwMDAwMDY1MzggMDAwMDAgbg0KMDAw MDAwNjY5MiAwMDAwMCBuDQowMDAwMDA2ODc4IDAwMDAwIG4NCjAwMDAwMDgxOTkgMDAwMDAgbg0K MDAwMDAwODM1MyAwMDAwMCBuDQowMDAwMDA4NTUxIDAwMDAwIG4NCjAwMDAwMTAzMDAgMDAwMDAg bg0KMDAwMDAxMDQ1NyAwMDAwMCBuDQowMDAwMDEwNjQ0IDAwMDAwIG4NCjAwMDAwMTIxOTcgMDAw MDAgbg0KMDAwMDAxMjM1NCAwMDAwMCBuDQowMDAwMDEyNTQxIDAwMDAwIG4NCjAwMDAwMTQwMTEg MDAwMDAgbg0KMDAwMDAxNDUyNiAwMDAwMCBuDQowMDAwMDE0NjY5IDAwMDAwIG4NCjAwMDAwMTUx ODQgMDAwMDAgbg0KMDAwMDAxNTYxNiAwMDAwMCBuDQowMDAwMDE1ODEyIDAwMDAwIG4NCjAwMDAw MTYwMjQgMDAwMDAgbg0KMDAwMDAyMjE4NyAwMDAwMCBuDQowMDAwMDIyMzk1IDAwMDAwIG4NCjAw MDAwMjI1OTUgMDAwMDAgbg0KMDAwMDAyMjgzMiAwMDAwMCBuDQowMDAwMDIyODYzIDAwMDAwIG4N CjAwMDAwMjI5MDcgMDAwMDAgbg0KMDAwMDAyMzAwNSAwMDAwMCBuDQowMDAwMDIzMTUyIDAwMDAw IG4NCnRyYWlsZXINPDwNL1NpemUgMzENL0lEWzwzNGQ5MGRkMjk4YmUxNmM3MzA5NDIxMmYxMmE0 MTJmNT48ZGVkNDI3N2U2ZjFhMTAzM2E1OWNjNzFiNWQ3NTBkZGM+XQ0+Pg1zdGFydHhyZWYNMTcz DSUlRU9GDQ== ------=_NextPart_000_0069_01C3AD1A.0F663FA0-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 05:58:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07973 for ; Mon, 17 Nov 2003 05:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALh5s-0004j6-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 05:58:56 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALh5r-0004j3-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 05:58:55 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C49FFD@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 5:58:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60829399 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 05:58:46 -0500 Received: from 137.222.10.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 05:58:46 -0400 Received: from isis.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 17 Nov 2003 10:58:08 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by isis.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hAHAv5N06946 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 17 Nov 2003 10:57:05 GMT References: <26BDFAFFB541B047B24179002EBE6D27C27CA3@orsmsx410.jf.intel.com> Originator-Info: login-token=Mulberry:01l0E7dfymnOnPgrTfxf2naN7Po7GY1wm3adfUq7SZxfpvsOA=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <323887896.1069066625@EEN9169.een.bris.ac.uk> Date: Mon, 17 Nov 2003 10:57:05 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D27C27CA3@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Lily, > I am not sure I follow exactly what you meant when you talk about > dynamic reconfiguration and the connection with metadata pass thru. Did > you mean LFB topology reconfiguration? It was a general observation about topology reconfiguration, not about specific attributes which I mentioned only as examples. Putting my comments another way, if you have a reconfigurable topology then you need a bunch of non-functional attributes to adjust the behaviour of the LFB instances after you have moved them around the FE. In my opinion, if you follow this line of thinking through, then you need to say a lot more about what an LFB implementation does and how it does it. Usually this means constraints on implementers, but this sort of thing doesn't come for free. Notwithstanding the discussion or whether it is actually a model requirement, I don't think incremental topology reconfiguration is useful or usable but so long as I can ignore it I have nothing against it. I hope my reply to David's consensus question clarified this. The next thing I would worry about is the length of time it will take to define, and agree on, the root LFB classes. Maybe your V.02 will clarify this. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 09:34:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12804 for ; Mon, 17 Nov 2003 09:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkSY-0007Bp-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 09:34:34 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALkSX-0007Bm-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 09:34:33 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C4A3F6@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 9:34:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60889501 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 09:34:32 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 09:34:30 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003111706334457:711 ; Mon, 17 Nov 2003 06:33:44 -0800 References: <26BDFAFFB541B047B24179002EBE6D27C27CA3@orsmsx410.jf.intel.com> <323887896.1069066625@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/17/2003 06:33:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/17/2003 06:33:46 AM, Serialize complete at 11/17/2003 06:33:46 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069079667.1023.8.camel@jzny.localdomain> Date: Mon, 17 Nov 2003 09:34:27 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <323887896.1069066625@EEN9169.een.bris.ac.uk> Precedence: list Content-Transfer-Encoding: 7bit Lily> Thank you very much for your comments. I agree it is important to Lily> keep NPF and ForCES aligned and anyone who is involved in both Lily> forums has to shoulder that responsibility. The NPF connection bothers me. AFAIK, the NPF has no liason with the IETF. Their documents other than ones which are complete are only accessible to members. Unfortunatley, docs which make more sense have not completed that level yet. Granted some people attending the NPF also attend the IETF, but it is extremely difficult to follow arguements based on some closed documents. Either the NPF makes exception or i strongly recommend we stop refering to them at ForCES. I am willing to keep the docs to myself and not redistribute it if an exception is made. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 16:53:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07637 for ; Mon, 17 Nov 2003 16:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrJg-00072y-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 16:53:52 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALrJf-00072v-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 16:53:52 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C4B02F@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 16:53:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60920639 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 16:53:47 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 16:53:47 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAHLrli83597 for ; Mon, 17 Nov 2003 16:53:47 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAHLrkf11239 for ; Mon, 17 Nov 2003 16:53:46 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id QAA27285 for ; Mon, 17 Nov 2003 16:53:46 -0500 (EST) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069106025.14238.52.camel@newcastle.torrentnet.com> Date: Mon, 17 Nov 2003 16:53:46 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The issue of support for multicast transport in the ForCES protocol has been a recurring topic of dispute between the competing protocol teams. Multicast is not explicitly called out as a protocol requirement in draft-ietf-forces-requirements-10.txt, and it is not mentioned in the protocol evaluation draft. However, there are at least some people (myself included) who believe that it is a pretty useful feature in some system environments where ForCES could be applicable. Rather than make an argument for or against multicast support (some people on this list have already heard my opinion anyway), I am wondering if there are any folks not directly involved in the protocol teams who have an opinion either pro or con? Apologies if I am exhuming a dead horse. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 18:22:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13399 for ; Mon, 17 Nov 2003 18:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALshI-0001Cm-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 18:22:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALshH-0001Cj-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 18:22:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C4B20F@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 18:22:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60928903 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 18:22:17 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 18:22:17 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAHNMnXC031480 for ; Mon, 17 Nov 2003 23:22:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAHNCsG21344 for ; Mon, 17 Nov 2003 23:12:54 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111715221223470 for ; Mon, 17 Nov 2003 15:22:12 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Nov 2003 15:22:12 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: NPF WAS (Re: ForCES model - other thoughts Thread-Index: AcOtGB8bfY/d2hQHSuWfkkWWVbWUtwARsnTA X-OriginalArrivalTime: 17 Nov 2003 23:22:12.0465 (UTC) FILETIME=[A1369E10:01C3AD61] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D27155FD5@orsmsx410.jf.intel.com> Date: Mon, 17 Nov 2003 15:22:11 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable The ForCES FE model document is meant to be self-contained and so there is no need to read NPF documents in order for you to understand FE model. But many other people do care about both and want to make sure the standards coming out of both IETF and NPF can work together. I don't see anything wrong with that.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, November 17, 2003 6:34 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: NPF WAS (Re: ForCES model - other thoughts Lily> Thank you very much for your comments. I agree it is important to Lily> keep NPF and ForCES aligned and anyone who is involved in both Lily> forums has to shoulder that responsibility. The NPF connection bothers me. AFAIK, the NPF has no liason with the IETF. Their documents other than ones which are complete are only accessible to members. Unfortunatley, docs which make more sense have not completed that level yet. Granted some people attending the NPF also attend the IETF, but it is extremely difficult to follow arguements based on some closed documents. Either the NPF makes exception or i strongly recommend we stop refering to them at ForCES. I am willing to keep the docs to myself and not redistribute it if an exception is made. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 21:09:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18460 for ; Mon, 17 Nov 2003 21:09:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvIq-0003Xm-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 21:09:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALvIq-0003Xi-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 21:09:16 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C4B449@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 21:09:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60941758 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 21:09:14 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 21:09:14 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hAI29IU16535 for ; Mon, 17 Nov 2003 18:09:18 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Mon, 17 Nov 2003 18:09:18 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D27155FD5@orsmsx410.jf.intel.com> Precedence: list Lily, I dont mean to be rude, but: Easier for you to say because you can get access to the NPF docs. I dont. Please dont tell me you havent looked at those docs or there is no correlation happening with the model or that that the NPF model doesnt get discussed in the model design team meetings. All i am asking for is access to those docs be made available or stop talking and corelating with the NPF. I would really like the chairs to make a comment on this issue. Otherwise i plan to raise this one level above. cheers, jamal On Mon, 17 Nov 2003, Yang, Lily L wrote: > The ForCES FE model document is meant to be self-contained and so there > is no need to read NPF documents in order for you to understand FE > model. But many other people do care about both and want to make sure > the standards coming out of both IETF and NPF can work together. I don't > see anything wrong with that. > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Monday, November 17, 2003 6:34 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: NPF WAS (Re: ForCES model - other thoughts > > Lily> Thank you very much for your comments. I agree it is important to > Lily> keep NPF and ForCES aligned and anyone who is involved in both > Lily> forums has to shoulder that responsibility. > > The NPF connection bothers me. AFAIK, the NPF has no liason with the > IETF. Their documents other than ones which are complete are only > accessible to members. Unfortunatley, docs which make more sense > have not completed that level yet. > Granted some people attending the NPF also attend the IETF, but it is > extremely difficult to follow arguements based on some closed documents. > Either the NPF makes exception or i strongly recommend we stop refering > to them at ForCES. > I am willing to keep the docs to myself and not redistribute it if an > exception is made. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 21:36:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19110 for ; Mon, 17 Nov 2003 21:36:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALviw-0003qs-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 21:36:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALviw-0003qp-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 21:36:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C4B373@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 21:36:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60943980 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 21:36:14 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 21:36:13 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAI2aT1o023326 for ; Tue, 18 Nov 2003 02:36:29 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAI2UKg29398 for ; Tue, 18 Nov 2003 02:30:20 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111718361226221 for ; Mon, 17 Nov 2003 18:36:12 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Nov 2003 18:36:12 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: NPF WAS (Re: ForCES model - other thoughts Thread-Index: AcOtePluTwJtr3ahTZOUo1anVXXc8wAAlBnQ X-OriginalArrivalTime: 18 Nov 2003 02:36:12.0400 (UTC) FILETIME=[BB27BF00:01C3AD7C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CAF2C@orsmsx410.jf.intel.com> Date: Mon, 17 Nov 2003 18:36:12 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable >=20 > Lily, >=20 > I dont mean to be rude, but: > Easier for you to say because you can get access to the NPF docs. > I dont. Please dont tell me you havent looked at those docs=20 > or there is > no correlation happening with the model or that that the NPF=20 > model doesnt > get discussed in the model design team meetings. As long as the FE model draft is self-contained, I don't see why you are = so upset about it. >=20 > All i am asking for is access to those docs be made available > or stop talking and corelating with the NPF. > I would really like the chairs to make a comment on this issue. > Otherwise i plan to raise this one level above. I don't see why I should stop you either :-) And I think I've said enough on the suject, so I will shut up and go = home now :-) >=20 > cheers, > jamal Good night :-) >=20 > On Mon, 17 Nov 2003, Yang, Lily L wrote: >=20 > > The ForCES FE model document is meant to be self-contained=20 > and so there > > is no need to read NPF documents in order for you to understand FE > > model. But many other people do care about both and want to=20 > make sure > > the standards coming out of both IETF and NPF can work=20 > together. I don't > > see anything wrong with that. > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Monday, November 17, 2003 6:34 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: NPF WAS (Re: ForCES model - other thoughts > > > > Lily> Thank you very much for your comments. I agree it is=20 > important to > > Lily> keep NPF and ForCES aligned and anyone who is involved in both > > Lily> forums has to shoulder that responsibility. > > > > The NPF connection bothers me. AFAIK, the NPF has no liason with the > > IETF. Their documents other than ones which are complete are only > > accessible to members. Unfortunatley, docs which make more sense > > have not completed that level yet. > > Granted some people attending the NPF also attend the IETF,=20 > but it is > > extremely difficult to follow arguements based on some=20 > closed documents. > > Either the NPF makes exception or i strongly recommend we=20 > stop refering > > to them at ForCES. > > I am willing to keep the docs to myself and not=20 > redistribute it if an > > exception is made. > > > > cheers, > > jamal > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 17 22:31:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20942 for ; Mon, 17 Nov 2003 22:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALwau-0004go-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 22:32:00 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ALwau-0004gl-00 for forces-archive@IETF.ORG; Mon, 17 Nov 2003 22:32:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C4B489@cherry.ease.lsoft.com>; Mon, 17 Nov 2003 22:32:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60948117 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Nov 2003 22:31:59 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Nov 2003 22:31:59 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hAI3W5a24993 for ; Mon, 17 Nov 2003 19:32:05 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Mon, 17 Nov 2003 19:32:05 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CAF2C@orsmsx410.jf.intel.com> Precedence: list On Mon, 17 Nov 2003, Yang, Lily L wrote: > > > > Lily, > > > > I dont mean to be rude, but: > > Easier for you to say because you can get access to the NPF docs. > > I dont. Please dont tell me you havent looked at those docs > > or there is > > no correlation happening with the model or that that the NPF > > model doesnt > > get discussed in the model design team meetings. > > As long as the FE model draft is self-contained, I don't see > why you are so upset about it. I may be missing something subtle, so pardon my ignorance. How do IEEE and ITU interact with IETF? Dont you think the NPF should be under similar ground rules? Please dont handwave on the NPF docs - They are used to influence the model. > > > > All i am asking for is access to those docs be made available > > or stop talking and corelating with the NPF. > > I would really like the chairs to make a comment on this issue. > > Otherwise i plan to raise this one level above. > > I don't see why I should stop you either :-) > And I think I've said enough on the suject, so I will shut up > and go home now :-) > I will wait for the chairs to comment. My offer still stands: I am willing to see these documents under a "do not distribute" non-disclosure. I am sure a lot of other people will as well. The best thing to do is to have a liason between ForCES and the NPF. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 03:00:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09450 for ; Tue, 18 Nov 2003 03:00:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0mv-000038-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 03:00:41 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM0mu-000035-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 03:00:40 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C4BBA9@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 3:00:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60972382 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 03:00:39 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 03:00:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOtVaR1GcIFTAOYR62qFgARZdXVBwAU3+9Q Approved-By: Tal Anker Message-ID: Date: Tue, 18 Nov 2003 10:00:50 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Well,=20 I would vote strongly for multicast support... I think that it would = obviously boost the performance of the CE (number of configurations = passed to FEs per unit of time, etc). The main issue with the usage of = multicast here is to deal correctly with the reliability of a = "transaction" made between the CE and a set of FEs. Given that this is = doable (and it obviously is by using well known building blocks) my = belief is that not using multicat will probably degrade the overall = router/switch performance when many FE's are involved... my 2c$. - Tal -----Original Message----- From: Steven Blake [mailto:slblake@torrentnet.com] Sent: Monday, November 17, 2003 11:54 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Support for multicast in the ForCES protocol The issue of support for multicast transport in the ForCES protocol has been a recurring topic of dispute between the competing protocol teams. Multicast is not explicitly called out as a protocol requirement in draft-ietf-forces-requirements-10.txt, and it is not mentioned in the protocol evaluation draft. However, there are at least some people (myself included) who believe that it is a pretty useful feature in some system environments where ForCES could be applicable. Rather than make an argument for or against multicast support (some people on this list have already heard my opinion anyway), I am wondering if there are any folks not directly involved in the protocol teams who have an opinion either pro or con? Apologies if I am exhuming a dead horse. Regards, =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 Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 05:44:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13816 for ; Tue, 18 Nov 2003 05:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3LC-0002Ns-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 05:44:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM3LB-0002Nn-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 05:44:13 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C4BDF6@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 5:44:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60976431 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 05:44:13 -0500 Received: from 192.19.192.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 05:44:13 -0400 Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail1.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hAIAiDU18114 for ; Tue, 18 Nov 2003 05:44:13 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hAIAiCd10327 for ; Tue, 18 Nov 2003 05:44:12 -0500 (EST) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 05:44:12 -0500 Received: from jrenwick ([135.149.246.32]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 05:44:07 -0500 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 V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 18 Nov 2003 10:44:07.0774 (UTC) FILETIME=[E4A34FE0:01C3ADC0] Approved-By: John Renwick Message-ID: Date: Tue, 18 Nov 2003 04:44:07 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069079667.1023.8.camel@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit Jamal, As a representative to NP Forum, please let me try to answer you. First, we can ask the NPF board if there's a way we can make some of our Functional API (FAPI) drafts public for the purpose of liaison with ForCES, but they may say no. Second, if you saw the NPF drafts, you might be "underwhelmed." In many ways they are in a rougher state than the ForCES drafts. Third, while we could establish a formal liaison, what's actually happening is much more effective than that: common authorship. Some of the people and companies making the strongest contributions to the ForCES model and protocol proposals are making the same or compatible proposals in NPF, even taking the lead there. This is the best way to ensure that ForCES and FAPI work well together, which is what we all want. ForCES is not being led in some sinister way down a path decided by NPF in secret. Rather, the same people are openly influencing both groups in the same directions, and their names are listed in the ForCES drafts as authors. Some NPF drafts that we thought were ready for approval are actually being held in the FAPI task group now, waiting for consensus to arrive in ForCES so that they can be adjusted to agree with ForCES details if necessary. I don't mean to suggest that you should join NPF, but if you were to participate there, you would see pretty much the same thing you're seeing in ForCES, many of the same people, and some of the same debates. As Lily said, the ForCES work stands on its own; the drafts are being worked on openly, not influenced or constrained in any way by things you can't see going on in NPF. Best Regards, John -- John Renwick Agere Systems Software Technical Manager 1230 Northland Drive Phone: (651) 675-2986 Mendota Heights, MN 55120 FAX: (707) 897-7928 Cell: (612) 669-9397 mailto:jrenwick@agere.com http://www.agere.com > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Monday, November 17, 2003 8:34 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: NPF WAS (Re: ForCES model - other thoughts > > > Lily> Thank you very much for your comments. I agree it is important to > Lily> keep NPF and ForCES aligned and anyone who is involved in both > Lily> forums has to shoulder that responsibility. > > The NPF connection bothers me. AFAIK, the NPF has no liason with the > IETF. Their documents other than ones which are complete are only > accessible to members. Unfortunatley, docs which make more sense > have not completed that level yet. > Granted some people attending the NPF also attend the IETF, but it is > extremely difficult to follow arguements based on some closed documents. > Either the NPF makes exception or i strongly recommend we stop refering > to them at ForCES. > I am willing to keep the docs to myself and not redistribute it if an > exception is made. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 06:50:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18151 for ; Tue, 18 Nov 2003 06:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM4Na-0003as-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 06:50:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM4NZ-0003ap-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 06:50:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C4C01B@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 6:50:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61011155 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 06:50:42 -0500 Received: from 137.222.10.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 06:50:41 -0400 Received: from ncs.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 18 Nov 2003 11:50:36 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by ncs.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hAIBoGM14496 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 18 Nov 2003 11:50:17 GMT References: Originator-Info: login-token=Mulberry:01+zh7RGCd3LgzefSuKWGeqK0zmvFnO22uqaY4ovRoKV5m8K8=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <86093696.1069156216@EEN9169.een.bris.ac.uk> Date: Tue, 18 Nov 2003 11:50:16 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Jamil, I appreciate your concerns but I agree with Lily's and John Renwick's comments: the ForCES model is a standalone document that is shaping the NPF's thoughts on how to model an FE. You aren't missing anything by not seeing the NPF's drafts. I've mentioned my concerns before about use by the NPF of the ForCES model off-the-shelf, particularly that the ForCES model becomes too specific that NPF implementers feel too constrained. However, (a) nobody in the NPF has actually yet said they feel it's a real problem, and (b) the way to avoid IMO it is to encourage the NPF group to contribute more to ForCES. I don't think there is any active contributor to the NPF's discussions who is not also a member of ForCES, or who does not have a close colleague involved in ForCES. I hope this will allow enough "liaison" to happen without the bureaucracy of a formal process worthy of ETSI or the ITU. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 10:06:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23845 for ; Tue, 18 Nov 2003 10:06:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7RK-0006VG-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 10:06:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM7RJ-0006V8-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 10:06:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C4C484@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 10:06:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61022138 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 10:06:45 -0500 Received: from 209.226.175.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 10:06:40 -0400 Received: from develSPavel ([67.69.27.58]) by tomts27-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031118150632.CFIG6808.tomts27-srv.bellnexxia.net@develSPavel> for ; Tue, 18 Nov 2003 10:06:32 -0500 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com> Date: Tue, 18 Nov 2003 10:07:56 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069106025.14238.52.camel@newcastle.torrentnet.com> Precedence: list Content-Transfer-Encoding: 7bit Hi there! I haven't followed this thread of discussions and therefore I apologize if I am repeating something that has been mentioned before. First of all, I must mention that I am totally with Steven and the others that ask for multicast support in the ForCES protocol. If necessary, in order to convince people we can come up with a number of examples and real world cases that would justify it. I am not sure if it is assumed or not but I think we should add broadcast next to multicast. However, these would be transport technology options rather than ForCES protocol message types. That is, we should leave the option of binding different ForCES protocol messages to either unicast, multicast or broadcast transport, as being platform (NE) specific. This is because different implementations might have different resources available at transport and physical level. The question is: do we add some sort of "multicast group management" as part of ForCES control protocol, or leave it to the transport layer itself? To conclude, considering the switching fabric and other interconnection technologies proposed in the last few years especially for distributed, multi-shelf core routers, I believe the only viable option is to include multicast/broadcast as transport options for ForCES protocol(s). Regard, Sandy Pavel -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake Sent: November 17, 2003 4:54 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Support for multicast in the ForCES protocol The issue of support for multicast transport in the ForCES protocol has been a recurring topic of dispute between the competing protocol teams. Multicast is not explicitly called out as a protocol requirement in draft-ietf-forces-requirements-10.txt, and it is not mentioned in the protocol evaluation draft. However, there are at least some people (myself included) who believe that it is a pretty useful feature in some system environments where ForCES could be applicable. Rather than make an argument for or against multicast support (some people on this list have already heard my opinion anyway), I am wondering if there are any folks not directly involved in the protocol teams who have an opinion either pro or con? Apologies if I am exhuming a dead horse. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 10:33:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25863 for ; Tue, 18 Nov 2003 10:33:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7r2-0006yd-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 10:33:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM7r1-0006ya-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 10:33:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C4C3D2@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 10:33:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61023746 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 10:33:21 -0500 Received: from 12.38.212.174 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 10:33:21 -0400 Received: from aatlas-lt2.avici.com (b2-pc109.avici.com [10.2.100.109]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id hAIFXKEA005135 for ; Tue, 18 Nov 2003 10:33:20 -0500 X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <1069106025.14238.52.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Alia Atlas Message-ID: <5.1.0.14.2.20031118102833.01d8ea08@mailhost.avici.com> Date: Tue, 18 Nov 2003 10:36:36 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alia Atlas Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com > Precedence: list Hi, I'd also like to chime in on the importance of having multicast transport in the FORCES protocol. Just the idea of trying to download common updated forwarding tables to dozens or more FEs individually and to do so extremely quickly is disturbing. As Sandy said, there are interconnection technologies to allow the packet replication/multicast distribution. It is necessary to have multicast to enable scaling to large numbers of FEs and non-trivial forwarding information (IPv4 prefixes, global ILM entries, etc). Unfortunately, multicast transport is not something which can be efficiently layered on top of the FORCES protocol; it needs to be built in. I've just started following FORCES, so I'm sorry if this is redundant. Alia Atlas At 10:07 AM 11/18/2003, Sandy Pavel wrote: >Hi there! > >I haven't followed this thread of discussions and therefore I apologize >if >I am repeating something that has been mentioned before. > >First of all, I must mention that I am totally with Steven and the >others that ask for multicast support in the ForCES protocol. If >necessary, in order to convince people we can come up with a number of >examples and real world cases that would justify it. > >I am not sure if it is assumed or not but I think we should add >broadcast next to multicast. > >However, these would be transport technology options rather than ForCES >protocol message types. That is, we should leave the option of binding >different ForCES protocol messages to either unicast, multicast or >broadcast transport, as being platform (NE) specific. This is because >different implementations might have different resources available at >transport and physical level. > >The question is: do we add some sort of "multicast group management" as >part of ForCES control protocol, or leave it to the transport layer >itself? > >To conclude, considering the switching fabric and other interconnection >technologies proposed in the last few years especially for distributed, >multi-shelf core routers, I believe the only viable option is to include >multicast/broadcast as transport options for ForCES protocol(s). > >Regard, >Sandy Pavel > > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >Sent: November 17, 2003 4:54 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Support for multicast in the ForCES protocol > >The issue of support for multicast transport in the ForCES protocol has >been a recurring topic of dispute between the competing protocol teams. >Multicast is not explicitly called out as a protocol requirement in >draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >protocol evaluation draft. However, there are at least some people >(myself included) who believe that it is a pretty useful feature in some >system environments where ForCES could be applicable. > >Rather than make an argument for or against multicast support (some >people on this list have already heard my opinion anyway), I am >wondering if there are any folks not directly involved in the protocol >teams who have an opinion either pro or con? > >Apologies if I am exhuming a dead horse. > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 11:43:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29653 for ; Tue, 18 Nov 2003 11:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8xN-0000X4-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 11:44:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM8xM-0000X1-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 11:44:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C4C587@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 11:44:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61032892 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 11:43:55 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 11:43:55 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003111808430759:2016 ; Tue, 18 Nov 2003 08:43:07 -0800 References: <86093696.1069156216@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2003 08:43:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2003 08:43:10 AM, Serialize complete at 11/18/2003 08:43:10 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069173830.1025.38.camel@jzny.localdomain> Date: Tue, 18 Nov 2003 11:43:50 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <86093696.1069156216@EEN9169.een.bris.ac.uk> Precedence: list Content-Transfer-Encoding: 7bit Alistair and John as well, I really didnt wanna cause disturbance with this - i just feel under-privileged for not having access to those docs ;-> On Tue, 2003-11-18 at 06:50, Alistair Munro wrote: > I don't think there is any active contributor to the NPF's discussions who > is not also a member of ForCES, or who does not have a close colleague > involved in ForCES. The corrollary is not true - which is the major issue here. Sure i have friends at the NPF but they are not allowed to give me docs by regulation. OTOH, anyone at the NPF can access IETF docs. I did manage to have a brief glance at one or two harcopies of NPF i did find they were useful[1]. I know they are being used in relation to ForCES. I know i may disagree with some of the ideas that may show up at ForCES originating from the NPF and in that case if i disagree with some of the ideas i would like to see what i am disagreeing with. > I hope this will allow enough "liaison" to happen > without the bureaucracy of a formal process worthy of ETSI or the ITU. > I dont wanna go to that level - there has to be a shortcut (such as making the docs accessible). cheers, jamal [1]They were passed to me by mistake and i had to give them up about 5 minutes later (rightly so i should add) when it was found that i wasnt a "member". From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 12:25:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02524 for ; Tue, 18 Nov 2003 12:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9c4-0001Y2-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 12:26:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AM9c3-0001Xu-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 12:26:04 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C4C77F@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 12:26:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61035649 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 12:26:02 -0500 Received: from 192.19.192.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 12:26:02 -0400 Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail1.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hAIHQ1U14719 for ; Tue, 18 Nov 2003 12:26:01 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id hAIHQ0d28026 for ; Tue, 18 Nov 2003 12:26:00 -0500 (EST) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 12:26:01 -0500 Received: from jrenwick ([135.149.51.19]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Nov 2003 12:26:00 -0500 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 V6.00.2800.1106 X-OriginalArrivalTime: 18 Nov 2003 17:26:00.0770 (UTC) FILETIME=[091A8220:01C3ADF9] Approved-By: John Renwick Message-ID: Date: Tue, 18 Nov 2003 11:26:02 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069173830.1025.38.camel@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit Jamal, > [stuff deleted] > I know i may disagree with some of the ideas that may show up > at ForCES originating from the NPF and in that case if i disagree with > some of the ideas i would like to see what i am disagreeing with. > This is related to the point Lily was making, which I agree with. Any idea contributed to ForCES must be fully explained in an Internet Draft and is subject to examination and justification in the ForCES WG, regardless of its origin. Ideas originating in NPF are no different in that regard. As a parallel example: an individual employee of vendor X submits an Internet Draft that happens to be based on X's not-yet-released product, the documentation for which is available only under NDA. They propose that it become a WG draft. In the IETF, the I-D stands or falls on its own merits; if it can't be understood and accepted without reference to private documents, then either it needs to be expanded upon or it simply shouldn't progress. It's neither necessary nor appropriate to ask X to disclose its source documents in order to achieve consensus on the I-D. You may substitute "NPF" for "Vendor X" in the above, and the argument changes not a bit. Regards, John From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 13:06:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04381 for ; Tue, 18 Nov 2003 13:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAEu-0002F8-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 13:06:13 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMAEu-0002F5-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 13:06:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C4C694@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 13:06:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61039270 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 13:06:11 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 13:06:11 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003111810052481:2127 ; Tue, 18 Nov 2003 10:05:24 -0800 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2003 10:05:25 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/18/2003 10:05:26 AM, Serialize complete at 11/18/2003 10:05:26 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069178768.1024.54.camel@jzny.localdomain> Date: Tue, 18 Nov 2003 13:06:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2003-11-18 at 12:26, John Renwick wrote: > You may substitute "NPF" for "Vendor X" in the above, and the argument > changes not a bit. Couldnt have put it better myself. Let me say i know where you are coming from and empathize but dont sympathize. NPF is "selling" a product that I am not supposed to see; it will just show up on the draft in the name of "contribution". Just like SCTP is showing up on IPFIX because CISCO has it. I see this as a big problem (both the CISCO at IPFIX issue and NPF at Forces) and I have reservations about the concept in general. In this case we can avoid it: Just release the docs under some dont-distribute clause or form a liason with the IETF. Lets at most have only 10% politics and reserve the other 90% for technical progress. cheers, jamal PS:- when i last attended the NPF it was a melee of marketing noise driven by exactly the above thinking. Progress was non-existent because people(chip vendors) thought things should be driven by the way their products are built. I heard theres a huge improvement now that customers are joining. From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 13:19:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05354 for ; Tue, 18 Nov 2003 13:19:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMASQ-0002b9-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 13:20:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMASP-0002b6-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 13:20:09 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C4C6D0@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 13:20:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61040184 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 13:20:08 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 13:20:08 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 722101F00D9 for ; Tue, 18 Nov 2003 13:20:07 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 5E1011F0061 for ; Tue, 18 Nov 2003 13:20:03 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-8.2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <1069178768.1024.54.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FBA62D0.C475F39F@idt.com> Date: Tue, 18 Nov 2003 13:20:00 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > > In this case we can avoid it: Just release the docs under some > dont-distribute clause or form a liason with the IETF. Other working groups (IEEE, etc.) already have this kind of relationship with IETF. They pre-release documents to certain IETF working groups. NPF could do something similar, if it's possible for them to restrict document access to the software group. Having some sort of "ietf/forces" account to obtain access to NPF archives would be useful, and would help facilitate communication between the groups. I think an offical request from the ForCES chair(s) to the NPF chair(s) would be appropriate here. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 15:01:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10287 for ; Tue, 18 Nov 2003 15:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMC2Q-0004UJ-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 15:01:26 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMC2Q-0004UG-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 15:01:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C4CA31@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 15:01:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61052177 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 15:01:24 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 15:01:24 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAIK1Ox06277 for ; Tue, 18 Nov 2003 15:01:24 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAIK1Nx08088 for ; Tue, 18 Nov 2003 15:01:23 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id PAA12962 for ; Tue, 18 Nov 2003 15:01:23 -0500 (EST) References: <9CB758BBEE58754F8F33234D75B9F4B009FFC4@orsmsx410.jf.intel.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069185682.14238.92.camel@newcastle.torrentnet.com> Date: Tue, 18 Nov 2003 15:01:22 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Call To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B009FFC4@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hormuzd, I'm super-busy today. Robert and I are working on the evaluation draft for Friday, and we are also putting together notes on netlink2 and FACT based on our dinner conversation last week. Stay tuned; we should have something available as a baseline for discussion before the end of the week. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 18 15:07:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11000 for ; Tue, 18 Nov 2003 15:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMC8U-0004ZA-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 15:07:42 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMC8U-0004Z7-00 for forces-archive@IETF.ORG; Tue, 18 Nov 2003 15:07:42 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C4C979@cherry.ease.lsoft.com>; Tue, 18 Nov 2003 15:07:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61052858 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Nov 2003 15:07:41 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Nov 2003 15:07:41 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAIK7ex06390 for ; Tue, 18 Nov 2003 15:07:40 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAIK7ex08542 for ; Tue, 18 Nov 2003 15:07:40 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id PAA13098 for ; Tue, 18 Nov 2003 15:07:39 -0500 (EST) References: <9CB758BBEE58754F8F33234D75B9F4B009FFC4@orsmsx410.jf.intel.com> <1069185682.14238.92.camel@newcastle.torrentnet.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069186059.14236.96.camel@newcastle.torrentnet.com> Date: Tue, 18 Nov 2003 15:07:39 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Whoops! [Re: Call] To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069185682.14238.92.camel@newcastle.torrentnet.com> Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2003-11-18 at 15:01, Steven Blake wrote: > Hormuzd, > > I'm super-busy today. Robert and I are working on the evaluation draft > for Friday, and we are also putting together notes on netlink2 and FACT > based on our dinner conversation last week. Stay tuned; we should have > something available as a baseline for discussion before the end of the > week. Sorry for misdirecting this private mail; I guess I should have my e-mail license revoked. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 07:29:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14348 for ; Wed, 19 Nov 2003 07:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRT8-0006A0-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 07:30:02 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMRT7-00069s-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 07:30:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C4DD0E@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 7:29:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61153537 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 07:29:58 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 07:29:58 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C4DDFF@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 7:29:58 -0500 Message-ID: Date: Wed, 19 Nov 2003 07:29:58 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Ligang Dong Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list hi, Yes, the multicast will improve the performance. I agree with Sandy Pavel about "first broadcast, next multicast". In fact, the GRMP (draft-wang- forces-grmp-00.txt) have already considered broadcast. By a careful design about the CE/FE identifier, it is not difficult to support multicast in GRMP. ligang On Tue, 18 Nov 2003 10:36:36 -0500, Alia Atlas wrote: >Hi, > >I'd also like to chime in on the importance of having multicast transport >in the FORCES protocol. Just the idea of trying to download common updated >forwarding tables to dozens or more FEs individually and to do so extremely >quickly is disturbing. As Sandy said, there are interconnection >technologies to allow the packet replication/multicast distribution. It is >necessary to have multicast to enable scaling to large numbers of FEs and >non-trivial forwarding information (IPv4 prefixes, global ILM entries, >etc). Unfortunately, multicast transport is not something which can be >efficiently layered on top of the FORCES protocol; it needs to be built in. > >I've just started following FORCES, so I'm sorry if this is redundant. > >Alia Atlas > > >At 10:07 AM 11/18/2003, Sandy Pavel wrote: >>Hi there! >> >>I haven't followed this thread of discussions and therefore I apologize >>if >>I am repeating something that has been mentioned before. >> >>First of all, I must mention that I am totally with Steven and the >>others that ask for multicast support in the ForCES protocol. If >>necessary, in order to convince people we can come up with a number of >>examples and real world cases that would justify it. >> >>I am not sure if it is assumed or not but I think we should add >>broadcast next to multicast. >> >>However, these would be transport technology options rather than ForCES >>protocol message types. That is, we should leave the option of binding >>different ForCES protocol messages to either unicast, multicast or >>broadcast transport, as being platform (NE) specific. This is because >>different implementations might have different resources available at >>transport and physical level. >> >>The question is: do we add some sort of "multicast group management" as >>part of ForCES control protocol, or leave it to the transport layer >>itself? >> >>To conclude, considering the switching fabric and other interconnection >>technologies proposed in the last few years especially for distributed, >>multi-shelf core routers, I believe the only viable option is to include >>multicast/broadcast as transport options for ForCES protocol(s). >> >>Regard, >>Sandy Pavel >> >> >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>Sent: November 17, 2003 4:54 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Support for multicast in the ForCES protocol >> >>The issue of support for multicast transport in the ForCES protocol has >>been a recurring topic of dispute between the competing protocol teams. >>Multicast is not explicitly called out as a protocol requirement in >>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>protocol evaluation draft. However, there are at least some people >>(myself included) who believe that it is a pretty useful feature in some >>system environments where ForCES could be applicable. >> >>Rather than make an argument for or against multicast support (some >>people on this list have already heard my opinion anyway), I am >>wondering if there are any folks not directly involved in the protocol >>teams who have an opinion either pro or con? >> >>Apologies if I am exhuming a dead horse. >> >> >>Regards, >> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>Steven L. Blake >>Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 14:38:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05705 for ; Wed, 19 Nov 2003 14:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMY9Y-0000Hk-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 14:38:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMY9Y-0000Hg-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 14:38:16 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C4E5A1@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 14:38:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61186214 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 14:38:14 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 14:38:14 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5842899 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 14:38:13 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com > <1069106025.14238.52.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031119142344.01a7acd8@localhost> Date: Wed, 19 Nov 2003 14:38:03 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.2.20031118102833.01d8ea08@mailhost.avici.com> Precedence: list I find myself very torn on this issue. So I am going to try to show my thinking in hopes that someone can either point out aspects I am missing, or point out why certain aspects are more important than I tend to treat them. It would be nice to simply say "multicast is for later". However, it is equally clear that if we are going to use multicast it is much better to support it as an integral part of the protocol suite. This directly effects core protocol features. At the same time, my gut feel is that the complexity is not worth the value. But that is not a good reason for anyone else to make a decision. It is not even a good reason for me to make a decision. I think some of this has to do with rates of change of information vs easily supportable load. Clearly, service configuration does not change often enough to require multicast. So the question becomes what rate of change of next-hops are we likely to need to support, what number of FEs per CE are we trying to communicate those changes to, and is the resultant load likely to be such that we will want multicast. Clearly, in many environments the answer is no. But that is not sufficient to say we should not support it. Equally clearly, there are some environments that we would like to support eventually that will push the limits for unicast distribution. But is that margin of applicability enough to justify the complexity. Yours, Joel At 10:36 AM 11/18/2003 -0500, you wrote: >Hi, > >I'd also like to chime in on the importance of having multicast transport >in the FORCES protocol. Just the idea of trying to download common updated >forwarding tables to dozens or more FEs individually and to do so extremely >quickly is disturbing. As Sandy said, there are interconnection >technologies to allow the packet replication/multicast distribution. It is >necessary to have multicast to enable scaling to large numbers of FEs and >non-trivial forwarding information (IPv4 prefixes, global ILM entries, >etc). Unfortunately, multicast transport is not something which can be >efficiently layered on top of the FORCES protocol; it needs to be built in. > >I've just started following FORCES, so I'm sorry if this is redundant. > >Alia Atlas > > >At 10:07 AM 11/18/2003, Sandy Pavel wrote: >>Hi there! >> >>I haven't followed this thread of discussions and therefore I apologize >>if >>I am repeating something that has been mentioned before. >> >>First of all, I must mention that I am totally with Steven and the >>others that ask for multicast support in the ForCES protocol. If >>necessary, in order to convince people we can come up with a number of >>examples and real world cases that would justify it. >> >>I am not sure if it is assumed or not but I think we should add >>broadcast next to multicast. >> >>However, these would be transport technology options rather than ForCES >>protocol message types. That is, we should leave the option of binding >>different ForCES protocol messages to either unicast, multicast or >>broadcast transport, as being platform (NE) specific. This is because >>different implementations might have different resources available at >>transport and physical level. >> >>The question is: do we add some sort of "multicast group management" as >>part of ForCES control protocol, or leave it to the transport layer >>itself? >> >>To conclude, considering the switching fabric and other interconnection >>technologies proposed in the last few years especially for distributed, >>multi-shelf core routers, I believe the only viable option is to include >>multicast/broadcast as transport options for ForCES protocol(s). >> >>Regard, >>Sandy Pavel >> >> >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>Sent: November 17, 2003 4:54 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Support for multicast in the ForCES protocol >> >>The issue of support for multicast transport in the ForCES protocol has >>been a recurring topic of dispute between the competing protocol teams. >>Multicast is not explicitly called out as a protocol requirement in >>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>protocol evaluation draft. However, there are at least some people >>(myself included) who believe that it is a pretty useful feature in some >>system environments where ForCES could be applicable. >> >>Rather than make an argument for or against multicast support (some >>people on this list have already heard my opinion anyway), I am >>wondering if there are any folks not directly involved in the protocol >>teams who have an opinion either pro or con? >> >>Apologies if I am exhuming a dead horse. >> >> >>Regards, >> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>Steven L. Blake >>Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 15:04:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06941 for ; Wed, 19 Nov 2003 15:04:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYYv-000107-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 15:04:29 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMYYu-000103-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 15:04:29 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C4E5B6@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 15:04:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61189355 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 15:04:26 -0500 Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 15:04:26 -0500 Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 19 Nov 2003 11:59:46 -0800 Received: from TSridhar (adsl-66-122-42-230.futsoft.com [66.122.42.230]) by sanjose.futsoft.com (8.12.2/8.12.5) with SMTP id hAJJd1jO000734 for ; Wed, 19 Nov 2003 11:39:04 -0800 MIME-Version: 1.0 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 V6.00.2727.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Approved-By: "T. Sridhar" Message-ID: Date: Wed, 19 Nov 2003 12:04:05 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "T. Sridhar" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031119142344.01a7acd8@localhost> Precedence: list Content-Transfer-Encoding: 7bit Hi, I am sure I am missing something but if multicasting is only done below the ForCES protocol level (e.g UDP over a multicast delivery mechanism), what are we giving up? Other than a group addressing scheme, what else do we need to add to the ForCES protocol itself? This does impose a group addressing and multicast delivery requirement on the underlying transport but that is not an unreasonable requirement, I feel. Thanks, Sridhar ---------------------------------------------- From: Forwarding and Control Element Separation [mailto:FORCES@peach.ease.lsoft.com]On Behalf Of Joel M. Halpern Sent: Wednesday, November 19, 2003 11:38 AM To: FORCES@peach.ease.lsoft.com Subject: Re: Support for multicast in the ForCES protocol I find myself very torn on this issue. So I am going to try to show my thinking in hopes that someone can either point out aspects I am missing, or point out why certain aspects are more important than I tend to treat them. It would be nice to simply say "multicast is for later". However, it is equally clear that if we are going to use multicast it is much better to support it as an integral part of the protocol suite. This directly effects core protocol features. At the same time, my gut feel is that the complexity is not worth the value. But that is not a good reason for anyone else to make a decision. It is not even a good reason for me to make a decision. I think some of this has to do with rates of change of information vs easily supportable load. Clearly, service configuration does not change often enough to require multicast. So the question becomes what rate of change of next-hops are we likely to need to support, what number of FEs per CE are we trying to communicate those changes to, and is the resultant load likely to be such that we will want multicast. Clearly, in many environments the answer is no. But that is not sufficient to say we should not support it. Equally clearly, there are some environments that we would like to support eventually that will push the limits for unicast distribution. But is that margin of applicability enough to justify the complexity. Yours, Joel At 10:36 AM 11/18/2003 -0500, you wrote: >Hi, > >I'd also like to chime in on the importance of having multicast transport >in the FORCES protocol. Just the idea of trying to download common updated >forwarding tables to dozens or more FEs individually and to do so extremely >quickly is disturbing. As Sandy said, there are interconnection >technologies to allow the packet replication/multicast distribution. It is >necessary to have multicast to enable scaling to large numbers of FEs and >non-trivial forwarding information (IPv4 prefixes, global ILM entries, >etc). Unfortunately, multicast transport is not something which can be >efficiently layered on top of the FORCES protocol; it needs to be built in. > >I've just started following FORCES, so I'm sorry if this is redundant. > >Alia Atlas > > >At 10:07 AM 11/18/2003, Sandy Pavel wrote: >>Hi there! >> >>I haven't followed this thread of discussions and therefore I apologize >>if >>I am repeating something that has been mentioned before. >> >>First of all, I must mention that I am totally with Steven and the >>others that ask for multicast support in the ForCES protocol. If >>necessary, in order to convince people we can come up with a number of >>examples and real world cases that would justify it. >> >>I am not sure if it is assumed or not but I think we should add >>broadcast next to multicast. >> >>However, these would be transport technology options rather than ForCES >>protocol message types. That is, we should leave the option of binding >>different ForCES protocol messages to either unicast, multicast or >>broadcast transport, as being platform (NE) specific. This is because >>different implementations might have different resources available at >>transport and physical level. >> >>The question is: do we add some sort of "multicast group management" as >>part of ForCES control protocol, or leave it to the transport layer >>itself? >> >>To conclude, considering the switching fabric and other interconnection >>technologies proposed in the last few years especially for distributed, >>multi-shelf core routers, I believe the only viable option is to include >>multicast/broadcast as transport options for ForCES protocol(s). >> >>Regard, >>Sandy Pavel >> >> >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>Sent: November 17, 2003 4:54 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Support for multicast in the ForCES protocol >> >>The issue of support for multicast transport in the ForCES protocol has >>been a recurring topic of dispute between the competing protocol teams. >>Multicast is not explicitly called out as a protocol requirement in >>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>protocol evaluation draft. However, there are at least some people >>(myself included) who believe that it is a pretty useful feature in some >>system environments where ForCES could be applicable. >> >>Rather than make an argument for or against multicast support (some >>people on this list have already heard my opinion anyway), I am >>wondering if there are any folks not directly involved in the protocol >>teams who have an opinion either pro or con? >> >>Apologies if I am exhuming a dead horse. >> >> >>Regards, >> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>Steven L. Blake >>Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 15:38:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10655 for ; Wed, 19 Nov 2003 15:38:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ5i-0001nO-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 15:38:22 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ5h-0001nL-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 15:38:21 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C4E802@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 15:38:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61192988 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 15:38:20 -0500 Received: from 192.19.192.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 15:38:19 -0500 Received: from alcerelay.agere.com (alcerelay.agere.com [128.94.210.102]) by alageremail1.agere.com (8.11.7+Sun/8.10.2) with ESMTP id hAJKcKU19724 for ; Wed, 19 Nov 2003 15:38:20 -0500 (EST) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alcerelay.agere.com (8.11.6/8.11.6) with ESMTP id hAJKcVj22999 for ; Wed, 19 Nov 2003 15:38:31 -0500 Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 15:38:19 -0500 Received: from jrenwick ([135.149.51.19]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 15:38:19 -0500 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 V6.00.2800.1106 X-OriginalArrivalTime: 19 Nov 2003 20:38:19.0307 (UTC) FILETIME=[110547B0:01C3AEDD] Approved-By: John Renwick Message-ID: Date: Wed, 19 Nov 2003 14:38:19 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: John Renwick Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031119142344.01a7acd8@localhost> Precedence: list Content-Transfer-Encoding: 7bit Joel, > [stuff deleted, all of which I agree with] > > So the question becomes what rate of change of next-hops are we likely to > need to support, what number of FEs per CE are we trying to communicate > those changes to, and is the resultant load likely to be such that we will > want multicast. > Clearly, in many environments the answer is no. But that is not > sufficient > to say we should not support it. > Equally clearly, there are some environments that we would like to support > eventually that will push the limits for unicast distribution. > But is that margin of applicability enough to justify the complexity. As you say: somewhere, somebody will inevitably come up with a set of numbers for link capacity, utilization, updates per second and number of FEs that will force a requirement for flooding. For instance, link capacity 10000 transactions per second, 10% maximum utilization, 10 updates per second, and 100 FEs. The problem is similar to the database synchronization that link state protocols do, and in that environment flooding is the accepted mechanism. Why not use it in ForCES as well, since it's something we're all comfortable with? -- John Renwick Agere Systems Software Technical Manager 1230 Northland Drive Phone: (651) 675-2986 Mendota Heights, MN 55120 FAX: (707) 897-7928 Cell: (612) 669-9397 mailto:jrenwick@agere.com http://www.agere.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 16:05:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11606 for ; Wed, 19 Nov 2003 16:05:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZVo-00029V-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 16:05:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMZVn-00029S-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 16:05:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C4E83C@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 16:05:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61195213 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 16:05:17 -0500 Received: from 209.226.175.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 16:05:17 -0500 Received: from develSPavel ([67.69.27.58]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031119210517.ESOU11704.tomts14-srv.bellnexxia.net@develSPavel> for ; Wed, 19 Nov 2003 16:05:17 -0500 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> Date: Wed, 19 Nov 2003 16:07:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I agree. The ForCES protocol should not reinvent the wheel by re-implementing a broadcast/multicast protocol. More, the actual multicast mechanism would be technology dependent. As mentioned before, having the _option_ in ForCES to _choose_ the transport mechanism (and in the case of multicast, to specify the multicast group), is at least in principle, most of what we need to do. It might sound simplistic but we should also try to consider the complexity and more importantly, the layer separation in the protocol stack that concerns ForCES. Static multicast group membership sounds to me as being acceptable and therefore there is no need to have a group membership management protocol. Functionally the multicast/broadcast is not necessary; it is merely a mechanism that allows for efficient use of the transport technology and _scalable_ router architectures. This is especially valid in core router space but less important in enterprise. Regards, Sandy -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of T. Sridhar Sent: November 19, 2003 3:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Support for multicast in the ForCES protocol Hi, I am sure I am missing something but if multicasting is only done below the ForCES protocol level (e.g UDP over a multicast delivery mechanism), what are we giving up? Other than a group addressing scheme, what else do we need to add to the ForCES protocol itself? This does impose a group addressing and multicast delivery requirement on the underlying transport but that is not an unreasonable requirement, I feel. Thanks, Sridhar ---------------------------------------------- From: Forwarding and Control Element Separation [mailto:FORCES@peach.ease.lsoft.com]On Behalf Of Joel M. Halpern Sent: Wednesday, November 19, 2003 11:38 AM To: FORCES@peach.ease.lsoft.com Subject: Re: Support for multicast in the ForCES protocol I find myself very torn on this issue. So I am going to try to show my thinking in hopes that someone can either point out aspects I am missing, or point out why certain aspects are more important than I tend to treat them. It would be nice to simply say "multicast is for later". However, it is equally clear that if we are going to use multicast it is much better to support it as an integral part of the protocol suite. This directly effects core protocol features. At the same time, my gut feel is that the complexity is not worth the value. But that is not a good reason for anyone else to make a decision. It is not even a good reason for me to make a decision. I think some of this has to do with rates of change of information vs easily supportable load. Clearly, service configuration does not change often enough to require multicast. So the question becomes what rate of change of next-hops are we likely to need to support, what number of FEs per CE are we trying to communicate those changes to, and is the resultant load likely to be such that we will want multicast. Clearly, in many environments the answer is no. But that is not sufficient to say we should not support it. Equally clearly, there are some environments that we would like to support eventually that will push the limits for unicast distribution. But is that margin of applicability enough to justify the complexity. Yours, Joel At 10:36 AM 11/18/2003 -0500, you wrote: >Hi, > >I'd also like to chime in on the importance of having multicast transport >in the FORCES protocol. Just the idea of trying to download common updated >forwarding tables to dozens or more FEs individually and to do so extremely >quickly is disturbing. As Sandy said, there are interconnection >technologies to allow the packet replication/multicast distribution. It is >necessary to have multicast to enable scaling to large numbers of FEs and >non-trivial forwarding information (IPv4 prefixes, global ILM entries, >etc). Unfortunately, multicast transport is not something which can be >efficiently layered on top of the FORCES protocol; it needs to be built in. > >I've just started following FORCES, so I'm sorry if this is redundant. > >Alia Atlas > > >At 10:07 AM 11/18/2003, Sandy Pavel wrote: >>Hi there! >> >>I haven't followed this thread of discussions and therefore I apologize >>if >>I am repeating something that has been mentioned before. >> >>First of all, I must mention that I am totally with Steven and the >>others that ask for multicast support in the ForCES protocol. If >>necessary, in order to convince people we can come up with a number of >>examples and real world cases that would justify it. >> >>I am not sure if it is assumed or not but I think we should add >>broadcast next to multicast. >> >>However, these would be transport technology options rather than ForCES >>protocol message types. That is, we should leave the option of binding >>different ForCES protocol messages to either unicast, multicast or >>broadcast transport, as being platform (NE) specific. This is because >>different implementations might have different resources available at >>transport and physical level. >> >>The question is: do we add some sort of "multicast group management" as >>part of ForCES control protocol, or leave it to the transport layer >>itself? >> >>To conclude, considering the switching fabric and other interconnection >>technologies proposed in the last few years especially for distributed, >>multi-shelf core routers, I believe the only viable option is to include >>multicast/broadcast as transport options for ForCES protocol(s). >> >>Regard, >>Sandy Pavel >> >> >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>Sent: November 17, 2003 4:54 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Support for multicast in the ForCES protocol >> >>The issue of support for multicast transport in the ForCES protocol has >>been a recurring topic of dispute between the competing protocol teams. >>Multicast is not explicitly called out as a protocol requirement in >>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>protocol evaluation draft. However, there are at least some people >>(myself included) who believe that it is a pretty useful feature in some >>system environments where ForCES could be applicable. >> >>Rather than make an argument for or against multicast support (some >>people on this list have already heard my opinion anyway), I am >>wondering if there are any folks not directly involved in the protocol >>teams who have an opinion either pro or con? >> >>Apologies if I am exhuming a dead horse. >> >> >>Regards, >> >>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>Steven L. Blake >>Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 16:58:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16659 for ; Wed, 19 Nov 2003 16:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMaLn-0003ub-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 16:59:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMaLm-0003uW-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 16:59:03 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C4E98B@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 16:59:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61200857 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 16:59:01 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 16:59:01 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id E92FD1F00BA for ; Wed, 19 Nov 2003 16:59:00 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 550351F00B4 for ; Wed, 19 Nov 2003 16:58:56 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-8.2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FBBE79D.4C7E9553@idt.com> Date: Wed, 19 Nov 2003 16:58:53 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sandy Pavel wrote: > > Static multicast group membership sounds to me as being acceptable and > therefore there is no need to have a group membership management > protocol. Multicast issues can be addressed via administrative issues above ForCES. That is, assuming that there *is* a multicast-capable transport under ForCES, a "multicast" update can simple appear to ForCES to be another FE. The system administrator would be responsible for maintenance of multicast group membership. This approach can avoid a lot of the issues surrounding multicast in ForCES, but may not avoid all of them. > Functionally the multicast/broadcast is not necessary; it is merely a > mechanism that allows for efficient use of the transport technology and > _scalable_ router architectures. > > This is especially valid in core router space but less important in > enterprise. It's also important for latency, which may be an issue. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 17:25:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18541 for ; Wed, 19 Nov 2003 17:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMalO-0004m1-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 17:25:30 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMalO-0004ly-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 17:25:30 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C4E9E0@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 17:25:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61204014 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 17:25:28 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 17:25:28 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003111914244189:3635 ; Wed, 19 Nov 2003 14:24:41 -0800 References: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/19/2003 02:24:42 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/19/2003 02:24:43 PM, Serialize complete at 11/19/2003 02:24:43 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069280726.1024.337.camel@jzny.localdomain> Date: Wed, 19 Nov 2003 17:25:26 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBBE79D.4C7E9553@idt.com> Precedence: list Content-Transfer-Encoding: 7bit Just in case people have missed it; netlink2 uses multicast by simply running over UDP; UDP also supports broadcast. The multicast groups or wires in netlink2 speak are dynamically discovered. The CEM-FEM interface makes the call which bundles/wires to join. There is absolutely no need for netlink2 (or a forces protocol) to be aware of this. As a fallback multicast or broadcast may be simulated via multi-unicast-sockets; but then thats innefficient because you end up using more resources (RAM, CPU and bandwidth) to achieve the same end goal. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 17:28:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18643 for ; Wed, 19 Nov 2003 17:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMaow-0004oT-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 17:29:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMaow-0004oQ-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 17:29:10 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C4EADB@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 17:29:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61204458 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 17:29:07 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 17:29:07 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003111914282129:3640 ; Wed, 19 Nov 2003 14:28:21 -0800 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/19/2003 02:28:21 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/19/2003 02:28:22 PM, Serialize complete at 11/19/2003 02:28:22 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069280945.1025.342.camel@jzny.localdomain> Date: Wed, 19 Nov 2003 17:29:05 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I think i am agreeing with you - not sure;-> Any design that puts an upper limits is doomed. What may be deemed an upper limit in this hour may be obsoleted in the next. cheers, jamal On Wed, 2003-11-19 at 15:38, John Renwick wrote: > > As you say: somewhere, somebody will inevitably come up with a set of > numbers for link capacity, utilization, updates per second and number of > FEs that will force a requirement for flooding. For instance, link > capacity 10000 transactions per second, 10% maximum utilization, 10 > updates per second, and 100 FEs. The problem is similar to the database > synchronization that link state protocols do, and in that environment > flooding is the accepted mechanism. Why not use it in ForCES as well, > since it's something we're all comfortable with? From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 18:49:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23729 for ; Wed, 19 Nov 2003 18:49:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc4c-0006Wz-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 18:49:26 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMc4b-0006Ww-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 18:49:25 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C4EB24@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 18:49:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61211109 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 18:49:23 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 18:49:23 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAJNnNB07181 for ; Wed, 19 Nov 2003 18:49:23 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAJNnNj31227 for ; Wed, 19 Nov 2003 18:49:23 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id hAJNnNk02969 for ; Wed, 19 Nov 2003 18:49:23 -0500 (EST) References: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1069285762.19297.111.camel@empress.torrentnet.com> Date: Wed, 19 Nov 2003 18:49:23 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBBE79D.4C7E9553@idt.com> Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-11-19 at 16:58, Alan DeKok wrote: > That is, assuming that there *is* a multicast-capable transport under > ForCES, a "multicast" update can simple appear to ForCES to be another > FE. The system administrator would be responsible for maintenance of > multicast group membership. It is important to keep in mind that the target audience of potential multicast configuration updates are a set of LFBs of identical type across one or more FEs, and not the FEs themselves. For example, just because the same LPM table must be loaded into two FEs', it does not mean that all other LFBs of the two FEs will also be programmed identically. In fact it is more probable that they won't. To be even more precise, the entities that need to be addressed by the same config information may not be even full LFBs, but rather some attributes of (e.g., tables) of these LFBs. It appears to me that using a layered approach, in which the ForCES protocol simply relies on multicast support in the lower layer, does not address the whole problem, since that only addresses the efficient distribution to a group of FEs and not a group of LFBs across these FEs. (Am I wrong?) That may be fine, provided that the rest of the problem can also be solved. But I am not sure it can be without support from the ForCES protocol itself. To explain what I mean by target audience of multicast config requests, consider the following (small-scale) example. CE---+---> FE1 ---+---> LFB1(*) | +---> LFB2(*) | +---> LFB3(LPM)--+--> prefixtab1 [VRF1] | | +--> prefixtab2 | +---> LFB4(*) | +---> LFB5(LPM)--+--> prefixtab1 | | +--> prefixtab2 [VRF1] | : | +---> FE2 ---+---> LFB1(*) | +---> LFB2(*) | : | +---> FE3 ---+---> LFB1(LPM)-----> prefixtab1 [VRF1] | +---> LFB2(*) | +---> LFB3(LPM)--+--> prefixtab1 | | +--> prefixtab2 : : +--> prefixtab3 [VRF1] The CE controls a number of FEs, each has a set of LFBs (the FEs may not have the same LFB topology). LFB(LPM) denotes LPM prefix lookup LFBs (which for simplicity are instances of the same LFB class). LFB(*) denotes other types of LFBs. In a VRF capable router the LPM LFBs may contain multiple LPM tables, and the number of LPM tables may be different from one LFB to the other (as indicated in the example). Suppose that the following tables are created to provide LPM for the same VRF (e.g., VRF1 as marked in the figure): FE1 : LFB3 : prefixtab1 FE1 : LFB5 : prefixtab2 FE3 : LFB1 : prefixtab1 FE3 : LFB3 : prefixtab3 In a large system where there is a large number of such tables, one should use the ForCES model in a clever way such that these tables are kept identical (not only the prefixes, which are obvious, but also the next hop identifiers associated with each prefix to address next hop entries in another LFB). If the tables are identical, then the exact same methods can be and should be sent to all of them to maintain the tables, and that is a case for multicast support. In other words, the above list of tables are the real and final target of the multicast messages. I am not sure what part of the problem would the underlying multicast layer solve, but I think it is only from the CE to the FEs (which is useful, but not sufficient). If so, there must be additional mechanisms to set up the "rest of the tree" on each FE, and I don't see how you can do that without explicit support from the ForCES protocol. What is needed is that the CE should be able to say: "I want to have FE1 : LFB3 : prefixtab1 FE1 : LFB5 : prefixtab2 FE3 : LFB1 : prefixtab1 FE3 : LFB3 : prefixtab3 to form a muticast group, accessible by a fictive address FEx : LFBy : prefixtab_z". To implement that the address triplet must be registered at the CE, a CE-to-FE multicast tree must be established (if one with identical membership does not exist yet), and then a table must be set up at the FE (and possibly even in each involved LFB). My main point, again, is that CE-to-FE multicast is useless unless the full tree can be set up (the leaves are tables within LFBs), and I suspect the ForCES protocol will need to pitch in to address the second and perhaps the third layer of the tree (the third can actually be solved within the LFB-specific protocol data, instead of the base protocol). My $0.02. Zsolt Haraszti From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 18:52:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23880 for ; Wed, 19 Nov 2003 18:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc7U-0006ZI-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 18:52:25 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMc7U-0006ZF-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 18:52:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C4EBFB@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 18:52:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61211250 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 18:52:23 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 18:52:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOu6J6QP545IGsDT/2E1PEeE4G/fwADnmcy Approved-By: Tal Anker Message-ID: Date: Thu, 20 Nov 2003 01:52:33 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 QWxhbiwNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGEgbmV0d29yayBlbGVtZW50IHdvdWxkIG5v dCBzdXBwb3J0IHRoZSByZWd1bGFyIGhvdC1pbnNlcnRpb24gdGhhdCBpcyBjb21tb24gZmVhdHVy ZSBpbiBlaXRoZXIgY2hhc2lzIG9yIHN0YWNrYWJsZSBwcm9kdWN0cz8gDQpJIGRvbid0IHRoaW5r IHRoYXQgbGVhcm5pbmcgZHluYW1pY2FsbHkgb24gbmV3IEZFJ3Mgd291bGQgbWFrZSB0aGUgb3Zl cmFsbCBzb2x1dGlvbiB0b28gY29tcGxleC4NCiANCkFzIGZvciBwZXJmb3JtYW5jZSAob25lIG9m IHRoZSBwcmV2aW91cyBtYWlscywgSSB0aGluayBpdCB3YXMgSm9lbCdzKS4uLiBXZSBzaG91bGQg YXNzdW1lIHRoYXQgc29tZSBORXMgd291bGQgbmVlZCB0byBzdXBwb3J0IGJpZyBJUCByb3V0aW5n IHRhYmxlcyAob3IgZm9yIHRoYXQgbWF0dGVyLCBiaWcgbGF5ZXIyIGZvcndhcmRpbmcgdGFibGUg aW4gdGhlIGNhc2Ugb2YgYSByb3V0ZXIvc3dpdGNoIE5FKS4gVGhlIG51bWJlciBvZiBlbGVtZW50 cyAocm91dGVzLCBMMiBmd2QgZW50cnksIGV0YykgdGhhdCBjYW4gYmUgaW5zdGFsbGVkIG9uIG1h bnkgRkUncyBwZXIgc29jb25kIHdvdWxkIGRlZmluaXRlbHkgY2FsbCBmb3IgbXVsdGljYXN0LCBh cyBtYW55IHBvaW50LTItcG9pbnQgImNvbm5lY3Rpb25zIiB3b3VsZCBiZSBhIGJpdCBwcm9ibGVt YXRpYy4uLg0KIA0KT25lIGxhc3QgaXNzdWUuLi4gdGhlIHNlbWFudGljcyBuZWVkZWQgZnJvbSB0 aGUgdHJhbnNwb3J0IGxheWVyIHNob3VsZCBiZSBjYXJlZnVsbHkgZGVmaW5lZCwgYXMgcmVndWxh ciBtdWx0aWNhc3QgaXMgbm90IHJlbGlhYmxlLCBhbmQgSSBleHBlY3QgdGhlIHByb3RvY29sIHRv IHJlbHkgb24gc29tZSByZWxpYWJsZSB0cmFuc3BvcnQgaW4gb3JkZXIgdG8ga25vdyB0aGUgQ0Ut RkUgdHJhbnNhY3Rpb24gaXMgY29tbWl0ZWQuLi4gdGhlIFJNVCBXRyBoYWQgZGVmaW5lZCB0b29s cyBmb3IgcmVsaWFibGUgbXVsdGljYXN0IHRoYXQgY2FuIGJlIGRlcGxveWVkIGhlcmUuLi4NCiAN Ci0gVGFsDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBBbGFuIERlS29r IFttYWlsdG86YWxhbi5kZWtva0BpZHQuY29tXSANCglTZW50OiBXZWQgMTEvMTkvMjAwMyAxMTo1 OCBQTSANCglUbzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NIA0KCUNjOiANCglTdWJqZWN0 OiBSZTogU3VwcG9ydCBmb3IgbXVsdGljYXN0IGluIHRoZSBGb3JDRVMgcHJvdG9jb2wNCgkNCgkN Cg0KCVNhbmR5IFBhdmVsIHdyb3RlOg0KCT4NCgk+IFN0YXRpYyBtdWx0aWNhc3QgZ3JvdXAgbWVt YmVyc2hpcCBzb3VuZHMgdG8gbWUgYXMgYmVpbmcgYWNjZXB0YWJsZSBhbmQNCgk+IHRoZXJlZm9y ZSB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgYSBncm91cCBtZW1iZXJzaGlwIG1hbmFnZW1lbnQN Cgk+IHByb3RvY29sLg0KCQ0KCSAgTXVsdGljYXN0IGlzc3VlcyBjYW4gYmUgYWRkcmVzc2VkIHZp YSBhZG1pbmlzdHJhdGl2ZSBpc3N1ZXMgYWJvdmUNCglGb3JDRVMuDQoJDQoJICBUaGF0IGlzLCBh c3N1bWluZyB0aGF0IHRoZXJlICppcyogYSBtdWx0aWNhc3QtY2FwYWJsZSB0cmFuc3BvcnQgdW5k ZXINCglGb3JDRVMsIGEgIm11bHRpY2FzdCIgdXBkYXRlIGNhbiBzaW1wbGUgYXBwZWFyIHRvIEZv ckNFUyB0byBiZSBhbm90aGVyDQoJRkUuICBUaGUgc3lzdGVtIGFkbWluaXN0cmF0b3Igd291bGQg YmUgcmVzcG9uc2libGUgZm9yIG1haW50ZW5hbmNlIG9mDQoJbXVsdGljYXN0IGdyb3VwIG1lbWJl cnNoaXAuDQoJDQoJICBUaGlzIGFwcHJvYWNoIGNhbiBhdm9pZCBhIGxvdCBvZiB0aGUgaXNzdWVz IHN1cnJvdW5kaW5nIG11bHRpY2FzdCBpbg0KCUZvckNFUywgYnV0IG1heSBub3QgYXZvaWQgYWxs IG9mIHRoZW0uDQoJDQoJPiBGdW5jdGlvbmFsbHkgdGhlIG11bHRpY2FzdC9icm9hZGNhc3QgaXMg bm90IG5lY2Vzc2FyeTsgaXQgaXMgbWVyZWx5IGENCgk+IG1lY2hhbmlzbSB0aGF0IGFsbG93cyBm b3IgZWZmaWNpZW50IHVzZSBvZiB0aGUgdHJhbnNwb3J0IHRlY2hub2xvZ3kgYW5kDQoJPiBfc2Nh bGFibGVfIHJvdXRlciBhcmNoaXRlY3R1cmVzLg0KCT4NCgk+IFRoaXMgaXMgZXNwZWNpYWxseSB2 YWxpZCBpbiBjb3JlIHJvdXRlciBzcGFjZSBidXQgbGVzcyBpbXBvcnRhbnQgaW4NCgk+IGVudGVy cHJpc2UuDQoJDQoJICBJdCdzIGFsc28gaW1wb3J0YW50IGZvciBsYXRlbmN5LCB3aGljaCBtYXkg YmUgYW4gaXNzdWUuDQoJDQoJICBBbGFuIERlS29rLg0KCQ0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 19:03:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24557 for ; Wed, 19 Nov 2003 19:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcIj-0006ol-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 19:04:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMcIi-0006oh-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 19:04:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C4EC5B@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 19:04:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61212892 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 19:03:59 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 19:03:58 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAK03xB07367 for ; Wed, 19 Nov 2003 19:03:59 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAK03wj31931 for ; Wed, 19 Nov 2003 19:03:58 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id TAA16778 for ; Wed, 19 Nov 2003 19:03:58 -0500 (EST) References: Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069286637.3183.23.camel@newcastle.torrentnet.com> Date: Wed, 19 Nov 2003 19:03:58 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-11-19 at 18:52, Tal Anker wrote: > One last issue... the semantics needed from the transport layer should be > carefully defined, as regular multicast is not reliable, and I expect the > protocol to rely on some reliable transport in order to know the CE-FE > transaction is commited... the RMT WG had defined tools for reliable multicast > that can be deployed here... This is actually orthogonal to multicast transport (reliable or otherwise). The fact that a reliable transport delivered a command message from a CE to a FE is insufficient to indicate to the CE that the command can and has been executed successfully by the FE. So the ForCES protocol will need to support application-layer acknowledgements of some variety. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 19:13:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24798 for ; Wed, 19 Nov 2003 19:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcRr-0006uK-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 19:13:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMcRq-0006uH-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 19:13:27 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C4ECA1@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 19:13:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61213943 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 19:13:26 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 19:13:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOu+jYsJ3Qat22RSZ2mv6xzIFh15wAAD3IF Approved-By: Tal Anker Message-ID: Date: Thu, 20 Nov 2003 02:13:36 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSBhZ2dyZWUgKHBvb3IgY2hvaWNlIG9mIHdvcmRpbmcgaW4gbXkgYmVoYWxmIGluIHRoZSBvcmln aW5hbCBtYWlsKS4gVGhlIHJlbGlhYmlsaXR5IG9mIHRoZSB0cmFuc3BvcnQgbGF5ZXIgd291bGQg cHJvYmFibHkgaGVscCB0byBzaW1wbGlmeSB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wuIFRoZSB0 cmFuc2FjdGlvbiBjb21taXQgc3RhdHVzIGlzIGluZGVlZCBhIHBhcnQgb2YgdGhlIGFwcGxpY2F0 aW9uIHJlc3BvbnNpYmlsaXR5Li4uIGFueSB0aG91Z2h0cyBvbiB0aGUgbW9kZWwgdGhlcmUgKDIg cGhhc2UvMyBwaGFzZSBjb21taXQsIGV0Yyk/IFRoZXJlIG1pZ2h0IGJlIHNvbWUgdHJhbnNhY3Rp b25zLCB3aGVuIGFwcGxpZWQgdG8gYSBncm91cCBvZiBGRXMgdGhhdCBjYW4gYmUgcmVnYXJkZWQg YXMgImNvbW1pdGVkIiBvbiBhIGFsbC1vci1ub25lIGJhc2lzLi4uDQogDQotIFRhbA0KDQoJLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogU3RldmVuIEJsYWtlIFttYWlsdG86c2xi bGFrZUB0b3JyZW50bmV0LmNvbV0gDQoJU2VudDogVGh1IDExLzIwLzIwMDMgMjowMyBBTSANCglU bzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NIA0KCUNjOiANCglTdWJqZWN0OiBSZTogU3Vw cG9ydCBmb3IgbXVsdGljYXN0IGluIHRoZSBGb3JDRVMgcHJvdG9jb2wNCgkNCgkNCg0KCU9uIFdl ZCwgMjAwMy0xMS0xOSBhdCAxODo1MiwgVGFsIEFua2VyIHdyb3RlOg0KCQ0KCT4gT25lIGxhc3Qg aXNzdWUuLi4gdGhlIHNlbWFudGljcyBuZWVkZWQgZnJvbSB0aGUgdHJhbnNwb3J0IGxheWVyIHNo b3VsZCBiZQ0KCT4gY2FyZWZ1bGx5IGRlZmluZWQsIGFzIHJlZ3VsYXIgbXVsdGljYXN0IGlzIG5v dCByZWxpYWJsZSwgYW5kIEkgZXhwZWN0IHRoZQ0KCT4gcHJvdG9jb2wgdG8gcmVseSBvbiBzb21l IHJlbGlhYmxlIHRyYW5zcG9ydCBpbiBvcmRlciB0byBrbm93IHRoZSBDRS1GRQ0KCT4gdHJhbnNh Y3Rpb24gaXMgY29tbWl0ZWQuLi4gdGhlIFJNVCBXRyBoYWQgZGVmaW5lZCB0b29scyBmb3IgcmVs aWFibGUgbXVsdGljYXN0DQoJPiB0aGF0IGNhbiBiZSBkZXBsb3llZCBoZXJlLi4uDQoJDQoJVGhp cyBpcyBhY3R1YWxseSBvcnRob2dvbmFsIHRvIG11bHRpY2FzdCB0cmFuc3BvcnQgKHJlbGlhYmxl IG9yDQoJb3RoZXJ3aXNlKS4gIFRoZSBmYWN0IHRoYXQgYSByZWxpYWJsZSB0cmFuc3BvcnQgZGVs aXZlcmVkIGEgY29tbWFuZA0KCW1lc3NhZ2UgZnJvbSBhIENFIHRvIGEgRkUgaXMgaW5zdWZmaWNp ZW50IHRvIGluZGljYXRlIHRvIHRoZSBDRSB0aGF0IHRoZQ0KCWNvbW1hbmQgY2FuIGFuZCBoYXMg YmVlbiBleGVjdXRlZCBzdWNjZXNzZnVsbHkgYnkgdGhlIEZFLiAgU28gdGhlIEZvckNFUw0KCXBy b3RvY29sIHdpbGwgbmVlZCB0byBzdXBwb3J0IGFwcGxpY2F0aW9uLWxheWVyIGFja25vd2xlZGdl bWVudHMgb2Ygc29tZQ0KCXZhcmlldHkuDQoJDQoJDQoJUmVnYXJkcywNCgkNCgk9LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0NCglTdGV2ZW4g TC4gQmxha2UgICAgICAgICAgICAgICA8c3RldmVuLmJsYWtlQGVyaWNzc29uLmNvbT4NCglFcmlj c3NvbiBJUCBJbmZyYXN0cnVjdHVyZSAgICAgICAgICAgICAgICArMSA5MTktNDcyLTk5MTMNCgkN Cg0K From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 20:02:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27371 for ; Wed, 19 Nov 2003 20:02:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdD5-0000LM-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 20:02:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMdD4-0000LI-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 20:02:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C4EE85@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 20:02:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61219242 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 20:02:12 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 20:02:12 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAK12prF014862 for ; Thu, 20 Nov 2003 01:02:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAK0qfC29542 for ; Thu, 20 Nov 2003 00:52:41 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003111917021015600 for ; Wed, 19 Nov 2003 17:02:10 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Nov 2003 17:02:07 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOu+c7OYHKRovBWRAGkRNJBCS/QJQABy84w X-OriginalArrivalTime: 20 Nov 2003 01:02:07.0894 (UTC) FILETIME=[EB97FB60:01C3AF01] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F6F8@orsmsx409.jf.intel.com> Date: Wed, 19 Nov 2003 17:02:07 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Steve. Are you saying that transport reliability is=20 * Necessary but not sufficient, or * Unnecessary? My impression was that having the transport (or the protocol itself) preserve ordering and avoid corruption of messages is necessary to ensure predictable behavior of the FE. So if using multicast, then either reliable=20 multicast is needed as Tal mentioned, or one must=20 implement application level support for these features. Also, in regards to multicast itself - I agree that application-layer acknowledgements are needed (I think there is a requirement about this as well). In the envisioned use of multicast, would the same multicast group be used to send the application layer=20 acknowledgements? That would cause every FE to see=20 every other FE's acknowledgment - or is the idea to use multicast in CE->FE and unicast in FE->CE messages? Thanks, David (chair hat is off) > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake > Sent: Wednesday, November 19, 2003 4:04 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Support for multicast in the ForCES protocol >=20 > This is actually orthogonal to multicast transport (reliable or > otherwise). The fact that a reliable transport delivered a command > message from a CE to a FE is insufficient to indicate to the=20 > CE that the command can and has been executed successfully by the FE. So=20 > the ForCES protocol will need to support application-layer=20 > acknowledgements of some variety. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 20:37:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28745 for ; Wed, 19 Nov 2003 20:37:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdl8-0000tK-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 20:37:26 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMdl7-0000tF-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 20:37:25 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C4EE64@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 20:37:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61222434 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 20:37:24 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 20:37:24 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAK1bOB08720 for ; Wed, 19 Nov 2003 20:37:25 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAK1bOj38338 for ; Wed, 19 Nov 2003 20:37:24 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id UAA17549 for ; Wed, 19 Nov 2003 20:37:24 -0500 (EST) References: <52D13A805349A249960B9943E5590BD881F6F8@orsmsx409.jf.intel.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069292243.4093.53.camel@newcastle.torrentnet.com> Date: Wed, 19 Nov 2003 20:37:23 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F6F8@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-11-19 at 20:02, Putzolu, David wrote: > Hi Steve. > > Are you saying that transport reliability is > * Necessary but not sufficient, or > * Unnecessary? Strictly speaking I think it is unnecessary; otherwise it would be impossible to run the ForCES protocol over bare Ethernet or UDP. Now, you may ask yourself why you would want to be able to run over bare Ethernet or UDP. I don't have much need for the ability to run over bare Ethernet personally (although I have heard that some AD expressed this as a requirement; maybe that's a myth). In the absence of an IETF-standard reliable multicast transport, being able to run over UDP is pretty important if you want to be able to support multicast. > My impression was that having the transport (or the > protocol itself) preserve ordering and avoid corruption > of messages is necessary to ensure predictable behavior > of the FE. So if using multicast, then either reliable > multicast is needed as Tal mentioned, or one must > implement application level support for these features. Right. In a perfect world we would have an IETF-standard RMT protocol that we could use for sequencing. Although I need to engage in some deep thinking to convince myself that transport-level sequencing is sufficient to support application-layer transactions; we may not want to impose the requirement that all application-layer messages are processed in order of reception. > Also, in regards to multicast itself - I agree that > application-layer acknowledgements are needed (I think > there is a requirement about this as well). In the > envisioned use of multicast, would the same multicast > group be used to send the application layer > acknowledgements? That would cause every FE to see > every other FE's acknowledgment - or is the idea to > use multicast in CE->FE and unicast in FE->CE messages? Both, actually. The former (using partial ACKs randomly multicast back to the originator as described in the Netlink2 draft) is actually a useful mechanism for reducing ACK load on the originator, although the partial ACK semantic is not as strong as full ACKs (it is a useful hint in the interim until a new multicast message with a bumped sequence number can be sent and NACKed by receivers that missed the earlier message). Full ACKs unicast back to the originator are needed if you need transaction semantics (although you don't necessarily need to ACK every message in a transaction sequence). Full ACKs are often considered to lead to ACK implosion at the originator, but note that the number of full ACKs is identical to what would be required if all messages were unicast from the originator. If full ACKs are used then multicast allows you to reduce the number of exchanged messages by roughly half (assuming more than a handful of FEs); the amount of data communicated is probably reduced by much more than half in the command case. That may appear as a substantial optimization for some but not others. The strongest argument for multicast support in ForCES will depend on whether a use case can be found for partial ACKs. I'm pretty sure that the popular use case people have mentioned for multicast in ForCES will work with partial ACKs. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 19 23:29:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02979 for ; Wed, 19 Nov 2003 23:29:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMgSC-0002zS-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 23:30:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMgSB-0002zP-00 for forces-archive@IETF.ORG; Wed, 19 Nov 2003 23:30:03 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C4F449@cherry.ease.lsoft.com>; Wed, 19 Nov 2003 23:30:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61238545 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 23:30:01 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Nov 2003 23:30:01 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5844198 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Nov 2003 23:30:01 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031119232704.018bfeb0@localhost> Date: Wed, 19 Nov 2003 23:29:52 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list This is one of the complexities. While there is a lot of useful experimental work on reliable and secured multicast transport, I do not believe that there is any engineering grade work that address both those requirements. And we are obliged to meet both of those needs. And compared with TCP / SCTP, there are not wide spread, easily available, well wrung out implementations of those protocols. Hence, putting a dependency on such work into ForCES introduces significant risk and complexity. Yours, Joel M. Halpern At 01:52 AM 11/20/2003 +0200, you wrote: >One last issue... the semantics needed from the transport layer should be >carefully defined, as regular multicast is not reliable, and I expect the >protocol to rely on some reliable transport in order to know the CE-FE >transaction is commited... the RMT WG had defined tools for reliable >multicast that can be deployed here... > >- Tal From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 03:25:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24700 for ; Thu, 20 Nov 2003 03:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMk8Z-0006a9-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 03:26:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMk8Z-0006Zz-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 03:26:03 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C4F785@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 3:25:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61260996 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 03:25:54 -0500 Received: from 137.222.10.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 03:25:53 -0500 Received: from isis.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 20 Nov 2003 08:25:47 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by isis.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hAK8PgN19444 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 20 Nov 2003 08:25:43 GMT References: <1069292243.4093.53.camel@newcastle.torrentnet.com> Originator-Info: login-token=Mulberry:01Dp1pj3MCygNG3uL5PHQDlvhG/9+yToATl/FLB+KzPHHL3vo=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <86665848.1069316742@EEN9169.een.bris.ac.uk> Date: Thu, 20 Nov 2003 08:25:42 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069292243.4093.53.camel@newcastle.torrentnet.com> Precedence: list Content-Transfer-Encoding: 7bit Hi All, Picking up on a couple of issues in this discussion, (and repeating things I said two years back although the world has moved on meantime): DP:>> >> Are you saying that transport reliability is >> * Necessary but not sufficient, or >> * Unnecessary? SB:> > Strictly speaking I think it is unnecessary; .... > DP:... So if using multicast, then either reliable >> multicast is needed as Tal mentioned, or one must >> implement application level support for these features. ... Although I need to engage in some SB:> deep thinking to convince myself that transport-level sequencing is > sufficient to support application-layer transactions; we may not want to > impose the requirement that all application-layer messages are processed > in order of reception. The NPF has published service level APIs that are basically asynchronous and reliable (i.e. the callback completions are not lost but may, potentially be processed/returned out of order) and allow calls to fail or succeed in a variety of ways. I know this is one step removed from the level we are discussing here but this model is being used at CE<->FE level too. This behaviour will have to be propagated into the protocol to give a equivalent transactional capability that will convey the semantics of NPF FE functional APIs to the CE across the intervening stack. Transport reliability is useful but I think we risk muddling layer functionality - it is application reliability that is the problem. It might be solved by a session protocol (the late unlamented OSI standards did it this way) but it's better to merge it with the application protocol I think. For this reason, I wonder how much we gain by using multicast. Halving the number of messages could be just the rare best case. As above, I don't think reliability of multicast would be anything more than just a useful behaviour. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 06:10:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28614 for ; Thu, 20 Nov 2003 06:10:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMmi1-0000gx-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:10:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMmi1-0000gu-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:10:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C4F9CB@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 6:10:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61285451 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 06:10:47 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 06:10:47 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAKBAfBs090236 for ; Thu, 20 Nov 2003 11:10:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAKB5SLE244380 for ; Thu, 20 Nov 2003 12:05:28 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA47970 for ; Thu, 20 Nov 2003 12:05:28 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20031119232704.018bfeb0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id hAKBAfBs090236 Approved-By: Robert Haas Message-ID: <3FBC9FF7.4080608@zurich.ibm.com> Date: Thu, 20 Nov 2003 12:05:27 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031119232704.018bfeb0@localhost> Precedence: list Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > This is one of the complexities. While there is a lot of useful > experimental work on reliable and secured multicast transport, I do not > believe that there is any engineering grade work that address both thos= e > requirements. And we are obliged to meet both of those needs. > And compared with TCP / SCTP, there are not wide spread, easily=20 > available, > well wrung out implementations of those protocols. > Hence, putting a dependency on such work into ForCES introduces=20 > significant > risk and complexity.=20 I don't think we are talking about putting a dependency on RMT here.=20 Rather we are ensuring that the necessary hooks are in the ForCES=20 protocol so it can make use of some form of multicast transport. And to do this, we need to have some form of group addressing at the=20 ForCES protocol level. Having spent some cycles on this, I can say it=20 requires a bit more than "rearranging the FE ID bits to have some=20 group-like meaning after the ForCES protocol has already been designed"=20 (I think I heard sth along these lines on the list). Cheers, -Robert > > > Yours, > Joel M. Halpern > > At 01:52 AM 11/20/2003 +0200, you wrote: > >> One last issue... the semantics needed from the transport layer=20 >> should be >> carefully defined, as regular multicast is not reliable, and I expect=20 >> the >> protocol to rely on some reliable transport in order to know the CE-FE >> transaction is commited... the RMT WG had defined tools for reliable >> multicast that can be deployed here... >> >> - Tal > > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 06:12:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28737 for ; Thu, 20 Nov 2003 06:12:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMmjy-0000jI-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:12:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMmjx-0000jF-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:12:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C4F93A@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 6:12:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61285926 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 06:12:44 -0500 Received: from 195.212.29.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 06:12:43 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.uk.ibm.com (8.12.10/8.12.10) with ESMTP id hAKB7Q7d019358 for ; Thu, 20 Nov 2003 11:08:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAKB0is6282038 for ; Thu, 20 Nov 2003 12:00:45 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA59262 for ; Thu, 20 Nov 2003 12:00:44 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> <1069285762.19297.111.camel@empress.torrentnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate5.uk.ibm.com id hAKB7Q7d019358 Approved-By: Robert Haas Message-ID: <3FBC9EDC.2070606@zurich.ibm.com> Date: Thu, 20 Nov 2003 12:00:44 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069285762.19297.111.camel@empress.torrentnet.com> Precedence: list Content-Transfer-Encoding: quoted-printable Zsolt, This "second-level mutlicast" you mention is also captured in the=20 netlink2 grouping mechanism that permits to create groups of LFBs on the=20 same/different FEs. For simplicity, we assumed that group membership is=20 statically configured at pre-association. If you remember, this is what=20 I tried to illustrate in Vienna on pages 8 and 11 of my presentation: http://www.zurich.ibm.com/~rha/netlink2-1.pdf Another key characterisitic in netlink2 is that one can address LFB by=20 type, i.e., "I want to send a routing table to all LFBs of the=20 IPv4_ROUTING type". That's a great simplification as opposed to having=20 to find out the IDs assigned to each individual LFB. Cheers, -Robert Zsolt Haraszti wrote: >On Wed, 2003-11-19 at 16:58, Alan DeKok wrote: > =20 > >> That is, assuming that there *is* a multicast-capable transport >> =20 >> >under > =20 > >>ForCES, a "multicast" update can simple appear to ForCES to be another >>FE. The system administrator would be responsible for maintenance of >>multicast group membership. >> =20 >> > >It is important to keep in mind that the target audience of >potential multicast configuration updates are a set of LFBs of >identical type across one or more FEs, and not the FEs >themselves. For example, just because the same LPM table must >be loaded into two FEs', it does not mean that all other >LFBs of the two FEs will also be programmed identically. In >fact it is more probable that they won't. > >To be even more precise, the entities that need to be addressed >by the same config information may not be even full LFBs, but >rather some attributes of (e.g., tables) of these LFBs. > >It appears to me that using a layered approach, in which the ForCES >protocol simply relies on multicast support in the lower layer, does >not address the whole problem, since that only addresses the >efficient distribution to a group of FEs and not a group of LFBs >across these FEs. (Am I wrong?) That may be fine, provided that >the rest of the problem can also be solved. But I am not sure it >can be without support from the ForCES protocol itself. > >To explain what I mean by target audience of multicast config >requests, consider the following (small-scale) example. > >CE---+---> FE1 ---+---> LFB1(*) > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 [VRF1] > | | +--> prefixtab2 > | +---> LFB4(*) > | +---> LFB5(LPM)--+--> prefixtab1 > | | +--> prefixtab2 [VRF1] > | : > | > +---> FE2 ---+---> LFB1(*) > | +---> LFB2(*) > | : > | > +---> FE3 ---+---> LFB1(LPM)-----> prefixtab1 [VRF1] > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 > | | +--> prefixtab2 > : : +--> prefixtab3 [VRF1] > > >The CE controls a number of FEs, each has a set of LFBs (the >FEs may not have the same LFB topology). LFB(LPM) denotes >LPM prefix lookup LFBs (which for simplicity are instances >of the same LFB class). LFB(*) denotes other types >of LFBs. In a VRF capable router the LPM LFBs may contain >multiple LPM tables, and the number of LPM tables may be >different from one LFB to the other (as indicated in the >example). Suppose that the following tables are created to >provide LPM for the same VRF (e.g., VRF1 as marked in the >figure): > >FE1 : LFB3 : prefixtab1 >FE1 : LFB5 : prefixtab2 >FE3 : LFB1 : prefixtab1 >FE3 : LFB3 : prefixtab3 > >In a large system where there is a large number of such tables, >one should use the ForCES model in a clever way such that these >tables are kept identical (not only the prefixes, which are >obvious, but also the next hop identifiers associated with >each prefix to address next hop entries in another LFB). If >the tables are identical, then the exact same methods can be >and should be sent to all of them to maintain the tables, and >that is a case for multicast support. In other words, >the above list of tables are the real and final target of the >multicast messages. > >I am not sure what part of the problem would the underlying >multicast layer solve, but I think it is only from the CE to >the FEs (which is useful, but not sufficient). If so, there >must be additional mechanisms to set up the "rest of the tree" >on each FE, and I don't see how you can do that without explicit >support from the ForCES protocol. What is needed is that the CE >should be able to say: "I want to have >FE1 : LFB3 : prefixtab1 >FE1 : LFB5 : prefixtab2 >FE3 : LFB1 : prefixtab1 >FE3 : LFB3 : prefixtab3 >to form a muticast group, accessible by a fictive address >FEx : LFBy : prefixtab_z". To implement that the address >triplet must be registered at the CE, a CE-to-FE multicast >tree must be established (if one with identical membership >does not exist yet), and then a table must be set up at >the FE (and possibly even in each involved LFB). > >My main point, again, is that CE-to-FE multicast is useless >unless the full tree can be set up (the leaves are tables within >LFBs), and I suspect the ForCES protocol will need to pitch in >to address the second and perhaps the third layer of the tree >(the third can actually be solved within the LFB-specific protocol >data, instead of the base protocol). > >My $0.02. > >Zsolt Haraszti > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 06:50:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29843 for ; Thu, 20 Nov 2003 06:50:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnKP-0001Eu-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:50:30 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMnKI-0001Eo-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 06:50:22 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C4FA8E@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 6:50:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61291842 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 06:50:21 -0500 Received: from 137.222.10.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 06:50:20 -0500 Received: from isis.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 20 Nov 2003 11:50:03 +0000 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by isis.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id hAKBn2N25882 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 20 Nov 2003 11:49:03 GMT References: <3FBC9FF7.4080608@zurich.ibm.com> Originator-Info: login-token=Mulberry:01HTLyoYKXUxVVc2sLS4OYHwpVlGjEXY+oIANanGvFS4BgZww=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Approved-By: Alistair Munro Message-ID: <98866232.1069328942@EEN9169.een.bris.ac.uk> Date: Thu, 20 Nov 2003 11:49:02 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBC9FF7.4080608@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Robert, > And to [ensure that the necessary hooks are in the ForCES protocol so it > can make use of some form of multicast transport], we need to have some > form of group addressing at the > ForCES protocol level. Having spent some cycles on this, I can say it > requires a bit more than "rearranging the FE ID bits to have some > group-like meaning after the ForCES protocol has already been designed" > (I think I heard sth along these lines on the list). I certainly think it would be good to be able to multicast/broadcast to LFBs via the ForCES protocol at application level. I don't see what this has to do with multicast *transport*. Could you explain how you would make the application layer FE LFB hooks visible at transport level? Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 07:47:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02232 for ; Thu, 20 Nov 2003 07:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoDM-0002Gr-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 07:47:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMoDL-0002Gn-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 07:47:15 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C4FBA0@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 7:47:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61296002 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 07:47:11 -0500 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 07:47:11 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAKCl3Hf050156 for ; Thu, 20 Nov 2003 12:47:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAKCkws6256806 for ; Thu, 20 Nov 2003 13:46:58 +0100 Received: from zurich.ibm.com (dhcp69-114.zurich.ibm.com [9.4.69.114]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA71588; Thu, 20 Nov 2003 13:46:58 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com > <1069106025.14238.52.camel@newcastle.torrentnet.com> <5.1.0.14.0.20031119142344.01a7acd8@localhost> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040809050709010409080605" Approved-By: Patrick Droz Message-ID: <3FBCB7C1.2010100@zurich.ibm.com> Date: Thu, 20 Nov 2003 13:46:57 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031119142344.01a7acd8@localhost> Precedence: list This is a cryptographically signed message in MIME format. --------------ms040809050709010409080605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joel, at least some time back I have heard from people that they intended to build boxes with more than 2000 ports and about 100K routes. In such a case multicast is very helpful to make ForCES scalable. I do not know if people still have such can of plans due to the downturn but I guess it makes sense to have ForCES future proof. Regards, Patrick Joel M. Halpern wrote: > I find myself very torn on this issue. > So I am going to try to show my thinking in hopes that someone can either > point out aspects I am missing, or point out why certain aspects are more > important than I tend to treat them. > > It would be nice to simply say "multicast is for later". > However, it is equally clear that if we are going to use multicast it is > much better to support it as an integral part of the protocol suite. This > directly effects core protocol features. > > At the same time, my gut feel is that the complexity is not worth the > value. But that is not a good reason for anyone else to make a > decision. It is not even a good reason for me to make a decision. > > I think some of this has to do with rates of change of information vs > easily supportable load. > > Clearly, service configuration does not change often enough to require > multicast. > So the question becomes what rate of change of next-hops are we likely to > need to support, what number of FEs per CE are we trying to communicate > those changes to, and is the resultant load likely to be such that we will > want multicast. > Clearly, in many environments the answer is no. But that is not sufficient > to say we should not support it. > Equally clearly, there are some environments that we would like to support > eventually that will push the limits for unicast distribution. > But is that margin of applicability enough to justify the complexity. > > Yours, > Joel > > At 10:36 AM 11/18/2003 -0500, you wrote: > >> Hi, >> >> I'd also like to chime in on the importance of having multicast transport >> in the FORCES protocol. Just the idea of trying to download common >> updated >> forwarding tables to dozens or more FEs individually and to do so >> extremely >> quickly is disturbing. As Sandy said, there are interconnection >> technologies to allow the packet replication/multicast distribution. >> It is >> necessary to have multicast to enable scaling to large numbers of FEs and >> non-trivial forwarding information (IPv4 prefixes, global ILM entries, >> etc). Unfortunately, multicast transport is not something which can be >> efficiently layered on top of the FORCES protocol; it needs to be >> built in. >> >> I've just started following FORCES, so I'm sorry if this is redundant. >> >> Alia Atlas >> >> >> At 10:07 AM 11/18/2003, Sandy Pavel wrote: >> >>> Hi there! >>> >>> I haven't followed this thread of discussions and therefore I apologize >>> if >>> I am repeating something that has been mentioned before. >>> >>> First of all, I must mention that I am totally with Steven and the >>> others that ask for multicast support in the ForCES protocol. If >>> necessary, in order to convince people we can come up with a number of >>> examples and real world cases that would justify it. >>> >>> I am not sure if it is assumed or not but I think we should add >>> broadcast next to multicast. >>> >>> However, these would be transport technology options rather than ForCES >>> protocol message types. That is, we should leave the option of binding >>> different ForCES protocol messages to either unicast, multicast or >>> broadcast transport, as being platform (NE) specific. This is because >>> different implementations might have different resources available at >>> transport and physical level. >>> >>> The question is: do we add some sort of "multicast group management" as >>> part of ForCES control protocol, or leave it to the transport layer >>> itself? >>> >>> To conclude, considering the switching fabric and other interconnection >>> technologies proposed in the last few years especially for distributed, >>> multi-shelf core routers, I believe the only viable option is to include >>> multicast/broadcast as transport options for ForCES protocol(s). >>> >>> Regard, >>> Sandy Pavel >>> >>> >>> >>> -----Original Message----- >>> From: Forwarding and Control Element Separation >>> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>> Sent: November 17, 2003 4:54 PM >>> To: FORCES@PEACH.EASE.LSOFT.COM >>> Subject: Support for multicast in the ForCES protocol >>> >>> The issue of support for multicast transport in the ForCES protocol has >>> been a recurring topic of dispute between the competing protocol teams. >>> Multicast is not explicitly called out as a protocol requirement in >>> draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>> protocol evaluation draft. However, there are at least some people >>> (myself included) who believe that it is a pretty useful feature in some >>> system environments where ForCES could be applicable. >>> >>> Rather than make an argument for or against multicast support (some >>> people on this list have already heard my opinion anyway), I am >>> wondering if there are any folks not directly involved in the protocol >>> teams who have an opinion either pro or con? >>> >>> Apologies if I am exhuming a dead horse. >>> >>> >>> Regards, >>> >>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Steven L. Blake >>> Ericsson IP Infrastructure +1 919-472-9913 > > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms040809050709010409080605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjAx MjQ2NTdaMCMGCSqGSIb3DQEJBDEWBBTb3csdWnrmbUxgLkMNMYSIqoCaTDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgCgeONc2p/BLCmmVDrlC9z/y+7PuN1i1bDGC 2/jlsCbfggEwcX2EggqTNMPBoJSZlOQTHV4stNSQ3rpRj78DotJ0JF9UDKUcaX0N2kbaaDC3 YMW9EKnN6F/DvgPOpVyua0NVl9ZIptk0ZJYBu+v1RXkWT+Fu3SOn7OOSwL0r/OeTAAAAAAAA --------------ms040809050709010409080605-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 07:59:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02546 for ; Thu, 20 Nov 2003 07:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMoPK-0002PI-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 07:59:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMoPJ-0002PE-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 07:59:37 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C4FB63@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 7:59:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61296665 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 07:59:30 -0500 Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 07:59:29 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAKCxKn0125672 for ; Thu, 20 Nov 2003 12:59:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAKCuRLE283996 for ; Thu, 20 Nov 2003 13:56:27 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA50226 for ; Thu, 20 Nov 2003 13:56:26 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FBC9FF7.4080608@zurich.ibm.com> <98866232.1069328942@EEN9169.een.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id hAKCxKn0125672 Approved-By: Robert Haas Message-ID: <3FBCB9FA.6000700@zurich.ibm.com> Date: Thu, 20 Nov 2003 13:56:26 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <98866232.1069328942@EEN9169.een.bris.ac.uk> Precedence: list Content-Transfer-Encoding: quoted-printable Hi Alistair, Alistair Munro wrote: > Hi Robert, > >> And to [ensure that the necessary hooks are in the ForCES protocol so = it >> can make use of some form of multicast transport], we need to have som= e >> form of group addressing at the >> ForCES protocol level. Having spent some cycles on this, I can say it >> requires a bit more than "rearranging the FE ID bits to have some >> group-like meaning after the ForCES protocol has already been designed= " >> (I think I heard sth along these lines on the list). > > > I certainly think it would be good to be able to multicast/broadcast to > LFBs via the ForCES protocol at application level. I don't see what thi= s > has to do with multicast *transport*. Nothing and you are absolutely right. I only say that if one has group=20 addressing capability at ForCES level, then one can consider making use=20 of multicast transport. The multicast transport stops at the FE door (IP=20 endpoint if running over IP), any other "multicast" further into FE LFBs=20 must be handled by ForCES itself. > Could you explain how you would make > the application layer FE LFB hooks visible at transport level? Nobodoy wants to assign an IP address to each LFB, and it is good so.=20 Therefore, grouping of LFBs is only visible at the ForCES-level=20 addressing. The underlying mutlicast transport is merely a way to get=20 closer to the LFBs up to the FE door, potentially saving substantial CPU=20 and bandwidth resources. Regards, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 09:04:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04666 for ; Thu, 20 Nov 2003 09:04:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpPt-0003MQ-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:04:17 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMpPt-0003MN-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:04:17 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C4FC14@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 9:04:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61300338 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:04:14 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 09:04:14 -0500 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id hAKE4ID19492 for ; Thu, 20 Nov 2003 06:04:18 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Thu, 20 Nov 2003 06:04:18 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Poll WAS(Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <86665848.1069316742@EEN9169.een.bris.ac.uk> Precedence: list Just changing the topic slightly since this topic is getting thread time. I would like to poll people who have deployed boxes; either single chasis with multiple FEs and CEs or within a rack or multi-rack; I believe this is what 90% of deployments that will happen with Forces. if you havent done the above but have opinions, just say so but mention that you havent deployed something forces-like at the level mentioned above. Did you deploy utilizing multicast or broadcast transport? If not why? And what did you use instead that solved the problem for you. -In the early days for example multicast support was not widely available in hardware so you had to emulate it. For such cases, you are forgiven. - Another reason is maybe you found multicast/bcast to be too complex. Explain why. cheers, jamal PS: All cauthors of netlink2 have experience implementing a forces-like protocol which used a variant of mcast/bcast in environments that got deployed at product level - thats why we feel very strongly about this issue. Note, we worked then and still work for different companies now. So we may be biased. PPS: This is a poll, it would be preferable to stick to the questions posed so i dont have to change the subject again. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 09:20:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05398 for ; Thu, 20 Nov 2003 09:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpg3-0003bY-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:20:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMpg2-0003bV-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:20:58 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C4FBDF@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 9:20:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61302149 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:20:56 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 09:20:55 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5845030 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:20:56 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031119142344.01a7acd8@localhost> <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com > <1069106025.14238.52.camel@newcastle.torrentnet.com> <5.1.0.14.0.20031119142344.01a7acd8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031120091143.0192a268@localhost> Date: Thu, 20 Nov 2003 09:20:44 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBCB7C1.2010100@zurich.ibm.com> Precedence: list I believe people have said this. However... While the route*port product affects startup time, I would be reluctant to include multicast for just startup. The question is what the rate of change of the routes is. Remember also that what we deal with in ForCES are FIB entries, not RIB entries. Even in the internet core there are rarely 100K FIB entries. Given that we are separating data and control concepts, one could argue that the ratio "should" get arbitrarily large. One can equally argue that the ratio "should" be kept bounded by deploying additional control entities as needed. We have not established any agreement in the working group as to what target we are after. That does not mean that the 2K port full internet table device is out of scope. It also does not mean it is in scope. Let me put this another way... In order to use multicast, we are going to have to define our own reliability / security /congestion control mechanisms (we will be able to use work from other working groups, but those do not appear to be sufficient.) That is a large effort for the working group. We are unlikely to declare multicast a :must implement". But doing a lot of work on an optional aspect seems counter to the goal of effective useable rapid progress. So I am trying to understand what problem we NEED to solve that multicast is important for. Yours, Joel M. Halpern At 01:46 PM 11/20/2003 +0100, you wrote: >Joel, > >at least some time back I have heard from people that they >intended to build boxes with more than 2000 ports and about >100K routes. In such a case multicast is very helpful to >make ForCES scalable. I do not know if people still have >such can of plans due to the downturn but I guess it makes >sense to have ForCES future proof. > >Regards, >Patrick > > >Joel M. Halpern wrote: > >>I find myself very torn on this issue. >>So I am going to try to show my thinking in hopes that someone can either >>point out aspects I am missing, or point out why certain aspects are more >>important than I tend to treat them. >>It would be nice to simply say "multicast is for later". >>However, it is equally clear that if we are going to use multicast it is >>much better to support it as an integral part of the protocol suite. This >>directly effects core protocol features. >>At the same time, my gut feel is that the complexity is not worth the >>value. But that is not a good reason for anyone else to make a >>decision. It is not even a good reason for me to make a decision. >>I think some of this has to do with rates of change of information vs >>easily supportable load. >>Clearly, service configuration does not change often enough to require >>multicast. >>So the question becomes what rate of change of next-hops are we likely to >>need to support, what number of FEs per CE are we trying to communicate >>those changes to, and is the resultant load likely to be such that we will >>want multicast. >>Clearly, in many environments the answer is no. But that is not sufficient >>to say we should not support it. >>Equally clearly, there are some environments that we would like to support >>eventually that will push the limits for unicast distribution. >>But is that margin of applicability enough to justify the complexity. >>Yours, >>Joel >>At 10:36 AM 11/18/2003 -0500, you wrote: >> >>>Hi, >>> >>>I'd also like to chime in on the importance of having multicast transport >>>in the FORCES protocol. Just the idea of trying to download common updated >>>forwarding tables to dozens or more FEs individually and to do so extremely >>>quickly is disturbing. As Sandy said, there are interconnection >>>technologies to allow the packet replication/multicast distribution. >>>It is >>>necessary to have multicast to enable scaling to large numbers of FEs and >>>non-trivial forwarding information (IPv4 prefixes, global ILM entries, >>>etc). Unfortunately, multicast transport is not something which can be >>>efficiently layered on top of the FORCES protocol; it needs to be built in. >>> >>>I've just started following FORCES, so I'm sorry if this is redundant. >>> >>>Alia Atlas >>> >>> >>>At 10:07 AM 11/18/2003, Sandy Pavel wrote: >>> >>>>Hi there! >>>> >>>>I haven't followed this thread of discussions and therefore I apologize >>>>if >>>>I am repeating something that has been mentioned before. >>>> >>>>First of all, I must mention that I am totally with Steven and the >>>>others that ask for multicast support in the ForCES protocol. If >>>>necessary, in order to convince people we can come up with a number of >>>>examples and real world cases that would justify it. >>>> >>>>I am not sure if it is assumed or not but I think we should add >>>>broadcast next to multicast. >>>> >>>>However, these would be transport technology options rather than ForCES >>>>protocol message types. That is, we should leave the option of binding >>>>different ForCES protocol messages to either unicast, multicast or >>>>broadcast transport, as being platform (NE) specific. This is because >>>>different implementations might have different resources available at >>>>transport and physical level. >>>> >>>>The question is: do we add some sort of "multicast group management" as >>>>part of ForCES control protocol, or leave it to the transport layer >>>>itself? >>>> >>>>To conclude, considering the switching fabric and other interconnection >>>>technologies proposed in the last few years especially for distributed, >>>>multi-shelf core routers, I believe the only viable option is to include >>>>multicast/broadcast as transport options for ForCES protocol(s). >>>> >>>>Regard, >>>>Sandy Pavel >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Forwarding and Control Element Separation >>>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake >>>>Sent: November 17, 2003 4:54 PM >>>>To: FORCES@PEACH.EASE.LSOFT.COM >>>>Subject: Support for multicast in the ForCES protocol >>>> >>>>The issue of support for multicast transport in the ForCES protocol has >>>>been a recurring topic of dispute between the competing protocol teams. >>>>Multicast is not explicitly called out as a protocol requirement in >>>>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the >>>>protocol evaluation draft. However, there are at least some people >>>>(myself included) who believe that it is a pretty useful feature in some >>>>system environments where ForCES could be applicable. >>>> >>>>Rather than make an argument for or against multicast support (some >>>>people on this list have already heard my opinion anyway), I am >>>>wondering if there are any folks not directly involved in the protocol >>>>teams who have an opinion either pro or con? >>>> >>>>Apologies if I am exhuming a dead horse. >>>> >>>> >>>>Regards, >>>> >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>Steven L. Blake >>>>Ericsson IP Infrastructure +1 919-472-9913 >> > >-- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 09:28:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05776 for ; Thu, 20 Nov 2003 09:28:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpnH-0003jR-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:28:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMpnG-0003jO-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:28:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C4FBA2@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 9:28:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61303011 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:28:23 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 09:28:23 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5845064 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:28:23 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <86665848.1069316742@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031120092315.01a80190@localhost> Date: Thu, 20 Nov 2003 09:28:10 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Poll WAS(Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list When the folks I worked for build and sold a distributed forwarder (multi box), we used unicast mechanisms. This was largely an architectural choice, since the interconnect technology (ATM) had point-to-multipoint. We had no difficulty maintaining the necessary update rate. [Nopt sure if the following is within what you asked for on your poll. If no, ignore it.] Of the earlier routers that I build, some used unicast communication of the forwarding table, and some used a shared table (which can be thought of as broadcast.) The shared table provided inherently reliable multicast, and was used because the entire device was a shared memory architecture. The device with actual communications channels used unicast for forwarding table, although the backplane had broadcast capability. Yours, Joel M. Halpern At 06:04 AM 11/20/2003 -0800, you wrote: >Just changing the topic slightly since this topic is getting thread time. > >I would like to poll people who have deployed boxes; either single chasis >with multiple FEs and CEs or within a rack or multi-rack; I believe this >is what 90% of deployments that will happen with Forces. >if you havent done the above but have opinions, just say so but mention >that you havent deployed something forces-like at the level mentioned >above. > >Did you deploy utilizing multicast or broadcast transport? If not why? >And what did you use instead that solved the problem for you. > >-In the early days for example multicast support was not >widely available in hardware so you had to emulate it. For such cases, >you are forgiven. >- Another reason is maybe you found multicast/bcast to be too complex. >Explain why. > >cheers, >jamal > >PS: All cauthors of netlink2 have experience implementing a forces-like >protocol which used a variant of mcast/bcast in environments that >got deployed at product level - thats why we feel very strongly about >this issue. Note, we worked then and still work for different companies >now. So we may be biased. > >PPS: This is a poll, it would be preferable to stick to the questions >posed so i dont have to change the subject again. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 09:51:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06824 for ; Thu, 20 Nov 2003 09:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMq9J-00049q-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:51:13 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMq9I-00049n-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 09:51:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C4FC8D@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 9:51:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61305988 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:51:10 -0500 Received: from 62.241.160.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 09:51:10 -0500 Received: from tom3 (1Cust60.tnt28.lnd4.gbr.da.uu.net [62.188.156.60]) by shockwave.systems.pipex.net (Postfix) with SMTP id D388B1C00232 for ; Thu, 20 Nov 2003 14:51:09 +0000 (GMT) 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Approved-By: Tom Petch Message-ID: <003301c3af75$44c80720$0301a8c0@tom3> Date: Thu, 20 Nov 2003 14:20:20 -0000 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Definitely a good idea; I am very much with Joel on this one. And for me as a consumer, the hot-pluggable blade is not leading edge, as some e-mails have put it, but the norm since about 2000. Tom Petch -----Original Message----- From: Putzolu, David To: FORCES@PEACH.EASE.LSOFT.COM Date: 10 November 2003 20:39 Subject: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts) [chair hat back on] Joel Halpern wrote> > We are discussing reconfigurability. I would really like to > retain that (as most folks have gathered by now.) I have an impression that there is some consensus around retaining at least some degree of reconfigurability. I would like to determine if this impression is correct or not. I request that everyone weigh in on the mailing list as to whether reconfigurability is desired or not. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 09:59:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07162 for ; Thu, 20 Nov 2003 09:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqHs-0004GN-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:00:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMqHr-0004GJ-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:00:04 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C4FDF0@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 10:00:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61306491 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 09:59:49 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 09:59:49 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAKExnB20360 for ; Thu, 20 Nov 2003 09:59:49 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAKExnj93913 for ; Thu, 20 Nov 2003 09:59:49 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id hAKExmh07081 for ; Thu, 20 Nov 2003 09:59:48 -0500 (EST) References: <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> <1069285762.19297.111.camel@empress.torrentnet.com> <3FBC9EDC.2070606@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1069340387.21781.5.camel@empress.torrentnet.com> Date: Thu, 20 Nov 2003 09:59:47 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBC9EDC.2070606@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: 7bit Rob, On Thu, 2003-11-20 at 06:00, Robert Haas wrote: > Zsolt, > > This "second-level mutlicast" you mention is also captured in the > netlink2 grouping mechanism that permits to create groups of LFBs on the > same/different FEs. Sorry, my ignorance. > For simplicity, we assumed that group membership is > statically configured at pre-association. If we allow dynamic topology changes in post association phase (and we decided to do so in the model team), then forming multicast groups should also be supported in post-association phase. > If you remember, this is what > I tried to illustrate in Vienna on pages 8 and 11 of my presentation: > http://www.zurich.ibm.com/~rha/netlink2-1.pdf > > Another key characterisitic in netlink2 is that one can address LFB by > type, i.e., "I want to send a routing table to all LFBs of the > IPv4_ROUTING type". That's a great simplification as opposed to having > to find out the IDs assigned to each individual LFB. > That is a nice feature for some specific cases/systems. /zsolt From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 10:11:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08200 for ; Thu, 20 Nov 2003 10:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqSx-0004RE-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:11:31 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMqSx-0004RB-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:11:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C4FDE7@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 10:11:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61309190 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 10:11:28 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 10:11:28 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5845229 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 10:11:28 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <3FBC9EDC.2070606@zurich.ibm.com> <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> <1069285762.19297.111.camel@empress.torrentnet.com> <3FBC9EDC.2070606@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031120100322.01a6ae98@localhost> Date: Thu, 20 Nov 2003 10:11:16 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069340387.21781.5.camel@empress.torrentnet.com> Precedence: list I think that addressing by type is likely to be at best of limitted use. There are very few LFB types that can be changed in parallel. People tend to assume that the "forwarding table" has this property. Even when the forwarding table is disjoint from the next hop table (a good idea in its own right) there are many uses of a "forwarding table LFB" which will not be populated with the same information. For example, one might use the same LFB type for policy forwarding as for routing protocol derived forwarding. Thus, to allow multicast to be used for routing protocol derived FIB propagation one needs to be more specific than merely "update the forwarding table LFB". We can create mechanisms where for the few LFBs whose contents are consistent there is a way to address them consistently. But type based addressing is not sufficient. Yours, Joel PS: It has been suggested in passing that multicast is good for backup FEs. For the kinds of backup I think ForCES will want, just having the CE install the necessary state (either in advance or when needed, as the system chooses to operate) is sufficient and MUCH simpler. PPS: Yes, I am finding myself seeing more complications and less benefits from multicast as this conversation continues. However, I will restrict the rate of my comments as I do not want to accidentally discourage others from speaking. I could easily be wrong. At 09:59 AM 11/20/2003 -0500, you wrote: > > If you remember, this is what > > I tried to illustrate in Vienna on pages 8 and 11 of my presentation: > > http://www.zurich.ibm.com/~rha/netlink2-1.pdf > > > > Another key characterisitic in netlink2 is that one can address LFB by > > type, i.e., "I want to send a routing table to all LFBs of the > > IPv4_ROUTING type". That's a great simplification as opposed to having > > to find out the IDs assigned to each individual LFB. > > > >That is a nice feature for some specific cases/systems. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 10:34:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09519 for ; Thu, 20 Nov 2003 10:34:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqpB-0004io-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:34:29 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMqpA-0004il-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 10:34:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C4FE5A@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 10:34:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61311190 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 10:34:24 -0500 Received: from 198.24.6.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 10:34:24 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAKFYPYb006797 for ; Thu, 20 Nov 2003 09:34:25 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Nov 2003 09:34:23 -0600 Received: from ericsson.com (142.133.72.81 [142.133.72.81]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XHG6A2VJ; Thu, 20 Nov 2003 10:34:20 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr, de, no, nn, sv, MIME-Version: 1.0 References: <3FBC9FF7.4080608@zurich.ibm.com> <98866232.1069328942@EEN9169.een.bris.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Jon Maloy Message-ID: <3FBCDEF5.7010509@ericsson.com> Date: Thu, 20 Nov 2003 10:34:13 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit You are right, multicast as seen from user level does not necessarily have anything to do with multicast at the transport level. What the user wants is "application level" multicast to conveniently send a message to a number of LFB's, irrespectively of where they are located. He does not care about how this is implemented by the base protocol. Transport level multicast is a completely different thing, and only serves the purpose of speeding up the transfer process while using the system resources as efficiently as possible. However, true transport level multicast/broadcast can only be used if application level multicast is supported by the API. Hence, as I see it, user level multicast must be a mandatory service provided by the base protocol, while transport level multicast may remain an option, useful, but not strictly necessary in small NE:s. In general I think that the benefits of transport level multicast/broadcast is overestimated, given modern CPU speeds and transport bandwidth. Up to a few dozen FE:s a 'replicast' implementation would be adequate, but the requirements are talking about _hundreds_ of FE:s, so, yes, transport level multicast/broadcast is probably needed at longer term. /Jon Alistair Munro wrote: > Hi Robert, > >> And to [ensure that the necessary hooks are in the ForCES protocol so it >> can make use of some form of multicast transport], we need to have some >> form of group addressing at the >> ForCES protocol level. Having spent some cycles on this, I can say it >> requires a bit more than "rearranging the FE ID bits to have some >> group-like meaning after the ForCES protocol has already been designed" >> (I think I heard sth along these lines on the list). > > > I certainly think it would be good to be able to multicast/broadcast to > LFBs via the ForCES protocol at application level. I don't see what this > has to do with multicast *transport*. Could you explain how you would > make > the application layer FE LFB hooks visible at transport level? > > Regards, > > Alistair > > -- > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 11:02:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10567 for ; Thu, 20 Nov 2003 11:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGs-00057m-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 11:03:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGs-00057i-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 11:03:06 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C4FF4F@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 11:03:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61317983 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 11:03:03 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 11:03:03 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112008021602:4318 ; Thu, 20 Nov 2003 08:02:16 -0800 References: <3FBC9EDC.2070606@zurich.ibm.com> <001401c3aee1$1e5c5cb0$a401a8c0@toronto.chantrynetworks.com> <3FBBE79D.4C7E9553@idt.com> <1069285762.19297.111.camel@empress.torrentnet.com> <3FBC9EDC.2070606@zurich.ibm.com> <5.1.0.14.0.20031120100322.01a6ae98@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/20/2003 08:02:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/20/2003 08:02:17 AM, Serialize complete at 11/20/2003 08:02:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069344180.1034.59.camel@jzny.localdomain> Date: Thu, 20 Nov 2003 11:03:01 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031120100322.01a6ae98@localhost> Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2003-11-20 at 10:11, Joel M. Halpern wrote: > I think that addressing by type is likely to be at best of limitted > use. There are very few LFB types that can be changed in parallel. > > People tend to assume that the "forwarding table" has this property. Even > when the forwarding table is disjoint from the next hop table (a good idea > in its own right) there are many uses of a "forwarding table LFB" which > will not be populated with the same information. I think thats a detail which belongs to the model.There will be different types of IPV4 LFBs - some requiring the clear demarcation you make. We are armed with the NE topology (how the FEs are interconnected and their respective topologies) - you could easily translate what the nexthop means. In both case there is value to address "all IPV4 forwarding LFBs". OTOH, neighbor mappings are a disjoint. You may have meant this later part. > For example, one might > use the same LFB type for policy forwarding as for routing protocol derived > forwarding. > So in these case you are even more corase than the finer granular level of using a separate addressing to the nexthop table. > Thus, to allow multicast to be used for routing protocol derived FIB > propagation one needs to be more specific than merely "update the > forwarding table LFB". We can create mechanisms where for the few LFBs > whose contents are consistent there is a way to address them > consistently. But type based addressing is not sufficient. > Its semantics: You could still have an "all IPV4" address. Protocol details dont diminish its need. cheers, jamal > Yours, > Joel > > PS: It has been suggested in passing that multicast is good for backup > FEs. For the kinds of backup I think ForCES will want, just having the CE > install the necessary state (either in advance or when needed, as the > system chooses to operate) is sufficient and MUCH simpler. > > PPS: Yes, I am finding myself seeing more complications and less benefits > from multicast as this conversation continues. However, I will restrict > the rate of my comments as I do not want to accidentally discourage others > from speaking. I could easily be wrong. > > At 09:59 AM 11/20/2003 -0500, you wrote: > > > If you remember, this is what > > > I tried to illustrate in Vienna on pages 8 and 11 of my presentation: > > > http://www.zurich.ibm.com/~rha/netlink2-1.pdf > > > > > > Another key characterisitic in netlink2 is that one can address LFB by > > > type, i.e., "I want to send a routing table to all LFBs of the > > > IPv4_ROUTING type". That's a great simplification as opposed to having > > > to find out the IDs assigned to each individual LFB. > > > > > > >That is a nice feature for some specific cases/systems. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 11:13:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11188 for ; Thu, 20 Nov 2003 11:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrRI-0005Jf-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 11:13:52 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMrRH-0005Jc-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 11:13:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C4FF81@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 11:13:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61318637 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 11:13:48 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 11:13:47 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112008130086:4338 ; Thu, 20 Nov 2003 08:13:00 -0800 References: <5.1.0.14.0.20031119142344.01a7acd8@localhost> <000e01c3ade5$d51dec90$a401a8c0@toronto.chantrynetworks.com > <1069106025.14238.52.camel@newcastle.torrentnet.com> <5.1.0.14.0.20031119142344.01a7acd8@localhost> <5.1.0.14.0.20031120091143.0192a268@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/20/2003 08:13:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/20/2003 08:13:02 AM, Serialize complete at 11/20/2003 08:13:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069344825.1033.70.camel@jzny.localdomain> Date: Thu, 20 Nov 2003 11:13:45 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031120091143.0192a268@localhost> Precedence: list Content-Transfer-Encoding: 7bit I dont think it is a startup challenge issue only. The challenge applies to all applications that build state based on packet arrival events. And there are many. Think of an IDS under a DOS. Or a flow tracking firewall system. 100s of FEs, millions of flows (say a 100K new ones per second). You certainly wanna distribute that info to the FEs. Unless you wanna rule out such apps for ForCES. I think it is a design flaw to say "we may need it to scale in the future or when we have slower hardware but lets forget ir right now". cheers, jamal On Thu, 2003-11-20 at 09:20, Joel M. Halpern wrote: > I believe people have said this. However... > > While the route*port product affects startup time, I would be reluctant to > include multicast for just startup. The question is what the rate of > change of the routes is. > > Remember also that what we deal with in ForCES are FIB entries, not RIB > entries. Even in the internet core there are rarely 100K FIB entries. > > Given that we are separating data and control concepts, one could argue > that the ratio "should" get arbitrarily large. One can equally argue that > the ratio "should" be kept bounded by deploying additional control entities > as needed. We have not established any agreement in the working group as > to what target we are after. That does not mean that the 2K port full > internet table device is out of scope. It also does not mean it is in scope. > > Let me put this another way... > In order to use multicast, we are going to have to define our own > reliability / security /congestion control mechanisms (we will be able to > use work from other working groups, but those do not appear to be sufficient.) > That is a large effort for the working group. > We are unlikely to declare multicast a :must implement". But doing a lot > of work on an optional aspect seems counter to the goal of effective > useable rapid progress. > > So I am trying to understand what problem we NEED to solve that multicast > is important for. > > Yours, > Joel M. Halpern > > At 01:46 PM 11/20/2003 +0100, you wrote: > >Joel, > > > >at least some time back I have heard from people that they > >intended to build boxes with more than 2000 ports and about > >100K routes. In such a case multicast is very helpful to > >make ForCES scalable. I do not know if people still have > >such can of plans due to the downturn but I guess it makes > >sense to have ForCES future proof. > > > >Regards, > >Patrick > > > > > >Joel M. Halpern wrote: > > > >>I find myself very torn on this issue. > >>So I am going to try to show my thinking in hopes that someone can either > >>point out aspects I am missing, or point out why certain aspects are more > >>important than I tend to treat them. > >>It would be nice to simply say "multicast is for later". > >>However, it is equally clear that if we are going to use multicast it is > >>much better to support it as an integral part of the protocol suite. This > >>directly effects core protocol features. > >>At the same time, my gut feel is that the complexity is not worth the > >>value. But that is not a good reason for anyone else to make a > >>decision. It is not even a good reason for me to make a decision. > >>I think some of this has to do with rates of change of information vs > >>easily supportable load. > >>Clearly, service configuration does not change often enough to require > >>multicast. > >>So the question becomes what rate of change of next-hops are we likely to > >>need to support, what number of FEs per CE are we trying to communicate > >>those changes to, and is the resultant load likely to be such that we will > >>want multicast. > >>Clearly, in many environments the answer is no. But that is not sufficient > >>to say we should not support it. > >>Equally clearly, there are some environments that we would like to support > >>eventually that will push the limits for unicast distribution. > >>But is that margin of applicability enough to justify the complexity. > >>Yours, > >>Joel > >>At 10:36 AM 11/18/2003 -0500, you wrote: > >> > >>>Hi, > >>> > >>>I'd also like to chime in on the importance of having multicast transport > >>>in the FORCES protocol. Just the idea of trying to download common updated > >>>forwarding tables to dozens or more FEs individually and to do so extremely > >>>quickly is disturbing. As Sandy said, there are interconnection > >>>technologies to allow the packet replication/multicast distribution. > >>>It is > >>>necessary to have multicast to enable scaling to large numbers of FEs and > >>>non-trivial forwarding information (IPv4 prefixes, global ILM entries, > >>>etc). Unfortunately, multicast transport is not something which can be > >>>efficiently layered on top of the FORCES protocol; it needs to be built in. > >>> > >>>I've just started following FORCES, so I'm sorry if this is redundant. > >>> > >>>Alia Atlas > >>> > >>> > >>>At 10:07 AM 11/18/2003, Sandy Pavel wrote: > >>> > >>>>Hi there! > >>>> > >>>>I haven't followed this thread of discussions and therefore I apologize > >>>>if > >>>>I am repeating something that has been mentioned before. > >>>> > >>>>First of all, I must mention that I am totally with Steven and the > >>>>others that ask for multicast support in the ForCES protocol. If > >>>>necessary, in order to convince people we can come up with a number of > >>>>examples and real world cases that would justify it. > >>>> > >>>>I am not sure if it is assumed or not but I think we should add > >>>>broadcast next to multicast. > >>>> > >>>>However, these would be transport technology options rather than ForCES > >>>>protocol message types. That is, we should leave the option of binding > >>>>different ForCES protocol messages to either unicast, multicast or > >>>>broadcast transport, as being platform (NE) specific. This is because > >>>>different implementations might have different resources available at > >>>>transport and physical level. > >>>> > >>>>The question is: do we add some sort of "multicast group management" as > >>>>part of ForCES control protocol, or leave it to the transport layer > >>>>itself? > >>>> > >>>>To conclude, considering the switching fabric and other interconnection > >>>>technologies proposed in the last few years especially for distributed, > >>>>multi-shelf core routers, I believe the only viable option is to include > >>>>multicast/broadcast as transport options for ForCES protocol(s). > >>>> > >>>>Regard, > >>>>Sandy Pavel > >>>> > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: Forwarding and Control Element Separation > >>>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake > >>>>Sent: November 17, 2003 4:54 PM > >>>>To: FORCES@PEACH.EASE.LSOFT.COM > >>>>Subject: Support for multicast in the ForCES protocol > >>>> > >>>>The issue of support for multicast transport in the ForCES protocol has > >>>>been a recurring topic of dispute between the competing protocol teams. > >>>>Multicast is not explicitly called out as a protocol requirement in > >>>>draft-ietf-forces-requirements-10.txt, and it is not mentioned in the > >>>>protocol evaluation draft. However, there are at least some people > >>>>(myself included) who believe that it is a pretty useful feature in some > >>>>system environments where ForCES could be applicable. > >>>> > >>>>Rather than make an argument for or against multicast support (some > >>>>people on this list have already heard my opinion anyway), I am > >>>>wondering if there are any folks not directly involved in the protocol > >>>>teams who have an opinion either pro or con? > >>>> > >>>>Apologies if I am exhuming a dead horse. > >>>> > >>>> > >>>>Regards, > >>>> > >>>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>>>Steven L. Blake > >>>>Ericsson IP Infrastructure +1 919-472-9913 > >> > > > >-- > > Dr. Patrick Droz | dro@zurich.ibm.com > > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 12:21:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14118 for ; Thu, 20 Nov 2003 12:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsUb-0006Wt-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 12:21:22 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMsUb-0006Wq-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 12:21:21 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C4FF65@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 12:21:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61322427 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 12:21:18 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 12:21:17 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 7BAE41F009F for ; Thu, 20 Nov 2003 12:21:05 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 5E8381F009B for ; Thu, 20 Nov 2003 12:20:55 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-8.2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FBCF7F4.779BAF02@idt.com> Date: Thu, 20 Nov 2003 12:20:52 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tal Anker wrote: > > Alan, > Are you suggesting that a network element would not support the regular hot-insertion that is common feature in either chasis or stackable products? Not at all. I'm just saying that complex configurations are more easily managed by system administrators, than by the CE. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 14:19:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19443 for ; Thu, 20 Nov 2003 14:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuKm-0000h6-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 14:19:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMuKl-0000h3-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 14:19:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C502D4@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 14:19:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61333773 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 14:19:17 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 14:19:17 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAKJJqBO023286 for ; Thu, 20 Nov 2003 19:19:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAKJ9aM17927 for ; Thu, 20 Nov 2003 19:09:36 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112011191004485 for ; Thu, 20 Nov 2003 11:19:10 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Nov 2003 11:19:10 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOu98ZUdSPth0WXRqeqeOmys1HIaQAnlecA X-OriginalArrivalTime: 20 Nov 2003 19:19:10.0426 (UTC) FILETIME=[2CE14BA0:01C3AF9B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0D008B3@orsmsx410.jf.intel.com> Date: Thu, 20 Nov 2003 11:19:10 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Zsolt, I think you have brought up a very good point,=20 although based on some assumptions.=20 (For now lets consider the assumptions are true.) I have been resisting getting into this thread since it was meant for folks "not directly involved with protocols". However I don't see that as the case any more :) In any case, what you are suggesting is that in order To use multicast efficiently, you will need to have this Tree in which multicast groups are assigned FE:LFB basis. (I will try to keep things simple for now by assuming 1 table per LFB) I agree its an efficient way to use multicast.=20 Now what this means is that, just in terms of no. of=20 connections from CE-to-FE, the ratio of unicast:multicast,=20 is the ratio of -> sum of Distinct LFBs per FE (M): no of FEs (N). So in case of a medium size Edge network element with 10 FEs=20 but 15 distinct LFBs (since it has to handle many diff protocols), This ratio is 15:10, which means that there will be more multicast=20 Groups than unicast connections ! This clearly has worse performance=20 than unicast. However, in case of a core router with 100 FEs and 10 distinct LFBs, This ration is 10:1, which means less multicast connections but not By a huge ratio. Now, this brings another question to mind... as to how "command Bundling" will be supported with this concept of multicast groups. Say I want to update entries in 3 LFBs (in 2 FEs) which belong to=20 different groups. Using multicast groups, you can send 3 messages On the 3 groups but how do you bundle that in an elegant way ? One way which I can think of is to bundle all 3 messages in a single Message and send it on one multicast connection. This does not Seem to be very elegant and there is no performance gain that I can think of. (Instead of sending 3, x size msgs, you sent 1 3x size msg) The only other way is to use a 2-phase commit in which you will land Up sending 6 messages, 3 for request and 3 to commit. This will definitely Be bad in terms of performance, etc and doesn't even meet the command Bundling requirement in spirit (single message). Let me know if you can think of an elegant, efficient way of doing this ? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti Sent: Wednesday, November 19, 2003 3:49 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Support for multicast in the ForCES protocol On Wed, 2003-11-19 at 16:58, Alan DeKok wrote: > That is, assuming that there *is* a multicast-capable transport under > ForCES, a "multicast" update can simple appear to ForCES to be another > FE. The system administrator would be responsible for maintenance of > multicast group membership. It is important to keep in mind that the target audience of potential multicast configuration updates are a set of LFBs of identical type across one or more FEs, and not the FEs themselves. For example, just because the same LPM table must be loaded into two FEs', it does not mean that all other LFBs of the two FEs will also be programmed identically. In fact it is more probable that they won't. To be even more precise, the entities that need to be addressed by the same config information may not be even full LFBs, but rather some attributes of (e.g., tables) of these LFBs. It appears to me that using a layered approach, in which the ForCES protocol simply relies on multicast support in the lower layer, does not address the whole problem, since that only addresses the efficient distribution to a group of FEs and not a group of LFBs across these FEs. (Am I wrong?) That may be fine, provided that the rest of the problem can also be solved. But I am not sure it can be without support from the ForCES protocol itself. To explain what I mean by target audience of multicast config requests, consider the following (small-scale) example. CE---+---> FE1 ---+---> LFB1(*) | +---> LFB2(*) | +---> LFB3(LPM)--+--> prefixtab1 [VRF1] | | +--> prefixtab2 | +---> LFB4(*) | +---> LFB5(LPM)--+--> prefixtab1 | | +--> prefixtab2 [VRF1] | : | +---> FE2 ---+---> LFB1(*) | +---> LFB2(*) | : | +---> FE3 ---+---> LFB1(LPM)-----> prefixtab1 [VRF1] | +---> LFB2(*) | +---> LFB3(LPM)--+--> prefixtab1 | | +--> prefixtab2 : : +--> prefixtab3 [VRF1] The CE controls a number of FEs, each has a set of LFBs (the FEs may not have the same LFB topology). LFB(LPM) denotes LPM prefix lookup LFBs (which for simplicity are instances of the same LFB class). LFB(*) denotes other types of LFBs. In a VRF capable router the LPM LFBs may contain multiple LPM tables, and the number of LPM tables may be different from one LFB to the other (as indicated in the example). Suppose that the following tables are created to provide LPM for the same VRF (e.g., VRF1 as marked in the figure): FE1 : LFB3 : prefixtab1 FE1 : LFB5 : prefixtab2 FE3 : LFB1 : prefixtab1 FE3 : LFB3 : prefixtab3 In a large system where there is a large number of such tables, one should use the ForCES model in a clever way such that these tables are kept identical (not only the prefixes, which are obvious, but also the next hop identifiers associated with each prefix to address next hop entries in another LFB). If the tables are identical, then the exact same methods can be and should be sent to all of them to maintain the tables, and that is a case for multicast support. In other words, the above list of tables are the real and final target of the multicast messages. I am not sure what part of the problem would the underlying multicast layer solve, but I think it is only from the CE to the FEs (which is useful, but not sufficient). If so, there must be additional mechanisms to set up the "rest of the tree" on each FE, and I don't see how you can do that without explicit support from the ForCES protocol. What is needed is that the CE should be able to say: "I want to have FE1 : LFB3 : prefixtab1 FE1 : LFB5 : prefixtab2 FE3 : LFB1 : prefixtab1 FE3 : LFB3 : prefixtab3 to form a muticast group, accessible by a fictive address FEx : LFBy : prefixtab_z". To implement that the address triplet must be registered at the CE, a CE-to-FE multicast tree must be established (if one with identical membership does not exist yet), and then a table must be set up at the FE (and possibly even in each involved LFB). My main point, again, is that CE-to-FE multicast is useless unless the full tree can be set up (the leaves are tables within LFBs), and I suspect the ForCES protocol will need to pitch in to address the second and perhaps the third layer of the tree (the third can actually be solved within the LFB-specific protocol data, instead of the base protocol). My $0.02. Zsolt Haraszti From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 15:52:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25354 for ; Thu, 20 Nov 2003 15:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnF-0002GI-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 15:52:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnE-0002GF-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 15:52:48 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C503ED@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 15:52:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61344734 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 15:52:46 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 15:52:46 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAKKqlB26859 for ; Thu, 20 Nov 2003 15:52:47 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAKKqkj20721 for ; Thu, 20 Nov 2003 15:52:46 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id hAKKqkq19662 for ; Thu, 20 Nov 2003 15:52:46 -0500 (EST) References: <9CB758BBEE58754F8F33234D75B9F4B0D008B3@orsmsx410.jf.intel.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1069361565.21783.165.camel@empress.torrentnet.com> Date: Thu, 20 Nov 2003 15:52:45 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0D008B3@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hormuzd, See my comment inline. On Thu, 2003-11-20 at 14:19, Khosravi, Hormuzd M wrote: > Hi Zsolt, > > I think you have brought up a very good point, > although based on some assumptions. > (For now lets consider the assumptions are true.) > I have been resisting getting into this thread since it > was meant for folks "not directly involved with protocols". > However I don't see that as the case any more :) > > In any case, what you are suggesting is that in order > To use multicast efficiently, you will need to have this > Tree in which multicast groups are assigned FE:LFB basis. > (I will try to keep things simple for now by assuming 1 table per LFB) > I agree its an efficient way to use multicast. > Now what this means is that, just in terms of no. of > connections from CE-to-FE, the ratio of unicast:multicast, > is the ratio of -> sum of Distinct LFBs per FE (M): no of FEs (N). > > So in case of a medium size Edge network element with 10 FEs > but 15 distinct LFBs (since it has to handle many diff protocols), > This ratio is 15:10, which means that there will be more multicast > Groups than unicast connections ! This clearly has worse performance > than unicast. > You make an assumption that does not hold: you assume that all 15 LFBS will share information with their counterpart in all other FEs. That is unlikely the case in practice. In fact only a very small number of LFBs will share information (though they may be the ones updated most frequently with large amount of information). A more realistic numerical example would be when 2 out of the 15 LFBs are part of multicast trees. So in this case I would have 10 unicast connections for normal LFB configuration, and 2 multicast trees. /zsolt > However, in case of a core router with 100 FEs and 10 distinct LFBs, > This ration is 10:1, which means less multicast connections but not > By a huge ratio. > > Now, this brings another question to mind... as to how "command > Bundling" will be supported with this concept of multicast groups. > Say I want to update entries in 3 LFBs (in 2 FEs) which belong to > different groups. Using multicast groups, you can send 3 messages > On the 3 groups but how do you bundle that in an elegant way ? > One way which I can think of is to bundle all 3 messages in a single > Message and send it on one multicast connection. This does not > Seem to be very elegant and there is no performance gain that I can > think of. > (Instead of sending 3, x size msgs, you sent 1 3x size msg) > The only other way is to use a 2-phase commit in which you will land > Up sending 6 messages, 3 for request and 3 to commit. This will > definitely > Be bad in terms of performance, etc and doesn't even meet the command > Bundling requirement in spirit (single message). > > Let me know if you can think of an elegant, efficient way of doing this > ? > > Thanks > Hormuzd > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti > Sent: Wednesday, November 19, 2003 3:49 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Support for multicast in the ForCES protocol > > > On Wed, 2003-11-19 at 16:58, Alan DeKok wrote: > > That is, assuming that there *is* a multicast-capable transport > under > > ForCES, a "multicast" update can simple appear to ForCES to be another > > FE. The system administrator would be responsible for maintenance of > > multicast group membership. > > It is important to keep in mind that the target audience of > potential multicast configuration updates are a set of LFBs of > identical type across one or more FEs, and not the FEs > themselves. For example, just because the same LPM table must > be loaded into two FEs', it does not mean that all other > LFBs of the two FEs will also be programmed identically. In > fact it is more probable that they won't. > > To be even more precise, the entities that need to be addressed > by the same config information may not be even full LFBs, but > rather some attributes of (e.g., tables) of these LFBs. > > It appears to me that using a layered approach, in which the ForCES > protocol simply relies on multicast support in the lower layer, does > not address the whole problem, since that only addresses the > efficient distribution to a group of FEs and not a group of LFBs > across these FEs. (Am I wrong?) That may be fine, provided that > the rest of the problem can also be solved. But I am not sure it > can be without support from the ForCES protocol itself. > > To explain what I mean by target audience of multicast config > requests, consider the following (small-scale) example. > > CE---+---> FE1 ---+---> LFB1(*) > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 [VRF1] > | | +--> prefixtab2 > | +---> LFB4(*) > | +---> LFB5(LPM)--+--> prefixtab1 > | | +--> prefixtab2 [VRF1] > | : > | > +---> FE2 ---+---> LFB1(*) > | +---> LFB2(*) > | : > | > +---> FE3 ---+---> LFB1(LPM)-----> prefixtab1 [VRF1] > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 > | | +--> prefixtab2 > : : +--> prefixtab3 [VRF1] > > > The CE controls a number of FEs, each has a set of LFBs (the > FEs may not have the same LFB topology). LFB(LPM) denotes > LPM prefix lookup LFBs (which for simplicity are instances > of the same LFB class). LFB(*) denotes other types > of LFBs. In a VRF capable router the LPM LFBs may contain > multiple LPM tables, and the number of LPM tables may be > different from one LFB to the other (as indicated in the > example). Suppose that the following tables are created to > provide LPM for the same VRF (e.g., VRF1 as marked in the > figure): > > FE1 : LFB3 : prefixtab1 > FE1 : LFB5 : prefixtab2 > FE3 : LFB1 : prefixtab1 > FE3 : LFB3 : prefixtab3 > > In a large system where there is a large number of such tables, > one should use the ForCES model in a clever way such that these > tables are kept identical (not only the prefixes, which are > obvious, but also the next hop identifiers associated with > each prefix to address next hop entries in another LFB). If > the tables are identical, then the exact same methods can be > and should be sent to all of them to maintain the tables, and > that is a case for multicast support. In other words, > the above list of tables are the real and final target of the > multicast messages. > > I am not sure what part of the problem would the underlying > multicast layer solve, but I think it is only from the CE to > the FEs (which is useful, but not sufficient). If so, there > must be additional mechanisms to set up the "rest of the tree" > on each FE, and I don't see how you can do that without explicit > support from the ForCES protocol. What is needed is that the CE > should be able to say: "I want to have > FE1 : LFB3 : prefixtab1 > FE1 : LFB5 : prefixtab2 > FE3 : LFB1 : prefixtab1 > FE3 : LFB3 : prefixtab3 > to form a muticast group, accessible by a fictive address > FEx : LFBy : prefixtab_z". To implement that the address > triplet must be registered at the CE, a CE-to-FE multicast > tree must be established (if one with identical membership > does not exist yet), and then a table must be set up at > the FE (and possibly even in each involved LFB). > > My main point, again, is that CE-to-FE multicast is useless > unless the full tree can be set up (the leaves are tables within > LFBs), and I suspect the ForCES protocol will need to pitch in > to address the second and perhaps the third layer of the tree > (the third can actually be solved within the LFB-specific protocol > data, instead of the base protocol). > > My $0.02. > > Zsolt Haraszti > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 16:57:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01334 for ; Thu, 20 Nov 2003 16:57:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwnu-0004Y7-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 16:57:34 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMwnt-0004Y4-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 16:57:34 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C5057B@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 16:57:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61350886 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 16:57:29 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 16:57:29 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAKLvl9X004731 for ; Thu, 20 Nov 2003 21:57:47 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAKLpXs02009 for ; Thu, 20 Nov 2003 21:51:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112013572611479 for ; Thu, 20 Nov 2003 13:57:26 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Nov 2003 13:57:26 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOvqFVLuTw4vV9XRx24VVwjLvXzzwABK0rQ X-OriginalArrivalTime: 20 Nov 2003 21:57:26.0955 (UTC) FILETIME=[49409FB0:01C3AFB1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0D00937@orsmsx410.jf.intel.com> Date: Thu, 20 Nov 2003 13:57:26 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Zsolt, So are you suggesting a combination of unicast and multicast to solve the efficiency problem ? That's interesting, and wasn't apparent to me in your previous email. BTW, the assumption that I made is exactly the same assumption that I thought you are also making regarding LFBs sharing the same information across FEs :-) (This is what I was referring to in the beginning of my email) Any thoughts on how to address the "command bundling" issue in a multicast approach ? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti Sent: Thursday, November 20, 2003 12:53 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Support for multicast in the ForCES protocol Hormuzd, See my comment inline. On Thu, 2003-11-20 at 14:19, Khosravi, Hormuzd M wrote: > Hi Zsolt, > > I think you have brought up a very good point, > although based on some assumptions. > (For now lets consider the assumptions are true.) > I have been resisting getting into this thread since it > was meant for folks "not directly involved with protocols". > However I don't see that as the case any more :) > > In any case, what you are suggesting is that in order > To use multicast efficiently, you will need to have this > Tree in which multicast groups are assigned FE:LFB basis. > (I will try to keep things simple for now by assuming 1 table per LFB) > I agree its an efficient way to use multicast. > Now what this means is that, just in terms of no. of > connections from CE-to-FE, the ratio of unicast:multicast, > is the ratio of -> sum of Distinct LFBs per FE (M): no of FEs (N). > > So in case of a medium size Edge network element with 10 FEs > but 15 distinct LFBs (since it has to handle many diff protocols), > This ratio is 15:10, which means that there will be more multicast > Groups than unicast connections ! This clearly has worse performance > than unicast. > You make an assumption that does not hold: you assume that all 15 LFBS will share information with their counterpart in all other FEs. That is unlikely the case in practice. In fact only a very small number of LFBs will share information (though they may be the ones updated most frequently with large amount of information). A more realistic numerical example would be when 2 out of the 15 LFBs are part of multicast trees. So in this case I would have 10 unicast connections for normal LFB configuration, and 2 multicast trees. /zsolt > However, in case of a core router with 100 FEs and 10 distinct LFBs, > This ration is 10:1, which means less multicast connections but not > By a huge ratio. > > Now, this brings another question to mind... as to how "command > Bundling" will be supported with this concept of multicast groups. > Say I want to update entries in 3 LFBs (in 2 FEs) which belong to > different groups. Using multicast groups, you can send 3 messages > On the 3 groups but how do you bundle that in an elegant way ? > One way which I can think of is to bundle all 3 messages in a single > Message and send it on one multicast connection. This does not > Seem to be very elegant and there is no performance gain that I can > think of. > (Instead of sending 3, x size msgs, you sent 1 3x size msg) > The only other way is to use a 2-phase commit in which you will land > Up sending 6 messages, 3 for request and 3 to commit. This will > definitely > Be bad in terms of performance, etc and doesn't even meet the command > Bundling requirement in spirit (single message). > > Let me know if you can think of an elegant, efficient way of doing this > ? > > Thanks > Hormuzd > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Zsolt Haraszti > Sent: Wednesday, November 19, 2003 3:49 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Support for multicast in the ForCES protocol > > > On Wed, 2003-11-19 at 16:58, Alan DeKok wrote: > > That is, assuming that there *is* a multicast-capable transport > under > > ForCES, a "multicast" update can simple appear to ForCES to be another > > FE. The system administrator would be responsible for maintenance of > > multicast group membership. > > It is important to keep in mind that the target audience of > potential multicast configuration updates are a set of LFBs of > identical type across one or more FEs, and not the FEs > themselves. For example, just because the same LPM table must > be loaded into two FEs', it does not mean that all other > LFBs of the two FEs will also be programmed identically. In > fact it is more probable that they won't. > > To be even more precise, the entities that need to be addressed > by the same config information may not be even full LFBs, but > rather some attributes of (e.g., tables) of these LFBs. > > It appears to me that using a layered approach, in which the ForCES > protocol simply relies on multicast support in the lower layer, does > not address the whole problem, since that only addresses the > efficient distribution to a group of FEs and not a group of LFBs > across these FEs. (Am I wrong?) That may be fine, provided that > the rest of the problem can also be solved. But I am not sure it > can be without support from the ForCES protocol itself. > > To explain what I mean by target audience of multicast config > requests, consider the following (small-scale) example. > > CE---+---> FE1 ---+---> LFB1(*) > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 [VRF1] > | | +--> prefixtab2 > | +---> LFB4(*) > | +---> LFB5(LPM)--+--> prefixtab1 > | | +--> prefixtab2 [VRF1] > | : > | > +---> FE2 ---+---> LFB1(*) > | +---> LFB2(*) > | : > | > +---> FE3 ---+---> LFB1(LPM)-----> prefixtab1 [VRF1] > | +---> LFB2(*) > | +---> LFB3(LPM)--+--> prefixtab1 > | | +--> prefixtab2 > : : +--> prefixtab3 [VRF1] > > > The CE controls a number of FEs, each has a set of LFBs (the > FEs may not have the same LFB topology). LFB(LPM) denotes > LPM prefix lookup LFBs (which for simplicity are instances > of the same LFB class). LFB(*) denotes other types > of LFBs. In a VRF capable router the LPM LFBs may contain > multiple LPM tables, and the number of LPM tables may be > different from one LFB to the other (as indicated in the > example). Suppose that the following tables are created to > provide LPM for the same VRF (e.g., VRF1 as marked in the > figure): > > FE1 : LFB3 : prefixtab1 > FE1 : LFB5 : prefixtab2 > FE3 : LFB1 : prefixtab1 > FE3 : LFB3 : prefixtab3 > > In a large system where there is a large number of such tables, > one should use the ForCES model in a clever way such that these > tables are kept identical (not only the prefixes, which are > obvious, but also the next hop identifiers associated with > each prefix to address next hop entries in another LFB). If > the tables are identical, then the exact same methods can be > and should be sent to all of them to maintain the tables, and > that is a case for multicast support. In other words, > the above list of tables are the real and final target of the > multicast messages. > > I am not sure what part of the problem would the underlying > multicast layer solve, but I think it is only from the CE to > the FEs (which is useful, but not sufficient). If so, there > must be additional mechanisms to set up the "rest of the tree" > on each FE, and I don't see how you can do that without explicit > support from the ForCES protocol. What is needed is that the CE > should be able to say: "I want to have > FE1 : LFB3 : prefixtab1 > FE1 : LFB5 : prefixtab2 > FE3 : LFB1 : prefixtab1 > FE3 : LFB3 : prefixtab3 > to form a muticast group, accessible by a fictive address > FEx : LFBy : prefixtab_z". To implement that the address > triplet must be registered at the CE, a CE-to-FE multicast > tree must be established (if one with identical membership > does not exist yet), and then a table must be set up at > the FE (and possibly even in each involved LFB). > > My main point, again, is that CE-to-FE multicast is useless > unless the full tree can be set up (the leaves are tables within > LFBs), and I suspect the ForCES protocol will need to pitch in > to address the second and perhaps the third layer of the tree > (the third can actually be solved within the LFB-specific protocol > data, instead of the base protocol). > > My $0.02. > > Zsolt Haraszti > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 18:19:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07290 for ; Thu, 20 Nov 2003 18:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMy5F-0006X2-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 18:19:33 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMy5E-0006Wz-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 18:19:32 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C508DD@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 18:19:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61358801 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 18:19:31 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 18:19:31 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAKNJTOf009328 for ; Thu, 20 Nov 2003 17:19:29 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <86093696.1069156216@EEN9169.een.bris.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FBD4C00.BDFF7BB6@alcatel.com> Date: Thu, 20 Nov 2003 17:19:28 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: NPF WAS (Re: ForCES model - other thoughts To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes, the ForCEs model should be a standalone document. As such, efforts to drive changes in terms used in the model document so that they allign with those used in the NPF documents are counter-productive. I think Jamal has a good point. Regards, Alex. Alistair Munro wrote: > Hi Jamil, > > I appreciate your concerns but I agree with Lily's and John Renwick's > comments: the ForCES model is a standalone document that is shaping the > NPF's thoughts on how to model an FE. You aren't missing anything by not > seeing the NPF's drafts. > > I've mentioned my concerns before about use by the NPF of the ForCES model > off-the-shelf, particularly that the ForCES model becomes too specific that > NPF implementers feel too constrained. However, (a) nobody in the NPF has > actually yet said they feel it's a real problem, and (b) the way to avoid > IMO it is to encourage the NPF group to contribute more to ForCES. > > I don't think there is any active contributor to the NPF's discussions who > is not also a member of ForCES, or who does not have a close colleague > involved in ForCES. I hope this will allow enough "liaison" to happen > without the bureaucracy of a formal process worthy of ETSI or the ITU. > > Regards, > > Alistair > > -- > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 20 18:32:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07787 for ; Thu, 20 Nov 2003 18:32:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyI4-0006jL-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 18:32:48 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AMyI3-0006jI-00 for forces-archive@IETF.ORG; Thu, 20 Nov 2003 18:32:47 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C5082E@cherry.ease.lsoft.com>; Thu, 20 Nov 2003 18:32:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61360352 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Nov 2003 18:32:44 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Nov 2003 18:32:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOviu/vXJ+4pta7SL+foXxAJs9TEgAMu9kv Approved-By: Tal Anker Message-ID: Date: Fri, 21 Nov 2003 01:32:55 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 QnV0IHdoYXQgYWJvdXQgdGhlIHNpbXBsZXN0IGZvcm0gb2YgaW5zZXJ0aW5nIGEgY2FyZCBpbnRv IGEgY2hhc2lzLCBvciBhZGRpbmcgYSB1bml0IGludG8gYSBzdGFja2FibGUgcHJvZHVjdD8NClRo aXMgImhvdC1pbnNlcnRpb24iIGNhcGFiaWxpdHkgZG9lcyBub3QgKHVzdWFsbHkpIHJlcXVpcmUg c3lzIGFkbWluIGludGVydmVudGlvbiAtIG90aGVyIHRoYW4ganVzdCBpbnNlcnRpbmcgdGhlIGNh cmQvdW5pdC4uLiB3aHkgcG9zaW5nIHN1Y2ggcmVzdHJpY3Rpb24gKGlmIHdlIHdpbGwgcmVxdWly ZSBncm91cCBtZW1iZXJzaGlwIHRvIGJlIHN0YXRpYyBjb25maWd1cmVkLi4uKSBmcm9tIHRoZSBi ZWdpbm5pbmc/IFdlIGNhbiBkZWZpbmUgdGhlIGdyb3VwIG1lbmFnZW1lbnQgYXMgYSBzZXJ2aWNl IHRoYXQgY2FuIGJlIGFkZGVkIGxhdGVyIG9uIGJ5IGp1c3QgZGVmaW5pbmcgdGhlIHByb3RvY29s IGludGVyZmFjZSB0byBzdWNoIHNlcnZpY2UgKGFkZCBtZW1iZXIvcmVtb3ZlIG1lbWJlciBldGMp LiBXZSBkbyBub3QgbmVlZCB0byBkZWZpbmUgdGhlIG1lbWJlcnNoaXAgbWFuYWdlbWVudCBhdCB0 aGUgbW9tZW50LCBidXQgcmF0aGVyIGp1c3QgdG8gYmUgYWJsZSB0byBjb3BlIHdpdGggZHluYW1p YyBhZGRpdGlvbnMvcmVtb3ZhbHMgb2YgRkVzICh0byBjb3BlIHdpdGggZXZlbnRzIG9mIHJlbW92 YWwvaW5zZXJ0aW9uIHdoZXJlIHRoZSBtZWNoYW5pc20gYW5kIHNvdXJjZSBvZiBzdWNoIGV2ZW50 cyBpcyBfY3VycmVudGx5XyBub3Qgc3BlY2lmaWVkKS4NCiANCi0gVGFsDQoNCgktLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBBbGFuIERlS29rIFttYWlsdG86YWxhbi5kZWtva0Bp ZHQuY29tXSANCglTZW50OiBUaHUgMTEvMjAvMjAwMyA3OjIwIFBNIA0KCVRvOiBGT1JDRVNAUEVB Q0guRUFTRS5MU09GVC5DT00gDQoJQ2M6IA0KCVN1YmplY3Q6IFJlOiBTdXBwb3J0IGZvciBtdWx0 aWNhc3QgaW4gdGhlIEZvckNFUyBwcm90b2NvbA0KCQ0KCQ0KDQoJVGFsIEFua2VyIHdyb3RlOg0K CT4NCgk+IEFsYW4sDQoJPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBhIG5ldHdvcmsgZWxlbWVu dCB3b3VsZCBub3Qgc3VwcG9ydCB0aGUgcmVndWxhciBob3QtaW5zZXJ0aW9uIHRoYXQgaXMgY29t bW9uIGZlYXR1cmUgaW4gZWl0aGVyIGNoYXNpcyBvciBzdGFja2FibGUgcHJvZHVjdHM/DQoJDQoJ ICBOb3QgYXQgYWxsLiAgSSdtIGp1c3Qgc2F5aW5nIHRoYXQgY29tcGxleCBjb25maWd1cmF0aW9u cyBhcmUgbW9yZQ0KCWVhc2lseSBtYW5hZ2VkIGJ5IHN5c3RlbSBhZG1pbmlzdHJhdG9ycywgdGhh biBieSB0aGUgQ0UuDQoJDQoJICBBbGFuIERlS29rLg0KCQ0KCQ0KCQ0KDQo= From tpqinfo@geocities.com Thu Nov 20 21:36:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14521; Thu, 20 Nov 2003 21:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN19h-0001on-00; Thu, 20 Nov 2003 21:36:21 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AN19h-0001oi-00; Thu, 20 Nov 2003 21:36:21 -0500 Received: from adsl-64-218-142-244.dsl.rcsntx.swbell.net ([64.218.142.244] helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AN19h-0007e1-7Y; Thu, 20 Nov 2003 21:36:22 -0500 From: "Informe Exclusivo" To: forces-archive@ietf.org Subject: Fórum Social Brasileiro: radiografia das esquerdas ref.: mvi X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 20 Nov 2003 21:36:22 -0500 c0311fsbavisop

oiv EstaCartaEnCastellano - ThisLetterInEnglish

Amigos:

O Primeiro Fórum Social Brasileiro (FSB) efetuou-se de 6 a 9 de novembro pp. na cidade brasileira de Belo Horizonte. Organizado pelo conselho brasileiro do Fórum Social Mundial (FSM), contou com a participação de 1.200 organizações brasileiras, de 15 mil ativistas inscritos oficialmente e de outros 15 mil convidados, entre os quais, observadores de 22 países.

O importante evento, um dos maiores até aqui realizados pelas esquerdas brasileiras, passou desapercebido aos grandes meios de comunicação.

O FSB foi marcado por conferências de cunho comuno-anárquico no político, oposto à propriedade privada e a livre iniciativa; e permissivistas no moral, a favor do aborto, da homossexualidade e da "transversalidade". Constituiu uma oportunidade única para obter uma radiografia atualizada das esquerdas brasileiras, com suas novas e velhas estratégias, seus dilemas, suas utopias, suas contradições internas, seus problemas e seus temores. Uma radiografia indispensável para conhecer o que poderá passar no curto e médio prazo com o regime Lula, com o Brasil e, em boa medida, com a América do Sul.

Oferecemos-lhes gratuitamente um Informe Exclusivo, com 5 capítulos, sobre tal evento.

Cordialmente, Roberto Fernández-Lopez, Ámbito Iberoamericano, Madri.

FSB:InformeCompletoGratuito(EnCastellano)

FSB:InformeCompletoGratuito(EmPortugues)

FSB:FullReport(InEnglish)

Série Fórum Social Brasileiro: radiografia das esquerdas

(Belo Horizonte, Nov. 6-9, 2003)

 

1) FSB: radiografia das esquerdas

Importante congresso de movimentos contestátarios brasileiros passa desapercebido aos grandes meios de comunicação

2) FSB: esquerdas debatem utopias, estratégias e dilemas

Os fantasmas de governos de esquerda derrocados na América Latina ressurgem em meio de ásperos debates

3) FSB: conjuntura latino-americana e política externa lulista

Recolocar o socialismo como uma alternativa viável e derrotar os Estados Unidos são duas das metas internacionais das esquerdas no FSB

4) FSB: articulações de "esquerda católica", MST e indigenistas

Uma "nova lógica" de construção do poder, através de "redes" de ONGs, para controlar o Estado e a sociedade

5) FSB: a meta de "desconstrução" e "reinvenção" do homem e da sociedade

Uma mudança de mentalidades que afaste o mais possivel o ser humano dos Mandamentos da Lei de Deus

LINKS:

FSB:InformeCompletoGratuito(EmPortuguês)

FSB:FullReportInEnglish

FSB:InformeCompletoGratuito(EnCastellano)

FSB:MinhaOpinao

FSB:MinhaSugestao

FSB:Unsubscribe-Br

  

 

 From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 15:08:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29648 for ; Fri, 21 Nov 2003 15:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHaF-00005u-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:08:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANHaF-00005f-01 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:08:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C520B9@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 15:08:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61490765 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:08:49 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 15:08:49 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hALK9U7w014517 for ; Fri, 21 Nov 2003 20:09:30 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hALK2qN23021 for ; Fri, 21 Nov 2003 20:02:52 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112112043817665 for ; Fri, 21 Nov 2003 12:04:39 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Nov 2003 12:04:34 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOvf8sjrxQWMNNsQIu8W84rJ2gHRQAwbl1A X-OriginalArrivalTime: 21 Nov 2003 20:04:34.0510 (UTC) FILETIME=[AEF946E0:01C3B06A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD80195EB79@orsmsx409.jf.intel.com> Date: Fri, 21 Nov 2003 12:04:34 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat off] Jamal Hadi Salim wrote> Joel Halpern wrote> > > > Even when the forwarding table is disjoint from the next hop=20 > > table (a good idea in its own right) there are many uses of=20 > > a "forwarding table LFB" which will not be populated with the=20 > > same information. >=20 > I think thats a detail which belongs to the model. There will be > different types of IPV4 LFBs - some requiring the clear=20 > demarcation you make. I'm not sure I follow here. The justification for the added complexity of multicast is that it will save bandwidth. Evaluating some realistic examples of saved bandwidth seems to me to be an important part of the discussion rather than just a detail! Aside from the issue of performance, there is also the question of feasibility. Whether unicast or multicast is used, the following requirements must be met when downloading FIB entries: 1 Data must not be corrupted in transit.=20 2 Data must not be reordered in transit.=20 3 Once delivered to the FE, the success or failure of a route addition attempt must be explicitly acknowledged. 4 There must be a way for the FE to know which LFB the route pertains to (FE will have many LFBs, and may even have multiple forwarding LFBs). 5 Route additions may sometimes be part of a larger transaction on a FE (e.g. "Add this prefix entry to LFB1, AND add this nexthop entry to LFB2, and use all or nothing semantics.") 6 When used over multiple hops, route additions (and all=20 other forces messages) must use an existing RFC2914 L4 transport. (charter requirement) For #1, TCP is satisfactory in unicast. In multicast, it will be necessary to add some sort of CRC to packets, or use an existing reliable multicast protocol. For #2, TCP is satisfactory in unicast. In multicast, sequence numbers will be necessary, or a reliable multicast transport protocol will need to be used. For #3, the same TCP connection can be used in unicast. In multicast, either the same multicast connection is used (this results in every FE seeing every other FE's ack - yuck!) or a separate TCP connection must be maintained by the FE to the CE. For #4, either the protocol or its payload probably needs a LFB identifier in the unicast case. In the multicast case, it will be necessary to come up with some sort of binding protocol, where LFBs are dynamically associated at runtime=20 with multicast groups. For #5, in the unicast case, a single message could contain transaction information and a set of sub-messages. In the multicast case I cannot off the top of my head come up with a mechanism to even support transactioning. For #6, in the unicast case, TCP is satisfactory. In the multicast case, a 2914 compliant multicast-based standard protocol would be needed. Are there existing, standard, robust implementations of a 2914 compliant multicast protocol available in the operating systems commonly used in CEs and FEs? In my (technical - chair hat still off) opinion, all of the above requirements have to be met for any solution (multicast or unicast) to be feasible. I can understand how the above are satisfied by unicast, and would like to understand better how the above can be satisfied when using multicast. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 15:45:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01587 for ; Fri, 21 Nov 2003 15:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANI9W-0000WP-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:45:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANI9W-0000WM-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:45:18 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C52299@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 15:45:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61494173 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:45:12 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 15:45:09 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALKj8A12541 for ; Fri, 21 Nov 2003 22:45:08 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Nov 2003 22:45:07 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 14:45:01 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOvgXpCQFC8fqp0SP296OL7nxigXAA7TQCg X-OriginalArrivalTime: 21 Nov 2003 20:45:01.0060 (UTC) FILETIME=[554F6C40:01C3B070] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Fri, 21 Nov 2003 15:45:00 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello Jamal, =20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of ext Jamal Hadi Salim > Sent: Thursday, November 20, 2003 11:14 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Support for multicast in the ForCES protocol >=20 >=20 > I dont think it is a startup challenge issue only. The=20 > challenge applies > to all applications that build state based on packet arrival=20 > events. And > there are many. > Think of an IDS under a DOS. Or a flow tracking firewall system. > 100s of FEs, millions of flows (say a 100K new ones per second). > You certainly wanna distribute that info to the FEs. > Unless you wanna rule out such apps for ForCES. >=20 You may be refering to some specific architecture issue and cannot be = generalized.=20 In IDS, you need to distinguish clearly about your placement of probing = and=20 monitoring/metering activity.=20 I would say that poor seperation is a design issue. In (distributed architecture) firewall or TCP off-loading case - = connection are pushed to forwarding blade after successfull connection = - mechanism like SYN-Defender etc protect the equipments. =20 We have hardware chips available today which does these things nicely = and also scales well. =20 =20 Regards Ramg From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 15:45:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01611 for ; Fri, 21 Nov 2003 15:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIAJ-0000Wq-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:46:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANIAI-0000Wn-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:46:06 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C52025@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 15:46:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61494250 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:46:02 -0500 Received: from 198.24.6.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 15:45:45 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hALKjjYb015589 for ; Fri, 21 Nov 2003 14:45:45 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Nov 2003 14:45:42 -0600 Received: from ericsson.com (142.133.72.81 [142.133.72.81]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XHG6A8MS; Fri, 21 Nov 2003 15:45:43 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr, de, no, nn, sv, MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD80195EB79@orsmsx409.jf.intel.com> Content-Type: multipart/alternative; boundary="------------080507010003030406090906" Approved-By: Jon Maloy Message-ID: <3FBE7972.6080305@ericsson.com> Date: Fri, 21 Nov 2003 15:45:38 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------080507010003030406090906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit /jon Putzolu, David wrote: [chair hat off] Jamal Hadi Salim wrote> Joel Halpern wrote> > Even when the forwarding table is disjoint from the next hop table (a good idea in its own right) there are many uses of a "forwarding table LFB" which will not be populated with the same information. I think thats a detail which belongs to the model. There will be different types of IPV4 LFBs - some requiring the clear demarcation you make. I'm not sure I follow here. The justification for the added complexity of multicast is that it will save bandwidth. Evaluating some realistic examples of saved bandwidth seems to me to be an important part of the discussion rather than just a detail! Aside from the issue of performance, there is also the question of feasibility. Whether unicast or multicast is used, the following requirements must be met when downloading FIB entries: 1 Data must not be corrupted in transit. 2 Data must not be reordered in transit. 3 Once delivered to the FE, the success or failure of a route addition attempt must be explicitly acknowledged. 4 There must be a way for the FE to know which LFB the route pertains to (FE will have many LFBs, and may even have multiple forwarding LFBs). 5 Route additions may sometimes be part of a larger transaction on a FE (e.g. "Add this prefix entry to LFB1, AND add this nexthop entry to LFB2, and use all or nothing semantics.") 6 When used over multiple hops, route additions (and all other forces messages) must use an existing RFC2914 L4 transport. (charter requirement) For #1, TCP is satisfactory in unicast. In multicast, it will be necessary to add some sort of CRC to packets, or use an existing reliable multicast protocol. For #2, TCP is satisfactory in unicast. In multicast, sequence numbers will be necessary, or a reliable multicast transport protocol will need to be used. For #3, the same TCP connection can be used in unicast. In multicast, either the same multicast connection is used (this results in every FE seeing every other FE's ack - yuck!) or a separate TCP connection must be maintained by the FE to the CE. The multicast ack case does not sound that horrible to me, but there _will_ have to be (some kind of) connections FE-CE anyway, - most messages are still not multicast. The bottom line is, no base protocol in this world can fulfil this requirement, the acks have to be sent user-to-user, and we are back to the "ack storm" scenario. For #4, either the protocol or its payload probably needs a LFB identifier in the unicast case. In the multicast case, it will be necessary to come up with some sort of binding protocol, where LFBs are dynamically associated at runtime with multicast groups. For #5, in the unicast case, a single message could contain transaction information and a set of sub-messages. In the multicast case I cannot off the top of my head come up with a mechanism to even support transactioning. Why is this different ? Each FE receiving the multicast with bundled sub-messages performs defines a local transaction and reports the result back to the sender. It may be tricky, but not different from the TCP based dito. For #6, in the unicast case, TCP is satisfactory. In the multicast case, a 2914 compliant multicast-based standard protocol would be needed. Are there existing, standard, robust implementations of a 2914 compliant multicast protocol available in the operating systems commonly used in CEs and FEs? In my (technical - chair hat still off) opinion, all of the above requirements have to be met for any solution (multicast or unicast) to be feasible. I can understand how the above are satisfied by unicast, and would like to understand better how the above can be satisfied when using multicast. Thanks, David --------------080507010003030406090906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit /jon

Putzolu, David wrote:
[chair hat off]
Jamal Hadi Salim wrote>
Joel Halpern wrote> >
  
Even when the forwarding table is disjoint from the next hop
table (a good idea in its own right) there are many uses of
a "forwarding table LFB" which will not be populated with the
same information.
      
I think thats a detail which belongs to the model.  There will be
different types of IPV4 LFBs - some requiring the clear
demarcation you make.
    

I'm not sure I follow here.  The justification for the added
complexity of multicast is that it will save bandwidth.  Evaluating
some realistic examples of saved bandwidth seems to me to
be an important part of the discussion rather than just a detail!

Aside from the issue of performance, there is also the question
of feasibility.  Whether unicast or multicast is used, the following
requirements must be met when downloading FIB entries:

1 Data must not be corrupted in transit.
2 Data must not be reordered in transit.
3 Once delivered to the FE, the success or failure of a route
  addition attempt must be explicitly acknowledged.
4 There must be a way for the FE to know which LFB the
  route pertains to (FE will have many LFBs, and may even
  have multiple forwarding LFBs).
5 Route additions may sometimes be part of a larger transaction
  on a FE (e.g. "Add this prefix entry to LFB1, AND add this
  nexthop entry to LFB2, and use all or nothing semantics.")
6 When used over multiple hops, route additions (and all
  other forces messages) must use an existing RFC2914 L4 transport.
  (charter requirement)

For #1, TCP is satisfactory in unicast. In multicast,
it will be necessary to add some sort of CRC to packets,
or use an existing reliable multicast protocol.

For #2, TCP is satisfactory in unicast. In multicast,
sequence numbers will be necessary, or a reliable
multicast transport protocol will need to be used.

For #3, the same TCP connection can be used in unicast. In
multicast, either the same multicast connection is used
(this results in every FE seeing every other FE's ack - yuck!)
or a separate TCP connection must be maintained by the FE to
the CE.
The multicast ack case does not sound that horrible to me, but there
_will_ have to be (some kind of) connections FE-CE anyway, - most
messages are still not multicast. The bottom line is, no base protocol
in this world can fulfil this requirement, the acks have to be sent
user-to-user, and we are back to the "ack storm" scenario.

For #4, either the protocol or its payload probably needs a
LFB identifier in the unicast case.  In the multicast case,
it will be necessary to come up with some sort of binding
protocol, where LFBs are dynamically associated at runtime
with multicast groups.

For #5, in the unicast case, a single message could contain
transaction information and a set of sub-messages.  In the
multicast case I cannot off the top of my head come up with
a mechanism to even support transactioning.
Why is this different ? Each FE receiving the multicast with bundled
sub-messages performs defines a local transaction and reports the
result back to the sender. It may be tricky, but not different from the
TCP based dito.

For #6, in the unicast case, TCP is satisfactory.  In the
multicast case, a 2914 compliant multicast-based standard
protocol would be needed.  Are there existing, standard,
robust implementations of a 2914 compliant multicast protocol
available in the operating systems commonly used in CEs and FEs?

In my (technical - chair hat still off) opinion, all of the
above requirements have to be met for any solution (multicast
or unicast) to be feasible.  I can understand how the above
are satisfied by unicast, and would like to understand better
how the above can be satisfied when using multicast.

Thanks,
David

--------------080507010003030406090906-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 15:58:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29645 for ; Fri, 21 Nov 2003 15:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHaF-00005q-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:08:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANHaF-00005f-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:08:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C520CE@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 15:08:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61490761 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:08:49 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 15:08:49 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hALK98qc031385 for ; Fri, 21 Nov 2003 20:09:08 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hALK2rN23035 for ; Fri, 21 Nov 2003 20:02:53 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112112044017677 for ; Fri, 21 Nov 2003 12:04:41 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Nov 2003 12:04:33 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOvgVDRdKTNNplrSpysep6Elz6AYwAvqGXg X-OriginalArrivalTime: 21 Nov 2003 20:04:33.0119 (UTC) FILETIME=[AE2506F0:01C3B06A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> Date: Fri, 21 Nov 2003 12:04:32 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat off] Jamal Hadi Salim wrote> > I dont think it is a startup challenge issue only. The=20 > challenge applies > to all applications that build state based on packet arrival=20 > events. And there are many. > Think of an IDS under a DOS. Or a flow tracking firewall system. > 100s of FEs, millions of flows (say a 100K new ones per second). > You certainly wanna distribute that info to the FEs. > Unless you wanna rule out such apps for ForCES. IDS and flow tracking firewall is a specialized and challenging application, and firewalls and load balancers are often architected differently from routers - is the CE:FE protocol in the=20 ForCES architecture the right solution for such an app? =20 Tracking flow state in a coherent fashion across blades can require updating state as often as once/packet in each flow. Using ForCES, that would require an event to the CE, followed by the CE creating and broadcasting a flow update message to every FE - all occurring every time a TCP SYN, SYNACK, or FIN (at least) is received. Wouldn't a FE:FE protocol be a much better fit for this class of applications? Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 15:59:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02128 for ; Fri, 21 Nov 2003 15:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANINX-0000gz-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:59:47 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANINX-0000gt-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 15:59:47 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C52234@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 15:59:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61495127 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:59:45 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 15:59:45 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 1C3301F00F2 for ; Fri, 21 Nov 2003 15:59:45 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id A19B31F00EF for ; Fri, 21 Nov 2003 15:59:40 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-8.2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3FBE7CB9.C67CDC2E@idt.com> Date: Fri, 21 Nov 2003 15:59:37 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Putzolu, David" wrote: > Tracking flow state in a coherent fashion across blades can require > updating state as often as once/packet in each flow. Using ForCES, > that would require an event to the CE, followed by the > CE creating and broadcasting a flow update message > to every FE - all occurring every time a TCP SYN, SYNACK, > or FIN (at least) is received. Wouldn't a FE:FE protocol > be a much better fit for this class of applications? In many cases, yes. In addition, FE's may have self-programming abilities, to keep track of flows, because it's very easy to do. In contrast, IDS updates occur much less often. One of the problems I've seen is that people confuse flow management with IDS or packet filter rules. They're orthogonal, and shouldn't be discussed at the same time. e.g. "We support 1000 IDS rules, and 100,000 flows, so that means we support 100,000,000 rules!" Such statements are marketing propoganda. The two data sets are independent, and cannot be combined, or compared. No one would claim that a router supports 100,000,000 ACL rules, because it allows 1000 ACL's to be applied to 100,000 flows. IDS and packet filter rules are the application of a small set of complex rules to a large number of packets. TCP flow management is the application of a large set of simple rules to a large number of packets. The confusion arises because many IDS rules are only useful when applied across packet boundaries (i.e. to flows, not individual packets). This means keeping track of flows, and the sub-part of the IDS rule that should be used to filter the current packet. But it does NOT mean creating a new "IDS rule" for every flow. So to bring the subject back to the original topic, I don't see IDS rules or packet filter rules being subject to high update rates: seconds per update. I do see packet flow management requiring high update rates: thousands to millions of updates per second. Are there use cases which *require* inter-FE or CE-FE communication for flow management? Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 16:50:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04823 for ; Fri, 21 Nov 2003 16:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJBF-0001cH-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 16:51:09 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANJBE-0001bi-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 16:51:08 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C5221B@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 16:50:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61500472 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 16:50:46 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 16:50:46 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hALLpO7w023789 for ; Fri, 21 Nov 2003 21:51:24 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hALLf1u18560 for ; Fri, 21 Nov 2003 21:41:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112113504104091 for ; Fri, 21 Nov 2003 13:50:41 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Nov 2003 13:50:40 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOwcH7BpUJhMWRZTJqSCJWicf3CUgAA+z9w X-OriginalArrivalTime: 21 Nov 2003 21:50:40.0882 (UTC) FILETIME=[81A08D20:01C3B079] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Date: Fri, 21 Nov 2003 13:50:40 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Jon Maloy wrote> David Putzolu wrote> > > > For #3, the same TCP connection can be used in unicast. In > > multicast, either the same multicast connection is used > > (this results in every FE seeing every other FE's ack - yuck!) > > or a separate TCP connection must be maintained by the FE to > > the CE. > The multicast ack case does not sound that horrible to me, but there > _will_ have to be (some kind of) connections FE-CE anyway, - most > messages are still not multicast. The bottom line is, no base protocol > in this world can fulfil this requirement, the acks have to be sent=20 > user-to-user, and we are back to the "ack storm" scenario. Hi Jon. I agree that the CE will see a lot of acks (as many as there are FEs) in this scenario whether unicast or multicast is used - it is unavoidable (and is actually the desired behavior - the CE wants to know that every FE received and successfully=20 processed the FIB update). I was more worried about what the FEs would see. In particular, I believe that if the same mcast grp is used for CE->FE *and* the=20 response FE->CE ACK, the difference is that not only will the CE=20 see N ACKs (desired behavior), but each FE would also see the=20 N-1 acks from all the other FEs as well (not desirable). FEs=20 are assumed to be fairly dumb boxes, and inundating them with=20 ACKs from other FEs to process (at least far enough to know to=20 discard them) precisely at the time of arrival of a route update=20 would be a bad thing. The only solution I saw to this is to use multicast in CE->FE communication, and unicast in FE->CE communication - this "shields" the other FEs from having to listen to (and at least partially parse) each other ACKing. One could use probabilistic ACKing, but I don't think any operator would be comfortable knowing that one or more of their line cards may have failed to add a route until the next time they add a route. > > For #5, in the unicast case, a single message could contain > > transaction information and a set of sub-messages. In the > > multicast case I cannot off the top of my head come up with > > a mechanism to even support transactioning. > Why is this different ? Each FE receiving the multicast with bundled > sub-messages performs defines a local transaction and reports the > result back to the sender. It may be tricky, but not different from the > TCP based dito. I was assuming a unicast approach something like the following (using an XML-like notation for simplicity, the wire=20 representation would likely be different): 138 // A nonce indifying the xaction // Start of a command to a LFB 17 // Indicates what LFB this command targets // in this case the IPv4 FIB LFB // This is a prefix add command, for FIB LFB 158.0.0.0 8 ... // End of the first command in the transaction 23 // Some other LFB that we want to be atomically // updated with the FIB update above ... // Body of the second command. ... // More commands // End of the transaction Upon receiving the above via unicast, a FE would manipulate=20 LFB 17 with the prefix add, LFB 32 with whatever command=20 was applied to it, etc., using all-or-nothing semantics. =20 Because the command is unicast to the FE, the LFB identifiers used in the transaction indicate what particular=20 LFBs to do the all-or-nothing semantics with. In the multicast case, I assume each FE would have a different set of IDs for the LFBs (perhaps the IPv4 FIB LFB would be #17 on FE#1, but would be #12 on FE#2. So just multicasting the above=20 message would not make any sense. In the non-transactioned case, I assume the mcast group tells the FE what LFB to deliver a message to. One could try to reuse that mechanism, but that requires either that one know a priori all possible combinations of LFBs across FEs that might be transactioned together (to allocate necessary groups in pre- association time), or one could just brute force it, allocating enough multicast groups to cover all cases (but that would cause a factorial explosion so isn't feasible). So the conclusion I came to was that for using multicast to carry transactions one would have to either assume that every=20 FE had the identical set of LFBs being addressed, in terms of transaction ID, data being pushed down, and LFB instance IDs, every time a transaction is used. This is of course in addition to requiring proper ordering & non-corruption of packets. I suspect that making the above assumption is not safe - different LFBs are likely to be addressed in each FE (either different instance IDs of the same type, or different types). Different data per FE (LFB instance IDs, transaction IDs) takes away the=20 benefit of multicast, which primarily holds when data is the=20 same for all receivers. -David From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 17:45:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09454 for ; Fri, 21 Nov 2003 17:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANK1q-0003Nm-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 17:45:30 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANK1p-0003Nj-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 17:45:29 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C52479@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 17:45:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61504902 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 17:45:28 -0500 Received: from 69.50.194.230 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 17:45:28 -0500 Received: from pool-138-88-199-187.res.east.verizon.net ([138.88.199.187] helo=monsoonrain.net) by server34.totalchoicehosting.com with asmtp (Exim 4.24) id 1ANK1j-0006ws-4M for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 15:45:23 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031106 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> <3FBE7CB9.C67CDC2E@idt.com> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server34.totalchoicehosting.com X-AntiAbuse: Original Domain - peach.ease.lsoft.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - monsoonrain.net Approved-By: Niranjan Vaidya Message-ID: <3FBE9584.7050300@monsoonrain.net> Date: Fri, 21 Nov 2003 17:45:24 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Niranjan Vaidya Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FBE7CB9.C67CDC2E@idt.com> Precedence: list Content-Transfer-Encoding: 7bit ["Putzolu, David" wrote:] > >>Tracking flow state in a coherent fashion across blades can require >>updating state as often as once/packet in each flow. Using ForCES, >>that would require an event to the CE, followed by the >>CE creating and broadcasting a flow update message >>to every FE - all occurring every time a TCP SYN, SYNACK, >>or FIN (at least) is received. Wouldn't a FE:FE protocol >>be a much better fit for this class of applications? > ["Alan DeKok" wrote:] > Are there use cases which *require* inter-FE or CE-FE communication > for flow management? > > Alan DeKok. > Consider a scenario where one FE is a hot standby for another and needs to maintain up-to-date state for a flow (or session or SA) in order to enable a hitless switchover. In many products today, this is enabled via a vendor proprietary solution. Is there interest in covering it under Forces? An argument in favor would be that each FE must implement Forces and from a vendor's perspective, FE-FE communication would be simplified by using pre-existing building blocks already defined for CE-FE communication. Regards, Niranjan From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 18:05:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10558 for ; Fri, 21 Nov 2003 18:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKLj-0003l4-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 18:06:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANKLi-0003l1-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 18:06:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C525DB@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 18:06:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61507084 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 18:06:00 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 18:06:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOvf8sjrxQWMNNsQIu8W84rJ2gHRQAwbl1AABB4hTo= Approved-By: Tal Anker Message-ID: Date: Sat, 22 Nov 2003 01:06:10 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SnVzdCBvbmUgY29tbWVudCBvbiB0aGUgdGV4dCBiZWxvdy4uLg0KSSB3b3VsZCBhZGQgb24gdGhl IGp1c3RpZmljYXRpb24gb2YgdXNpbmcgbXVsdGljYXN0LCB0aGF0IGFzIG9wcG9zZSB0byB0aGUg bWVyaXRzIG9uIHVzaW5nIG11bHRpY2FzdCBpbiB0aGUgSW50ZXJuZXQgKEJXIHNhdmluZywgZXRj KSBpbiB0aGUgc2NvcGUgb2YgZm9yY2VzIEkgd291bGQgc2F5IHRoYXQgc2F2aW5nIHRoZSBDRSBj cHUgcmVzb3VyY2VzIGlzIGV2ZW4gbW9yZSBpbXBvcnRhbnQuLi4gSS5lLiwgaW5zdGVhZCBvZiBo YXZpbmcgdG8gc2VuZCBhIHRyYW5zYWN0aW9uIChjb21tYW5kKSBvbiBtdWx0aXBsZSBjb25uZWN0 aW9ucywgdGhlIENFIGNwdSBjYW4gc2VuZCBhIHNpbmdsZSBwYWNrZXQuLi4gdGhlcmUgaXMgYSBn b29kIGNoYW5jZSB0aGF0IGV2ZW4gZmFzdC1ldGhlcm5ldCB1c2VkIGFzIGhlIE5FICJiYWNrcGxh bmUiIHdvdWxkIGJlIGVub3VnaCBpbiB0ZXJtcyBvZiBiYW5kd2lkdGgsIHdoaWxlIHRoZSBDUFUg cHJvY2Vzc2luZyBwb3dlciBtYXkgYmUgYSBib3R0bGVuZWNrLi4uDQogDQotIFRhbA0KDQoJLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogUHV0em9sdSwgRGF2aWQgW21haWx0bzpk YXZpZC5wdXR6b2x1QGludGVsLmNvbV0gDQoJU2VudDogRnJpIDExLzIxLzIwMDMgMTA6MDQgUE0g DQoJVG86IEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTSANCglDYzogDQoJU3ViamVjdDogUmU6 IFN1cHBvcnQgZm9yIG11bHRpY2FzdCBpbiB0aGUgRm9yQ0VTIHByb3RvY29sDQoJDQoJDQoNCglb Y2hhaXIgaGF0IG9mZl0NCglKYW1hbCBIYWRpIFNhbGltIHdyb3RlPg0KCUpvZWwgSGFscGVybiB3 cm90ZT4gPg0KCT4gPiBFdmVuIHdoZW4gdGhlIGZvcndhcmRpbmcgdGFibGUgaXMgZGlzam9pbnQg ZnJvbSB0aGUgbmV4dCBob3ANCgk+ID4gdGFibGUgKGEgZ29vZCBpZGVhIGluIGl0cyBvd24gcmln aHQpIHRoZXJlIGFyZSBtYW55IHVzZXMgb2YNCgk+ID4gYSAiZm9yd2FyZGluZyB0YWJsZSBMRkIi IHdoaWNoIHdpbGwgbm90IGJlIHBvcHVsYXRlZCB3aXRoIHRoZQ0KCT4gPiBzYW1lIGluZm9ybWF0 aW9uLg0KCT4NCgk+IEkgdGhpbmsgdGhhdHMgYSBkZXRhaWwgd2hpY2ggYmVsb25ncyB0byB0aGUg bW9kZWwuICBUaGVyZSB3aWxsIGJlDQoJPiBkaWZmZXJlbnQgdHlwZXMgb2YgSVBWNCBMRkJzIC0g c29tZSByZXF1aXJpbmcgdGhlIGNsZWFyDQoJPiBkZW1hcmNhdGlvbiB5b3UgbWFrZS4NCgkNCglJ J20gbm90IHN1cmUgSSBmb2xsb3cgaGVyZS4gIFRoZSBqdXN0aWZpY2F0aW9uIGZvciB0aGUgYWRk ZWQNCgljb21wbGV4aXR5IG9mIG11bHRpY2FzdCBpcyB0aGF0IGl0IHdpbGwgc2F2ZSBiYW5kd2lk dGguICBFdmFsdWF0aW5nDQoJc29tZSByZWFsaXN0aWMgZXhhbXBsZXMgb2Ygc2F2ZWQgYmFuZHdp ZHRoIHNlZW1zIHRvIG1lIHRvDQoJYmUgYW4gaW1wb3J0YW50IHBhcnQgb2YgdGhlIGRpc2N1c3Np b24gcmF0aGVyIHRoYW4ganVzdCBhIGRldGFpbCENCgkNCglBc2lkZSBmcm9tIHRoZSBpc3N1ZSBv ZiBwZXJmb3JtYW5jZSwgdGhlcmUgaXMgYWxzbyB0aGUgcXVlc3Rpb24NCglvZiBmZWFzaWJpbGl0 eS4gIFdoZXRoZXIgdW5pY2FzdCBvciBtdWx0aWNhc3QgaXMgdXNlZCwgdGhlIGZvbGxvd2luZw0K CXJlcXVpcmVtZW50cyBtdXN0IGJlIG1ldCB3aGVuIGRvd25sb2FkaW5nIEZJQiBlbnRyaWVzOg0K CQ0KCTEgRGF0YSBtdXN0IG5vdCBiZSBjb3JydXB0ZWQgaW4gdHJhbnNpdC4NCgkyIERhdGEgbXVz dCBub3QgYmUgcmVvcmRlcmVkIGluIHRyYW5zaXQuDQoJMyBPbmNlIGRlbGl2ZXJlZCB0byB0aGUg RkUsIHRoZSBzdWNjZXNzIG9yIGZhaWx1cmUgb2YgYSByb3V0ZQ0KCSAgYWRkaXRpb24gYXR0ZW1w dCBtdXN0IGJlIGV4cGxpY2l0bHkgYWNrbm93bGVkZ2VkLg0KCTQgVGhlcmUgbXVzdCBiZSBhIHdh eSBmb3IgdGhlIEZFIHRvIGtub3cgd2hpY2ggTEZCIHRoZQ0KCSAgcm91dGUgcGVydGFpbnMgdG8g KEZFIHdpbGwgaGF2ZSBtYW55IExGQnMsIGFuZCBtYXkgZXZlbg0KCSAgaGF2ZSBtdWx0aXBsZSBm b3J3YXJkaW5nIExGQnMpLg0KCTUgUm91dGUgYWRkaXRpb25zIG1heSBzb21ldGltZXMgYmUgcGFy dCBvZiBhIGxhcmdlciB0cmFuc2FjdGlvbg0KCSAgb24gYSBGRSAoZS5nLiAiQWRkIHRoaXMgcHJl Zml4IGVudHJ5IHRvIExGQjEsIEFORCBhZGQgdGhpcw0KCSAgbmV4dGhvcCBlbnRyeSB0byBMRkIy LCBhbmQgdXNlIGFsbCBvciBub3RoaW5nIHNlbWFudGljcy4iKQ0KCTYgV2hlbiB1c2VkIG92ZXIg bXVsdGlwbGUgaG9wcywgcm91dGUgYWRkaXRpb25zIChhbmQgYWxsDQoJICBvdGhlciBmb3JjZXMg bWVzc2FnZXMpIG11c3QgdXNlIGFuIGV4aXN0aW5nIFJGQzI5MTQgTDQgdHJhbnNwb3J0Lg0KCSAg KGNoYXJ0ZXIgcmVxdWlyZW1lbnQpDQoJDQoJRm9yICMxLCBUQ1AgaXMgc2F0aXNmYWN0b3J5IGlu IHVuaWNhc3QuIEluIG11bHRpY2FzdCwNCglpdCB3aWxsIGJlIG5lY2Vzc2FyeSB0byBhZGQgc29t ZSBzb3J0IG9mIENSQyB0byBwYWNrZXRzLA0KCW9yIHVzZSBhbiBleGlzdGluZyByZWxpYWJsZSBt dWx0aWNhc3QgcHJvdG9jb2wuDQoJDQoJRm9yICMyLCBUQ1AgaXMgc2F0aXNmYWN0b3J5IGluIHVu aWNhc3QuIEluIG11bHRpY2FzdCwNCglzZXF1ZW5jZSBudW1iZXJzIHdpbGwgYmUgbmVjZXNzYXJ5 LCBvciBhIHJlbGlhYmxlDQoJbXVsdGljYXN0IHRyYW5zcG9ydCBwcm90b2NvbCB3aWxsIG5lZWQg dG8gYmUgdXNlZC4NCgkNCglGb3IgIzMsIHRoZSBzYW1lIFRDUCBjb25uZWN0aW9uIGNhbiBiZSB1 c2VkIGluIHVuaWNhc3QuIEluDQoJbXVsdGljYXN0LCBlaXRoZXIgdGhlIHNhbWUgbXVsdGljYXN0 IGNvbm5lY3Rpb24gaXMgdXNlZA0KCSh0aGlzIHJlc3VsdHMgaW4gZXZlcnkgRkUgc2VlaW5nIGV2 ZXJ5IG90aGVyIEZFJ3MgYWNrIC0geXVjayEpDQoJb3IgYSBzZXBhcmF0ZSBUQ1AgY29ubmVjdGlv biBtdXN0IGJlIG1haW50YWluZWQgYnkgdGhlIEZFIHRvDQoJdGhlIENFLg0KCQ0KCUZvciAjNCwg ZWl0aGVyIHRoZSBwcm90b2NvbCBvciBpdHMgcGF5bG9hZCBwcm9iYWJseSBuZWVkcyBhDQoJTEZC IGlkZW50aWZpZXIgaW4gdGhlIHVuaWNhc3QgY2FzZS4gIEluIHRoZSBtdWx0aWNhc3QgY2FzZSwN CglpdCB3aWxsIGJlIG5lY2Vzc2FyeSB0byBjb21lIHVwIHdpdGggc29tZSBzb3J0IG9mIGJpbmRp bmcNCglwcm90b2NvbCwgd2hlcmUgTEZCcyBhcmUgZHluYW1pY2FsbHkgYXNzb2NpYXRlZCBhdCBy dW50aW1lDQoJd2l0aCBtdWx0aWNhc3QgZ3JvdXBzLg0KCQ0KCUZvciAjNSwgaW4gdGhlIHVuaWNh c3QgY2FzZSwgYSBzaW5nbGUgbWVzc2FnZSBjb3VsZCBjb250YWluDQoJdHJhbnNhY3Rpb24gaW5m b3JtYXRpb24gYW5kIGEgc2V0IG9mIHN1Yi1tZXNzYWdlcy4gIEluIHRoZQ0KCW11bHRpY2FzdCBj YXNlIEkgY2Fubm90IG9mZiB0aGUgdG9wIG9mIG15IGhlYWQgY29tZSB1cCB3aXRoDQoJYSBtZWNo YW5pc20gdG8gZXZlbiBzdXBwb3J0IHRyYW5zYWN0aW9uaW5nLg0KCQ0KCUZvciAjNiwgaW4gdGhl IHVuaWNhc3QgY2FzZSwgVENQIGlzIHNhdGlzZmFjdG9yeS4gIEluIHRoZQ0KCW11bHRpY2FzdCBj YXNlLCBhIDI5MTQgY29tcGxpYW50IG11bHRpY2FzdC1iYXNlZCBzdGFuZGFyZA0KCXByb3RvY29s IHdvdWxkIGJlIG5lZWRlZC4gIEFyZSB0aGVyZSBleGlzdGluZywgc3RhbmRhcmQsDQoJcm9idXN0 IGltcGxlbWVudGF0aW9ucyBvZiBhIDI5MTQgY29tcGxpYW50IG11bHRpY2FzdCBwcm90b2NvbA0K CWF2YWlsYWJsZSBpbiB0aGUgb3BlcmF0aW5nIHN5c3RlbXMgY29tbW9ubHkgdXNlZCBpbiBDRXMg YW5kIEZFcz8NCgkNCglJbiBteSAodGVjaG5pY2FsIC0gY2hhaXIgaGF0IHN0aWxsIG9mZikgb3Bp bmlvbiwgYWxsIG9mIHRoZQ0KCWFib3ZlIHJlcXVpcmVtZW50cyBoYXZlIHRvIGJlIG1ldCBmb3Ig YW55IHNvbHV0aW9uIChtdWx0aWNhc3QNCglvciB1bmljYXN0KSB0byBiZSBmZWFzaWJsZS4gIEkg Y2FuIHVuZGVyc3RhbmQgaG93IHRoZSBhYm92ZQ0KCWFyZSBzYXRpc2ZpZWQgYnkgdW5pY2FzdCwg YW5kIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBiZXR0ZXINCglob3cgdGhlIGFib3ZlIGNhbiBi ZSBzYXRpc2ZpZWQgd2hlbiB1c2luZyBtdWx0aWNhc3QuDQoJDQoJVGhhbmtzLA0KCURhdmlkDQoJ DQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 18:12:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11277 for ; Fri, 21 Nov 2003 18:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKSV-0003nr-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 18:13:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANKSU-0003no-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 18:13:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C52754@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 18:13:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61507517 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 18:13:01 -0500 Received: from 141.211.144.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 18:13:00 -0500 Received: (from www@localhost) by muskogee.web.itd.umich.edu (8.12.9/8.12.9) id hALND0VO030929 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 18:13:00 -0500 X-Authentication-Warning: muskogee.web.itd.umich.edu: www set sender to sgoswami@umich.edu using -f Received: from 206-176-229-202.vbbn.com (206-176-229-202.vbbn.com [206.176.229.202]) by carrierpigeon.mail.umich.edu (IMP) with HTTP for ; Fri, 21 Nov 2003 18:13:00 -0500 References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-IMP-Server: carrierpigeon.mail.umich.edu X-Originating-IP: 206.176.229.202 X-Originating-User: sgoswami Approved-By: sgoswami@UMICH.EDU Message-ID: <1069456380.3fbe9bfc8b91c@carrierpigeon.mail.umich.edu> Date: Fri, 21 Nov 2003 18:13:00 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Subrata Goswami Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 8bit See in-line Quoting Tal Anker : > Just one comment on the text below... > I would add on the justification of using multicast, that as oppose to the > merits on using multicast in the Internet (BW saving, etc) in the scope of > forces I would say that saving the CE cpu resources is even more important... > I.e., instead of having to send a transaction (command) on multiple > connections, the CE cpu can send a single packet... there is a good chance > that even fast-ethernet used as he NE "backplane" would be enough in terms of > bandwidth, while the CPU processing power may be a bottleneck... > > - Tal Good point. On the flip side, the FE CPU(?) would have to spend more cycles to go through all the mcast packets and filtering the ones it needs. Subrata > > -----Original Message----- > From: Putzolu, David [mailto:david.putzolu@intel.com] > Sent: Fri 11/21/2003 10:04 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Cc: > Subject: Re: Support for multicast in the ForCES protocol > > > > [chair hat off] > Jamal Hadi Salim wrote> > Joel Halpern wrote> > > > > Even when the forwarding table is disjoint from the next hop > > > table (a good idea in its own right) there are many uses of > > > a "forwarding table LFB" which will not be populated with the > > > same information. > > > > I think thats a detail which belongs to the model. There will be > > different types of IPV4 LFBs - some requiring the clear > > demarcation you make. > > I'm not sure I follow here. The justification for the added > complexity of multicast is that it will save bandwidth. Evaluating > some realistic examples of saved bandwidth seems to me to > be an important part of the discussion rather than just a detail! > > Aside from the issue of performance, there is also the question > of feasibility. Whether unicast or multicast is used, the following > requirements must be met when downloading FIB entries: > > 1 Data must not be corrupted in transit. > 2 Data must not be reordered in transit. > 3 Once delivered to the FE, the success or failure of a route > addition attempt must be explicitly acknowledged. > 4 There must be a way for the FE to know which LFB the > route pertains to (FE will have many LFBs, and may even > have multiple forwarding LFBs). > 5 Route additions may sometimes be part of a larger transaction > on a FE (e.g. "Add this prefix entry to LFB1, AND add this > nexthop entry to LFB2, and use all or nothing semantics.") > 6 When used over multiple hops, route additions (and all > other forces messages) must use an existing RFC2914 L4 transport. > (charter requirement) > > For #1, TCP is satisfactory in unicast. In multicast, > it will be necessary to add some sort of CRC to packets, > or use an existing reliable multicast protocol. > > For #2, TCP is satisfactory in unicast. In multicast, > sequence numbers will be necessary, or a reliable > multicast transport protocol will need to be used. > > For #3, the same TCP connection can be used in unicast. In > multicast, either the same multicast connection is used > (this results in every FE seeing every other FE's ack - yuck!) > or a separate TCP connection must be maintained by the FE to > the CE. > > For #4, either the protocol or its payload probably needs a > LFB identifier in the unicast case. In the multicast case, > it will be necessary to come up with some sort of binding > protocol, where LFBs are dynamically associated at runtime > with multicast groups. > > For #5, in the unicast case, a single message could contain > transaction information and a set of sub-messages. In the > multicast case I cannot off the top of my head come up with > a mechanism to even support transactioning. > > For #6, in the unicast case, TCP is satisfactory. In the > multicast case, a 2914 compliant multicast-based standard > protocol would be needed. Are there existing, standard, > robust implementations of a 2914 compliant multicast protocol > available in the operating systems commonly used in CEs and FEs? > > In my (technical - chair hat still off) opinion, all of the > above requirements have to be met for any solution (multicast > or unicast) to be feasible. I can understand how the above > are satisfied by unicast, and would like to understand better > how the above can be satisfied when using multicast. > > Thanks, > David > > > Subrata Goswami, Ph.D. From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 23:41:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19666 for ; Fri, 21 Nov 2003 23:41:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANPaZ-0007YI-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 23:41:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANPaY-0007YF-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 23:41:42 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C52C93@cherry.ease.lsoft.com>; Fri, 21 Nov 2003 23:41:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61530378 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 23:41:39 -0500 Received: from 218.108.250.186 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 23:41:38 -0500 Received: from wwm1([218.108.152.81]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm1c3fbf3fb0; Sat, 22 Nov 2003 12:37:53 +0800 References: <5.1.0.14.0.20031119232704.018bfeb0@localhost> <3FBC9FF7.4080608@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <008801c3b0b2$a8a50480$7b19fea9@wwm1> Date: Sat, 22 Nov 2003 12:38:46 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Support for multicast in the ForCES protocol Comments: cc: wmwang@mail.hzic.edu.cn To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpJIHJlbWVtYmVyIHdlJ3YgIGhhZCBhIHNob3J0IGRpc2N1c3Npb24gb24gdGhl IGJyb2FkY2FzdC9tdWx0aWNhc3QgaXNzdWUgaW4gTWlubi4NCkkgYWdyZWUgdGhhdCBpdCdzIG5v dCBqdXN0IGFzIHNpbXBsZSBhcyB0byBhcnJhbmdlIEZFIElEcywgYnV0IEkgc3RpbGwgdGhpbmsg dGhhdCB0aGUgbGVmdA0KaXMgaW4gdGhlIGVuY2Fwc3VsYXRpb24gc2NvcGUuICBNYXliZSB3ZSBu ZWVkIGEgc3BlY2lmaWMgZGVmaW5pdGlvbiBkb2N1bWVudCBmb3IgdGhpcw0KIHNjb3BlLiANCg0K IEkgYWxzbyBhcmd1ZSB0aGF0IHRoZSBob29rcyBpbiBGb3JDRVMgcHJvdG9jb2wgZm9yIHRoZSBt dWx0aWNhc3QgZW5jYXBzdWxhdGlvbg0Kc2hvdWxkIGJlIGxpbWl0ZWQgdG8gRkUgSURzIGluc3Rl YWQgb2YgTEZCIHR5cGVzLCBsZWF2aW5nIGxhdGVyIGFzIGhvb2tzIG9ubHkgaW5zaWRlIG9uZSBG RS4gDQpGb3IgSSdtIHN0aWxsIG5vdCBzdXJlIGhvdyBhbiBMRkIgdHlwZSBjYW4gYmUgdXNlZCBk aXJlY3RseSBhcyBob29rcyBmb3IgdGhlIG11bHRpY2FzdCwgaXQgc2VlbXMNCmEgbGl0dGxlIGNh c2Ugc3BlY2lmaWMuIE1heWJlIEkgbWlzcyBzb21ldGhpbmcuIA0KVGhhbmsgeW91Lg0KDQpXZWlt aW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUm9iZXJ0IEhhYXMi IDxyaGFAenVyaWNoLmlibS5jb20+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4N ClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMCwgMjAwMyA3OjA1IFBNDQpTdWJqZWN0OiBSZTog U3VwcG9ydCBmb3IgbXVsdGljYXN0IGluIHRoZSBGb3JDRVMgcHJvdG9jb2wNCg0KDQpKb2VsIE0u IEhhbHBlcm4gd3JvdGU6DQoNCj4gVGhpcyBpcyBvbmUgb2YgdGhlIGNvbXBsZXhpdGllcy4gIFdo aWxlIHRoZXJlIGlzIGEgbG90IG9mIHVzZWZ1bA0KPiBleHBlcmltZW50YWwgd29yayBvbiByZWxp YWJsZSBhbmQgc2VjdXJlZCBtdWx0aWNhc3QgdHJhbnNwb3J0LCBJIGRvIG5vdA0KPiBiZWxpZXZl IHRoYXQgdGhlcmUgaXMgYW55IGVuZ2luZWVyaW5nIGdyYWRlIHdvcmsgdGhhdCBhZGRyZXNzIGJv dGggdGhvc2UNCj4gcmVxdWlyZW1lbnRzLiAgQW5kIHdlIGFyZSBvYmxpZ2VkIHRvIG1lZXQgYm90 aCBvZiB0aG9zZSBuZWVkcy4NCj4gQW5kIGNvbXBhcmVkIHdpdGggVENQIC8gU0NUUCwgdGhlcmUg YXJlIG5vdCB3aWRlIHNwcmVhZCwgZWFzaWx5IA0KPiBhdmFpbGFibGUsDQo+IHdlbGwgd3J1bmcg b3V0IGltcGxlbWVudGF0aW9ucyBvZiB0aG9zZSBwcm90b2NvbHMuDQo+IEhlbmNlLCBwdXR0aW5n IGEgZGVwZW5kZW5jeSBvbiBzdWNoIHdvcmsgaW50byBGb3JDRVMgaW50cm9kdWNlcyANCj4gc2ln bmlmaWNhbnQNCj4gcmlzayBhbmQgY29tcGxleGl0eS4gDQoNCkkgZG9uJ3QgdGhpbmsgd2UgYXJl IHRhbGtpbmcgYWJvdXQgcHV0dGluZyBhIGRlcGVuZGVuY3kgb24gUk1UIGhlcmUuIA0KUmF0aGVy IHdlIGFyZSBlbnN1cmluZyB0aGF0IHRoZSBuZWNlc3NhcnkgaG9va3MgYXJlIGluIHRoZSBGb3JD RVMgDQpwcm90b2NvbCBzbyBpdCBjYW4gbWFrZSB1c2Ugb2Ygc29tZSBmb3JtIG9mIG11bHRpY2Fz dCB0cmFuc3BvcnQuDQoNCkFuZCB0byBkbyB0aGlzLCB3ZSBuZWVkIHRvIGhhdmUgc29tZSBmb3Jt IG9mIGdyb3VwIGFkZHJlc3NpbmcgYXQgdGhlIA0KRm9yQ0VTIHByb3RvY29sIGxldmVsLiBIYXZp bmcgc3BlbnQgc29tZSBjeWNsZXMgb24gdGhpcywgSSBjYW4gc2F5IGl0IA0KcmVxdWlyZXMgYSBi aXQgbW9yZSB0aGFuICJyZWFycmFuZ2luZyB0aGUgRkUgSUQgYml0cyB0byBoYXZlIHNvbWUgDQpn cm91cC1saWtlIG1lYW5pbmcgYWZ0ZXIgdGhlIEZvckNFUyBwcm90b2NvbCBoYXMgYWxyZWFkeSBi ZWVuIGRlc2lnbmVkIiANCihJIHRoaW5rIEkgaGVhcmQgc3RoIGFsb25nIHRoZXNlIGxpbmVzIG9u IHRoZSBsaXN0KS4NCg0KQ2hlZXJzLA0KLVJvYmVydA0KDQo+DQo+DQo+IFlvdXJzLA0KPiBKb2Vs IE0uIEhhbHBlcm4NCj4NCj4gQXQgMDE6NTIgQU0gMTEvMjAvMjAwMyArMDIwMCwgeW91IHdyb3Rl Og0KPg0KPj4gT25lIGxhc3QgaXNzdWUuLi4gdGhlIHNlbWFudGljcyBuZWVkZWQgZnJvbSB0aGUg dHJhbnNwb3J0IGxheWVyIA0KPj4gc2hvdWxkIGJlDQo+PiBjYXJlZnVsbHkgZGVmaW5lZCwgYXMg cmVndWxhciBtdWx0aWNhc3QgaXMgbm90IHJlbGlhYmxlLCBhbmQgSSBleHBlY3QgDQo+PiB0aGUN Cj4+IHByb3RvY29sIHRvIHJlbHkgb24gc29tZSByZWxpYWJsZSB0cmFuc3BvcnQgaW4gb3JkZXIg dG8ga25vdyB0aGUgQ0UtRkUNCj4+IHRyYW5zYWN0aW9uIGlzIGNvbW1pdGVkLi4uIHRoZSBSTVQg V0cgaGFkIGRlZmluZWQgdG9vbHMgZm9yIHJlbGlhYmxlDQo+PiBtdWx0aWNhc3QgdGhhdCBjYW4g YmUgZGVwbG95ZWQgaGVyZS4uLg0KPj4NCj4+IC0gVGFsDQo+DQo+DQo+DQoNCi0tIA0KUm9iZXJ0 IEhhYXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KU+R1bWVyc3RyYXNzZSA0DQpD SC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCnBob25lICs0MS0xLTcyNC04Njk4ICBmYXgg KzQxLTEtNzI0LTg1NzggIGh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYQ== From owner-forces@PEACH.EASE.LSOFT.COM Fri Nov 21 23:59:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20105 for ; Fri, 21 Nov 2003 23:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANPsF-0007kq-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 23:59:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANPsF-0007kn-00 for forces-archive@IETF.ORG; Fri, 21 Nov 2003 23:59:59 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C52D2A@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 0:00:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61531140 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Nov 2003 23:59:59 -0500 Received: from 218.108.250.186 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Nov 2003 23:59:58 -0500 Received: from wwm1([218.108.152.81]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm303fbf28e2; Sat, 22 Nov 2003 12:56:15 +0800 References: <5.1.0.14.0.20031119232704.018bfeb0@localhost> <3FBC9FF7.4080608@zurich.ibm.com> <008801c3b0b2$a8a50480$7b19fea9@wwm1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <00a301c3b0b5$45048880$7b19fea9@wwm1> Date: Sat, 22 Nov 2003 12:58:28 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: ID update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 IEhpLA0KDQpUaGUgZm9sbG93aW5nIGlzIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBHUk1QOg0KDQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLWZvcmNlcy1ncm1w LTAxLnR4dA0KDQpUaGUgbWFpbiBtb2RpZmljYXRpb24gaW4gdGhlIHVwZGF0ZSBpcyB0aGF0IHRo ZSBMRkIgdG9wb2xvZ3kgcmVwcmVzZW50YXRpb24gcGFydCBpcyBleGNsdWRlZCBmcm9tIHRoZQ0K ZG9jdW1lbnQsIGFuZCAgd2lsbCBiZSBtb3ZlZCB0byB0aGUgZHJhZnQgIlRvcG9sb2d5IHJlcHJl c2VudGF0aW9uIGZvciBGRSBtb2RlbCIgdGhhdA0Kd2lsbCBiZSB1cGRhdGVkIHNvb24uIFRoZSBw dXJwb3NlIGZvciB0aGlzIG1vZGlmaWNhdGlvbiBpcyB0aGF0IHRoZSBhdXRob3IocykgdGhpbmsg aXQgbW9yZSByZWFzb25hbGJlIHRvIA0KdG8gaGF2ZSBhbGwgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0 byBMRkIgdG9wb2xvZ3kgcmVwcmVzZW50YWlvbiBpbiB0aGUgRkUgbW9kZWwgc2NvcGUgaW5zdGVh ZCBvZiBpbiANCkZvckNFUyBwcm90b2NvbCBzY29wZSwgc28gdGhhdCB0aGUgbGF0ZXIgRm9yQ0VT IGRpc2N1c3Npb24gY2FuIGJlIG1vcmUgY29uY2VudHJhdGluZy4NCg0KQmVzdCByZWdhcmRzLA0K DQpXZWltaW5nDQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 13:02:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17591 for ; Sat, 22 Nov 2003 13:02:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANc5p-0000an-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANc5o-0000ak-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:48 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C53741@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 13:02:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61595153 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 13:02:47 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 13:02:47 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112207420740:6585 ; Sat, 22 Nov 2003 07:42:07 -0800 References: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 07:42:08 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 10:01:59 AM, Serialize complete at 11/22/2003 10:01:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069515768.1061.1849.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 10:42:48 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2003-11-21 at 15:04, Putzolu, David wrote: > [chair hat off] > Jamal Hadi Salim wrote> > > I dont think it is a startup challenge issue only. The > > challenge applies > > to all applications that build state based on packet arrival > > events. And there are many. > > Think of an IDS under a DOS. Or a flow tracking firewall system. > > 100s of FEs, millions of flows (say a 100K new ones per second). > > You certainly wanna distribute that info to the FEs. > > Unless you wanna rule out such apps for ForCES. > > IDS and flow tracking firewall is a specialized and challenging > application, Challenging is a good word ;-> > and firewalls and load balancers are often architected > differently from routers > > - is the CE:FE protocol in the > ForCES architecture the right solution for such an app? > I just gave those two as an example and i think they are valid. The general class of the problem is events that are caused by packet arrivals (or maybe even timers) that require distributed state updates. I know some routers(since it seems thats the operative word unfortunately) or router architectures that use LPM cache entries or adjacencies to speed up lookups (i.e you have a FIB which is considered the slow path and some form of cache as the fast path). Some people may have given up those architectures, they are however very useful IMO because they allow you to associate additional state to the simple FIB entry added either at the beggining of the FIB + (mostly)srcIP tuple being hit or adjacency being created. I dont want to sell their virtue or argue their value; suffice it is to say they exist. Now that i have used the operative word "router" - would those serve as good example? In regards to architectures being different: I think that boundaries are greying - in particular at the edges of the network. I havent seen a router(at least in my contact) in the last 2-3 years which didnt have some firewalling capability built in. In fact quiet a few that i have seen are also adding loadbalancing capability; pick a $10 router from foundry (not sure how commodity you wanted to get) and you will see what i am talking about. I suspect the trend is gonna head that way. And i suspect these devices are gonna scale even further by going into chasis and chasis going further into racks. Would you want these devices selling for $50 a chasis out of Taiwan be able to use Forces? I want them to. > Tracking flow state in a coherent fashion across blades can require > updating state as often as once/packet in each flow. Using ForCES, > that would require an event to the CE, followed by the > CE creating and broadcasting a flow update message > to every FE - all occurring every time a TCP SYN, SYNACK, > or FIN (at least) is received. Did you forget RST? ;-> just kidding. You would have to do a few smart things, but this is the wrong place to discuss that. > Wouldn't a FE:FE protocol > be a much better fit for this class of applications? If you are multicast capable, it doesnt matter: Use CE-FE events. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 13:02:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17628 for ; Sat, 22 Nov 2003 13:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANc5r-0000ay-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:51 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ANc5q-0000av-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by manatick with esmtp (Exim 4.24) id 1ANc5r-00019B-Cq for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00C5383F@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 13:02:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61595163 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 13:02:48 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 13:02:48 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112208291352:6619 ; Sat, 22 Nov 2003 08:29:13 -0800 References: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 08:29:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 10:02:01 AM, Serialize complete at 11/22/2003 10:02:01 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069518599.1056.1947.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 11:29:59 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Continuation of the last thread with a change in topic - i think these are the real issues that need to be addressed instead of the distraction to "multicast is evil". Lets really list the requirements needed for a successful underlying transport protocol that will serve ForCES well. i may be missing some - but i hope to get challenged so i can add to them; I am thinking of turning this into a draft so people read it first and then post. My previous email has some more claims which i will assume here. I. ForCES mechanisms requiring reliability: a) time limit very sensitive (in other words obsolence period is faster): Example table updates; I have argued TCP doesnt qualify in my previous email. SCTP-PR may qualify. Something like what netlink2 over UDP qualifies because it gives control to netlink2 to make such decisions. b) time limit best effort (obsolence takes longer) Sample apps: File transfers,etc. TCP qualifies but AFAIK, we dont have this need. II. mechanisms capable of tolerating unreliability: Example psamp. TCP doesnt qualify. something(like netlink2) over UDP or SCTP-PR. III. mechanisms that prefer timeliness over reliability: Ex heartbeats something (like netlink2) over UDP or SCTP-PR. Clearly in the bigger picture TCP is not the best protocol. UDP and SCTP-PR qualify partially merely because they dont hinder progress not because they have some magic. Another non-IETF protocol that would qualify is TIPC. I havent carefully studied DCCP but i believe it also has a fit. I will exclude it because its not there yet. So, to summarize: the transport protocol that meets all the requirements For Forces has not been born. Choosing TCP is choosing an answer and then trying to justify the questions that it brings. It does sound like peer pressure instead of looking at requirements and then deciding what you need to do. I think we recognized this in netlink2 and made it clear that the choice of underlying protocol chosen is up to the pre-association phase. We compensate for "missing features" depending on the transport choice (read the draft). It's very few lines of code to provide that luxury. So the cost is low. Now on the choice of netlink2 UDP vs SCTP-PR 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available Netlink2 can run over it. For now we choose to be standalone: We can run over IP, over UDP or over ethernet, you take your pick. 2) UDP provides multicast (and broadcast). SCTP-PR does not. Since SCTP has turned to be a swiss knife (or maybe a multi faceted beast), i am sure it will soon as well support multicast;-> If multicast is there - we will use it. Sans that we will do something multicast like (Jon calls it unireplicate i think). All the three cauthors have had pleasant experiences using multicast for ForCES like. We think it is a good thing to have. But we will not torture you if you dont have multicast or broadcast ;-> Why Multicast is useful: -- I must apologize since i have to repeat this. In the simple case of a single multicast wire: each of the CEs or FEs opens a single multicast socket/channel. Why is this good: 1) Bandwidth is less used a)because one or more CEs can send a single message to all FEs. I really dont want to be teaching people the hows but i will provide one example which David or maybe it was Joel didnt seem to make sense out of (but one that i have successfuly used)[1] b) you can reduce the number of packets further by limiting on ACKs (partial acks) 2) RAM on the embedded CE or FE is used less. There are less sockets open and less messages being built 3) CPU is preserved more. Since there are fewer messages to process and fewer (socket states) states to track. 4) The ability for all listeners on the wire to see message exchanges even when not directed at them provides a cheap way to synchronize. 5) At a transport level, (not the forces transaction level), having access to multicast provides location transparency. 6) A lot of switch fabrics (shared memory designs or otherwise) interconnecting FEs and CES have multicast capabilities; so it is good if we can take advantage of it where possible. The above is the simple case, by induction you could extend the reasoning to the case where you have X sockets. I dont want to preach multicast as panacea; we address some of the limitations in the draft; however, i want it to be available when i need it and not shoved down the toilet. So far apart from Joel (who implemented on ATM) on real boxes and Ram (who did something very specific that needs unicast) the rest of the arguements i have seen are from people who see the need for this feature. You can choose to ignore it - and you may be influenced by some implementation you are familiar with - thats your loss. I do think TCP is valid for some cases (low latency and congestion), but i wouldnt claim it to be the answer weve all been waiting for. Again let me reiterate that Netlink2 does not need to have multicast (it is a MAY) but would love to have it when it is available. We can run on your favorite protocol TCP ;-> cheers, jamal [1] I will give the example in another email - this one is already getting too long. From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 13:53:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17594 for ; Sat, 22 Nov 2003 13:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANc5p-0000as-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANc5p-0000ak-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 13:02:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C53753@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 13:02:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61595158 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 13:02:48 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 13:02:47 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112208101745:6606 ; Sat, 22 Nov 2003 08:10:17 -0800 References: <52D13A805349A249960B9943E5590BD80195EB79@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 08:10:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 10:02:00 AM, Serialize complete at 11/22/2003 10:02:00 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069517463.1056.1905.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 11:11:03 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD80195EB79@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2003-11-21 at 15:04, Putzolu, David wrote: > [chair hat off] > Jamal Hadi Salim wrote> > Joel Halpern wrote> > > > > Even when the forwarding table is disjoint from the next hop > > > table (a good idea in its own right) there are many uses of > > > a "forwarding table LFB" which will not be populated with the > > > same information. > > > > I think thats a detail which belongs to the model. There will be > > different types of IPV4 LFBs - some requiring the clear > > demarcation you make. > > I'm not sure I follow here. The justification for the added > complexity of multicast Lets hope we can clear this confusion Bear with me while i become as verbose as you or more - its saturday morning, cold outside - so plenty of time here. Maybe we can have an internet draft to capture all these issues which seem to have been beaten to death many times. > is that it will save bandwidth. And a few other things such as location transparency, ease of synchronizing state etc. > Evaluating > some realistic examples of saved bandwidth seems to me to > be an important part of the discussion rather than just a detail! > > Aside from the issue of performance, there is also the question > of feasibility. Whether unicast or multicast is used, the following > requirements must be met when downloading FIB entries: > > 1 Data must not be corrupted in transit. Sure. > 2 Data must not be reordered in transit. You compute at the transaction level, so this statement is a little misleading. In any case i would think in a ForCES environment (single chasis or within a rack with a few L2 Multihops) - the possibility of reordering is slim to non-existent. > 3 Once delivered to the FE, the success or failure of a route > addition attempt must be explicitly acknowledged. nod. > 4 There must be a way for the FE to know which LFB the > route pertains to (FE will have many LFBs, and may even > have multiple forwarding LFBs). A given. > 5 Route additions may sometimes be part of a larger transaction > on a FE (e.g. "Add this prefix entry to LFB1, AND add this > nexthop entry to LFB2, and use all or nothing semantics.") Lets call this a transaction. > 6 When used over multiple hops, route additions (and all > other forces messages) must use an existing RFC2914 L4 transport. > (charter requirement) The most important law to design is to review the requirements first and then throw terms around. Lets look at the scenario deployment environments for ForCES. 1) A private dedicated link from CE-FE, mostly within a single chasis but may cross chasis or racks. Essentially "the close proximity" situation. Mostly a single L3 setup or even single hop L2 in a network dedicated for this activity (switch fabric within a chasis or multi switch fabrics across chasis interconnected by some hierachical L2 switch). 2) The above in addition croses a private Lan. Maybe one or two L2 hops maybe one or two L3 hops. 3) In addition to crossing a private lan #2 croses the big bad internet. Many L3 hops. I claim #1 would be the most deployed environment. I can handwave this would be 90% of the deployments. I claim #2 would take 9.5% again using the handwaving clairvoyance. The rest would fall under #3 (It may be useful for remote office management, countering dDOS amongst participating sites etc). There will be competing protocols for #3 so you may never see ForCES deployed for such work. RFC2914 L4 protocols aka multihop is applicable for #3 mostly and #2 partially and for those scenarios it MUST be used. Using the "optimize for the most" design rules, there are other requirements which are more important than need to be met than simply invoking RFC2914. I personally dont care about people who throw cliches around - i prefer reasoning. Again i am not downplaying the need, i just think that in the most cases the term is abused. So lets kill this arguement please. [ A good parody for this is: http://inetpix.com/dare/ ] > For #1, TCP is satisfactory in unicast. In multicast, > it will be necessary to add some sort of CRC to packets, > or use an existing reliable multicast protocol. Take the pedagogical definition of reliability: 1) Message is delivered with integrity. This means the mesage is delivered identical to what was sent. Additionaly only _one_ copy is delivered. 2) A valid message is delivered. And in this portion a timeliness connotation comes in. The "valid" part infact defines a time limit where the message is considered useful. Let me exagerate a little and expand the time axis: if a message that was valid last month (such as "route add") got delivered today then you should be able to at least discard it since its validity time limit is over. Sure you wasted bandwidth by sending a useless transaction, but its ok to junk it (sequence numbers protect against this). TCP is know for its famous head-of-line blocking. Once a message is queued, my friend pray to the lord to have mercy on the packet because it shall be sent - whether you like it or not. Whether it is "valid" as described or not. For this reason TCP is in fact a failure. What was supposed to save you in the case of congestion control just turned out to be your achilles heel. When you have no congestion, and have low latencies, this problem doesnt exist. But since the big claim is that TCP is good because it has congestion control is being thrown around, I am pointing to you that infact that is a falacy. That may be fine for a file transfer where the validity bounds are almost unlimited (go and drink coffee while you wait for ftp to complete) but not for a transaction that has expired. To illustrate: Think of a two phase commit of a route cmd to several FEs within an NE from a CE(window slashed to two packets, heavy congestion): A revert (assuming its in a single packet) is queued behind a commit (assuming its in a single packet) even though the commit is irrelevant at that point - then there is no need to reconsider sending either one or maybe even both of them. There is no user supervision to control this. A better protocol would be SCTP-PR (only recently, last week or so has it become a RFC). But you are not talking SCTP-PR, you insist TCP. An alternative would be something that runs on UDP as what Netlink2 is doing. > For #2, TCP is satisfactory in unicast. In multicast, > sequence numbers will be necessary, or a reliable > multicast transport protocol will need to be used. Even when you use TCP you still need transaction sequence numbers. So this is moot. And i dont know why/how TCP guarantees ordering in the network. The Forces protocol dealing at the transaction level requires ordering, which all protocols i have seen proposed handle at the message level - TCP does not provide magical panacea to solve this. > For #3, the same TCP connection can be used in unicast. In > multicast, either the same multicast connection is used > (this results in every FE seeing every other FE's ack - yuck!) Note the netlink2 draft talks about these issues: You could make use of filtering even at hardware level. You could use partial acks to control implosions. You could scale to more sockets which do multicast etc (the total number of sockets used would be very few in comparison still), you could choose to add a unicast socket on the fly. You make it sound ugly that FEs could see other FEs ACKs or see other transactions directed at other FEs. In fact having ability to do so when you so wish is a good thing for things such as almost-free-state synchronization (you cant with unicast only without incuring more overhead). > or a separate TCP connection must be maintained by the FE to > the CE. You have that choice with netlink2. > For #4, either the protocol or its payload probably needs a > LFB identifier in the unicast case. In the multicast case, > it will be necessary to come up with some sort of binding > protocol, where LFBs are dynamically associated at runtime > with multicast groups. All protocols proposed so far have LFB identification. I dont understand what you mean by the "binding" part. I think this is one of those mysterious claims being made. Can you explain? > For #5, in the unicast case, a single message could contain > transaction information and a set of sub-messages. In the > multicast case I cannot off the top of my head come up with > a mechanism to even support transactioning. You obviously didnt read the netlink2 draft or maybe didnt listen too closely to the presentations ;-> I am afraid i am gonna have to force you to go and read the netlink2 draft ;-> > For #6, in the unicast case, TCP is satisfactory. In the > multicast case, a 2914 compliant multicast-based standard > protocol would be needed. Are there existing, standard, > robust implementations of a 2914 compliant multicast protocol > available in the operating systems commonly used in CEs and FEs? Please read my comments on this above. > In my (technical - chair hat still off) opinion, all of the > above requirements have to be met for any solution (multicast > or unicast) to be feasible. I can understand how the above > are satisfied by unicast, and would like to understand better > how the above can be satisfied when using multicast. I hope the above is helpful. I will split the real discussion into another email to avoid the usenet-loop effect. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 15:41:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21441 for ; Sat, 22 Nov 2003 15:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANeZa-000207-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 15:41:42 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANeZa-000203-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 15:41:42 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C53A09@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 15:41:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61604103 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 15:41:40 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 15:41:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAMKfd625933 for ; Sat, 22 Nov 2003 22:41:39 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 22 Nov 2003 22:41:35 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 22 Nov 2003 12:41:37 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Poll WAS(Re: Support for multicast in the ForCES protocol Thread-Index: AcOvcQS3P5WTxgLET9SCnwuyKJoYCABAE0jg X-OriginalArrivalTime: 22 Nov 2003 20:41:37.0728 (UTC) FILETIME=[06872C00:01C3B139] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Sat, 22 Nov 2003 15:41:36 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: Poll WAS(Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello Jamal, =20 I knew products and also working on products that are currently on the = field and uses reliable, unicast mechanism within FE-CE communication. = They deal with huge amount of information and those equipment demands = robust mechanisms.=20 We can take this offline if you need more information. =20 Since you asked why you choose one over the other - they are specific = to company's business and technical decision and you may or may not get = correct answer in this list. =20 BTW, FACT authors have built systems that uses unicast mechanism. Regards Ramg =20 =20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of ext Jamal Hadi Salim > Sent: Thursday, November 20, 2003 9:04 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Poll WAS(Re: Support for multicast in the ForCES protocol >=20 >=20 > Just changing the topic slightly since this topic is getting=20 > thread time. >=20 > I would like to poll people who have deployed boxes; either=20 > single chasis > with multiple FEs and CEs or within a rack or multi-rack; I=20 > believe this > is what 90% of deployments that will happen with Forces. > if you havent done the above but have opinions, just say so=20 > but mention > that you havent deployed something forces-like at the level mentioned > above. >=20 > Did you deploy utilizing multicast or broadcast transport? If not why? > And what did you use instead that solved the problem for you. >=20 > -In the early days for example multicast support was not > widely available in hardware so you had to emulate it. For such cases, > you are forgiven. > - Another reason is maybe you found multicast/bcast to be too complex. > Explain why. >=20 > cheers, > jamal >=20 > PS: All cauthors of netlink2 have experience implementing a=20 > forces-like > protocol which used a variant of mcast/bcast in environments that > got deployed at product level - thats why we feel very strongly about > this issue. Note, we worked then and still work for different=20 > companies > now. So we may be biased. >=20 > PPS: This is a poll, it would be preferable to stick to the questions > posed so i dont have to change the subject again. >=20 From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 16:57:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22622 for ; Sat, 22 Nov 2003 16:57:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANfkz-0002jE-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 16:57:33 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANfky-0002jB-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 16:57:32 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C538FA@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 16:57:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61607491 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 16:57:31 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 16:57:31 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5880751 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 16:57:30 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031122165546.018c37a8@localhost> Date: Sat, 22 Nov 2003 16:57:03 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069515768.1061.1849.camel@jzny.localdomain> Precedence: list In most lookup cache, flow processing, or RSVP architectures I know of, at most two (and typically one) FE would need to be updated when there is a change. Hence, I am unclear as to why this is being suggested as a reason for multicast. Yours, Joel M. halpern At 10:42 AM 11/22/2003 -0500, you wrote: >On Fri, 2003-11-21 at 15:04, Putzolu, David wrote: > > [chair hat off] > > Jamal Hadi Salim wrote> > > > I dont think it is a startup challenge issue only. The > > > challenge applies > > > to all applications that build state based on packet arrival > > > events. And there are many. > > > Think of an IDS under a DOS. Or a flow tracking firewall system. > > > 100s of FEs, millions of flows (say a 100K new ones per second). > > > You certainly wanna distribute that info to the FEs. > > > Unless you wanna rule out such apps for ForCES. > > > > IDS and flow tracking firewall is a specialized and challenging > > application, > >Challenging is a good word ;-> > > > and firewalls and load balancers are often architected > > differently from routers > > > > - is the CE:FE protocol in the > > ForCES architecture the right solution for such an app? > > > >I just gave those two as an example and i think they are valid. >The general class of the problem is events that are caused by packet >arrivals (or maybe even timers) that require distributed state updates. >I know some routers(since it seems thats the operative word >unfortunately) or router architectures that use LPM cache entries or >adjacencies to speed up lookups (i.e you have a FIB which is considered >the slow path and some form of cache as the fast path). Some people may >have given up those architectures, they are however very useful IMO >because they allow you to associate additional state to the simple FIB >entry added either at the beggining of the FIB + (mostly)srcIP tuple >being hit or adjacency being created. I dont want to sell their virtue >or argue their value; suffice it is to say they exist. >Now that i have used the operative word "router" - would those serve as >good example? >In regards to architectures being different: >I think that boundaries are greying - in particular at the edges of the >network. I havent seen a router(at least in my contact) in the last 2-3 >years which didnt have some firewalling capability built in. >In fact quiet a few that i have seen are also adding loadbalancing >capability; pick a $10 router from foundry (not sure how commodity you >wanted to get) and you will see what i am talking about. I suspect the >trend is gonna head that way. And i suspect these devices are gonna >scale even further by going into chasis and chasis going further into >racks. Would you want these devices selling for $50 a chasis out >of Taiwan be able to use Forces? I want them to. > > > Tracking flow state in a coherent fashion across blades can require > > updating state as often as once/packet in each flow. Using ForCES, > > that would require an event to the CE, followed by the > > CE creating and broadcasting a flow update message > > to every FE - all occurring every time a TCP SYN, SYNACK, > > or FIN (at least) is received. > >Did you forget RST? ;-> just kidding. >You would have to do a few smart things, but this is the wrong place to >discuss that. > > > Wouldn't a FE:FE protocol > > be a much better fit for this class of applications? > >If you are multicast capable, it doesnt matter: Use CE-FE events. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 17:03:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22828 for ; Sat, 22 Nov 2003 17:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANfqR-0002pr-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 17:03:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANfqR-0002po-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 17:03:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C53BE0@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 17:03:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61608220 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 17:02:47 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 17:02:47 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5880758 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 17:02:46 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031122170003.0191a298@localhost> Date: Sat, 22 Nov 2003 17:02:22 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069518599.1056.1947.camel@jzny.localdomain> Precedence: list For the control protocol (not for the encapsulation of data between the CE and the FE, I have to disagree. I think that every transaction must be transferred successfully, and in order. Otherwise, ensuring the CE properly understands the state of the FE is extremely difficult. Note that your argument about extreme delay is probably a red herring. If transactions are being delayed that long, the communication needs to be declared down, and you start over with a clean slate. This has very little relationship to actual protocol behavior. Yours, Joel M. Halpern At 11:29 AM 11/22/2003 -0500, you wrote: >I. ForCES mechanisms requiring reliability: > >a) time limit very sensitive (in other words obsolence period is >faster): >Example table updates; >I have argued TCP doesnt qualify in my previous email. SCTP-PR may >qualify. >Something like what netlink2 over UDP qualifies because it gives control >to netlink2 to make such decisions. > >b) time limit best effort (obsolence takes longer) >Sample apps: File transfers,etc. >TCP qualifies but AFAIK, we dont have this need. > >II. mechanisms capable of tolerating unreliability: Example psamp. >TCP doesnt qualify. >something(like netlink2) over UDP or SCTP-PR. > >III. mechanisms that prefer timeliness over reliability: Ex heartbeats >something (like netlink2) over UDP or SCTP-PR. From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 19:13:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26757 for ; Sat, 22 Nov 2003 19:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANhsm-0004BF-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 19:13:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANhsm-0004B8-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 19:13:44 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C53CD2@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 19:13:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61615263 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 19:13:43 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 19:13:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Support for multicast in the ForCES protocol Thread-Index: AcOxQ/q0YfDjiYB6TmihJZft9qF1HgAEY2nd Approved-By: Tal Anker Message-ID: Date: Sun, 23 Nov 2003 02:13:52 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSBhZ2dyZWUgdGhhdCB0aGUgSURTL0RPRC9mbG93IHRyYWNraW5nIHNlZW1zIG1vcmUgc3VpdGFi bGUgZm9yIDEtPnZlcnktZmV3IEZFJ3MgY2FzZS4gSG93ZXZlciwgZGlzdHJpYnV0aW5nIEwzIEZJ QiBvciBMMiBGREIgYXJlIGdvb2QgY2FuZGlkYXRlcyBmb3IgbXVsdGljYXN0LCBhcyB0aGV5IGFy ZSAoaW4gbW9zdCBjYXNlcykgLSB0aGUgc2FtZSBvbiBhbGwvbW9zdCBGRXMuIEFzIG9uZSBwYXJh bWV0ZXIgb2YgbWVhc3VyaW5nIHJvdXRlci9zd2l0Y2ggcGVyZm9ybWFuY2UgaXMgdGhlIHdheSB0 aGV5IGhhbmRsZSBtYW55IHVwZGF0ZXMgcGVyIHNlY29uZCB3aGlsZSBzdGlsbCBiZWluZyBhYmxl IHRvIHBlcmZvcm0gc29tZSBvdGhlciB1c2VmdWxsIGZ1bmN0aW9ucyAobWFpbnRhaW5pbmcgbWFu YWdlbWVudCBzZXNzaW9ucywgZXRjKSBoYXZpbmcgbXVsdGljYXN0IGF0IGxlYXN0IGFzIGFuIG9w dGlvbiBmb3IgZm9yY2VzIHNlZW1zIGEgZ29vZCB0aGluZy4gV2UgbWF5IG5vdCBuZWVkIHRvIGRv IHRoZSBmdWxsIGRlc2lnbiBhdCBmaXJzdCBwaGFzZSwgYnV0IHdlIHN1cmUgYXQgbGVhc3QgbmVl ZCB0byB0cnkgdG8gbm90IGRvIGFueXRoaW5nIHRoYXQgd2lsbCBsYXRlciBtYWtlIGluY29ycG9y YXRpb24gb2YgbXVsdGljYXN0IGEgaGFyZCB0aGluZy4gDQpTb21lb25lIG9uIHRoZSBsaXN0IHN1 Z2dlc3RlZCAoaWYgSSBhbSBub3QgbWlzdGFrZW4pIHRvIGhhdmUgdGhlIHByb3BlciAiaG9va3Mi IGZvciBtdWx0aWNhc3QsIGFuZCBmb3IgdGhhdCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgd2hhdCBp cyB0aGUgbW9kZWwgYW5kIHJlcXVpcmVtZW50IGZyb20gc3VjaCB0cmFuc3BvcnQuIA0KIA0KLSBU YWwNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEpvZWwgTS4gSGFscGVy biBbbWFpbHRvOmpvZWxAc3RldmVjcm9ja2VyLmNvbV0gDQoJU2VudDogU2F0IDExLzIyLzIwMDMg MTE6NTcgUE0gDQoJVG86IEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTSANCglDYzogDQoJU3Vi amVjdDogUmU6IFN1cHBvcnQgZm9yIG11bHRpY2FzdCBpbiB0aGUgRm9yQ0VTIHByb3RvY29sDQoJ DQoJDQoNCglJbiBtb3N0IGxvb2t1cCBjYWNoZSwgZmxvdyBwcm9jZXNzaW5nLCBvciBSU1ZQIGFy Y2hpdGVjdHVyZXMgSSBrbm93IG9mLCBhdA0KCW1vc3QgdHdvIChhbmQgdHlwaWNhbGx5IG9uZSkg RkUgd291bGQgbmVlZCB0byBiZSB1cGRhdGVkIHdoZW4gdGhlcmUgaXMgYQ0KCWNoYW5nZS4gIEhl bmNlLCBJIGFtIHVuY2xlYXIgYXMgdG8gd2h5IHRoaXMgaXMgYmVpbmcgc3VnZ2VzdGVkIGFzIGEg cmVhc29uDQoJZm9yIG11bHRpY2FzdC4NCgkNCglZb3VycywNCglKb2VsIE0uIGhhbHBlcm4NCgkN CglBdCAxMDo0MiBBTSAxMS8yMi8yMDAzIC0wNTAwLCB5b3Ugd3JvdGU6DQoJPk9uIEZyaSwgMjAw My0xMS0yMSBhdCAxNTowNCwgUHV0em9sdSwgRGF2aWQgd3JvdGU6DQoJPiA+IFtjaGFpciBoYXQg b2ZmXQ0KCT4gPiBKYW1hbCBIYWRpIFNhbGltIHdyb3RlPg0KCT4gPiA+IEkgZG9udCB0aGluayBp dCBpcyBhIHN0YXJ0dXAgY2hhbGxlbmdlIGlzc3VlIG9ubHkuIFRoZQ0KCT4gPiA+IGNoYWxsZW5n ZSBhcHBsaWVzDQoJPiA+ID4gdG8gYWxsIGFwcGxpY2F0aW9ucyB0aGF0IGJ1aWxkIHN0YXRlIGJh c2VkIG9uIHBhY2tldCBhcnJpdmFsDQoJPiA+ID4gZXZlbnRzLiBBbmQgdGhlcmUgYXJlIG1hbnku DQoJPiA+ID4gVGhpbmsgb2YgYW4gSURTIHVuZGVyIGEgRE9TLiBPciBhIGZsb3cgdHJhY2tpbmcg ZmlyZXdhbGwgc3lzdGVtLg0KCT4gPiA+IDEwMHMgb2YgRkVzLCBtaWxsaW9ucyBvZiBmbG93cyAo c2F5IGEgMTAwSyBuZXcgb25lcyBwZXIgc2Vjb25kKS4NCgk+ID4gPiBZb3UgY2VydGFpbmx5IHdh bm5hIGRpc3RyaWJ1dGUgdGhhdCBpbmZvIHRvIHRoZSBGRXMuDQoJPiA+ID4gVW5sZXNzIHlvdSB3 YW5uYSBydWxlIG91dCBzdWNoIGFwcHMgZm9yIEZvckNFUy4NCgk+ID4NCgk+ID4gSURTIGFuZCBm bG93IHRyYWNraW5nIGZpcmV3YWxsIGlzIGEgc3BlY2lhbGl6ZWQgYW5kIGNoYWxsZW5naW5nDQoJ PiA+IGFwcGxpY2F0aW9uLA0KCT4NCgk+Q2hhbGxlbmdpbmcgaXMgYSBnb29kIHdvcmQgOy0+DQoJ Pg0KCT4gPiBhbmQgZmlyZXdhbGxzIGFuZCBsb2FkIGJhbGFuY2VycyBhcmUgb2Z0ZW4gYXJjaGl0 ZWN0ZWQNCgk+ID4gZGlmZmVyZW50bHkgZnJvbSByb3V0ZXJzDQoJPiA+DQoJPiA+IC0gaXMgdGhl IENFOkZFIHByb3RvY29sIGluIHRoZQ0KCT4gPiBGb3JDRVMgYXJjaGl0ZWN0dXJlIHRoZSByaWdo dCBzb2x1dGlvbiBmb3Igc3VjaCBhbiBhcHA/DQoJPiA+DQoJPg0KCT5JIGp1c3QgZ2F2ZSB0aG9z ZSB0d28gYXMgYW4gZXhhbXBsZSBhbmQgaSB0aGluayB0aGV5IGFyZSB2YWxpZC4NCgk+VGhlIGdl bmVyYWwgY2xhc3Mgb2YgdGhlIHByb2JsZW0gaXMgZXZlbnRzIHRoYXQgYXJlIGNhdXNlZCBieSBw YWNrZXQNCgk+YXJyaXZhbHMgKG9yIG1heWJlIGV2ZW4gdGltZXJzKSB0aGF0IHJlcXVpcmUgZGlz dHJpYnV0ZWQgc3RhdGUgdXBkYXRlcy4NCgk+SSBrbm93IHNvbWUgcm91dGVycyhzaW5jZSBpdCBz ZWVtcyB0aGF0cyB0aGUgb3BlcmF0aXZlIHdvcmQNCgk+dW5mb3J0dW5hdGVseSkgb3Igcm91dGVy IGFyY2hpdGVjdHVyZXMgdGhhdCB1c2UgTFBNIGNhY2hlIGVudHJpZXMgb3INCgk+YWRqYWNlbmNp ZXMgdG8gc3BlZWQgdXAgbG9va3VwcyAoaS5lIHlvdSBoYXZlIGEgRklCIHdoaWNoIGlzIGNvbnNp ZGVyZWQNCgk+dGhlIHNsb3cgcGF0aCBhbmQgc29tZSBmb3JtIG9mIGNhY2hlIGFzIHRoZSBmYXN0 IHBhdGgpLiBTb21lIHBlb3BsZSBtYXkNCgk+aGF2ZSBnaXZlbiB1cCB0aG9zZSBhcmNoaXRlY3R1 cmVzLCB0aGV5IGFyZSBob3dldmVyIHZlcnkgdXNlZnVsIElNTw0KCT5iZWNhdXNlIHRoZXkgYWxs b3cgeW91IHRvIGFzc29jaWF0ZSBhZGRpdGlvbmFsIHN0YXRlIHRvIHRoZSBzaW1wbGUgRklCDQoJ PmVudHJ5IGFkZGVkIGVpdGhlciBhdCB0aGUgYmVnZ2luaW5nIG9mIHRoZSBGSUIgKyAobW9zdGx5 KXNyY0lQIHR1cGxlDQoJPmJlaW5nIGhpdCBvciBhZGphY2VuY3kgYmVpbmcgY3JlYXRlZC4gSSBk b250IHdhbnQgdG8gc2VsbCB0aGVpciB2aXJ0dWUNCgk+b3IgYXJndWUgdGhlaXIgdmFsdWU7IHN1 ZmZpY2UgaXQgaXMgdG8gc2F5IHRoZXkgZXhpc3QuDQoJPk5vdyB0aGF0IGkgaGF2ZSB1c2VkIHRo ZSBvcGVyYXRpdmUgd29yZCAicm91dGVyIiAtIHdvdWxkIHRob3NlIHNlcnZlIGFzDQoJPmdvb2Qg ZXhhbXBsZT8NCgk+SW4gcmVnYXJkcyB0byBhcmNoaXRlY3R1cmVzIGJlaW5nIGRpZmZlcmVudDoN Cgk+SSB0aGluayB0aGF0IGJvdW5kYXJpZXMgYXJlIGdyZXlpbmcgLSBpbiBwYXJ0aWN1bGFyIGF0 IHRoZSBlZGdlcyBvZiB0aGUNCgk+bmV0d29yay4gSSBoYXZlbnQgc2VlbiBhIHJvdXRlcihhdCBs ZWFzdCBpbiBteSBjb250YWN0KSBpbiB0aGUgbGFzdCAyLTMNCgk+eWVhcnMgd2hpY2ggZGlkbnQg aGF2ZSBzb21lIGZpcmV3YWxsaW5nIGNhcGFiaWxpdHkgYnVpbHQgaW4uDQoJPkluIGZhY3QgcXVp ZXQgYSBmZXcgdGhhdCBpIGhhdmUgc2VlbiBhcmUgYWxzbyBhZGRpbmcgbG9hZGJhbGFuY2luZw0K CT5jYXBhYmlsaXR5OyBwaWNrIGEgJDEwIHJvdXRlciBmcm9tIGZvdW5kcnkgKG5vdCBzdXJlIGhv dyBjb21tb2RpdHkgeW91DQoJPndhbnRlZCB0byBnZXQpIGFuZCB5b3Ugd2lsbCBzZWUgd2hhdCBp IGFtIHRhbGtpbmcgYWJvdXQuIEkgc3VzcGVjdCB0aGUNCgk+dHJlbmQgaXMgZ29ubmEgaGVhZCB0 aGF0IHdheS4gQW5kIGkgc3VzcGVjdCB0aGVzZSBkZXZpY2VzIGFyZSBnb25uYQ0KCT5zY2FsZSBl dmVuIGZ1cnRoZXIgYnkgZ29pbmcgaW50byBjaGFzaXMgYW5kIGNoYXNpcyBnb2luZyBmdXJ0aGVy IGludG8NCgk+cmFja3MuIFdvdWxkIHlvdSB3YW50IHRoZXNlIGRldmljZXMgc2VsbGluZyBmb3Ig JDUwIGEgY2hhc2lzIG91dA0KCT5vZiBUYWl3YW4gYmUgYWJsZSB0byB1c2UgRm9yY2VzPyBJIHdh bnQgdGhlbSB0by4NCgk+DQoJPiA+IFRyYWNraW5nIGZsb3cgc3RhdGUgaW4gYSBjb2hlcmVudCBm YXNoaW9uIGFjcm9zcyBibGFkZXMgY2FuIHJlcXVpcmUNCgk+ID4gdXBkYXRpbmcgc3RhdGUgYXMg b2Z0ZW4gYXMgb25jZS9wYWNrZXQgaW4gZWFjaCBmbG93LiBVc2luZyBGb3JDRVMsDQoJPiA+IHRo YXQgd291bGQgcmVxdWlyZSBhbiBldmVudCB0byB0aGUgQ0UsIGZvbGxvd2VkIGJ5IHRoZQ0KCT4g PiBDRSBjcmVhdGluZyBhbmQgYnJvYWRjYXN0aW5nIGEgZmxvdyB1cGRhdGUgbWVzc2FnZQ0KCT4g PiB0byBldmVyeSBGRSAtIGFsbCBvY2N1cnJpbmcgZXZlcnkgdGltZSBhIFRDUCBTWU4sIFNZTkFD SywNCgk+ID4gb3IgRklOIChhdCBsZWFzdCkgaXMgcmVjZWl2ZWQuDQoJPg0KCT5EaWQgeW91IGZv cmdldCBSU1Q/IDstPiBqdXN0IGtpZGRpbmcuDQoJPllvdSB3b3VsZCBoYXZlIHRvIGRvIGEgZmV3 IHNtYXJ0IHRoaW5ncywgYnV0IHRoaXMgaXMgdGhlIHdyb25nIHBsYWNlIHRvDQoJPmRpc2N1c3Mg dGhhdC4NCgk+DQoJPiA+IFdvdWxkbid0IGEgRkU6RkUgcHJvdG9jb2wNCgk+ID4gYmUgYSBtdWNo IGJldHRlciBmaXQgZm9yIHRoaXMgY2xhc3Mgb2YgYXBwbGljYXRpb25zPw0KCT4NCgk+SWYgeW91 IGFyZSBtdWx0aWNhc3QgY2FwYWJsZSwgaXQgZG9lc250IG1hdHRlcjogVXNlIENFLUZFIGV2ZW50 cy4NCgk+DQoJPmNoZWVycywNCgk+amFtYWwNCgkNCg0K From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 21:28:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28608 for ; Sat, 22 Nov 2003 21:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANjz0-0005Cw-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:28:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANjz0-0005Ct-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:28:18 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C53CD2@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 21:28:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61622438 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 21:28:17 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 21:28:17 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112218272728:6905 ; Sat, 22 Nov 2003 18:27:27 -0800 References: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:27:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:27:30 PM, Serialize complete at 11/22/2003 06:27:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069554493.1059.2634.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 21:28:14 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2003-11-21 at 16:50, Putzolu, David wrote: > > I was assuming a unicast approach something like the following > (using an XML-like notation for simplicity, the wire > representation would likely be different): Ok, thanks for providing this because it cleared some confusion as to what angle you are looking at things. We are being bitten by lack of some NPF document again (i saw your description before in my brief glance of an NPF doc at MPLS). As i mentioned the need for NPF documents is to at least understand what one is arguing against. We would have saved a lot of bandwith on this thread. I am glad i took a break and came back and read all these messages. I dont need to give an example anymore, this is a good one;-> Again, thanks for providing this. > > 138 // A nonce indifying the xaction > // Start of a command to a LFB > 17 // Indicates what LFB this command targets > // in this case the IPv4 FIB LFB > // This is a prefix add command, for FIB LFB > 158.0.0.0 > 8 > ... > > // End of the first command in the transaction > > 23 // Some other LFB that we want to be atomically > // updated with the FIB update above > ... // Body of the second command. > > ... // More commands > // End of the transaction > > Upon receiving the above via unicast, a FE would manipulate > LFB 17 with the prefix add, LFB 32 with whatever command > was applied to it, etc., using all-or-nothing semantics. > Because the command is unicast to the FE, the LFB identifiers > used in the transaction indicate what particular > LFBs to do the all-or-nothing semantics with. > > In the multicast case, I assume each FE would have a different set > of IDs for the LFBs (perhaps the IPv4 FIB LFB would be #17 on > FE#1, but would be #12 on FE#2. So just multicasting the above > message would not make any sense. > Why would the LFBID change depending on whether it was unicast or multicast? The LFBID would stay pretty static across FEs, and is probably issued by IANA. Lets take the case of netlink2 running on top of multicast. [Refer to netlink2 current draft section 5.1 for the header.] -cmd/type = RTM_NEWROUTE which is essentially saying "this is directed to the IPV4 Forwarding LFB to add the entry(ies) associated with this message" -Destination PID = either a specific FEs proxy for IPV4 LFB, or the "all IPV4 LFBs", or directly targeting a specific LFB. Refer to section 8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template". The template is infact an encapsulator of a IPV4 LFB _transaction_ i.e not only does it include the prefix entry needed for the transaction but also the nexthop gateway. I suspect the nexthop gw is what you were trying to do with your LFBID = 23. A transaction like the above could be encapsulated in a message in the simple case within a single UDP PDU. To illustrate, it will be sent on a UDP socket on port 5000 to a multicast IP address. Does that clarify things? If it gets sent on that multicast address, and three FEs are joined to it, all three will see it. All three may ACK it. Or two may ACK and one will send a NACK. Or partial ACKS may be used. Or one of the FEs may be passive synchronizing state as a backup. etc. Does this clarify how multicast is being used by netlink2? Its merely a transport which when available is used. > In the non-transactioned case, I assume the mcast group tells > the FE what LFB to deliver a message to. I am begining to understand where all the confusion was coming from. I have to say i found it strange when i saw mentions of multicast groups per LFB that were posted earlier. Please make those NPF documents available. The LFB message for a single transaction must be sent on the same multicast group or you dont save much. The RTM_* netlink2 template puts them together, so it is a non-issue. The NPF document i believe separates the nh gw from the IPV4 Prefix to be two separate LFBs - too fine grained and very very implementation specific IMO. If they are part of the same transaction, it may not make sense to separate them - when will a next hop be configured without a route to associate with? I would encourage that we demarcate the concept of LFBs at the transaction level, not every little table that exists on a device. It will help making it a lot non-hardware specific. That is why you need to have it in one message like you attempted to (but left out i.e LFBID 23). You can go fine grained and separate them, but you better make sure you have atomicity to make their updates a single transaction. BTW, all these details have been explained in a few presentations at the WG on netlink2 and rather painfully laboriously in the draft. You could jump to: page 30 "section 7.5.5 Atomicity and Ordering of Transactions". > One could try to reuse > that mechanism, but that requires either that one know a priori > all possible combinations of LFBs across FEs that might be > transactioned together (to allocate necessary groups in pre- > association time), or one could just brute force it, allocating > enough multicast groups to cover all cases (but that would cause > a factorial explosion so isn't feasible). > Think transaction level (the way netlink2 does) and you will feel much better. A transaction configuration always goes onto the same wire. I think the problem with the NPF model is it is too fine grained. It follows what MIT Click and infact abuses it by implying each table to be an LFB. This may make sense for something like a meter. It doesnt for IPV4/6 Forwarding. You need to group a number of tables together to form a meaningful service. You can then refer to that as an LFB. You may think you are being clever, but some devices may infact _not_ separate the GW and L3 tables i.e they are closely intertwined. > So the conclusion I came to was that for using multicast to > carry transactions one would have to either assume that every > FE had the identical set of LFBs being addressed, in terms of > transaction ID, data being pushed down, and LFB instance IDs, > every time a transaction is used. This is of course in addition > to requiring proper ordering & non-corruption of packets. I > suspect that making the above assumption is not safe - different > LFBs are likely to be addressed in each FE (either different > instance IDs of the same type, or different types). Different > data per FE (LFB instance IDs, transaction IDs) takes away the > benefit of multicast, which primarily holds when data is the > same for all receivers. That may be true for the other proposed protocols, it is not for netlink2. I strongly recommend reading the netlink2 draft then lets discuss further. And you really oughta make those docs available if you want to save bandwidth (in the same manner that multicast does;->). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 21:33:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28713 for ; Sat, 22 Nov 2003 21:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANk3j-0005H3-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:33:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANk3j-0005H0-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:33:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C53DB1@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 21:33:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61622641 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 21:33:10 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 21:33:10 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112218322160:6910 ; Sat, 22 Nov 2003 18:32:21 -0800 References: <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB78@orsmsx409.jf.intel.com> <5.1.0.14.0.20031122165546.018c37a8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:32:22 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:32:23 PM, Serialize complete at 11/22/2003 06:32:23 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069554788.1059.2640.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 21:33:08 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031122165546.018c37a8@localhost> Precedence: list Content-Transfer-Encoding: 7bit The discussion digressed. Someone claimed that multicast would be useful only if you did have a lot of updates per unit of time (of course i have never thought of this as the reason why multicast would be useful;->). BGP route updates were pointed out. Someone else claimed BGP updates were only meaningful at startup. Someone else suggest events equivalent to flooding would be useful etc ...... I think you could do clever things like breaking down the event to be per few FEs and hierachical, but thats besides the point. cheers, jamal On Sat, 2003-11-22 at 16:57, Joel M. Halpern wrote: > In most lookup cache, flow processing, or RSVP architectures I know of, at > most two (and typically one) FE would need to be updated when there is a > change. Hence, I am unclear as to why this is being suggested as a reason > for multicast. > > Yours, > Joel M. halpern > > At 10:42 AM 11/22/2003 -0500, you wrote: > >On Fri, 2003-11-21 at 15:04, Putzolu, David wrote: > > > [chair hat off] > > > Jamal Hadi Salim wrote> > > > > I dont think it is a startup challenge issue only. The > > > > challenge applies > > > > to all applications that build state based on packet arrival > > > > events. And there are many. > > > > Think of an IDS under a DOS. Or a flow tracking firewall system. > > > > 100s of FEs, millions of flows (say a 100K new ones per second). > > > > You certainly wanna distribute that info to the FEs. > > > > Unless you wanna rule out such apps for ForCES. > > > > > > IDS and flow tracking firewall is a specialized and challenging > > > application, > > > >Challenging is a good word ;-> > > > > > and firewalls and load balancers are often architected > > > differently from routers > > > > > > - is the CE:FE protocol in the > > > ForCES architecture the right solution for such an app? > > > > > > >I just gave those two as an example and i think they are valid. > >The general class of the problem is events that are caused by packet > >arrivals (or maybe even timers) that require distributed state updates. > >I know some routers(since it seems thats the operative word > >unfortunately) or router architectures that use LPM cache entries or > >adjacencies to speed up lookups (i.e you have a FIB which is considered > >the slow path and some form of cache as the fast path). Some people may > >have given up those architectures, they are however very useful IMO > >because they allow you to associate additional state to the simple FIB > >entry added either at the beggining of the FIB + (mostly)srcIP tuple > >being hit or adjacency being created. I dont want to sell their virtue > >or argue their value; suffice it is to say they exist. > >Now that i have used the operative word "router" - would those serve as > >good example? > >In regards to architectures being different: > >I think that boundaries are greying - in particular at the edges of the > >network. I havent seen a router(at least in my contact) in the last 2-3 > >years which didnt have some firewalling capability built in. > >In fact quiet a few that i have seen are also adding loadbalancing > >capability; pick a $10 router from foundry (not sure how commodity you > >wanted to get) and you will see what i am talking about. I suspect the > >trend is gonna head that way. And i suspect these devices are gonna > >scale even further by going into chasis and chasis going further into > >racks. Would you want these devices selling for $50 a chasis out > >of Taiwan be able to use Forces? I want them to. > > > > > Tracking flow state in a coherent fashion across blades can require > > > updating state as often as once/packet in each flow. Using ForCES, > > > that would require an event to the CE, followed by the > > > CE creating and broadcasting a flow update message > > > to every FE - all occurring every time a TCP SYN, SYNACK, > > > or FIN (at least) is received. > > > >Did you forget RST? ;-> just kidding. > >You would have to do a few smart things, but this is the wrong place to > >discuss that. > > > > > Wouldn't a FE:FE protocol > > > be a much better fit for this class of applications? > > > >If you are multicast capable, it doesnt matter: Use CE-FE events. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 21:38:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28769 for ; Sat, 22 Nov 2003 21:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANk9J-0005Io-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:38:57 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANk9I-0005Il-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 21:38:56 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C53E57@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 21:38:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61622844 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 21:38:56 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 21:38:56 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112218380654:6915 ; Sat, 22 Nov 2003 18:38:06 -0800 References: <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <5.1.0.14.0.20031122170003.0191a298@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:38:07 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/22/2003 06:38:08 PM, Serialize complete at 11/22/2003 06:38:08 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069555132.1056.2647.camel@jzny.localdomain> Date: Sat, 22 Nov 2003 21:38:53 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031122170003.0191a298@localhost> Precedence: list Content-Transfer-Encoding: 7bit On Sat, 2003-11-22 at 17:02, Joel M. Halpern wrote: > For the control protocol (not for the encapsulation of data between the CE > and the FE, I have to disagree. > I think that every transaction must be transferred successfully, and in order. > Otherwise, ensuring the CE properly understands the state of the FE is > extremely difficult. > Thats the transaction level not the transport protocol level. And we dont disagree there. > Note that your argument about extreme delay is probably a red herring. If > transactions are being delayed that long, the communication needs to be > declared down, and you start over with a clean slate. This has very little > relationship to actual protocol behavior. > I take it you had no issue with the other points mentioned otherwise you would have said something about them? I am afraid, the extreme delay is as much a red herring (it is there to illustrate a point) as multicast "would complicate things" or "multicast is only useful if you have a lot of updates per unit of time" . Maybe ive said enough for today. cheers, jamal > Yours, > Joel M. Halpern > > At 11:29 AM 11/22/2003 -0500, you wrote: > >I. ForCES mechanisms requiring reliability: > > > >a) time limit very sensitive (in other words obsolence period is > >faster): > >Example table updates; > >I have argued TCP doesnt qualify in my previous email. SCTP-PR may > >qualify. > >Something like what netlink2 over UDP qualifies because it gives control > >to netlink2 to make such decisions. > > > >b) time limit best effort (obsolence takes longer) > >Sample apps: File transfers,etc. > >TCP qualifies but AFAIK, we dont have this need. > > > >II. mechanisms capable of tolerating unreliability: Example psamp. > >TCP doesnt qualify. > >something(like netlink2) over UDP or SCTP-PR. > > > >III. mechanisms that prefer timeliness over reliability: Ex heartbeats > >something (like netlink2) over UDP or SCTP-PR. From owner-forces@PEACH.EASE.LSOFT.COM Sat Nov 22 23:35:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00396 for ; Sat, 22 Nov 2003 23:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANly8-0006EI-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 23:35:32 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANly8-0006EF-00 for forces-archive@IETF.ORG; Sat, 22 Nov 2003 23:35:32 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C5417F@cherry.ease.lsoft.com>; Sat, 22 Nov 2003 23:35:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61630095 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 23:35:31 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Nov 2003 23:35:31 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5881193 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Nov 2003 23:35:30 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20031122170003.0191a298@localhost> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <5.1.0.14.0.20031122170003.0191a298@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031122233048.0192bbc8@localhost> Date: Sat, 22 Nov 2003 23:34:58 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069555132.1056.2647.camel@jzny.localdomain> Precedence: list My both our own agreement and the direction we have been given, we have to deal with flow control, retransmission, and congestion control in the transfer of ForCES control messages. (And security.) With TCP / SCTP for Unicast we get those things. With UDP, we will have to redefine all those behaviors for ourselves. With Multicast, all those things are significantly more complex. (The correct semantics for multicast flow control even in a limited environment are tricky, for example.) Now, if there is a substantial benefit to the use of multicast, then it may be worth our while to support it. If there are protocols hooks that can easily be put in now that would allow addition of full support for multicast later, those are worth considering if there is a reasonable value to multicast. But otherwise it seems sensible to just stick to unicast. Remember that as a general rule optional mechanisms (even simple optional mechanisms) are a source of interoperability failures. Yours, Joel M. Halpern At 09:38 PM 11/22/2003 -0500, Jamal Hadi Salim wrote: >On Sat, 2003-11-22 at 17:02, Joel M. Halpern wrote: > > For the control protocol (not for the encapsulation of data between the CE > > and the FE, I have to disagree. > > I think that every transaction must be transferred successfully, and in > order. > > Otherwise, ensuring the CE properly understands the state of the FE is > > extremely difficult. > > > >Thats the transaction level not the transport protocol level. And we >dont disagree there. > > > Note that your argument about extreme delay is probably a red herring. If > > transactions are being delayed that long, the communication needs to be > > declared down, and you start over with a clean slate. This has very little > > relationship to actual protocol behavior. > > > >I take it you had no issue with the other points mentioned otherwise >you would have said something about them? >I am afraid, the extreme delay is as much a red herring (it is there to >illustrate a point) as multicast "would complicate things" or "multicast >is only useful if you have a lot of updates per unit of time" . > >Maybe ive said enough for today. > >cheers, >jamal > > > Yours, > > Joel M. Halpern > > > > At 11:29 AM 11/22/2003 -0500, you wrote: > > >I. ForCES mechanisms requiring reliability: > > > > > >a) time limit very sensitive (in other words obsolence period is > > >faster): > > >Example table updates; > > >I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > >qualify. > > >Something like what netlink2 over UDP qualifies because it gives control > > >to netlink2 to make such decisions. > > > > > >b) time limit best effort (obsolence takes longer) > > >Sample apps: File transfers,etc. > > >TCP qualifies but AFAIK, we dont have this need. > > > > > >II. mechanisms capable of tolerating unreliability: Example psamp. > > >TCP doesnt qualify. > > >something(like netlink2) over UDP or SCTP-PR. > > > > > >III. mechanisms that prefer timeliness over reliability: Ex heartbeats > > >something (like netlink2) over UDP or SCTP-PR. From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 23 11:00:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23962 for ; Sun, 23 Nov 2003 11:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANwfU-0004DO-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 11:01:00 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1ANwfT-0004DF-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 11:00:59 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C54973@cherry.ease.lsoft.com>; 23 Nov 2003 11:00:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61681353 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Nov 2003 11:00:56 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Nov 2003 11:00:56 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112308000584:7191 ; Sun, 23 Nov 2003 08:00:05 -0800 References: <5.1.0.14.0.20031122170003.0191a298@localhost> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <52D13A805349A249960B9943E5590BD80195EB7F@orsmsx409.jf.intel.com> <5.1.0.14.0.20031122170003.0191a298@localhost> <5.1.0.14.0.20031122233048.0192bbc8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 08:00:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 08:00:08 AM, Serialize complete at 11/23/2003 08:00:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069603252.1058.2689.camel@jzny.localdomain> Date: Sun, 23 Nov 2003 11:00:52 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031122233048.0192bbc8@localhost> Precedence: list Content-Transfer-Encoding: 7bit Sigh. We are back to square one. We have two religious views based on our implementation experiences. Ive just spent 10 emails explaining why i dont think TCP is sufficient by itself and why multicast transport is useful;-> Ive been on enough threads on usenet and email to wisen up and know when to stop.[1] This is the point where reasonable people agree to disagree and end the discussion. If this was an implementation this is where we fork ;-> cheers, jamal PS: Selection of what gets used for transport is a pre-association config issue not sure what you see as being interoperable with that. [1]Otherwise you will make me repeat everything i said in the last 10 emails and you will then repeat exactly what you say below. Its a vicious cycle - you have not changed my views on multicast and neither have i changed yours. On Sat, 2003-11-22 at 23:34, Joel M. Halpern wrote: > My both our own agreement and the direction we have been given, we have to > deal with flow control, retransmission, and congestion control in the > transfer of ForCES control messages. (And security.) With TCP / SCTP for > Unicast we get those things. With UDP, we will have to redefine all those > behaviors for ourselves. With Multicast, all those things are > significantly more complex. (The correct semantics for multicast flow > control even in a limited environment are tricky, for example.) > > Now, if there is a substantial benefit to the use of multicast, then it may > be worth our while to support it. > If there are protocols hooks that can easily be put in now that would allow > addition of full support for multicast later, those are worth considering > if there is a reasonable value to multicast. > But otherwise it seems sensible to just stick to unicast. > > Remember that as a general rule optional mechanisms (even simple optional > mechanisms) are a source of interoperability failures. > > Yours, > Joel M. Halpern > > At 09:38 PM 11/22/2003 -0500, Jamal Hadi Salim wrote: > >On Sat, 2003-11-22 at 17:02, Joel M. Halpern wrote: > > > For the control protocol (not for the encapsulation of data between the CE > > > and the FE, I have to disagree. > > > I think that every transaction must be transferred successfully, and in > > order. > > > Otherwise, ensuring the CE properly understands the state of the FE is > > > extremely difficult. > > > > > > >Thats the transaction level not the transport protocol level. And we > >dont disagree there. > > > > > Note that your argument about extreme delay is probably a red herring. If > > > transactions are being delayed that long, the communication needs to be > > > declared down, and you start over with a clean slate. This has very little > > > relationship to actual protocol behavior. > > > > > > >I take it you had no issue with the other points mentioned otherwise > >you would have said something about them? > >I am afraid, the extreme delay is as much a red herring (it is there to > >illustrate a point) as multicast "would complicate things" or "multicast > >is only useful if you have a lot of updates per unit of time" . > > > >Maybe ive said enough for today. > > > >cheers, > >jamal > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:29 AM 11/22/2003 -0500, you wrote: > > > >I. ForCES mechanisms requiring reliability: > > > > > > > >a) time limit very sensitive (in other words obsolence period is > > > >faster): > > > >Example table updates; > > > >I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > > >qualify. > > > >Something like what netlink2 over UDP qualifies because it gives control > > > >to netlink2 to make such decisions. > > > > > > > >b) time limit best effort (obsolence takes longer) > > > >Sample apps: File transfers,etc. > > > >TCP qualifies but AFAIK, we dont have this need. > > > > > > > >II. mechanisms capable of tolerating unreliability: Example psamp. > > > >TCP doesnt qualify. > > > >something(like netlink2) over UDP or SCTP-PR. > > > > > > > >III. mechanisms that prefer timeliness over reliability: Ex heartbeats > > > >something (like netlink2) over UDP or SCTP-PR. From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 23 19:30:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05844 for ; Sun, 23 Nov 2003 19:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4ce-0001z3-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 19:30:36 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AO4ce-0001yz-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 19:30:36 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C54EF9@cherry.ease.lsoft.com>; 23 Nov 2003 19:30:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61706933 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Nov 2003 19:30:31 -0500 Received: from 64.12.136.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Nov 2003 19:30:31 -0500 Received: from Aaudu2000@aol.com by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id a.128.35da4563 (2168) for ; Sun, 23 Nov 2003 19:30:27 -0500 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_128.35da4563.2cf2ab23_boundary" X-Mailer: 7.0 for Windows sub 10705 Approved-By: Aaudu2000@AOL.COM Message-ID: <128.35da4563.2cf2ab23@aol.com> Date: Sun, 23 Nov 2003 19:30:27 EST Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --part1_128.35da4563.2cf2ab23_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi All, All this talk about the need and benefits of multicast certainly makes ones feel it is a cure all for what is being termed as the ailment in ForCEs' requirements. Look, it has to be told that you can't do multicast on the cheap. And you have to answer some key questions if you really want to sell multicast in a critical environment,..viz: 1) How would you guarrantee the relaible delivery of the messages being blasted to all the targets? What if the messages don't arrive at all their intended targets? How do you recover from this? This suggests you need a reliable multicast mechanism. I am not sure you can do this over UDP as it is currently being done in NetLink2. That is only good for un-reliable multicast. I am not sure if you can trust critical configuration messages like routing table information or basic LFB service/tree structure messages over such an unreliable mechanism. 2) How do you deal with the issue of security, given that we don't have secure multicast yet? I have seen some people call for broadcast capability also. One result of multicast/broadcast is you run the risk of a potential attacker listening in on say, the routing information being blasted to the FEs. I don't think multicasting over UDP has an answer to this. There is also this myth that all the FEs will have the same routing information always. I submit that this is not true. One of the problems ForCEs is meant to solve is scalability. This certainly relates to the abilty to manage the rapid growth of routing table sizes by distributing the routing information as partial routes into various FE groups. Granted there is still some scaling issues here,..but is definitely not as bad as people have been making it to be. ..more comments in-line... Regards, Alex. In a message dated 11/22/2003 12:03:24 PM Central Standard Time, hadi@znyx.com writes: > Continuation of the last thread with a change in topic - i think these > are the real issues that need to be addressed instead of the distraction > to "multicast is evil". > > Lets really list the requirements needed for a successful underlying > transport protocol that will serve ForCES well. i may be > missing some - but i hope to get challenged so i can add to them; > I am thinking of turning this into a draft so people read it first and > then post. > My previous email has some more claims which i will assume here. > > I. ForCES mechanisms requiring reliability: > > a) time limit very sensitive (in other words obsolence period is > faster): > Example table updates; > I have argued TCP doesnt qualify in my previous email. SCTP-PR may > qualify. > Something like what netlink2 over UDP qualifies because it gives control > to netlink2 to make such decisions. > How can you have reliable communcation over UDP? > b) time limit best effort (obsolence takes longer) > Sample apps: File transfers,etc. > TCP qualifies but AFAIK, we dont have this need. > > II. mechanisms capable of tolerating unreliability: Example psamp. > TCP doesnt qualify. > something(like netlink2) over UDP or SCTP-PR. > Why do you say TCP doesn't qualify here? Any application that can live with un-reliable transport can sure do better with a relaible one. > III. mechanisms that prefer timeliness over reliability: Ex heartbeats > something (like netlink2) over UDP or SCTP-PR. > > Clearly in the bigger picture TCP is not the best protocol. > UDP and SCTP-PR qualify partially merely because they dont hinder > progress not because they have some magic. Another non-IETF protocol > that would qualify is TIPC. I havent carefully studied DCCP but i > believe it also has a fit. I will exclude it because its not there yet. > > So, to summarize: the transport protocol that meets all the requirements > For Forces has not been born. > > Choosing TCP is choosing an answer and then trying to justify the > questions that it brings. It does sound like peer pressure instead of > looking at requirements and then deciding what you need to do. > I think we recognized this in netlink2 and made it clear that the choice > of underlying protocol chosen is up to the pre-association phase. > We compensate for "missing features" depending on the transport choice > (read the draft). > It's very few lines of code to provide that luxury. So the cost is low. > > Now on the choice of netlink2 UDP vs SCTP-PR > > 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > Netlink2 can run over it. For now we choose to be standalone: We can run > over IP, over UDP or over ethernet, you take your pick. > I believe SCTP-PR is now in IESG queue. Even when it is available, you have to run it in a reliable mode to guarantee that those critical configuration messages get to their destination safely. And it still doesn't buy you security. > 2) UDP provides multicast (and broadcast). SCTP-PR does not. > Since SCTP has turned to be a swiss knife (or maybe a multi faceted > beast), i am sure it will soon as well support multicast;-> > > If multicast is there - we will use it. Sans that we will do something > multicast like (Jon calls it unireplicate i think). > All the three cauthors have had pleasant experiences using multicast for > ForCES like. We think it is a good thing to have. But we will not > torture you if you dont have multicast or broadcast ;-> > > Why Multicast is useful: > -- > I must apologize since i have to repeat this. > In the simple case of a single multicast wire: each of the CEs or FEs > opens a single multicast socket/channel. > > Why is this good: > > 1) Bandwidth is less used > a)because one or more CEs can send a single message to all FEs. > I really dont want to be teaching people the hows but i will provide one > example which David or maybe it was Joel didnt seem to make sense out of > (but one that i have successfuly used)[1] > b) you can reduce the number of packets further by limiting on > ACKs (partial acks) > > 2) RAM on the embedded CE or FE is used less. There are less sockets > open and less messages being built > > 3) CPU is preserved more. > Since there are fewer messages to process and fewer (socket states) > states to track. > As far as I am concerned, the more critical resource CPU-wise is FE. The mutlicast scheme Netlink2 proposes blasts all every packet to every FE. Each FE has to do work to filter out which packet doesn't belong to it. Thus, the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles that should be best used in forwarding packets. > 4) The ability for all listeners on the wire to see message exchanges > even when not directed at them provides a cheap way to synchronize. And of course, if this is a malicious node, it will gladly gleam as much information as is enough to mount an attack. This is why secure multicast is necessary. > 5) At a transport level, (not the forces transaction level), having > access to multicast provides location transparency. > > 6) A lot of switch fabrics (shared memory designs or otherwise) > interconnecting FEs and CES have multicast capabilities; so it is good > if we can take advantage of it where possible. > > The above is the simple case, by induction you could extend the > reasoning to the case where you have X sockets. > > I dont want to preach multicast as panacea; we address some of the > limitations in the draft; however, i want it to be available when i need > it and not shoved down the toilet. > > So far apart from Joel (who implemented on ATM) on real boxes and Ram > (who did something very specific that needs unicast) the rest of the > arguements i have seen are from people who see the need for this > feature. You can choose to ignore it - and you may be influenced by some > implementation you are familiar with - thats your loss. I do think TCP > is valid for some cases (low latency and congestion), but i wouldnt > claim it to be the answer weve all been waiting for. > Again let me reiterate that Netlink2 does not need to have multicast (it > is a MAY) but would love to have it when it is available. We can run on > your favorite protocol TCP ;-> > > cheers, > jamal > > [1] I will give the example in another email - this one is already > getting too long. > --part1_128.35da4563.2cf2ab23_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All,

All this talk about the need and benefits of multicast certainly makes ones<= BR> feel it is a cure all for what is being termed as the ailment in ForCEs' req= uirements.

Look, it has to be told that you can't do multicast on the cheap. And you ha= ve
to answer some key questions if you really want to sell multicast in a criti= cal
environment,..viz:

1) How would you guarrantee the relaible delivery of the messages being
    blasted to all the targets? What if the messages don't ar= rive at all their
    intended targets? How do you recover from this? This sugg= ests you need
    a reliable multicast mechanism.  I am not sure you c= an do this over UDP
    as it is currently being done in NetLink2.  That is=20= only good for un-reliable
    multicast. I am not sure if you can trust critical config= uration messages
    like routing table information or basic LFB service/tree=20= structure messages
    over such an unreliable mechanism.

2) How do you deal with the issue of security, given that we don't have sec= ure
     multicast yet?  I have seen some people call f= or broadcast capability also.
     One result of multicast/broadcast is you run the ri= sk of a potential attacker
     listening in on say, the routing information being=20= blasted to the FEs. I don't
     think multicasting over UDP has an answer to this.&= nbsp; 


There is also this myth that all the FEs will have the same routing informat= ion
always. I submit that this is not true.  One of the problems ForCEs is=20= meant to
solve is scalability. This certainly relates to the abilty to manage the rap= id
growth of routing table sizes by distributing the routing information as par= tial
routes into various FE groups.  Granted there is still some scaling iss= ues
here,..but is definitely not as bad as people have been making it to be.

     ..more comments in-line...

Regards,
Alex.   

In a message dated 11/22/2003 12:03:24 PM Central Standard Time, hadi@znyx.c= om writes:


Continuation of the last thread= with a change in topic - i think these
are the real issues that need to be addressed instead of the distraction
to "multicast is evil".

Lets really list the requirements needed for a successful underlying
transport protocol that will serve ForCES well. i may be
missing some - but i hope to get challenged so i can add to them;
I am thinking of turning this into a draft so people read it first and
then post.
My previous email has some more claims which i will assume here.

I. ForCES  mechanisms requiring reliability:

a) time limit very sensitive (in other words obsolence period is
faster):
Example table updates;
I have argued TCP doesnt qualify in my previous email. SCTP-PR may
qualify.
Something like what netlink2 over UDP qualifies because it gives control
to netlink2 to make such decisions.


How can you have reliable co= mmuncation over UDP?

b) time limit best effort (obso= lence takes longer)
Sample apps: File transfers,etc.
TCP qualifies but AFAIK, we dont have this need.

II.  mechanisms capable of tolerating unreliability: Example psamp.
TCP doesnt qualify.
something(like netlink2) over UDP or SCTP-PR.


Why do you say TCP doesn't q= ualify here?  Any application that can live
with un-reliable transport can sure do better with a relaible one.

III. mechanisms that prefer tim= eliness over reliability: Ex heartbeats
something (like netlink2) over UDP or SCTP-PR.

Clearly in the bigger picture TCP is not the best protocol.
UDP and SCTP-PR qualify partially merely because they dont hinder
progress not because they have some magic. Another non-IETF protocol
that would qualify is TIPC. I havent carefully studied DCCP but i
believe it also has a fit. I will exclude it because its not there yet.

So, to summarize: the transport protocol that meets all the requirements
For Forces has not been born.

Choosing TCP is choosing an answer and then trying to justify the
questions that it brings. It does sound like peer pressure instead of
looking at requirements and then deciding what you need to do.
I think we recognized this in netlink2 and made it clear that the choice
of underlying protocol chosen is up to the pre-association phase.
We compensate for "missing features" depending on the transport choice
(read the draft).
It's very few lines of code to provide that luxury. So the cost is low.

Now on the choice of netlink2 UDP vs SCTP-PR

1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available
Netlink2 can run over it. For now we choose to be standalone: We can run
over IP, over UDP or over ethernet, you take your pick.


I believe SCTP-PR is now in=20= IESG queue. Even when it is available, you have
to run it in a reliable mode to guarantee that those critical configuration=20=
messages get to their destination safely. And it still doesn't buy you secur= ity.


2) UDP provides multicast (and=20= broadcast). SCTP-PR does not.
Since SCTP has turned to be a swiss knife (or maybe a multi faceted
beast), i am sure it will soon as well support multicast;->

If multicast is there - we will use it. Sans that we will do something
multicast like (Jon calls it unireplicate i think).
All the three cauthors have had pleasant experiences using multicast for
ForCES like. We think it is a good thing to have. But we will not
torture you if you dont have multicast or broadcast ;->

Why Multicast is useful:
--
I must apologize since i have to repeat this.
In the simple case of a single multicast wire: each of the CEs or FEs
opens a single multicast socket/channel.

Why is this good:

1) Bandwidth is less used
a)because one or more CEs can send a single message to all FEs.
I really dont want to be teaching people the hows but i will provide one
example which David or maybe it was Joel didnt seem to make sense out of
(but one that i have successfuly used)[1]
b) you can reduce the number of packets further by limiting on
ACKs (partial acks)

2) RAM on the embedded CE or FE is used less. There are less sockets
open and less messages being built

3) CPU is preserved more.
Since there are fewer messages to process and fewer (socket states)
states to track.


As far as I am concerned, th= e more critical resource CPU-wise is FE. The
mutlicast scheme Netlink2 proposes blasts all every packet to every FE.
Each FE has to do work to filter out which packet doesn't belong to it. Thus= ,
the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles that should be best used in forwarding packets.


4) The ability for all listener= s on the wire to see message exchanges
even when not directed at them provides a cheap way to synchronize.


And of course, if this is a=20= malicious node, it will gladly gleam as much information
as is enough to mount an attack. This is why secure multicast is necessary.<= /FONT>

5) At a transport level, (not t= he forces transaction level), having
access to multicast provides location transparency.

6) A lot of switch fabrics (shared memory designs or otherwise)
interconnecting FEs and CES have multicast capabilities; so it is good
if we can take advantage of it where possible.

The above is the simple case, by induction you could extend the
reasoning to the case where you have X sockets.

I dont want to preach multicast as panacea; we address some of the
limitations in the draft; however, i want it to be available when i need
it and not shoved down the toilet.

So far apart from Joel (who implemented on ATM) on real boxes and Ram
(who did something very specific that needs unicast) the rest of the
arguements i have seen are from people who see the need for this
feature. You can choose to ignore it - and you may be influenced by some
implementation you are familiar with - thats your loss. I do think TCP
is valid for some cases (low latency and congestion), but i wouldnt
claim it to be the answer weve all been waiting for.
Again let me reiterate that Netlink2 does not need to have multicast (it
is a MAY) but would love to have it when it is available. We can run on
your favorite protocol TCP ;->

cheers,
jamal

[1] I will give the example in another email - this one is already
getting too long.


 --part1_128.35da4563.2cf2ab23_boundary-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 23 22:37:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09765 for ; Sun, 23 Nov 2003 22:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO7Xw-0003xM-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 22:37:56 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AO7Xv-0003x8-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 22:37:55 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C550AF@cherry.ease.lsoft.com>; 23 Nov 2003 22:37:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61715892 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Nov 2003 22:37:22 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Nov 2003 22:37:22 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAO3c821000977 for ; Mon, 24 Nov 2003 03:38:08 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAO3VPP22913 for ; Mon, 24 Nov 2003 03:31:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112319372128705 for ; Sun, 23 Nov 2003 19:37:21 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 23 Nov 2003 19:37:21 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOx2v6dHS7Y39lzS8G9J+dP+GDGUAAXaYhA X-OriginalArrivalTime: 24 Nov 2003 03:37:21.0174 (UTC) FILETIME=[4464BB60:01C3B23C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F549E7@orsmsx410.jf.intel.com> Date: Sun, 23 Nov 2003 19:37:21 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I don't see why this has to be a religious debate. No body is saying "unicast is good, multicast is evil" This should not be the approach for making technical decisions. Unicast and multicast both have their merits and drawbacks and we have to select one that best meets our needs. Unicast has been working well for a long time in client/server, Master/slave type of environment. Multicast fits well for Peer-to-peer environment. ForCES is clearly a master/slave environment, where the CE is the master or controller and=20 the FE is the slave or the element being controlled. Hopefully, there should be no disagreement on this basic idea. In addition, we have certain reliability and security requirements that need to be fulfilled. On the issue of scalability let me try to give an example which will bring to light the importance of congestion control. OSPF has been stated as one of the main examples of a protocol which uses=20 multicast as one of its transports in multicast enabled networks. One of the current OSPF WG drafts... http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt Talks about recommendations for improving OSPF scalability in large networks. It specifically recommends prioritization and congestion avoidance procedures to help improve the scalability. This draft is not just based on implementation, but also deployment experience by a=20 large operator (AT&T). regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, November 23, 2003 8:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Sigh. We are back to square one. We have two religious views based on our implementation experiences. Ive just spent 10 emails explaining why i dont think TCP is sufficient by itself and why multicast transport is useful;-> Ive been on enough threads on usenet and email to wisen up and know when to stop.[1] This is the point where reasonable people agree to disagree and end the discussion. If this was an implementation this is where we fork ;-> cheers, jamal PS: Selection of what gets used for transport is a pre-association config issue not sure what you see as being interoperable with that. [1]Otherwise you will make me repeat everything i said in the last 10 emails and you will then repeat exactly what you say below. Its a vicious cycle - you have not changed my views on multicast and neither have i changed yours. From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 23 22:50:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10172 for ; Sun, 23 Nov 2003 22:50:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO7kG-00047e-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 22:50:40 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AO7kG-00047b-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 22:50:40 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C54FDB@cherry.ease.lsoft.com>; 23 Nov 2003 22:50:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61716391 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Nov 2003 22:50:38 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Nov 2003 22:50:38 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112319494817:7427 ; Sun, 23 Nov 2003 19:49:48 -0800 References: <128.35da4563.2cf2ab23@aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 07:49:49 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 07:49:50 PM, Serialize complete at 11/23/2003 07:49:50 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069645835.1035.132.camel@jzny.localdomain> Date: Sun, 23 Nov 2003 22:50:35 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <128.35da4563.2cf2ab23@aol.com> Precedence: list Content-Transfer-Encoding: 7bit On Sun, 2003-11-23 at 19:30, Alex Audu wrote: > Hi All, > > All this talk about the need and benefits of multicast certainly makes > ones > feel it is a cure all for what is being termed as the ailment in > ForCEs' requirements. > It is useful to have; it is not listed as a requirement - just like congestion control is not listed as a requirement in the non-global scope but useful to have. > Look, it has to be told that you can't do multicast on the cheap. And You will have to show me a single switch fabric that cant do multicast or broadcast. Pick any netgear or dlink $1 switch and show me it doesnt support multicast. How cheap do you want to go? > you have > to answer some key questions if you really want to sell multicast in a > critical > environment,..viz: [deleted things which have been repeated in the last 10 emails on this subject for brevity] > > There is also this myth that all the FEs will have the same routing > information > always. All examples i have seen say that most not all. > I submit that this is not true. One of the problems ForCEs is meant > to > solve is scalability. This certainly relates to the abilty to manage > the rapid > growth of routing table sizes by distributing the routing information > as partial > routes into various FE groups. Granted there is still some scaling > issues > here,..but is definitely not as bad as people have been making it to > be. > I am not sure i followed. Are we back to the topic that the problem is a startup issue? > ..more comments in-line... Thanks for being brave and addresing these issues. > Regards, > Alex. > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > hadi@znyx.com writes: > > > > Continuation of the last thread with a change in topic - i think > > these > > are the real issues that need to be addressed instead of the > > distraction > > to "multicast is evil". > > > > Lets really list the requirements needed for a successful underlying > > transport protocol that will serve ForCES well. i may be > > missing some - but i hope to get challenged so i can add to them; > > I am thinking of turning this into a draft so people read it first > > and > > then post. > > My previous email has some more claims which i will assume here. > > > > I. ForCES mechanisms requiring reliability: > > > > a) time limit very sensitive (in other words obsolence period is > > faster): > > Example table updates; > > I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > qualify. > > Something like what netlink2 over UDP qualifies because it gives > > control > > to netlink2 to make such decisions. > > > How can you have reliable communcation over UDP? > The mechanisms would be a retransmit timer and ability to get ACKs or NACKs. Note the definition of reliability includes a valid time. So this validity is best controled by the app (the ForCES protocol). TCP doesnt allow you to do this. > > II. mechanisms capable of tolerating unreliability: Example psamp. > > TCP doesnt qualify. > > something(like netlink2) over UDP or SCTP-PR. > > > Why do you say TCP doesn't qualify here? Any application that can > live > with un-reliable transport can sure do better with a relaible one. > You are right. TCP qualifies and the other two as well. > > III. mechanisms that prefer timeliness over reliability: Ex > > heartbeats > > something (like netlink2) over UDP or SCTP-PR. > > I take it you agree TCP fails if you really value timelines. > > Now on the choice of netlink2 UDP vs SCTP-PR > > > > 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > > Netlink2 can run over it. For now we choose to be standalone: We can > > run > > over IP, over UDP or over ethernet, you take your pick. > > I believe SCTP-PR is now in IESG queue. Even when it is available, you > have > to run it in a reliable mode to guarantee that those critical > configuration > messages get to their destination safely. And it still doesn't buy you > security. I think it has been issued RFC status. SCTP-PR would be a better choice than TCP. Because it will give user control of removing stale messages. > > > 2) UDP provides multicast (and broadcast). SCTP-PR does not. > > Since SCTP has turned to be a swiss knife (or maybe a multi faceted > > beast), i am sure it will soon as well support multicast;-> > > > > If multicast is there - we will use it. Sans that we will do > > something > > multicast like (Jon calls it unireplicate i think). > > All the three cauthors have had pleasant experiences using multicast > > for > > ForCES like. We think it is a good thing to have. But we will not > > torture you if you dont have multicast or broadcast ;-> > > > > Why Multicast is useful: > > -- > > I must apologize since i have to repeat this. > > In the simple case of a single multicast wire: each of the CEs or > > FEs > > opens a single multicast socket/channel. > > > > Why is this good: > > > > 1) Bandwidth is less used > > a)because one or more CEs can send a single message to all FEs. > > I really dont want to be teaching people the hows but i will provide > > one > > example which David or maybe it was Joel didnt seem to make sense > > out of > > (but one that i have successfuly used)[1] > > b) you can reduce the number of packets further by limiting on > > ACKs (partial acks) > > > > 2) RAM on the embedded CE or FE is used less. There are less sockets > > open and less messages being built > > I take it you agree with the above two ;-> > > 3) CPU is preserved more. > > Since there are fewer messages to process and fewer (socket states) > > states to track. > > > As far as I am concerned, the more critical resource CPU-wise is FE. > The > mutlicast scheme Netlink2 proposes blasts all every packet to every > FE. > Each FE has to do work to filter out which packet doesn't belong to > it. Thus, > the FE spends a lot of CPU cycles filtering off unwanted > packets,..cycles > that should be best used in forwarding packets. > I wasnt sure whether i should respond to this or not. I have addressed it in previous emails and it is addresed in the draft. For brevity: Yes this may become an issue, but there are solutions. > > > 4) The ability for all listeners on the wire to see message > > exchanges > > even when not directed at them provides a cheap way to synchronize. > > > And of course, if this is a malicious node, it will gladly gleam as > much information > as is enough to mount an attack. This is why secure multicast is > necessary. The MSEC people showed up at the last WG meeting - it is too bad that noone raised this issue. I dont wanna discuss this - its a separate issue. It is solvable. Let me ask the following since you bring the issue of scalability: If you were to encrypt messages, would it be cheaper to encrypt two multicasted flows or 8 unireplicated flows? I have seen processors having problem with a single flow. > > 5) At a transport level, (not the forces transaction level), having > > access to multicast provides location transparency. > > I take it you agree with this. > > 6) A lot of switch fabrics (shared memory designs or otherwise) > > interconnecting FEs and CES have multicast capabilities; so it is > > good > > if we can take advantage of it where possible. > > I take it you agree with this. > > The above is the simple case, by induction you could extend the > > reasoning to the case where you have X sockets. > > I take it you agree with this as well. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Nov 23 23:13:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10590 for ; Sun, 23 Nov 2003 23:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO86p-0004NN-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 23:13:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AO86o-0004NJ-00 for forces-archive@IETF.ORG; Sun, 23 Nov 2003 23:13:58 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C553F8@cherry.ease.lsoft.com>; 23 Nov 2003 23:13:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61718945 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Nov 2003 23:13:57 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Nov 2003 23:13:56 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112320130712:7437 ; Sun, 23 Nov 2003 20:13:07 -0800 References: <9CB758BBEE58754F8F33234D75B9F4B0F549E7@orsmsx410.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 08:13:07 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/23/2003 08:13:09 PM, Serialize complete at 11/23/2003 08:13:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069647229.1037.157.camel@jzny.localdomain> Date: Sun, 23 Nov 2003 23:13:49 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0F549E7@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Sun, 2003-11-23 at 22:37, Khosravi, Hormuzd M wrote: > I don't see why this has to be a religious debate. It is when you discuss for a long time and reach the same conclusion you both had when you started. > No body is saying "unicast is good, multicast is evil" > This should not be the approach for making technical decisions. > Unicast and multicast both have their merits and drawbacks > and we have to select one that best meets our needs. Do you think TCP satisfies all the requirements? Please read my email on this topic before responding. It will be that religious discussion i am talking about if you dont read the emails. BTW, When did we say we have to choose one over the other? Could they both be supported maybe? This is a config issue. Noone has ever ruled out unicast. I dont understand why you are so adamant on ruling out multicast. Let me guess: could it be because FACT doesnt support it? > Unicast has been working well for a long time in client/server, > Master/slave type of environment. Multicast fits well for > Peer-to-peer environment. ForCES is clearly a master/slave > environment, where the CE is the master or controller and > the FE is the slave or the element being controlled. Hopefully, > there should be no disagreement on this basic idea. In addition, Multicast typically has a sender (the CE in this case mostly) and one or more receivers (the FE in the case of ForCES). The FE could send an unsolicited event. Whatever terminology you end up calling such a setup is unimportant. I am just curious why you are bringing this topic? > we have certain reliability and security requirements that need > to be fulfilled. And they are being met. > On the issue of scalability let me try to give an example which > will bring to light the importance of congestion control. OSPF has > been stated as one of the main examples of a protocol which uses > multicast as one of its transports in multicast enabled networks. > One of the current OSPF WG drafts... > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt > Talks about recommendations for improving OSPF scalability in large > networks. It specifically recommends prioritization and congestion > avoidance procedures to help improve the scalability. This draft is > not just based on implementation, but also deployment experience by a > large operator (AT&T). > Good, we can learn from it. How exactly does this say multicast is bad? I did search for the word multicast on that draft and it is not mentioend once. But you are probably refering to it because OSPF uses multicast - I would say it is a good proof there is something good about multicast. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 02:02:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17222 for ; Mon, 24 Nov 2003 02:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAjt-0007BC-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 02:02:29 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOAjs-0007B9-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 02:02:28 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C55695@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 2:02:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61727537 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 02:02:24 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 02:02:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 MIME-Version: 1.0 X-MS-TNEF-Correlator: Thread-Topic: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOyQYofOCqE+l8KS6q6ya6YeCwk+AAFt6p1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Approved-By: Tal Anker Message-ID: Date: Mon, 24 Nov 2003 09:02:36 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 QWxsLA0KSSBkbyBiZWxpZXZlIHRoYXQgdGhpcyB0aHJlYWQgc2hvdWxkIGNvbnZlcmdlIHRvIF9z b21lXyByZXN1bHQuLi4NCkkgdGhpbmsgSSByZW1lbWJlciBzb21lb25lIHNheWluZyBoZSBpcyB3 cml0aW5nIGEgZHJhZnQgdG8gY2FwdHVyZSBhbGwgdGhlIGlzc3VlcyB3aXRoIG11bHRpY2FzdCBh bmQgZm9yY2VzLi4uSSBiZWxpZXZlIHRoaXMgaXMgYSBnb29kIGRpcmVjdGlvbiAobWF5YmUgdGhl IGRyYWZ0IGNhbiBhbHNvIGluZGljYXRlIHJlcXVpcmVtZW50cyBvZiB0aGUgZm9yY2VzIHByb3Rv Y29sIHNvIHRoYXQgaXQgY2FuIGxhdGVyIHdvcmsgb3ZlciBbcmVsaWFibGUgP10gbXVsdGljYXN0 IHRyYW5zcG9ydC4uLikuIFdoeSBkb24ndCB3ZSB3YWl0IGZvciB0aGUgZHJhZnQgdG8gYmUgYXZh aWxhYmxlIChvciBpcyB0aGVyZSBhIHRpbWUgaXNzdWUgaGVyZSB0aGF0IEkgYW0gbm90IGF3YXJl IG9mLi4uIC0gYXNzdW1pbmcgdGhlIGRyYWZ0IHdvdWxkIG5vdCB0YWtlIHRvbyBsb25nIC4uLiku DQogDQotIFRhbA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogSmFtYWwg SGFkaSBTYWxpbSBbbWFpbHRvOmhhZGlAem55eC5jb21dIA0KCVNlbnQ6IE1vbiAxMS8yNC8yMDAz IDY6MTMgQU0gDQoJVG86IEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTSANCglDYzogDQoJU3Vi amVjdDogUmU6IEZvckNFUyB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIFdBUyAoUmU6IFN1cHBvcnQg Zm9yIG11bHRpY2FzdCBpbiB0aGUgRm9yQ0VTIHByb3RvY29sDQoJDQoJDQoNCglPbiBTdW4sIDIw MDMtMTEtMjMgYXQgMjI6MzcsIEtob3NyYXZpLCBIb3JtdXpkIE0gd3JvdGU6DQoJPiBJIGRvbid0 IHNlZSB3aHkgdGhpcyBoYXMgdG8gYmUgYSByZWxpZ2lvdXMgZGViYXRlLg0KCQ0KCUl0IGlzIHdo ZW4geW91IGRpc2N1c3MgZm9yIGEgbG9uZyB0aW1lIGFuZCByZWFjaCB0aGUgc2FtZQ0KCWNvbmNs dXNpb24geW91IGJvdGggaGFkIHdoZW4geW91IHN0YXJ0ZWQuDQoJDQoJPiBObyBib2R5IGlzIHNh eWluZyAidW5pY2FzdCBpcyBnb29kLCBtdWx0aWNhc3QgaXMgZXZpbCINCgk+IFRoaXMgc2hvdWxk IG5vdCBiZSB0aGUgYXBwcm9hY2ggZm9yIG1ha2luZyB0ZWNobmljYWwgZGVjaXNpb25zLg0KCT4g VW5pY2FzdCBhbmQgbXVsdGljYXN0IGJvdGggaGF2ZSB0aGVpciBtZXJpdHMgYW5kIGRyYXdiYWNr cw0KCT4gYW5kIHdlIGhhdmUgdG8gc2VsZWN0IG9uZSB0aGF0IGJlc3QgbWVldHMgb3VyIG5lZWRz Lg0KCQ0KCURvIHlvdSB0aGluayBUQ1Agc2F0aXNmaWVzIGFsbCB0aGUgcmVxdWlyZW1lbnRzPw0K CVBsZWFzZSByZWFkIG15IGVtYWlsIG9uIHRoaXMgdG9waWMgYmVmb3JlIHJlc3BvbmRpbmcuIEl0 IHdpbGwgYmUNCgl0aGF0IHJlbGlnaW91cyBkaXNjdXNzaW9uIGkgYW0gdGFsa2luZyBhYm91dCBp ZiB5b3UgZG9udCByZWFkIHRoZQ0KCWVtYWlscy4NCglCVFcsIFdoZW4gZGlkIHdlIHNheSB3ZSBo YXZlIHRvIGNob29zZSBvbmUgb3ZlciB0aGUgb3RoZXI/DQoJQ291bGQgdGhleSBib3RoIGJlIHN1 cHBvcnRlZCBtYXliZT8NCglUaGlzIGlzIGEgY29uZmlnIGlzc3VlLiBOb29uZSBoYXMgZXZlciBy dWxlZCBvdXQgdW5pY2FzdC4gSSBkb250DQoJdW5kZXJzdGFuZCB3aHkgeW91IGFyZSBzbyBhZGFt YW50IG9uIHJ1bGluZyBvdXQgbXVsdGljYXN0LiBMZXQgbWUgZ3Vlc3M6DQoJY291bGQgaXQgYmUg YmVjYXVzZSBGQUNUIGRvZXNudCBzdXBwb3J0IGl0Pw0KCQ0KCT4gVW5pY2FzdCBoYXMgYmVlbiB3 b3JraW5nIHdlbGwgZm9yIGEgbG9uZyB0aW1lIGluIGNsaWVudC9zZXJ2ZXIsDQoJPiBNYXN0ZXIv c2xhdmUgdHlwZSBvZiBlbnZpcm9ubWVudC4gTXVsdGljYXN0IGZpdHMgd2VsbCBmb3INCgk+IFBl ZXItdG8tcGVlciBlbnZpcm9ubWVudC4gRm9yQ0VTIGlzIGNsZWFybHkgYSBtYXN0ZXIvc2xhdmUN Cgk+IGVudmlyb25tZW50LCB3aGVyZSB0aGUgQ0UgaXMgdGhlIG1hc3RlciBvciBjb250cm9sbGVy IGFuZA0KCT4gdGhlIEZFIGlzIHRoZSBzbGF2ZSBvciB0aGUgZWxlbWVudCBiZWluZyBjb250cm9s bGVkLiBIb3BlZnVsbHksDQoJPiB0aGVyZSBzaG91bGQgYmUgbm8gZGlzYWdyZWVtZW50IG9uIHRo aXMgYmFzaWMgaWRlYS4gSW4gYWRkaXRpb24sDQoJDQoJTXVsdGljYXN0IHR5cGljYWxseSBoYXMg YSBzZW5kZXIgKHRoZSBDRSBpbiB0aGlzIGNhc2UgbW9zdGx5KSBhbmQgb25lDQoJb3IgbW9yZSBy ZWNlaXZlcnMgKHRoZSBGRSBpbiB0aGUgY2FzZSBvZiBGb3JDRVMpLiBUaGUgRkUgY291bGQgc2Vu ZCBhbg0KCXVuc29saWNpdGVkIGV2ZW50LiBXaGF0ZXZlciB0ZXJtaW5vbG9neSB5b3UgZW5kIHVw IGNhbGxpbmcgc3VjaA0KCWEgc2V0dXAgaXMgdW5pbXBvcnRhbnQuDQoJSSBhbSBqdXN0IGN1cmlv dXMgd2h5IHlvdSBhcmUgYnJpbmdpbmcgdGhpcyB0b3BpYz8NCgkNCgk+IHdlIGhhdmUgY2VydGFp biByZWxpYWJpbGl0eSBhbmQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIHRoYXQgbmVlZA0KCT4gdG8g YmUgZnVsZmlsbGVkLg0KCQ0KCUFuZCB0aGV5IGFyZSBiZWluZyBtZXQuDQoJDQoJPiBPbiB0aGUg aXNzdWUgb2Ygc2NhbGFiaWxpdHkgbGV0IG1lIHRyeSB0byBnaXZlIGFuIGV4YW1wbGUgd2hpY2gN Cgk+IHdpbGwgYnJpbmcgdG8gbGlnaHQgdGhlIGltcG9ydGFuY2Ugb2YgY29uZ2VzdGlvbiBjb250 cm9sLiBPU1BGIGhhcw0KCT4gYmVlbiBzdGF0ZWQgYXMgb25lIG9mIHRoZSBtYWluIGV4YW1wbGVz IG9mIGEgcHJvdG9jb2wgd2hpY2ggdXNlcw0KCT4gbXVsdGljYXN0IGFzIG9uZSBvZiBpdHMgdHJh bnNwb3J0cyBpbiBtdWx0aWNhc3QgZW5hYmxlZCBuZXR3b3Jrcy4NCgk+IE9uZSBvZiB0aGUgY3Vy cmVudCBPU1BGIFdHIGRyYWZ0cy4uLg0KCT4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1vc3BmLXNjYWxhYmlsaXR5LTA2LnR4dA0KCT4gVGFsa3MgYWJvdXQg cmVjb21tZW5kYXRpb25zIGZvciBpbXByb3ZpbmcgT1NQRiBzY2FsYWJpbGl0eSBpbiBsYXJnZQ0K CT4gbmV0d29ya3MuIEl0IHNwZWNpZmljYWxseSByZWNvbW1lbmRzIHByaW9yaXRpemF0aW9uIGFu ZCBjb25nZXN0aW9uDQoJPiBhdm9pZGFuY2UgcHJvY2VkdXJlcyB0byBoZWxwIGltcHJvdmUgdGhl IHNjYWxhYmlsaXR5LiBUaGlzIGRyYWZ0IGlzDQoJPiBub3QganVzdCBiYXNlZCBvbiBpbXBsZW1l bnRhdGlvbiwgYnV0IGFsc28gZGVwbG95bWVudCBleHBlcmllbmNlIGJ5IGENCgk+IGxhcmdlIG9w ZXJhdG9yIChBVCZUKS4NCgk+DQoJDQoJR29vZCwgd2UgY2FuIGxlYXJuIGZyb20gaXQuIEhvdyBl eGFjdGx5IGRvZXMgdGhpcyBzYXkgbXVsdGljYXN0IGlzIGJhZD8NCglJIGRpZCBzZWFyY2ggZm9y IHRoZSB3b3JkIG11bHRpY2FzdCBvbiB0aGF0IGRyYWZ0IGFuZCBpdCBpcyBub3QNCgltZW50aW9l bmQgb25jZS4gQnV0IHlvdSBhcmUgcHJvYmFibHkgcmVmZXJpbmcgdG8gaXQgYmVjYXVzZSBPU1BG IHVzZXMNCgltdWx0aWNhc3QgLSBJIHdvdWxkIHNheSBpdCBpcyBhIGdvb2QgcHJvb2YgdGhlcmUg aXMgc29tZXRoaW5nIGdvb2QgYWJvdXQNCgltdWx0aWNhc3QuDQoJDQoJY2hlZXJzLA0KCWphbWFs DQoJDQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 03:29:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29596 for ; Mon, 24 Nov 2003 03:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOC6I-0000O2-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 03:29:42 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOC6H-0000Nz-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 03:29:41 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C5579D@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 3:29:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61730033 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 03:29:09 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 03:29:08 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAO8T3Bs095026 for ; Mon, 24 Nov 2003 08:29:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAO8SxQB283088 for ; Mon, 24 Nov 2003 09:28:59 +0100 Received: from zurich.ibm.com (dhcp69-114.zurich.ibm.com [9.4.69.114]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA71526; Mon, 24 Nov 2003 09:28:58 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030705080507030505050907" Approved-By: Patrick Droz Message-ID: <3FC1C145.1030602@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:28:53 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <128.35da4563.2cf2ab23@aol.com> Precedence: list This is a cryptographically signed message in MIME format. --------------ms030705080507030505050907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [chair hat off] see comments inline Alex Audu wrote: > Hi All, > > All this talk about the need and benefits of multicast certainly makes ones > feel it is a cure all for what is being termed as the ailment in ForCEs' > requirements. > > Look, it has to be told that you can't do multicast on the cheap. And > you have > to answer some key questions if you really want to sell multicast in a > critical > environment,..viz: > > 1) How would you guarrantee the relaible delivery of the messages being > blasted to all the targets? What if the messages don't arrive at all > their > intended targets? How do you recover from this? This suggests you need > a reliable multicast mechanism. I am not sure you can do this over UDP > as it is currently being done in NetLink2. That is only good for > un-reliable > multicast. I am not sure if you can trust critical configuration > messages > like routing table information or basic LFB service/tree structure > messages > over such an unreliable mechanism. > > 2) How do you deal with the issue of security, given that we don't have > secure > multicast yet? I have seen some people call for broadcast > capability also. > One result of multicast/broadcast is you run the risk of a > potential attacker > listening in on say, the routing information being blasted to the > FEs. I don't > think multicasting over UDP has an answer to this. > > > There is also this myth that all the FEs will have the same routing > information could you please provide some evidence of this? Keep in mind we are moving from a centralized (single routing table) to a distributed router architecture. Why should it change that the routing table should be much different. Or do you want to go into the discussion of how you avoid routing loops? > always. I submit that this is not true. One of the problems ForCEs is > meant to > solve is scalability. This certainly relates to the abilty to manage the > rapid > growth of routing table sizes by distributing the routing information as > partial > routes into various FE groups. Granted there is still some scaling issues > here,..but is definitely not as bad as people have been making it to be. > > ..more comments in-line... > > Regards, > Alex. Regards, Patrick > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > hadi@znyx.com writes: > > >> Continuation of the last thread with a change in topic - i think these >> are the real issues that need to be addressed instead of the distraction >> to "multicast is evil". >> >> Lets really list the requirements needed for a successful underlying >> transport protocol that will serve ForCES well. i may be >> missing some - but i hope to get challenged so i can add to them; >> I am thinking of turning this into a draft so people read it first and >> then post. >> My previous email has some more claims which i will assume here. >> >> I. ForCES mechanisms requiring reliability: >> >> a) time limit very sensitive (in other words obsolence period is >> faster): >> Example table updates; >> I have argued TCP doesnt qualify in my previous email. SCTP-PR may >> qualify. >> Something like what netlink2 over UDP qualifies because it gives control >> to netlink2 to make such decisions. > > > > How can you have reliable communcation over UDP? > >> b) time limit best effort (obsolence takes longer) >> Sample apps: File transfers,etc. >> TCP qualifies but AFAIK, we dont have this need. >> >> II. mechanisms capable of tolerating unreliability: Example psamp. >> TCP doesnt qualify. >> something(like netlink2) over UDP or SCTP-PR. > > > > Why do you say TCP doesn't qualify here? Any application that can live > with un-reliable transport can sure do better with a relaible one. > >> III. mechanisms that prefer timeliness over reliability: Ex heartbeats >> something (like netlink2) over UDP or SCTP-PR. >> >> Clearly in the bigger picture TCP is not the best protocol. >> UDP and SCTP-PR qualify partially merely because they dont hinder >> progress not because they have some magic. Another non-IETF protocol >> that would qualify is TIPC. I havent carefully studied DCCP but i >> believe it also has a fit. I will exclude it because its not there yet. >> >> So, to summarize: the transport protocol that meets all the requirements >> For Forces has not been born. >> >> Choosing TCP is choosing an answer and then trying to justify the >> questions that it brings. It does sound like peer pressure instead of >> looking at requirements and then deciding what you need to do. >> I think we recognized this in netlink2 and made it clear that the choice >> of underlying protocol chosen is up to the pre-association phase. >> We compensate for "missing features" depending on the transport choice >> (read the draft). >> It's very few lines of code to provide that luxury. So the cost is low. >> >> Now on the choice of netlink2 UDP vs SCTP-PR >> >> 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available >> Netlink2 can run over it. For now we choose to be standalone: We can run >> over IP, over UDP or over ethernet, you take your pick. > > > > I believe SCTP-PR is now in IESG queue. Even when it is available, you have > to run it in a reliable mode to guarantee that those critical configuration > messages get to their destination safely. And it still doesn't buy you > security. > > >> 2) UDP provides multicast (and broadcast). SCTP-PR does not. >> Since SCTP has turned to be a swiss knife (or maybe a multi faceted >> beast), i am sure it will soon as well support multicast;-> >> >> If multicast is there - we will use it. Sans that we will do something >> multicast like (Jon calls it unireplicate i think). >> All the three cauthors have had pleasant experiences using multicast for >> ForCES like. We think it is a good thing to have. But we will not >> torture you if you dont have multicast or broadcast ;-> >> >> Why Multicast is useful: >> -- >> I must apologize since i have to repeat this. >> In the simple case of a single multicast wire: each of the CEs or FEs >> opens a single multicast socket/channel. >> >> Why is this good: >> >> 1) Bandwidth is less used >> a)because one or more CEs can send a single message to all FEs. >> I really dont want to be teaching people the hows but i will provide one >> example which David or maybe it was Joel didnt seem to make sense out of >> (but one that i have successfuly used)[1] >> b) you can reduce the number of packets further by limiting on >> ACKs (partial acks) >> >> 2) RAM on the embedded CE or FE is used less. There are less sockets >> open and less messages being built >> >> 3) CPU is preserved more. >> Since there are fewer messages to process and fewer (socket states) >> states to track. > > > > As far as I am concerned, the more critical resource CPU-wise is FE. The > mutlicast scheme Netlink2 proposes blasts all every packet to every FE. > Each FE has to do work to filter out which packet doesn't belong to it. > Thus, > the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles > that should be best used in forwarding packets. > > >> 4) The ability for all listeners on the wire to see message exchanges >> even when not directed at them provides a cheap way to synchronize. > > > > And of course, if this is a malicious node, it will gladly gleam as much > information > as is enough to mount an attack. This is why secure multicast is necessary. > >> 5) At a transport level, (not the forces transaction level), having >> access to multicast provides location transparency. >> >> 6) A lot of switch fabrics (shared memory designs or otherwise) >> interconnecting FEs and CES have multicast capabilities; so it is good >> if we can take advantage of it where possible. >> >> The above is the simple case, by induction you could extend the >> reasoning to the case where you have X sockets. >> >> I dont want to preach multicast as panacea; we address some of the >> limitations in the draft; however, i want it to be available when i need >> it and not shoved down the toilet. >> >> So far apart from Joel (who implemented on ATM) on real boxes and Ram >> (who did something very specific that needs unicast) the rest of the >> arguements i have seen are from people who see the need for this >> feature. You can choose to ignore it - and you may be influenced by some >> implementation you are familiar with - thats your loss. I do think TCP >> is valid for some cases (low latency and congestion), but i wouldnt >> claim it to be the answer weve all been waiting for. >> Again let me reiterate that Netlink2 does not need to have multicast (it >> is a MAY) but would love to have it when it is available. We can run on >> your favorite protocol TCP ;-> >> >> cheers, >> jamal >> >> [1] I will give the example in another email - this one is already >> getting too long. > > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms030705080507030505050907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjQw ODI4NTNaMCMGCSqGSIb3DQEJBDEWBBQJNbwtbpIGLmhcKg5xw2y5qWYDPDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgF0WeKZ5zPYPgghGRqVFnVKhz4rNSKyiU7lb g747/xCIsIAbcRbKaI5BaqRL3ibIbkSd7cM3LqmvNcbYpsNhFcbfCUz8vyX0t/+WqJbUYVxi HVyBTZJaI10NM55UQxp8WoO7NBKYlaStMaVE06mXqVhUyibobjzZ8dzdgQt4BOHQAAAAAAAA --------------ms030705080507030505050907-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 03:45:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00072 for ; Mon, 24 Nov 2003 03:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCLu-0000aF-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 03:45:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOCLu-0000aC-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 03:45:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C55759@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 3:45:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61730645 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 03:45:49 -0500 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 03:45:49 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAO8jmIi058296 for ; Mon, 24 Nov 2003 08:45:48 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAO8jmQB225612 for ; Mon, 24 Nov 2003 09:45:48 +0100 Received: from zurich.ibm.com (dhcp69-114.zurich.ibm.com [9.4.69.114]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA54308; Mon, 24 Nov 2003 09:45:47 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0F549E7@orsmsx410.jf.intel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040503060900070803040300" Approved-By: Patrick Droz Message-ID: <3FC1C536.9030508@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:45:42 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0F549E7@orsmsx410.jf.intel.com> Precedence: list This is a cryptographically signed message in MIME format. --------------ms040503060900070803040300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [chair hat off] Hormuzd, Khosravi, Hormuzd M wrote: > I don't see why this has to be a religious debate. > No body is saying "unicast is good, multicast is evil" > This should not be the approach for making technical decisions. > Unicast and multicast both have their merits and drawbacks > and we have to select one that best meets our needs. why you say one? why is it not both? > > Unicast has been working well for a long time in client/server, > Master/slave type of environment. Multicast fits well for > Peer-to-peer environment. ForCES is clearly a master/slave why is it not a master and many slaves? > environment, where the CE is the master or controller and > the FE is the slave or the element being controlled. Hopefully, > there should be no disagreement on this basic idea. In addition, > we have certain reliability and security requirements that need > to be fulfilled. I agree on this as long as you also mention that we usually will have a small number of masters but maybe a very large number of slaves. > > On the issue of scalability let me try to give an example which > will bring to light the importance of congestion control. OSPF has > been stated as one of the main examples of a protocol which uses > multicast as one of its transports in multicast enabled networks. > One of the current OSPF WG drafts... > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt > Talks about recommendations for improving OSPF scalability in large > networks. It specifically recommends prioritization and congestion > avoidance procedures to help improve the scalability. This draft is > not just based on implementation, but also deployment experience by a > large operator (AT&T). > how can you compare OSPF with ForCES? OSPF is a protocol that is deployed over many nodes in general. ForCES will be in many cases just used inside a single box. Could you please elaborate and tell us what is the relationship between ForCES and OSPF. > > regards > Hormuzd > Regards, Patrick > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Sunday, November 23, 2003 8:01 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for > multicast in the ForCES protocol > > > Sigh. We are back to square one. We have two religious views based on > our implementation experiences. Ive just spent 10 emails explaining why > i dont think TCP is sufficient by itself and why multicast transport is > useful;-> Ive been on enough threads on usenet and email to wisen up > and know when to stop.[1] > This is the point where reasonable people agree to disagree and end the > discussion. If this was an implementation this is where we fork ;-> > > cheers, > jamal > > PS: Selection of what gets used for transport is a pre-association > config issue not sure what you see as being interoperable with that. > > [1]Otherwise you will make me repeat everything i said in the last 10 > emails and you will then repeat exactly what you say below. Its a > vicious cycle - you have not changed my views on multicast and neither > have i changed yours. > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms040503060900070803040300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjQw ODQ1NDJaMCMGCSqGSIb3DQEJBDEWBBQiFnavD6hKpzL9M3oSBBcj5Dv3wDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgI2ssPkG5uYvzqEo95uyUaCRvsQ3ej9OsIDj eSi4JEUUjbfMh4frnzhNByWmYtvnFKBPEJy/2DjkKfbLSJFtW9czxf3YkYrYsrleGucpYCQ9 +VHP44Np4ZXKBw3YmNOthjhLY8igdUxR3RvQCpI3M35ZE2xf76b/WV5KEMFeB54KAAAAAAAA --------------ms040503060900070803040300-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 11:08:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14407 for ; Mon, 24 Nov 2003 11:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJGF-0007VS-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 11:08:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOJGE-0007VO-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 11:08:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C55F3C@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 11:08:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61799500 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 11:08:23 -0500 Received: from 209.226.175.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 11:08:23 -0500 Received: from develSPavel ([67.69.27.58]) by tomts7-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031124160822.KCHR15470.tomts7-srv.bellnexxia.net@develSPavel> for ; Mon, 24 Nov 2003 11:08:22 -0500 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <004a01c3b2a5$7dfbfc80$a401a8c0@toronto.chantrynetworks.com> Date: Mon, 24 Nov 2003 11:10:34 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069647229.1037.157.camel@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit I believe I am missing something here. Wasn't this group supposed to give a generic solution for a protocol that would be flexible enough to cover all kinds of technologies or possible practical implementations? Or, do we only look at what we have experienced so far in our careers and anything else is either not true, impossible or not worth considering? ... Is ForCES supposed to use only TCP/IP over a network? How about those who would map it (possibly directly) to the proprietary hardware transport protocol that runs on the switching fabric? I hope I don't need to give arguments for this case. As far as I can tell, there are multi-blade architectures that use switching fabrics that have a dilation factor between 1.2 and 1.6 (the multiplication factor that gives the switch internal bandwidth based on the total external aggregate capacity). This would carry both FE-FE and CE-FE traffic. It is not hard to see why, cost wise, it would be preferable to have a switching fabric with 1.2 dilation factor that also provides a multicast mechanism versus one that has 1.6 dilation factor that allows only for unicast. (I am not saying that the 0.4 factor difference would represent real world multicast overhead for CE-FE communications. But it can be for both FE-FE plus CE-FE communication. This is an example to make a point.) But an even more compelling argument in favour of multicast was brought by those who mentioned the cost in CPU cycles when it comes to simulating multicast by unicasts. Arguments suggesting that these days we have processors that run 'faster and faster' are good in a science/technology journal for the masses, but less so in this group. Just an opinion. Sandy Pavel From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 11:37:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15157 for ; Mon, 24 Nov 2003 11:37:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJil-00001l-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 11:37:55 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOJik-00001i-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 11:37:54 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C55FDB@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 11:37:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61801808 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 11:37:51 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 11:37:47 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAOGbkLS013671 for ; Mon, 24 Nov 2003 10:37:46 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <1069645835.1035.132.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC233D8.FFB5262C@alcatel.com> Date: Mon, 24 Nov 2003 10:37:44 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Multicast is great to have, but certainly not at the cost of reliability and security! Multicasting "Hello" messages is sure much less critical than multicasting critical LFB configuration information where packets have to arrive in sequence and without curruption. Regards, Alex. Jamal Hadi Salim wrote: > On Sun, 2003-11-23 at 19:30, Alex Audu wrote: > > Hi All, > > > > All this talk about the need and benefits of multicast certainly makes > > ones > > feel it is a cure all for what is being termed as the ailment in > > ForCEs' requirements. > > > > It is useful to have; it is not listed as a requirement - just like > congestion control is not listed as a requirement in the non-global > scope but useful to have. > > > Look, it has to be told that you can't do multicast on the cheap. And > > You will have to show me a single switch fabric that cant do multicast > or broadcast. Pick any netgear or dlink $1 switch and show me it doesnt > support multicast. How cheap do you want to go? > > > you have > > to answer some key questions if you really want to sell multicast in a > > critical > > environment,..viz: > > [deleted things which have been repeated in the last 10 emails on this > subject for brevity] > > > > > There is also this myth that all the FEs will have the same routing > > information > > always. > > All examples i have seen say that most not all. > > > I submit that this is not true. One of the problems ForCEs is meant > > to > > solve is scalability. This certainly relates to the abilty to manage > > the rapid > > growth of routing table sizes by distributing the routing information > > as partial > > routes into various FE groups. Granted there is still some scaling > > issues > > here,..but is definitely not as bad as people have been making it to > > be. > > > > I am not sure i followed. Are we back to the topic that the problem is a > startup issue? > > > ..more comments in-line... > > Thanks for being brave and addresing these issues. > > > Regards, > > Alex. > > > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > > hadi@znyx.com writes: > > > > > > > Continuation of the last thread with a change in topic - i think > > > these > > > are the real issues that need to be addressed instead of the > > > distraction > > > to "multicast is evil". > > > > > > Lets really list the requirements needed for a successful underlying > > > transport protocol that will serve ForCES well. i may be > > > missing some - but i hope to get challenged so i can add to them; > > > I am thinking of turning this into a draft so people read it first > > > and > > > then post. > > > My previous email has some more claims which i will assume here. > > > > > > I. ForCES mechanisms requiring reliability: > > > > > > a) time limit very sensitive (in other words obsolence period is > > > faster): > > > Example table updates; > > > I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > > qualify. > > > Something like what netlink2 over UDP qualifies because it gives > > > control > > > to netlink2 to make such decisions. > > > > > > How can you have reliable communcation over UDP? > > > > The mechanisms would be a retransmit timer and ability to get ACKs > or NACKs. > Note the definition of reliability includes a valid time. So this > validity is best controled by the app (the ForCES protocol). TCP > doesnt allow you to do this. > > > > II. mechanisms capable of tolerating unreliability: Example psamp. > > > TCP doesnt qualify. > > > something(like netlink2) over UDP or SCTP-PR. > > > > > > Why do you say TCP doesn't qualify here? Any application that can > > live > > with un-reliable transport can sure do better with a relaible one. > > > > You are right. TCP qualifies and the other two as well. > > > > III. mechanisms that prefer timeliness over reliability: Ex > > > heartbeats > > > something (like netlink2) over UDP or SCTP-PR. > > > > > I take it you agree TCP fails if you really value timelines. > > > > Now on the choice of netlink2 UDP vs SCTP-PR > > > > > > 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > > > Netlink2 can run over it. For now we choose to be standalone: We can > > > run > > > over IP, over UDP or over ethernet, you take your pick. > > > > I believe SCTP-PR is now in IESG queue. Even when it is available, you > > have > > to run it in a reliable mode to guarantee that those critical > > configuration > > messages get to their destination safely. And it still doesn't buy you > > security. > > I think it has been issued RFC status. > SCTP-PR would be a better choice than TCP. Because it will give user > control of removing stale messages. > > > > > > 2) UDP provides multicast (and broadcast). SCTP-PR does not. > > > Since SCTP has turned to be a swiss knife (or maybe a multi faceted > > > beast), i am sure it will soon as well support multicast;-> > > > > > > If multicast is there - we will use it. Sans that we will do > > > something > > > multicast like (Jon calls it unireplicate i think). > > > All the three cauthors have had pleasant experiences using multicast > > > for > > > ForCES like. We think it is a good thing to have. But we will not > > > torture you if you dont have multicast or broadcast ;-> > > > > > > Why Multicast is useful: > > > -- > > > I must apologize since i have to repeat this. > > > In the simple case of a single multicast wire: each of the CEs or > > > FEs > > > opens a single multicast socket/channel. > > > > > > Why is this good: > > > > > > 1) Bandwidth is less used > > > a)because one or more CEs can send a single message to all FEs. > > > I really dont want to be teaching people the hows but i will provide > > > one > > > example which David or maybe it was Joel didnt seem to make sense > > > out of > > > (but one that i have successfuly used)[1] > > > b) you can reduce the number of packets further by limiting on > > > ACKs (partial acks) > > > > > > 2) RAM on the embedded CE or FE is used less. There are less sockets > > > open and less messages being built > > > > > I take it you agree with the above two ;-> > > > > 3) CPU is preserved more. > > > Since there are fewer messages to process and fewer (socket states) > > > states to track. > > > > > > As far as I am concerned, the more critical resource CPU-wise is FE. > > The > > mutlicast scheme Netlink2 proposes blasts all every packet to every > > FE. > > Each FE has to do work to filter out which packet doesn't belong to > > it. Thus, > > the FE spends a lot of CPU cycles filtering off unwanted > > packets,..cycles > > that should be best used in forwarding packets. > > > > I wasnt sure whether i should respond to this or not. I have addressed > it in previous emails and it is addresed in the draft. > For brevity: Yes this may become an issue, but there are solutions. > > > > > > 4) The ability for all listeners on the wire to see message > > > exchanges > > > even when not directed at them provides a cheap way to synchronize. > > > > > > And of course, if this is a malicious node, it will gladly gleam as > > much information > > as is enough to mount an attack. This is why secure multicast is > > necessary. > > The MSEC people showed up at the last WG meeting - it is too bad that > noone raised this issue. I dont wanna discuss this - its a separate > issue. It is solvable. Let me ask the following since you bring the > issue of scalability: > If you were to encrypt messages, would it be cheaper to encrypt two > multicasted flows > or 8 unireplicated flows? I have seen processors having problem with a > single flow. > > > > 5) At a transport level, (not the forces transaction level), having > > > access to multicast provides location transparency. > > > > > I take it you agree with this. > > > > 6) A lot of switch fabrics (shared memory designs or otherwise) > > > interconnecting FEs and CES have multicast capabilities; so it is > > > good > > > if we can take advantage of it where possible. > > > > > I take it you agree with this. > > > > The above is the simple case, by induction you could extend the > > > reasoning to the case where you have X sockets. > > > > > I take it you agree with this as well. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 12:02:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16133 for ; Mon, 24 Nov 2003 12:02:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOK6L-0000PG-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 12:02:17 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOK6K-0000PC-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 12:02:16 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C55E8A@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 12:02:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61803813 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 12:02:11 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 12:02:11 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAOH2ALS018239 for ; Mon, 24 Nov 2003 11:02:10 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <1069645835.1035.132.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC23991.F526AFF9@alcatel.com> Date: Mon, 24 Nov 2003 11:02:10 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit To add to my previous comments: On the following question: > How can you have reliable communcation over UDP? > Jamal wrote: The mechanisms would be a retransmit timer and ability to get ACKs or NACKs. Note the definition of reliability includes a valid time. So this validity is best controled by the app (the ForCES protocol). TCP doesnt allow you to do this. My comments: So the retransmit timer fires, and then you do another broadcast or multicast? I can see how this does wonders for your CE-FE bandwidth efficiency. I don't see why TCP can't cope with sending data over zero, one or two hops (the environment for ForCES) in time to warrant the use of UDP. After all, it is not like we are sending packets from one end of the globe to another! And you can't just wave the issue of security away. Routing security is quite important the IETF created the RPSEC WG to look into ways of making routing protocols more secure. The outcome of that may make some demands on the router architectures. For example, separating less critical but attack-prone "Hello" message channel from ciritical LFB configuration and control message channel is a good revelation. Regards, Alex. Jamal Hadi Salim wrote: > On Sun, 2003-11-23 at 19:30, Alex Audu wrote: > > Hi All, > > > > All this talk about the need and benefits of multicast certainly makes > > ones > > feel it is a cure all for what is being termed as the ailment in > > ForCEs' requirements. > > > > It is useful to have; it is not listed as a requirement - just like > congestion control is not listed as a requirement in the non-global > scope but useful to have. > > > Look, it has to be told that you can't do multicast on the cheap. And > > You will have to show me a single switch fabric that cant do multicast > or broadcast. Pick any netgear or dlink $1 switch and show me it doesnt > support multicast. How cheap do you want to go? > > > you have > > to answer some key questions if you really want to sell multicast in a > > critical > > environment,..viz: > > [deleted things which have been repeated in the last 10 emails on this > subject for brevity] > > > > > There is also this myth that all the FEs will have the same routing > > information > > always. > > All examples i have seen say that most not all. > > > I submit that this is not true. One of the problems ForCEs is meant > > to > > solve is scalability. This certainly relates to the abilty to manage > > the rapid > > growth of routing table sizes by distributing the routing information > > as partial > > routes into various FE groups. Granted there is still some scaling > > issues > > here,..but is definitely not as bad as people have been making it to > > be. > > > > I am not sure i followed. Are we back to the topic that the problem is a > startup issue? > > > ..more comments in-line... > > Thanks for being brave and addresing these issues. > > > Regards, > > Alex. > > > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > > hadi@znyx.com writes: > > > > > > > Continuation of the last thread with a change in topic - i think > > > these > > > are the real issues that need to be addressed instead of the > > > distraction > > > to "multicast is evil". > > > > > > Lets really list the requirements needed for a successful underlying > > > transport protocol that will serve ForCES well. i may be > > > missing some - but i hope to get challenged so i can add to them; > > > I am thinking of turning this into a draft so people read it first > > > and > > > then post. > > > My previous email has some more claims which i will assume here. > > > > > > I. ForCES mechanisms requiring reliability: > > > > > > a) time limit very sensitive (in other words obsolence period is > > > faster): > > > Example table updates; > > > I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > > qualify. > > > Something like what netlink2 over UDP qualifies because it gives > > > control > > > to netlink2 to make such decisions. > > > > > > How can you have reliable communcation over UDP? > > > > The mechanisms would be a retransmit timer and ability to get ACKs > or NACKs. > Note the definition of reliability includes a valid time. So this > validity is best controled by the app (the ForCES protocol). TCP > doesnt allow you to do this. > > > > II. mechanisms capable of tolerating unreliability: Example psamp. > > > TCP doesnt qualify. > > > something(like netlink2) over UDP or SCTP-PR. > > > > > > Why do you say TCP doesn't qualify here? Any application that can > > live > > with un-reliable transport can sure do better with a relaible one. > > > > You are right. TCP qualifies and the other two as well. > > > > III. mechanisms that prefer timeliness over reliability: Ex > > > heartbeats > > > something (like netlink2) over UDP or SCTP-PR. > > > > > I take it you agree TCP fails if you really value timelines. > > > > Now on the choice of netlink2 UDP vs SCTP-PR > > > > > > 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > > > Netlink2 can run over it. For now we choose to be standalone: We can > > > run > > > over IP, over UDP or over ethernet, you take your pick. > > > > I believe SCTP-PR is now in IESG queue. Even when it is available, you > > have > > to run it in a reliable mode to guarantee that those critical > > configuration > > messages get to their destination safely. And it still doesn't buy you > > security. > > I think it has been issued RFC status. > SCTP-PR would be a better choice than TCP. Because it will give user > control of removing stale messages. > > > > > > 2) UDP provides multicast (and broadcast). SCTP-PR does not. > > > Since SCTP has turned to be a swiss knife (or maybe a multi faceted > > > beast), i am sure it will soon as well support multicast;-> > > > > > > If multicast is there - we will use it. Sans that we will do > > > something > > > multicast like (Jon calls it unireplicate i think). > > > All the three cauthors have had pleasant experiences using multicast > > > for > > > ForCES like. We think it is a good thing to have. But we will not > > > torture you if you dont have multicast or broadcast ;-> > > > > > > Why Multicast is useful: > > > -- > > > I must apologize since i have to repeat this. > > > In the simple case of a single multicast wire: each of the CEs or > > > FEs > > > opens a single multicast socket/channel. > > > > > > Why is this good: > > > > > > 1) Bandwidth is less used > > > a)because one or more CEs can send a single message to all FEs. > > > I really dont want to be teaching people the hows but i will provide > > > one > > > example which David or maybe it was Joel didnt seem to make sense > > > out of > > > (but one that i have successfuly used)[1] > > > b) you can reduce the number of packets further by limiting on > > > ACKs (partial acks) > > > > > > 2) RAM on the embedded CE or FE is used less. There are less sockets > > > open and less messages being built > > > > > I take it you agree with the above two ;-> > > > > 3) CPU is preserved more. > > > Since there are fewer messages to process and fewer (socket states) > > > states to track. > > > > > > As far as I am concerned, the more critical resource CPU-wise is FE. > > The > > mutlicast scheme Netlink2 proposes blasts all every packet to every > > FE. > > Each FE has to do work to filter out which packet doesn't belong to > > it. Thus, > > the FE spends a lot of CPU cycles filtering off unwanted > > packets,..cycles > > that should be best used in forwarding packets. > > > > I wasnt sure whether i should respond to this or not. I have addressed > it in previous emails and it is addresed in the draft. > For brevity: Yes this may become an issue, but there are solutions. > > > > > > 4) The ability for all listeners on the wire to see message > > > exchanges > > > even when not directed at them provides a cheap way to synchronize. > > > > > > And of course, if this is a malicious node, it will gladly gleam as > > much information > > as is enough to mount an attack. This is why secure multicast is > > necessary. > > The MSEC people showed up at the last WG meeting - it is too bad that > noone raised this issue. I dont wanna discuss this - its a separate > issue. It is solvable. Let me ask the following since you bring the > issue of scalability: > If you were to encrypt messages, would it be cheaper to encrypt two > multicasted flows > or 8 unireplicated flows? I have seen processors having problem with a > single flow. > > > > 5) At a transport level, (not the forces transaction level), having > > > access to multicast provides location transparency. > > > > > I take it you agree with this. > > > > 6) A lot of switch fabrics (shared memory designs or otherwise) > > > interconnecting FEs and CES have multicast capabilities; so it is > > > good > > > if we can take advantage of it where possible. > > > > > I take it you agree with this. > > > > The above is the simple case, by induction you could extend the > > > reasoning to the case where you have X sockets. > > > > > I take it you agree with this as well. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 12:08:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16528 for ; Mon, 24 Nov 2003 12:08:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKCC-0000X3-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 12:08:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOKCC-0000X0-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 12:08:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C55F19@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 12:08:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61804767 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 12:08:19 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 12:08:14 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAOH8DLS019647 for ; Mon, 24 Nov 2003 11:08:14 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <1069645835.1035.132.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC23AFD.A56309B@alcatel.com> Date: Mon, 24 Nov 2003 11:08:13 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Further comments: In response to this snipet: > And of course, if this is a malicious node, it will gladly gleam as > much information > as is enough to mount an attack. This is why secure multicast is > necessary. Jamal wrote the following: The MSEC people showed up at the last WG meeting - it is too bad that noone raised this issue. I dont wanna discuss this - its a separate issue. It is solvable. Let me ask the following since you bring the issue of scalability: If you were to encrypt messages, would it be cheaper to encrypt two multicasted flows or 8 unireplicated flows? I have seen processors having problem with a single flow. My comments: I think the question is "how are you going to solve multicast security problem?" You say it is solvable. I really will like to know. Regards, Alex. Jamal Hadi Salim wrote: > On Sun, 2003-11-23 at 19:30, Alex Audu wrote: > > Hi All, > > > > All this talk about the need and benefits of multicast certainly makes > > ones > > feel it is a cure all for what is being termed as the ailment in > > ForCEs' requirements. > > > > It is useful to have; it is not listed as a requirement - just like > congestion control is not listed as a requirement in the non-global > scope but useful to have. > > > Look, it has to be told that you can't do multicast on the cheap. And > > You will have to show me a single switch fabric that cant do multicast > or broadcast. Pick any netgear or dlink $1 switch and show me it doesnt > support multicast. How cheap do you want to go? > > > you have > > to answer some key questions if you really want to sell multicast in a > > critical > > environment,..viz: > > [deleted things which have been repeated in the last 10 emails on this > subject for brevity] > > > > > There is also this myth that all the FEs will have the same routing > > information > > always. > > All examples i have seen say that most not all. > > > I submit that this is not true. One of the problems ForCEs is meant > > to > > solve is scalability. This certainly relates to the abilty to manage > > the rapid > > growth of routing table sizes by distributing the routing information > > as partial > > routes into various FE groups. Granted there is still some scaling > > issues > > here,..but is definitely not as bad as people have been making it to > > be. > > > > I am not sure i followed. Are we back to the topic that the problem is a > startup issue? > > > ..more comments in-line... > > Thanks for being brave and addresing these issues. > > > Regards, > > Alex. > > > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > > hadi@znyx.com writes: > > > > > > > Continuation of the last thread with a change in topic - i think > > > these > > > are the real issues that need to be addressed instead of the > > > distraction > > > to "multicast is evil". > > > > > > Lets really list the requirements needed for a successful underlying > > > transport protocol that will serve ForCES well. i may be > > > missing some - but i hope to get challenged so i can add to them; > > > I am thinking of turning this into a draft so people read it first > > > and > > > then post. > > > My previous email has some more claims which i will assume here. > > > > > > I. ForCES mechanisms requiring reliability: > > > > > > a) time limit very sensitive (in other words obsolence period is > > > faster): > > > Example table updates; > > > I have argued TCP doesnt qualify in my previous email. SCTP-PR may > > > qualify. > > > Something like what netlink2 over UDP qualifies because it gives > > > control > > > to netlink2 to make such decisions. > > > > > > How can you have reliable communcation over UDP? > > > > The mechanisms would be a retransmit timer and ability to get ACKs > or NACKs. > Note the definition of reliability includes a valid time. So this > validity is best controled by the app (the ForCES protocol). TCP > doesnt allow you to do this. > > > > II. mechanisms capable of tolerating unreliability: Example psamp. > > > TCP doesnt qualify. > > > something(like netlink2) over UDP or SCTP-PR. > > > > > > Why do you say TCP doesn't qualify here? Any application that can > > live > > with un-reliable transport can sure do better with a relaible one. > > > > You are right. TCP qualifies and the other two as well. > > > > III. mechanisms that prefer timeliness over reliability: Ex > > > heartbeats > > > something (like netlink2) over UDP or SCTP-PR. > > > > > I take it you agree TCP fails if you really value timelines. > > > > Now on the choice of netlink2 UDP vs SCTP-PR > > > > > > 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > > > Netlink2 can run over it. For now we choose to be standalone: We can > > > run > > > over IP, over UDP or over ethernet, you take your pick. > > > > I believe SCTP-PR is now in IESG queue. Even when it is available, you > > have > > to run it in a reliable mode to guarantee that those critical > > configuration > > messages get to their destination safely. And it still doesn't buy you > > security. > > I think it has been issued RFC status. > SCTP-PR would be a better choice than TCP. Because it will give user > control of removing stale messages. > > > > > > 2) UDP provides multicast (and broadcast). SCTP-PR does not. > > > Since SCTP has turned to be a swiss knife (or maybe a multi faceted > > > beast), i am sure it will soon as well support multicast;-> > > > > > > If multicast is there - we will use it. Sans that we will do > > > something > > > multicast like (Jon calls it unireplicate i think). > > > All the three cauthors have had pleasant experiences using multicast > > > for > > > ForCES like. We think it is a good thing to have. But we will not > > > torture you if you dont have multicast or broadcast ;-> > > > > > > Why Multicast is useful: > > > -- > > > I must apologize since i have to repeat this. > > > In the simple case of a single multicast wire: each of the CEs or > > > FEs > > > opens a single multicast socket/channel. > > > > > > Why is this good: > > > > > > 1) Bandwidth is less used > > > a)because one or more CEs can send a single message to all FEs. > > > I really dont want to be teaching people the hows but i will provide > > > one > > > example which David or maybe it was Joel didnt seem to make sense > > > out of > > > (but one that i have successfuly used)[1] > > > b) you can reduce the number of packets further by limiting on > > > ACKs (partial acks) > > > > > > 2) RAM on the embedded CE or FE is used less. There are less sockets > > > open and less messages being built > > > > > I take it you agree with the above two ;-> > > > > 3) CPU is preserved more. > > > Since there are fewer messages to process and fewer (socket states) > > > states to track. > > > > > > As far as I am concerned, the more critical resource CPU-wise is FE. > > The > > mutlicast scheme Netlink2 proposes blasts all every packet to every > > FE. > > Each FE has to do work to filter out which packet doesn't belong to > > it. Thus, > > the FE spends a lot of CPU cycles filtering off unwanted > > packets,..cycles > > that should be best used in forwarding packets. > > > > I wasnt sure whether i should respond to this or not. I have addressed > it in previous emails and it is addresed in the draft. > For brevity: Yes this may become an issue, but there are solutions. > > > > > > 4) The ability for all listeners on the wire to see message > > > exchanges > > > even when not directed at them provides a cheap way to synchronize. > > > > > > And of course, if this is a malicious node, it will gladly gleam as > > much information > > as is enough to mount an attack. This is why secure multicast is > > necessary. > > The MSEC people showed up at the last WG meeting - it is too bad that > noone raised this issue. I dont wanna discuss this - its a separate > issue. It is solvable. Let me ask the following since you bring the > issue of scalability: > If you were to encrypt messages, would it be cheaper to encrypt two > multicasted flows > or 8 unireplicated flows? I have seen processors having problem with a > single flow. > > > > 5) At a transport level, (not the forces transaction level), having > > > access to multicast provides location transparency. > > > > > I take it you agree with this. > > > > 6) A lot of switch fabrics (shared memory designs or otherwise) > > > interconnecting FEs and CES have multicast capabilities; so it is > > > good > > > if we can take advantage of it where possible. > > > > > I take it you agree with this. > > > > The above is the simple case, by induction you could extend the > > > reasoning to the case where you have X sockets. > > > > > I take it you agree with this as well. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 13:42:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20607 for ; Mon, 24 Nov 2003 13:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLfr-000226-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 13:43:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOLfq-000223-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 13:43:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00C5610D@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 13:43:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61811267 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 13:43:00 -0500 Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 13:43:00 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOIbavY135004 for ; Mon, 24 Nov 2003 18:42:59 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOFpT33093396 for ; Mon, 24 Nov 2003 16:51:30 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA59752 for ; Mon, 24 Nov 2003 16:51:29 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20031119232704.018bfeb0@localhost> <3FBC9FF7.4080608@zurich.ibm.com> <008801c3b0b2$a8a50480$7b19fea9@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id hAOIbavY135004 Approved-By: Robert Haas Message-ID: <3FC22900.3040905@zurich.ibm.com> Date: Mon, 24 Nov 2003 16:51:28 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <008801c3b0b2$a8a50480$7b19fea9@wwm1> Precedence: list Content-Transfer-Encoding: quoted-printable Hi Weiming, Weiming Wang wrote: >Hi Rob, > >I remember we'v had a short discussion on the broadcast/multicast issue= in Minn. >I agree that it's not just as simple as to arrange FE IDs, but I still t= hink that the left >is in the encapsulation scope. Maybe we need a specific definition docu= ment for this > scope.=20 > =20 > Could you elaborate what encapsulation scope means ? > I also argue that the hooks in ForCES protocol for the multicast encaps= ulation >should be limited to FE IDs instead of LFB types, leaving later as hooks= only inside one FE.=20 >For I'm still not sure how an LFB type can be used directly as hooks for= the multicast, it seems >a little case specific. Maybe I miss something.=20 >Thank you. > =20 > I was considering the basic scenario of a distributed router for which a=20 forwarding table must be replicated and maintained over many FEs.=20 Imagine a CE can produce a message such as "send this forwarding=20 table/updates to all LFBs that peform IPv4 forwarding (optional: in a=20 particular virtual network)". This is why I consider this "addressing=20 by type" a basic functionality that the ForCES protocol should suppport,=20 as it greatly simplifies how to use the protocol. Indeed, there is no=20 need for the application to first figure out the specific LFB IDs that=20 have been assigned to the IPv4 LFB, nor the particular FE IDs. Regards, -Robert >Weiming > >----- Original Message -----=20 >From: "Robert Haas" >To: >Sent: Thursday, November 20, 2003 7:05 PM >Subject: Re: Support for multicast in the ForCES protocol > > >Joel M. Halpern wrote: > > =20 > >>This is one of the complexities. While there is a lot of useful >>experimental work on reliable and secured multicast transport, I do not >>believe that there is any engineering grade work that address both thos= e >>requirements. And we are obliged to meet both of those needs. >>And compared with TCP / SCTP, there are not wide spread, easily=20 >>available, >>well wrung out implementations of those protocols. >>Hence, putting a dependency on such work into ForCES introduces=20 >>significant >>risk and complexity.=20 >> =20 >> > >I don't think we are talking about putting a dependency on RMT here.=20 >Rather we are ensuring that the necessary hooks are in the ForCES=20 >protocol so it can make use of some form of multicast transport. > >And to do this, we need to have some form of group addressing at the=20 >ForCES protocol level. Having spent some cycles on this, I can say it=20 >requires a bit more than "rearranging the FE ID bits to have some=20 >group-like meaning after the ForCES protocol has already been designed"=20 >(I think I heard sth along these lines on the list). > >Cheers, >-Robert > > =20 > >>Yours, >>Joel M. Halpern >> >>At 01:52 AM 11/20/2003 +0200, you wrote: >> >> =20 >> >>>One last issue... the semantics needed from the transport layer=20 >>>should be >>>carefully defined, as regular multicast is not reliable, and I expect=20 >>>the >>>protocol to rely on some reliable transport in order to know the CE-FE >>>transaction is commited... the RMT WG had defined tools for reliable >>>multicast that can be deployed here... >>> >>>- Tal >>> =20 >>> >> >> =20 >> > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 14:16:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22444 for ; Mon, 24 Nov 2003 14:16:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMCU-0002kA-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 14:16:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOMCU-0002k7-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 14:16:46 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C5619A@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 14:16:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61814054 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 14:16:43 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 14:16:39 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAOJGbOf011929 for ; Mon, 24 Nov 2003 13:16:37 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <3FC1C145.1030602@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC25914.E513A7CA@alcatel.com> Date: Mon, 24 Nov 2003 13:16:37 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Patrick, Please my comments in-line.. Regards, Alex. Patrick Droz wrote: > [chair hat off] > > see comments inline > > Alex Audu wrote: > > > Hi All, > > > > All this talk about the need and benefits of multicast certainly makes ones > > feel it is a cure all for what is being termed as the ailment in ForCEs' > > requirements. > > > > Look, it has to be told that you can't do multicast on the cheap. And > > you have > > to answer some key questions if you really want to sell multicast in a > > critical > > environment,..viz: > > > > 1) How would you guarrantee the relaible delivery of the messages being > > blasted to all the targets? What if the messages don't arrive at all > > their > > intended targets? How do you recover from this? This suggests you need > > a reliable multicast mechanism. I am not sure you can do this over UDP > > as it is currently being done in NetLink2. That is only good for > > un-reliable > > multicast. I am not sure if you can trust critical configuration > > messages > > like routing table information or basic LFB service/tree structure > > messages > > over such an unreliable mechanism. > > > > 2) How do you deal with the issue of security, given that we don't have > > secure > > multicast yet? I have seen some people call for broadcast > > capability also. > > One result of multicast/broadcast is you run the risk of a > > potential attacker > > listening in on say, the routing information being blasted to the > > FEs. I don't > > think multicasting over UDP has an answer to this. > > > > > > There is also this myth that all the FEs will have the same routing > > information > > could you please provide some evidence of this? Keep in mind we are > moving from a centralized (single routing table) to a distributed > router architecture. Why should it change that the routing table > should be much different. Or do you want to go into the discussion > of how you avoid routing loops? > One of the benefits of distributing the NE is the ability to handle many more routes,..many more than the current core routers are capable of. Route table sizes start becoming a problem at that scale. Storing partial routes in a logically hierarchical distributed entities can help. Of course, you have to assign the default routes appropriately to prevent routing loops. > > > always. I submit that this is not true. One of the problems ForCEs is > > meant to > > solve is scalability. This certainly relates to the abilty to manage the > > rapid > > growth of routing table sizes by distributing the routing information as > > partial > > routes into various FE groups. Granted there is still some scaling issues > > here,..but is definitely not as bad as people have been making it to be. > > > > ..more comments in-line... > > > > Regards, > > Alex. > > Regards, > Patrick > > > > > In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > > hadi@znyx.com writes: > > > > > >> Continuation of the last thread with a change in topic - i think these > >> are the real issues that need to be addressed instead of the distraction > >> to "multicast is evil". > >> > >> Lets really list the requirements needed for a successful underlying > >> transport protocol that will serve ForCES well. i may be > >> missing some - but i hope to get challenged so i can add to them; > >> I am thinking of turning this into a draft so people read it first and > >> then post. > >> My previous email has some more claims which i will assume here. > >> > >> I. ForCES mechanisms requiring reliability: > >> > >> a) time limit very sensitive (in other words obsolence period is > >> faster): > >> Example table updates; > >> I have argued TCP doesnt qualify in my previous email. SCTP-PR may > >> qualify. > >> Something like what netlink2 over UDP qualifies because it gives control > >> to netlink2 to make such decisions. > > > > > > > > How can you have reliable communcation over UDP? > > > >> b) time limit best effort (obsolence takes longer) > >> Sample apps: File transfers,etc. > >> TCP qualifies but AFAIK, we dont have this need. > >> > >> II. mechanisms capable of tolerating unreliability: Example psamp. > >> TCP doesnt qualify. > >> something(like netlink2) over UDP or SCTP-PR. > > > > > > > > Why do you say TCP doesn't qualify here? Any application that can live > > with un-reliable transport can sure do better with a relaible one. > > > >> III. mechanisms that prefer timeliness over reliability: Ex heartbeats > >> something (like netlink2) over UDP or SCTP-PR. > >> > >> Clearly in the bigger picture TCP is not the best protocol. > >> UDP and SCTP-PR qualify partially merely because they dont hinder > >> progress not because they have some magic. Another non-IETF protocol > >> that would qualify is TIPC. I havent carefully studied DCCP but i > >> believe it also has a fit. I will exclude it because its not there yet. > >> > >> So, to summarize: the transport protocol that meets all the requirements > >> For Forces has not been born. > >> > >> Choosing TCP is choosing an answer and then trying to justify the > >> questions that it brings. It does sound like peer pressure instead of > >> looking at requirements and then deciding what you need to do. > >> I think we recognized this in netlink2 and made it clear that the choice > >> of underlying protocol chosen is up to the pre-association phase. > >> We compensate for "missing features" depending on the transport choice > >> (read the draft). > >> It's very few lines of code to provide that luxury. So the cost is low. > >> > >> Now on the choice of netlink2 UDP vs SCTP-PR > >> > >> 1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > >> Netlink2 can run over it. For now we choose to be standalone: We can run > >> over IP, over UDP or over ethernet, you take your pick. > > > > > > > > I believe SCTP-PR is now in IESG queue. Even when it is available, you have > > to run it in a reliable mode to guarantee that those critical configuration > > messages get to their destination safely. And it still doesn't buy you > > security. > > > > > >> 2) UDP provides multicast (and broadcast). SCTP-PR does not. > >> Since SCTP has turned to be a swiss knife (or maybe a multi faceted > >> beast), i am sure it will soon as well support multicast;-> > >> > >> If multicast is there - we will use it. Sans that we will do something > >> multicast like (Jon calls it unireplicate i think). > >> All the three cauthors have had pleasant experiences using multicast for > >> ForCES like. We think it is a good thing to have. But we will not > >> torture you if you dont have multicast or broadcast ;-> > >> > >> Why Multicast is useful: > >> -- > >> I must apologize since i have to repeat this. > >> In the simple case of a single multicast wire: each of the CEs or FEs > >> opens a single multicast socket/channel. > >> > >> Why is this good: > >> > >> 1) Bandwidth is less used > >> a)because one or more CEs can send a single message to all FEs. > >> I really dont want to be teaching people the hows but i will provide one > >> example which David or maybe it was Joel didnt seem to make sense out of > >> (but one that i have successfuly used)[1] > >> b) you can reduce the number of packets further by limiting on > >> ACKs (partial acks) > >> > >> 2) RAM on the embedded CE or FE is used less. There are less sockets > >> open and less messages being built > >> > >> 3) CPU is preserved more. > >> Since there are fewer messages to process and fewer (socket states) > >> states to track. > > > > > > > > As far as I am concerned, the more critical resource CPU-wise is FE. The > > mutlicast scheme Netlink2 proposes blasts all every packet to every FE. > > Each FE has to do work to filter out which packet doesn't belong to it. > > Thus, > > the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles > > that should be best used in forwarding packets. > > > > > >> 4) The ability for all listeners on the wire to see message exchanges > >> even when not directed at them provides a cheap way to synchronize. > > > > > > > > And of course, if this is a malicious node, it will gladly gleam as much > > information > > as is enough to mount an attack. This is why secure multicast is necessary. > > > >> 5) At a transport level, (not the forces transaction level), having > >> access to multicast provides location transparency. > >> > >> 6) A lot of switch fabrics (shared memory designs or otherwise) > >> interconnecting FEs and CES have multicast capabilities; so it is good > >> if we can take advantage of it where possible. > >> > >> The above is the simple case, by induction you could extend the > >> reasoning to the case where you have X sockets. > >> > >> I dont want to preach multicast as panacea; we address some of the > >> limitations in the draft; however, i want it to be available when i need > >> it and not shoved down the toilet. > >> > >> So far apart from Joel (who implemented on ATM) on real boxes and Ram > >> (who did something very specific that needs unicast) the rest of the > >> arguements i have seen are from people who see the need for this > >> feature. You can choose to ignore it - and you may be influenced by some > >> implementation you are familiar with - thats your loss. I do think TCP > >> is valid for some cases (low latency and congestion), but i wouldnt > >> claim it to be the answer weve all been waiting for. > >> Again let me reiterate that Netlink2 does not need to have multicast (it > >> is a MAY) but would love to have it when it is available. We can run on > >> your favorite protocol TCP ;-> > >> > >> cheers, > >> jamal > >> > >> [1] I will give the example in another email - this one is already > >> getting too long. > > > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 15:13:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25898 for ; Mon, 24 Nov 2003 15:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AON5d-0003cy-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 15:13:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AON5d-0003ct-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 15:13:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C5629B@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 15:13:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61819591 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 15:13:40 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 15:13:40 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAOKDdOf022117 for ; Mon, 24 Nov 2003 14:13:39 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <004a01c3b2a5$7dfbfc80$a401a8c0@toronto.chantrynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC26672.A8608122@alcatel.com> Date: Mon, 24 Nov 2003 14:13:38 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Sandy, Surely, as we move forward, we will be wise to draw on our past experiences. Else we will have missed the great lessons of histroy. Certainly processors are getting ever more powerful. That is why today, we are able to pack the power of yesterday's CRAY into a box that sits on a desktop and for fraction of the cost. Even more interesting, the incredible gain in processing power is driving the idea of peer-to-peer networking to new practically feasible levels (as exemplified by likes of KAZAA). So, don't under-estimate the power of the processor. Regards, Alex. Sandy Pavel wrote: > I believe I am missing something here. > Wasn't this group supposed to give a generic solution for a protocol > that would be flexible enough to cover all kinds of technologies or > possible practical implementations? > Or, do we only look at what we have experienced so far in our careers > and anything else is either not true, impossible or not worth > considering? ... > > Is ForCES supposed to use only TCP/IP over a network? How about those > who would map it (possibly directly) to the proprietary hardware > transport protocol that runs on the switching fabric? I hope I don't > need to give arguments for this case. > > As far as I can tell, there are multi-blade architectures that use > switching fabrics that have a dilation factor between 1.2 and 1.6 (the > multiplication factor that gives the switch internal bandwidth based on > the total external aggregate capacity). This would carry both FE-FE and > CE-FE traffic. > It is not hard to see why, cost wise, it would be preferable to have a > switching fabric with 1.2 dilation factor that also provides a multicast > mechanism versus one that has 1.6 dilation factor that allows only for > unicast. (I am not saying that the 0.4 factor difference would > represent real world multicast overhead for CE-FE communications. But it > can be for both FE-FE plus CE-FE communication. This is an example to > make a point.) > > But an even more compelling argument in favour of multicast was brought > by those who mentioned the cost in CPU cycles when it comes to > simulating multicast by unicasts. > Arguments suggesting that these days we have processors that run 'faster > and faster' are good in a science/technology journal for the masses, but > less so in this group. > > Just an opinion. > Sandy Pavel From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 15:29:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27159 for ; Mon, 24 Nov 2003 15:29:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONL5-0003zJ-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 15:29:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AONL4-0003zG-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 15:29:42 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C5646F@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 15:29:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61820735 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 15:29:40 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 15:29:40 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAOKTqBV007932 for ; Mon, 24 Nov 2003 20:29:53 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAOKJXb00916 for ; Mon, 24 Nov 2003 20:19:33 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112412292707058 for ; Mon, 24 Nov 2003 12:29:27 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Nov 2003 12:29:28 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOyZ2Wvc8DxXjh5QI2vFlJrlMxY3AAXU5BA X-OriginalArrivalTime: 24 Nov 2003 20:29:28.0475 (UTC) FILETIME=[A8AF7EB0:01C3B2C9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54AF0@orsmsx410.jf.intel.com> Date: Mon, 24 Nov 2003 12:29:28 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Patrick, Pls see my comments below... -----Original Message----- [chair hat off] Hormuzd, Khosravi, Hormuzd M wrote: > I don't see why this has to be a religious debate. > No body is saying "unicast is good, multicast is evil" > This should not be the approach for making technical decisions. > Unicast and multicast both have their merits and drawbacks > and we have to select one that best meets our needs. why you say one? why is it not both? [HK] The reason to choose one is driven by simplicity and=20 interoperability. When you say choose both, you mean certain control messages from CE-to-FE such as route updates use multicast and the rest use unicast ? What does this mean in terms of Interoperable solutions ? What does this complexity buy you ? It would be better to say either use Unicast or use Multicast for all control messages. However, from the discussion so far doesn't seem like multicast can be used efficiently or in all cases, without using unicast as well. >=20 > Unicast has been working well for a long time in client/server, > Master/slave type of environment. Multicast fits well for > Peer-to-peer environment. ForCES is clearly a master/slave why is it not a master and many slaves? [HK] Sure, that's a given. Any client-server architecture has One server and many clients or one master and many slaves. Does that automatically mean using multicast ? If this was the case then all client-server architectures would be using Multicast to improve performance. The claims being made regarding scalability are analogous to saying that a web-server cannot handle hundreds of clients and will need multicast to scale. Even a Linux box with a single P3 processor can easily scale to Hundreds of web clients. I need not mention some of the high end servers using multiple processors which can easily handle Hundreds of thousands or even millions of clients. Do you agree ? > environment, where the CE is the master or controller and=20 > the FE is the slave or the element being controlled. Hopefully, > there should be no disagreement on this basic idea. In addition, > we have certain reliability and security requirements that need > to be fulfilled. I agree on this as long as you also mention that we usually will have a small number of masters but maybe a very large number of slaves. [HK] Sure, I agree. Same as above. >=20 > On the issue of scalability let me try to give an example which > will bring to light the importance of congestion control. OSPF has > been stated as one of the main examples of a protocol which uses=20 > multicast as one of its transports in multicast enabled networks. > One of the current OSPF WG drafts... > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt > Talks about recommendations for improving OSPF scalability in large > networks. It specifically recommends prioritization and congestion > avoidance procedures to help improve the scalability. This draft is > not just based on implementation, but also deployment experience by a=20 > large operator (AT&T). >=20 how can you compare OSPF with ForCES? OSPF is a protocol that is deployed over many nodes in general. ForCES will be in many cases just used inside a single box. Could you please elaborate and tell us what is the relationship between ForCES and OSPF. [HK] I completely agree, OSPF is very different and is used for=20 exchanging information between routing peers. I have seen OSPF being used as a primary example of a protocol which uses multicast, and motivating the use of multicast in ForCES based on it. As you said OSPF is very different and is probably not a good analogy. However, even if you take OSPF as an example for motivating ForCES, there are issues with OSPF such as Congestion Control which were not considered in its initial design but are being discovered after years of deployment experience. If anything, we can learn from the experience and wisdom out there and avoid making similar mistakes in our protocol design. Regards, Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 16:13:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00444 for ; Mon, 24 Nov 2003 16:13:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOO1I-0004oY-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 16:13:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOO1H-0004oV-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 16:13:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C56584@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 16:13:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61825716 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 16:13:18 -0500 Received: from 209.226.175.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 16:13:18 -0500 Received: from develSPavel ([67.69.27.58]) by tomts27-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031124211313.NNTA24322.tomts27-srv.bellnexxia.net@develSPavel> for ; Mon, 24 Nov 2003 16:13:13 -0500 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <004e01c3b2d0$13fc0110$a401a8c0@toronto.chantrynetworks.com> Date: Mon, 24 Nov 2003 16:15:14 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC26672.A8608122@alcatel.com> Precedence: list Content-Transfer-Encoding: 7bit Thanks for the history lesson :) From the pages of the same history book we have learned of many, notorious by now, claims that the power of the processor is enough for the tasks at hand, for that specific moment in time and forever. And yet, the demand for more power is here; people have discovered that they can do so much more when more CPU power is available. I wonder if we can say that ForCES protocol is future proof since the power of processor can only increase. If yes, I rest my case. (should I mention the word 'scalability'?) Anyway, enough history; lets focus on the technical aspects. Regards, Sandy Pavel P.S. Alex, I hope that my previous message hasn't offended you or anyone else for that matter. If it has, I apologize. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: November 24, 2003 3:14 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCES protocol Hello Sandy, Surely, as we move forward, we will be wise to draw on our past experiences. Else we will have missed the great lessons of histroy. Certainly processors are getting ever more powerful. That is why today, we are able to pack the power of yesterday's CRAY into a box that sits on a desktop and for fraction of the cost. Even more interesting, the incredible gain in processing power is driving the idea of peer-to-peer networking to new practically feasible levels (as exemplified by likes of KAZAA). So, don't under-estimate the power of the processor. Regards, Alex. Sandy Pavel wrote: > I believe I am missing something here. > Wasn't this group supposed to give a generic solution for a protocol > that would be flexible enough to cover all kinds of technologies or > possible practical implementations? > Or, do we only look at what we have experienced so far in our careers > and anything else is either not true, impossible or not worth > considering? ... > > Is ForCES supposed to use only TCP/IP over a network? How about those > who would map it (possibly directly) to the proprietary hardware > transport protocol that runs on the switching fabric? I hope I don't > need to give arguments for this case. > > As far as I can tell, there are multi-blade architectures that use > switching fabrics that have a dilation factor between 1.2 and 1.6 (the > multiplication factor that gives the switch internal bandwidth based on > the total external aggregate capacity). This would carry both FE-FE and > CE-FE traffic. > It is not hard to see why, cost wise, it would be preferable to have a > switching fabric with 1.2 dilation factor that also provides a multicast > mechanism versus one that has 1.6 dilation factor that allows only for > unicast. (I am not saying that the 0.4 factor difference would > represent real world multicast overhead for CE-FE communications. But it > can be for both FE-FE plus CE-FE communication. This is an example to > make a point.) > > But an even more compelling argument in favour of multicast was brought > by those who mentioned the cost in CPU cycles when it comes to > simulating multicast by unicasts. > Arguments suggesting that these days we have processors that run 'faster > and faster' are good in a science/technology journal for the masses, but > less so in this group. > > Just an opinion. > Sandy Pavel From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 18:23:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10620 for ; Mon, 24 Nov 2003 18:23:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQ36-0000Yb-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 18:23:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOQ35-0000YY-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 18:23:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C5679A@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 18:23:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61835543 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 18:23:18 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 18:23:17 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAONAJCc005425 for ; Mon, 24 Nov 2003 23:23:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAOKTIu22567 for ; Mon, 24 Nov 2003 20:29:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112412351211513 for ; Mon, 24 Nov 2003 12:35:12 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Nov 2003 12:35:13 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOyQYofOCqE+l8KS6q6ya6YeCwk+AAFt6p1ABx4CRA= X-OriginalArrivalTime: 24 Nov 2003 20:35:13.0759 (UTC) FILETIME=[767DA6F0:01C3B2CA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54AF2@orsmsx410.jf.intel.com> Date: Mon, 24 Nov 2003 12:35:13 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Tal There is already a ForCES Requirements draft which has been approved for RFC. Pls see... http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx t This has a section on protocol requirements. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Tal Anker Sent: Sunday, November 23, 2003 11:03 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol All, I do believe that this thread should converge to _some_ result... I think I remember someone saying he is writing a draft to capture all the issues with multicast and forces...I believe this is a good direction (maybe the draft can also indicate requirements of the forces protocol so that it can later work over [reliable ?] multicast transport...). Why don't we wait for the draft to be available (or is there a time issue here that I am not aware of... - assuming the draft would not take too long ...). =20 - Tal -----Original Message-----=20 From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Mon 11/24/2003 6:13 AM=20 To: FORCES@PEACH.EASE.LSOFT.COM=20 Cc:=20 Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol =09 =09 On Sun, 2003-11-23 at 22:37, Khosravi, Hormuzd M wrote: > I don't see why this has to be a religious debate. =09 It is when you discuss for a long time and reach the same conclusion you both had when you started. =09 > No body is saying "unicast is good, multicast is evil" > This should not be the approach for making technical decisions. > Unicast and multicast both have their merits and drawbacks > and we have to select one that best meets our needs. =09 Do you think TCP satisfies all the requirements? Please read my email on this topic before responding. It will be that religious discussion i am talking about if you dont read the emails. BTW, When did we say we have to choose one over the other? Could they both be supported maybe? This is a config issue. Noone has ever ruled out unicast. I dont understand why you are so adamant on ruling out multicast. Let me guess: could it be because FACT doesnt support it? =09 > Unicast has been working well for a long time in client/server, > Master/slave type of environment. Multicast fits well for > Peer-to-peer environment. ForCES is clearly a master/slave > environment, where the CE is the master or controller and > the FE is the slave or the element being controlled. Hopefully, > there should be no disagreement on this basic idea. In addition, =09 Multicast typically has a sender (the CE in this case mostly) and one or more receivers (the FE in the case of ForCES). The FE could send an unsolicited event. Whatever terminology you end up calling such a setup is unimportant. I am just curious why you are bringing this topic? =09 > we have certain reliability and security requirements that need > to be fulfilled. =09 And they are being met. =09 > On the issue of scalability let me try to give an example which > will bring to light the importance of congestion control. OSPF has > been stated as one of the main examples of a protocol which uses > multicast as one of its transports in multicast enabled networks. > One of the current OSPF WG drafts... > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt > Talks about recommendations for improving OSPF scalability in large > networks. It specifically recommends prioritization and congestion > avoidance procedures to help improve the scalability. This draft is > not just based on implementation, but also deployment experience by a > large operator (AT&T). > =09 Good, we can learn from it. How exactly does this say multicast is bad? I did search for the word multicast on that draft and it is not mentioend once. But you are probably refering to it because OSPF uses multicast - I would say it is a good proof there is something good about multicast. =09 cheers, jamal =09 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 18:35:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11158 for ; Mon, 24 Nov 2003 18:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQEd-0000in-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 18:35:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOQEb-0000ik-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 18:35:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00C567C1@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 18:35:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61836548 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 18:35:12 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 18:35:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 MIME-Version: 1.0 X-MS-TNEF-Correlator: Thread-Topic: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... Thread-Index: AcOyrONLVU/GemdmSFaWXMWdmLKoDwANX+5b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Approved-By: Tal Anker Message-ID: Date: Tue, 25 Nov 2003 01:35:23 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgQWxleCwNCkluIHRoZSBlbnZpcm9ubWVudCBJIGV4cGVjdCB0aGUgcHJvdG9jb2wgdG8gd29y ayBpbiwgSSBleHBlY3QgdGhhdCB3aXRoIGdvb2QgZW5naW5lZXJpbmcgbW9zdCBvZiB0aGUgcHJv dG9jb2wgcGFja2V0cyB3aWxsIHJlYWNoIHRoZWlyIGRlc3RpbmF0aW9uLiBJIHdvdWxkIGV4cGVj dCByZWxhdGl2ZWx5IGEgc21hbGwgbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucy4gVGh1cywgSSBk byBub3QgdGhpbmsgdGhhdCB0aGUgZmFjdCB0aGF0IGEgcGFja2V0IGlzIHJldHJhbnNtaXR0ZWQg dmlhIG11bHRpY2FzdCB3b3VsZCBiZSBhIGJpZyBpc3N1ZSAobm90ZSB0aGF0IHdoZW4gcmV0cmFu c21pdHRpbmcgZHVlIHRvIGEgTkFDSyB5b3UgY2FuIGVpdGhlciBzZW5kIHZpYSBtdWx0aWNhc3Qg b3IgZGlyZWN0bHkgdXNpbmcgdW5pY2FzdCwgZGVwZW5kaW5nIG9uIHRoZSBhbW91bnQgb2YgRkUn cyB0aGF0IGhhZCBuYWNrZWQgdGhlIHBhY2tldC4uLikuIA0KIA0KQWxzbyAtIHNlY3VyaXR5IGFu ZCBtdWx0aWNhc3QgaGF2ZSByZWNlaXZlZCBxdWl0ZSBsb3RzIG9mIGF0dGVudGlvbiAtIGJvdGgg aW4gdGhlIElFVEYgYW5kIGluIHRoZSByZXNlYXJjaCBjb21tdW5pdHkuLi4gQXMgdGhlIG51bWJl ciBvZiBGRXMgd291bGQgbm90IGJlIHRvbyBiaWcsIHRoZXJlIGFyZSBuaWNlIGFuZCBlbGVnYW50 IHRlY2hpcXVlcyBmb3IgcGVyZm9ybWluZyBhdXRoZW50aWNhdGlvbiBhbmQgZWZmaWNpZW50IGtl eSBleGNoYW5nZSBpbiBzdWNoIGdyb3VwcyAoSSBndWVzcyB0aGF0IGEgcmVhc29uYWJsZSBudW1i ZXIgd291bGQgYmUgb24gdGhlIG9yZGVyIG9mIGNvdXBsZSBvZiBkb3plbnMgaW4gYSByZWFsaXN0 aWMgc2NlbmFyaW8sIGJ1dCBodW5kcmVkcyB3aWxsIGFsc28gd29yayBvaykuDQogDQotIFRhbA0K IA0KIA0KIA0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQWxleCBB dWR1IFttYWlsdG86YWxleC5hdWR1QGFsY2F0ZWwuY29tXSANCglTZW50OiBNb24gMTEvMjQvMjAw MyA3OjAyIFBNIA0KCVRvOiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00gDQoJQ2M6IA0KCVN1 YmplY3Q6IFJlOiBGb3JDRVMgdHJhbnNwb3J0IHJlcXVpcmVtZW50cyBXQVMgKFJlOiBTdXBwb3J0 IGZvciBtdWx0aWNhc3QgaW50aGUgRm9yQ0UuLi4NCgkNCgkNCg0KCVRvIGFkZCB0byBteSBwcmV2 aW91cyBjb21tZW50czoNCgkNCglPbiB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uOg0KCT4gSG93IGNh biB5b3UgaGF2ZSByZWxpYWJsZSBjb21tdW5jYXRpb24gb3ZlciBVRFA/DQoJPg0KCUphbWFsICB3 cm90ZToNCgkgIFRoZSBtZWNoYW5pc21zIHdvdWxkIGJlIGEgcmV0cmFuc21pdCB0aW1lciBhbmQg YWJpbGl0eSB0byBnZXQgQUNLcw0KCSAgb3IgTkFDS3MuDQoJICBOb3RlIHRoZSBkZWZpbml0aW9u IG9mIHJlbGlhYmlsaXR5IGluY2x1ZGVzIGEgdmFsaWQgdGltZS4gU28gdGhpcw0KCSAgdmFsaWRp dHkgaXMgYmVzdCBjb250cm9sZWQgYnkgdGhlIGFwcCAodGhlIEZvckNFUyBwcm90b2NvbCkuIFRD UA0KCSAgZG9lc250IGFsbG93IHlvdSB0byBkbyB0aGlzLg0KCQ0KCU15IGNvbW1lbnRzOg0KCVNv IHRoZSByZXRyYW5zbWl0IHRpbWVyIGZpcmVzLCBhbmQgdGhlbiB5b3UgZG8gYW5vdGhlciBicm9h ZGNhc3Qgb3INCgltdWx0aWNhc3Q/DQoJSSBjYW4gc2VlIGhvdyB0aGlzIGRvZXMgd29uZGVycyBm b3IgeW91ciBDRS1GRSBiYW5kd2lkdGggZWZmaWNpZW5jeS4NCgkNCglJIGRvbid0IHNlZSB3aHkg VENQIGNhbid0IGNvcGUgd2l0aCBzZW5kaW5nIGRhdGEgb3ZlciB6ZXJvLCBvbmUgb3IgdHdvIGhv cHMNCgkodGhlIGVudmlyb25tZW50IGZvciBGb3JDRVMpIGluIHRpbWUgdG8gd2FycmFudCB0aGUg dXNlIG9mIFVEUC4gQWZ0ZXINCglhbGwsIGl0IGlzIG5vdCBsaWtlIHdlIGFyZSBzZW5kaW5nIHBh Y2tldHMgZnJvbSBvbmUgZW5kIG9mIHRoZSBnbG9iZSB0bw0KCWFub3RoZXIhDQoJDQoJQW5kIHlv dSBjYW4ndCBqdXN0IHdhdmUgdGhlIGlzc3VlIG9mIHNlY3VyaXR5IGF3YXkuICAgUm91dGluZyBz ZWN1cml0eSBpcw0KCXF1aXRlDQoJaW1wb3J0YW50IHRoZSBJRVRGIGNyZWF0ZWQgdGhlIFJQU0VD IFdHIHRvIGxvb2sgaW50byB3YXlzIG9mIG1ha2luZw0KCXJvdXRpbmcgcHJvdG9jb2xzIG1vcmUg c2VjdXJlLiAgVGhlIG91dGNvbWUgb2YgdGhhdCBtYXkgbWFrZSBzb21lIGRlbWFuZHMNCglvbiB0 aGUgcm91dGVyIGFyY2hpdGVjdHVyZXMuIEZvciBleGFtcGxlLCBzZXBhcmF0aW5nIGxlc3MgY3Jp dGljYWwgYnV0DQoJYXR0YWNrLXByb25lDQoJIkhlbGxvIiBtZXNzYWdlIGNoYW5uZWwgZnJvbSBj aXJpdGljYWwgTEZCIGNvbmZpZ3VyYXRpb24gYW5kIGNvbnRyb2wgbWVzc2FnZQ0KCQ0KCWNoYW5u ZWwgaXMgYSBnb29kIHJldmVsYXRpb24uDQoJDQoJUmVnYXJkcywNCglBbGV4Lg0KCQ0KCUphbWFs IEhhZGkgU2FsaW0gd3JvdGU6DQoJDQoJPiBPbiBTdW4sIDIwMDMtMTEtMjMgYXQgMTk6MzAsIEFs ZXggQXVkdSB3cm90ZToNCgk+ID4gSGkgQWxsLA0KCT4gPg0KCT4gPiBBbGwgdGhpcyB0YWxrIGFi b3V0IHRoZSBuZWVkIGFuZCBiZW5lZml0cyBvZiBtdWx0aWNhc3QgY2VydGFpbmx5IG1ha2VzDQoJ PiA+IG9uZXMNCgk+ID4gZmVlbCBpdCBpcyBhIGN1cmUgYWxsIGZvciB3aGF0IGlzIGJlaW5nIHRl cm1lZCBhcyB0aGUgYWlsbWVudCBpbg0KCT4gPiBGb3JDRXMnIHJlcXVpcmVtZW50cy4NCgk+ID4N Cgk+DQoJPiBJdCBpcyB1c2VmdWwgdG8gaGF2ZTsgaXQgaXMgbm90IGxpc3RlZCBhcyBhIHJlcXVp cmVtZW50IC0ganVzdCBsaWtlDQoJPiBjb25nZXN0aW9uIGNvbnRyb2wgaXMgbm90IGxpc3RlZCBh cyBhIHJlcXVpcmVtZW50IGluIHRoZSBub24tZ2xvYmFsDQoJPiBzY29wZSBidXQgdXNlZnVsIHRv IGhhdmUuDQoJPg0KCT4gPiBMb29rLCBpdCBoYXMgdG8gYmUgdG9sZCB0aGF0IHlvdSBjYW4ndCBk byBtdWx0aWNhc3Qgb24gdGhlIGNoZWFwLiBBbmQNCgk+DQoJPiBZb3Ugd2lsbCBoYXZlIHRvIHNo b3cgbWUgYSBzaW5nbGUgc3dpdGNoIGZhYnJpYyB0aGF0IGNhbnQgZG8gbXVsdGljYXN0DQoJPiBv ciBicm9hZGNhc3QuIFBpY2sgYW55IG5ldGdlYXIgb3IgZGxpbmsgJDEgc3dpdGNoIGFuZCBzaG93 IG1lIGl0IGRvZXNudA0KCT4gc3VwcG9ydCBtdWx0aWNhc3QuIEhvdyBjaGVhcCBkbyB5b3Ugd2Fu dCB0byBnbz8NCgk+DQoJPiA+ICB5b3UgaGF2ZQ0KCT4gPiB0byBhbnN3ZXIgc29tZSBrZXkgcXVl c3Rpb25zIGlmIHlvdSByZWFsbHkgd2FudCB0byBzZWxsIG11bHRpY2FzdCBpbiBhDQoJPiA+IGNy aXRpY2FsDQoJPiA+IGVudmlyb25tZW50LC4udml6Og0KCT4NCgk+IFtkZWxldGVkIHRoaW5ncyB3 aGljaCBoYXZlIGJlZW4gcmVwZWF0ZWQgaW4gdGhlIGxhc3QgMTAgZW1haWxzIG9uIHRoaXMNCgk+ IHN1YmplY3QgZm9yIGJyZXZpdHldDQoJPg0KCT4gPg0KCT4gPiBUaGVyZSBpcyBhbHNvIHRoaXMg bXl0aCB0aGF0IGFsbCB0aGUgRkVzIHdpbGwgaGF2ZSB0aGUgc2FtZSByb3V0aW5nDQoJPiA+IGlu Zm9ybWF0aW9uDQoJPiA+IGFsd2F5cy4NCgk+DQoJPiBBbGwgZXhhbXBsZXMgaSBoYXZlIHNlZW4g c2F5IHRoYXQgbW9zdCBub3QgYWxsLg0KCT4NCgk+ID4gSSBzdWJtaXQgdGhhdCB0aGlzIGlzIG5v dCB0cnVlLiAgT25lIG9mIHRoZSBwcm9ibGVtcyBGb3JDRXMgaXMgbWVhbnQNCgk+ID4gdG8NCgk+ ID4gc29sdmUgaXMgc2NhbGFiaWxpdHkuIFRoaXMgY2VydGFpbmx5IHJlbGF0ZXMgdG8gdGhlIGFi aWx0eSB0byBtYW5hZ2UNCgk+ID4gdGhlIHJhcGlkDQoJPiA+IGdyb3d0aCBvZiByb3V0aW5nIHRh YmxlIHNpemVzIGJ5IGRpc3RyaWJ1dGluZyB0aGUgcm91dGluZyBpbmZvcm1hdGlvbg0KCT4gPiBh cyBwYXJ0aWFsDQoJPiA+IHJvdXRlcyBpbnRvIHZhcmlvdXMgRkUgZ3JvdXBzLiAgR3JhbnRlZCB0 aGVyZSBpcyBzdGlsbCBzb21lIHNjYWxpbmcNCgk+ID4gaXNzdWVzDQoJPiA+IGhlcmUsLi5idXQg aXMgZGVmaW5pdGVseSBub3QgYXMgYmFkIGFzIHBlb3BsZSBoYXZlIGJlZW4gbWFraW5nIGl0IHRv DQoJPiA+IGJlLg0KCT4gPg0KCT4NCgk+IEkgYW0gbm90IHN1cmUgaSBmb2xsb3dlZC4gQXJlIHdl IGJhY2sgdG8gdGhlIHRvcGljIHRoYXQgdGhlIHByb2JsZW0gaXMgYQ0KCT4gc3RhcnR1cCBpc3N1 ZT8NCgk+DQoJPiA+ICAgICAgLi5tb3JlIGNvbW1lbnRzIGluLWxpbmUuLi4NCgk+DQoJPiBUaGFu a3MgZm9yIGJlaW5nIGJyYXZlIGFuZCBhZGRyZXNpbmcgdGhlc2UgaXNzdWVzLg0KCT4NCgk+ID4g UmVnYXJkcywNCgk+ID4gQWxleC4NCgk+ID4NCgk+ID4gSW4gYSBtZXNzYWdlIGRhdGVkIDExLzIy LzIwMDMgMTI6MDM6MjQgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lLA0KCT4gPiBoYWRpQHpueXgu Y29tIHdyaXRlczoNCgk+ID4NCgk+ID4NCgk+ID4gPiBDb250aW51YXRpb24gb2YgdGhlIGxhc3Qg dGhyZWFkIHdpdGggYSBjaGFuZ2UgaW4gdG9waWMgLSBpIHRoaW5rDQoJPiA+ID4gdGhlc2UNCgk+ ID4gPiBhcmUgdGhlIHJlYWwgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgaW5zdGVh ZCBvZiB0aGUNCgk+ID4gPiBkaXN0cmFjdGlvbg0KCT4gPiA+IHRvICJtdWx0aWNhc3QgaXMgZXZp bCIuDQoJPiA+ID4NCgk+ID4gPiBMZXRzIHJlYWxseSBsaXN0IHRoZSByZXF1aXJlbWVudHMgbmVl ZGVkIGZvciBhIHN1Y2Nlc3NmdWwgdW5kZXJseWluZw0KCT4gPiA+IHRyYW5zcG9ydCBwcm90b2Nv bCB0aGF0IHdpbGwgc2VydmUgRm9yQ0VTIHdlbGwuIGkgbWF5IGJlDQoJPiA+ID4gbWlzc2luZyBz b21lIC0gYnV0IGkgaG9wZSB0byBnZXQgY2hhbGxlbmdlZCBzbyBpIGNhbiBhZGQgdG8gdGhlbTsN Cgk+ID4gPiBJIGFtIHRoaW5raW5nIG9mIHR1cm5pbmcgdGhpcyBpbnRvIGEgZHJhZnQgc28gcGVv cGxlIHJlYWQgaXQgZmlyc3QNCgk+ID4gPiBhbmQNCgk+ID4gPiB0aGVuIHBvc3QuDQoJPiA+ID4g TXkgcHJldmlvdXMgZW1haWwgaGFzIHNvbWUgbW9yZSBjbGFpbXMgd2hpY2ggaSB3aWxsIGFzc3Vt ZSBoZXJlLg0KCT4gPiA+DQoJPiA+ID4gSS4gRm9yQ0VTICBtZWNoYW5pc21zIHJlcXVpcmluZyBy ZWxpYWJpbGl0eToNCgk+ID4gPg0KCT4gPiA+IGEpIHRpbWUgbGltaXQgdmVyeSBzZW5zaXRpdmUg KGluIG90aGVyIHdvcmRzIG9ic29sZW5jZSBwZXJpb2QgaXMNCgk+ID4gPiBmYXN0ZXIpOg0KCT4g PiA+IEV4YW1wbGUgdGFibGUgdXBkYXRlczsNCgk+ID4gPiBJIGhhdmUgYXJndWVkIFRDUCBkb2Vz bnQgcXVhbGlmeSBpbiBteSBwcmV2aW91cyBlbWFpbC4gU0NUUC1QUiBtYXkNCgk+ID4gPiBxdWFs aWZ5Lg0KCT4gPiA+IFNvbWV0aGluZyBsaWtlIHdoYXQgbmV0bGluazIgb3ZlciBVRFAgcXVhbGlm aWVzIGJlY2F1c2UgaXQgZ2l2ZXMNCgk+ID4gPiBjb250cm9sDQoJPiA+ID4gdG8gbmV0bGluazIg dG8gbWFrZSBzdWNoIGRlY2lzaW9ucy4NCgk+ID4NCgk+ID4NCgk+ID4gSG93IGNhbiB5b3UgaGF2 ZSByZWxpYWJsZSBjb21tdW5jYXRpb24gb3ZlciBVRFA/DQoJPiA+DQoJPg0KCT4gVGhlIG1lY2hh bmlzbXMgd291bGQgYmUgYSByZXRyYW5zbWl0IHRpbWVyIGFuZCBhYmlsaXR5IHRvIGdldCBBQ0tz DQoJPiBvciBOQUNLcy4NCgk+IE5vdGUgdGhlIGRlZmluaXRpb24gb2YgcmVsaWFiaWxpdHkgaW5j bHVkZXMgYSB2YWxpZCB0aW1lLiBTbyB0aGlzDQoJPiB2YWxpZGl0eSBpcyBiZXN0IGNvbnRyb2xl ZCBieSB0aGUgYXBwICh0aGUgRm9yQ0VTIHByb3RvY29sKS4gVENQDQoJPiBkb2VzbnQgYWxsb3cg eW91IHRvIGRvIHRoaXMuDQoJPg0KCT4gPiA+IElJLiAgbWVjaGFuaXNtcyBjYXBhYmxlIG9mIHRv bGVyYXRpbmcgdW5yZWxpYWJpbGl0eTogRXhhbXBsZSBwc2FtcC4NCgk+ID4gPiBUQ1AgZG9lc250 IHF1YWxpZnkuDQoJPiA+ID4gc29tZXRoaW5nKGxpa2UgbmV0bGluazIpIG92ZXIgVURQIG9yIFND VFAtUFIuDQoJPiA+DQoJPiA+DQoJPiA+IFdoeSBkbyB5b3Ugc2F5IFRDUCBkb2Vzbid0IHF1YWxp ZnkgaGVyZT8gIEFueSBhcHBsaWNhdGlvbiB0aGF0IGNhbg0KCT4gPiBsaXZlDQoJPiA+IHdpdGgg dW4tcmVsaWFibGUgdHJhbnNwb3J0IGNhbiBzdXJlIGRvIGJldHRlciB3aXRoIGEgcmVsYWlibGUg b25lLg0KCT4gPg0KCT4NCgk+IFlvdSBhcmUgcmlnaHQuIFRDUCBxdWFsaWZpZXMgYW5kIHRoZSBv dGhlciB0d28gYXMgd2VsbC4NCgk+DQoJPiA+ID4gSUlJLiBtZWNoYW5pc21zIHRoYXQgcHJlZmVy IHRpbWVsaW5lc3Mgb3ZlciByZWxpYWJpbGl0eTogRXgNCgk+ID4gPiBoZWFydGJlYXRzDQoJPiA+ ID4gc29tZXRoaW5nIChsaWtlIG5ldGxpbmsyKSBvdmVyIFVEUCBvciBTQ1RQLVBSLg0KCT4gPiA+ DQoJPg0KCT4gSSB0YWtlIGl0IHlvdSBhZ3JlZSBUQ1AgZmFpbHMgaWYgeW91IHJlYWxseSB2YWx1 ZSB0aW1lbGluZXMuDQoJPg0KCT4gPiA+IE5vdyBvbiB0aGUgY2hvaWNlIG9mIG5ldGxpbmsyIFVE UCB2cyBTQ1RQLVBSDQoJPiA+ID4NCgk+ID4gPiAxKSBVRFAgaXMgaGVyZSB0b2RheS4gU0NUUC1Q UiBpcyBub3QuIFdoZW4gU0NUUC1QUiBiZWNvbWVzIGF2YWlsYWJsZQ0KCT4gPiA+IE5ldGxpbmsy IGNhbiBydW4gb3ZlciBpdC4gRm9yIG5vdyB3ZSBjaG9vc2UgdG8gYmUgc3RhbmRhbG9uZTogV2Ug Y2FuDQoJPiA+ID4gcnVuDQoJPiA+ID4gb3ZlciBJUCwgb3ZlciBVRFAgb3Igb3ZlciBldGhlcm5l dCwgeW91IHRha2UgeW91ciBwaWNrLg0KCT4gPg0KCT4gPiBJIGJlbGlldmUgU0NUUC1QUiBpcyBu b3cgaW4gSUVTRyBxdWV1ZS4gRXZlbiB3aGVuIGl0IGlzIGF2YWlsYWJsZSwgeW91DQoJPiA+IGhh dmUNCgk+ID4gdG8gcnVuIGl0IGluIGEgcmVsaWFibGUgbW9kZSB0byBndWFyYW50ZWUgdGhhdCB0 aG9zZSBjcml0aWNhbA0KCT4gPiBjb25maWd1cmF0aW9uDQoJPiA+IG1lc3NhZ2VzIGdldCB0byB0 aGVpciBkZXN0aW5hdGlvbiBzYWZlbHkuIEFuZCBpdCBzdGlsbCBkb2Vzbid0IGJ1eSB5b3UNCgk+ ID4gc2VjdXJpdHkuDQoJPg0KCT4gSSB0aGluayBpdCBoYXMgYmVlbiBpc3N1ZWQgUkZDIHN0YXR1 cy4NCgk+IFNDVFAtUFIgd291bGQgYmUgYSBiZXR0ZXIgY2hvaWNlIHRoYW4gVENQLiBCZWNhdXNl IGl0IHdpbGwgZ2l2ZSB1c2VyDQoJPiBjb250cm9sIG9mIHJlbW92aW5nIHN0YWxlIG1lc3NhZ2Vz Lg0KCT4NCgk+ID4NCgk+ID4gPiAyKSBVRFAgcHJvdmlkZXMgbXVsdGljYXN0IChhbmQgYnJvYWRj YXN0KS4gU0NUUC1QUiBkb2VzIG5vdC4NCgk+ID4gPiBTaW5jZSBTQ1RQIGhhcyB0dXJuZWQgdG8g YmUgYSBzd2lzcyBrbmlmZSAob3IgbWF5YmUgYSBtdWx0aSBmYWNldGVkDQoJPiA+ID4gYmVhc3Qp LCBpIGFtIHN1cmUgaXQgd2lsbCBzb29uIGFzIHdlbGwgc3VwcG9ydCBtdWx0aWNhc3Q7LT4NCgk+ ID4gPg0KCT4gPiA+IElmIG11bHRpY2FzdCBpcyB0aGVyZSAtIHdlIHdpbGwgdXNlIGl0LiBTYW5z IHRoYXQgd2Ugd2lsbCBkbw0KCT4gPiA+IHNvbWV0aGluZw0KCT4gPiA+IG11bHRpY2FzdCBsaWtl IChKb24gY2FsbHMgaXQgdW5pcmVwbGljYXRlIGkgdGhpbmspLg0KCT4gPiA+IEFsbCB0aGUgdGhy ZWUgY2F1dGhvcnMgaGF2ZSBoYWQgcGxlYXNhbnQgZXhwZXJpZW5jZXMgdXNpbmcgbXVsdGljYXN0 DQoJPiA+ID4gZm9yDQoJPiA+ID4gRm9yQ0VTIGxpa2UuIFdlIHRoaW5rIGl0IGlzIGEgZ29vZCB0 aGluZyB0byBoYXZlLiBCdXQgd2Ugd2lsbCBub3QNCgk+ID4gPiB0b3J0dXJlIHlvdSBpZiB5b3Ug ZG9udCBoYXZlIG11bHRpY2FzdCBvciBicm9hZGNhc3QgOy0+DQoJPiA+ID4NCgk+ID4gPiBXaHkg TXVsdGljYXN0IGlzIHVzZWZ1bDoNCgk+ID4gPiAtLQ0KCT4gPiA+IEkgbXVzdCBhcG9sb2dpemUg c2luY2UgaSBoYXZlIHRvIHJlcGVhdCB0aGlzLg0KCT4gPiA+IEluIHRoZSBzaW1wbGUgY2FzZSBv ZiBhIHNpbmdsZSBtdWx0aWNhc3Qgd2lyZTogZWFjaCBvZiB0aGUgQ0VzIG9yDQoJPiA+ID4gRkVz DQoJPiA+ID4gb3BlbnMgYSBzaW5nbGUgbXVsdGljYXN0IHNvY2tldC9jaGFubmVsLg0KCT4gPiA+ DQoJPiA+ID4gV2h5IGlzIHRoaXMgZ29vZDoNCgk+ID4gPg0KCT4gPiA+IDEpIEJhbmR3aWR0aCBp cyBsZXNzIHVzZWQNCgk+ID4gPiBhKWJlY2F1c2Ugb25lIG9yIG1vcmUgQ0VzIGNhbiBzZW5kIGEg c2luZ2xlIG1lc3NhZ2UgdG8gYWxsIEZFcy4NCgk+ID4gPiBJIHJlYWxseSBkb250IHdhbnQgdG8g YmUgdGVhY2hpbmcgcGVvcGxlIHRoZSBob3dzIGJ1dCBpIHdpbGwgcHJvdmlkZQ0KCT4gPiA+IG9u ZQ0KCT4gPiA+IGV4YW1wbGUgd2hpY2ggRGF2aWQgb3IgbWF5YmUgaXQgd2FzIEpvZWwgZGlkbnQg c2VlbSB0byBtYWtlIHNlbnNlDQoJPiA+ID4gb3V0IG9mDQoJPiA+ID4gKGJ1dCBvbmUgdGhhdCBp IGhhdmUgc3VjY2Vzc2Z1bHkgdXNlZClbMV0NCgk+ID4gPiBiKSB5b3UgY2FuIHJlZHVjZSB0aGUg bnVtYmVyIG9mIHBhY2tldHMgZnVydGhlciBieSBsaW1pdGluZyBvbg0KCT4gPiA+IEFDS3MgKHBh cnRpYWwgYWNrcykNCgk+ID4gPg0KCT4gPiA+IDIpIFJBTSBvbiB0aGUgZW1iZWRkZWQgQ0Ugb3Ig RkUgaXMgdXNlZCBsZXNzLiBUaGVyZSBhcmUgbGVzcyBzb2NrZXRzDQoJPiA+ID4gb3BlbiBhbmQg bGVzcyBtZXNzYWdlcyBiZWluZyBidWlsdA0KCT4gPiA+DQoJPg0KCT4gSSB0YWtlIGl0IHlvdSBh Z3JlZSB3aXRoIHRoZSBhYm92ZSB0d28gOy0+DQoJPg0KCT4gPiA+IDMpIENQVSBpcyBwcmVzZXJ2 ZWQgbW9yZS4NCgk+ID4gPiBTaW5jZSB0aGVyZSBhcmUgZmV3ZXIgbWVzc2FnZXMgdG8gcHJvY2Vz cyBhbmQgZmV3ZXIgKHNvY2tldCBzdGF0ZXMpDQoJPiA+ID4gc3RhdGVzIHRvIHRyYWNrLg0KCT4g Pg0KCT4gPg0KCT4gPiBBcyBmYXIgYXMgSSBhbSBjb25jZXJuZWQsIHRoZSBtb3JlIGNyaXRpY2Fs IHJlc291cmNlIENQVS13aXNlIGlzIEZFLg0KCT4gPiBUaGUNCgk+ID4gbXV0bGljYXN0IHNjaGVt ZSBOZXRsaW5rMiBwcm9wb3NlcyBibGFzdHMgYWxsIGV2ZXJ5IHBhY2tldCB0byBldmVyeQ0KCT4g PiBGRS4NCgk+ID4gRWFjaCBGRSBoYXMgdG8gZG8gd29yayB0byBmaWx0ZXIgb3V0IHdoaWNoIHBh Y2tldCBkb2Vzbid0IGJlbG9uZyB0bw0KCT4gPiBpdC4gVGh1cywNCgk+ID4gdGhlIEZFIHNwZW5k cyBhIGxvdCBvZiBDUFUgY3ljbGVzIGZpbHRlcmluZyBvZmYgdW53YW50ZWQNCgk+ID4gcGFja2V0 cywuLmN5Y2xlcw0KCT4gPiB0aGF0IHNob3VsZCBiZSBiZXN0IHVzZWQgaW4gZm9yd2FyZGluZyBw YWNrZXRzLg0KCT4gPg0KCT4NCgk+IEkgd2FzbnQgc3VyZSB3aGV0aGVyIGkgc2hvdWxkIHJlc3Bv bmQgdG8gdGhpcyBvciBub3QuIEkgaGF2ZSBhZGRyZXNzZWQNCgk+IGl0IGluIHByZXZpb3VzIGVt YWlscyBhbmQgaXQgaXMgYWRkcmVzZWQgaW4gdGhlIGRyYWZ0Lg0KCT4gRm9yIGJyZXZpdHk6IFll cyB0aGlzIG1heSBiZWNvbWUgYW4gaXNzdWUsIGJ1dCB0aGVyZSBhcmUgc29sdXRpb25zLg0KCT4N Cgk+ID4NCgk+ID4gPiA0KSBUaGUgYWJpbGl0eSBmb3IgYWxsIGxpc3RlbmVycyBvbiB0aGUgd2ly ZSB0byBzZWUgbWVzc2FnZQ0KCT4gPiA+IGV4Y2hhbmdlcw0KCT4gPiA+IGV2ZW4gd2hlbiBub3Qg ZGlyZWN0ZWQgYXQgdGhlbSBwcm92aWRlcyBhIGNoZWFwIHdheSB0byBzeW5jaHJvbml6ZS4NCgk+ ID4NCgk+ID4NCgk+ID4gQW5kIG9mIGNvdXJzZSwgaWYgdGhpcyBpcyBhIG1hbGljaW91cyBub2Rl LCBpdCB3aWxsIGdsYWRseSBnbGVhbSBhcw0KCT4gPiBtdWNoIGluZm9ybWF0aW9uDQoJPiA+IGFz IGlzIGVub3VnaCB0byBtb3VudCBhbiBhdHRhY2suIFRoaXMgaXMgd2h5IHNlY3VyZSBtdWx0aWNh c3QgaXMNCgk+ID4gbmVjZXNzYXJ5Lg0KCT4NCgk+IFRoZSBNU0VDIHBlb3BsZSBzaG93ZWQgdXAg YXQgdGhlIGxhc3QgV0cgbWVldGluZyAtIGl0IGlzIHRvbyBiYWQgdGhhdA0KCT4gbm9vbmUgcmFp c2VkIHRoaXMgaXNzdWUuIEkgZG9udCB3YW5uYSBkaXNjdXNzIHRoaXMgLSBpdHMgYSBzZXBhcmF0 ZQ0KCT4gaXNzdWUuIEl0IGlzIHNvbHZhYmxlLiBMZXQgbWUgYXNrIHRoZSBmb2xsb3dpbmcgc2lu Y2UgeW91IGJyaW5nIHRoZQ0KCT4gaXNzdWUgb2Ygc2NhbGFiaWxpdHk6DQoJPiBJZiB5b3Ugd2Vy ZSB0byBlbmNyeXB0IG1lc3NhZ2VzLCB3b3VsZCBpdCBiZSBjaGVhcGVyIHRvIGVuY3J5cHQgdHdv DQoJPiBtdWx0aWNhc3RlZCBmbG93cw0KCT4gb3IgOCB1bmlyZXBsaWNhdGVkIGZsb3dzPyBJIGhh dmUgc2VlbiBwcm9jZXNzb3JzIGhhdmluZyBwcm9ibGVtIHdpdGggYQ0KCT4gc2luZ2xlIGZsb3cu DQoJPg0KCT4gPiA+IDUpIEF0IGEgdHJhbnNwb3J0IGxldmVsLCAobm90IHRoZSBmb3JjZXMgdHJh bnNhY3Rpb24gbGV2ZWwpLCBoYXZpbmcNCgk+ID4gPiBhY2Nlc3MgdG8gbXVsdGljYXN0IHByb3Zp ZGVzIGxvY2F0aW9uIHRyYW5zcGFyZW5jeS4NCgk+ID4gPg0KCT4NCgk+IEkgdGFrZSBpdCB5b3Ug YWdyZWUgd2l0aCB0aGlzLg0KCT4NCgk+ID4gPiA2KSBBIGxvdCBvZiBzd2l0Y2ggZmFicmljcyAo c2hhcmVkIG1lbW9yeSBkZXNpZ25zIG9yIG90aGVyd2lzZSkNCgk+ID4gPiBpbnRlcmNvbm5lY3Rp bmcgRkVzIGFuZCBDRVMgaGF2ZSBtdWx0aWNhc3QgY2FwYWJpbGl0aWVzOyBzbyBpdCBpcw0KCT4g PiA+IGdvb2QNCgk+ID4gPiBpZiB3ZSBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YgaXQgd2hlcmUgcG9z c2libGUuDQoJPiA+ID4NCgk+DQoJPiBJIHRha2UgaXQgeW91IGFncmVlIHdpdGggdGhpcy4NCgk+ DQoJPiA+ID4gVGhlIGFib3ZlIGlzIHRoZSBzaW1wbGUgY2FzZSwgYnkgaW5kdWN0aW9uIHlvdSBj b3VsZCBleHRlbmQgdGhlDQoJPiA+ID4gcmVhc29uaW5nIHRvIHRoZSBjYXNlIHdoZXJlIHlvdSBo YXZlIFggc29ja2V0cy4NCgk+ID4gPg0KCT4NCgk+IEkgdGFrZSBpdCB5b3UgYWdyZWUgd2l0aCB0 aGlzIGFzIHdlbGwuDQoJPg0KCT4gY2hlZXJzLA0KCT4gamFtYWwNCgkNCgkNCgkNCg0K From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 19:53:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14363 for ; Mon, 24 Nov 2003 19:53:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORS7-00027Z-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 19:53:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AORS7-00027S-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 19:53:15 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C56AE2@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 19:53:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61841610 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 19:53:13 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 19:53:13 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAP0rYBV008502 for ; Tue, 25 Nov 2003 00:53:34 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAP0hEb02416 for ; Tue, 25 Nov 2003 00:43:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112416531023585 for ; Mon, 24 Nov 2003 16:53:10 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Nov 2003 16:53:10 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Support for multicast in the ForCES protocol Thread-Index: AcOxaXfFy5My8WUcSSWPyS2RglqAVgBdzA3Q X-OriginalArrivalTime: 25 Nov 2003 00:53:10.0725 (UTC) FILETIME=[7F7B3F50:01C3B2EE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD80195EB86@orsmsx409.jf.intel.com> Date: Mon, 24 Nov 2003 16:53:10 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable [chair hat off] Jamal Hadi Salim wrote > David Putzolu wrote > > > Ok, thanks for providing this because it cleared some confusion as to > what angle you are looking at things. > We are being bitten by lack of some NPF document again (i saw your > description before in my brief glance of an NPF doc at MPLS). As i > mentioned the need for NPF documents is to at least understand what one > is arguing against. We would have saved a lot of bandwith on this > thread. I used XML because it is a well known and fairly understandable=20 way of expressing structured information. I didn't base the example on any NPF materials. Likely this is a case of some NPF proposal using XML and my example using XML both for the=20 same reasons: it is useful :) > > In the multicast case, I assume each FE would have a different set > > of IDs for the LFBs (perhaps the IPv4 FIB LFB would be #17 on > > FE#1, but would be #12 on FE#2. So just multicasting the above > > message would not make any sense. >=20 > Why would the LFBID change depending on whether it was unicast or > multicast? The LFBID would stay pretty static across FEs, > and is probably issued by IANA. I assume IANA will issue LFB *type* identifiers - so there would=20 indeed be a single one for IPv4 FIB type. I had also assumed that individual FEs will instantiate LFBs of each type one or more=20 times, with assigned instance identifiers. For those familiar with OO, this is equivalent to the difference between declaring classes=20 and instantiating objects. More concretely: FE1 has two IPv4 FIBs (IANA FIB type ID =3D 37): FIB1 (instance ID=3D17) = and FIB2 (instance ID=3D21). FE2 has one IPv4 FIB (IANA FIB type ID =3D 37): FIB3 (instance ID=3D12) = and=20 FIB4 (instance ID=3D23). The goal is to add an entry to FIB1 and FIB4, but not FIB2 or=20 FIB3, and to use multicast to do it. Using netlink2 terminology, I'd be worried about=20 multicasting a RTM_NEWROUTE command to both FEs, because it would affect all 4 FIBs. Adding the PID attribute and having it map to instance identifiers to the mcast message doesn't seem=20 to help, because in a multicast message the identical PID value=20 would be sent to both FE recipients. One solution to allow type-based (as opposed to instance-based) addressing is to stipulate that multicast can only be used when=20 there is exactly one instance of each LFB type on every FE. This solves the problem, but it narrows the utility of=20 multicast significantly. > I am begining to understand where all the confusion was coming from. > I have to say i found it strange when i saw mentions of=20 > multicast groups per LFB that were posted earlier. Please make those=20 > NPF documents available. The most relevant NPF document (and the only one I've consulted=20 while participating in this discussion) is the NPF IPv4=20 forwarding API, which can be found at: http://www.npforum.org/techinfo/IPv4_IA.pdf However, my concern about IANA-defined LFB type identifiers vs. runtime assigned LFB instance identifiers in the context of multicast is independent of the NPF docs. I'm probably missing something here - I'm not a netlink2 expert - and there is probably a way to address the concern above=20 while using multicast and still allowing multiple instances=20 of each LFB type per FE, without requiring an explosion of multicast groups. However, I couldn't find it in my readings or recollection, so please help me out here by pointing it out! Cheers, David=20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 21:19:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16736 for ; Mon, 24 Nov 2003 21:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOSnw-0003IR-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 21:19:53 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOSnw-0003IO-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 21:19:52 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C56BCE@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 21:19:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61849331 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 21:19:51 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 21:19:51 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAP2Jp326876 for ; Mon, 24 Nov 2003 21:19:51 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAP2JoB56514 for ; Mon, 24 Nov 2003 21:19:50 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id VAA06628 for ; Mon, 24 Nov 2003 21:19:50 -0500 (EST) References: <9CB758BBEE58754F8F33234D75B9F4B0F54AF2@orsmsx410.jf.intel.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069726789.30919.7.camel@newcastle.torrentnet.com> Date: Mon, 24 Nov 2003 21:19:49 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0F54AF2@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2003-11-24 at 15:35, Khosravi, Hormuzd M wrote: > Hi Tal > > There is already a ForCES Requirements draft which has been approved for > RFC. > Pls see... > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx > t > This has a section on protocol requirements. The problem with this draft (IMHO) is that it specifies a very broad range of requirements, and it is not clear that they can all be satisfied simultaneously using the same protocol techniques (which is not to say that they cannot be satisfied using the same protocol, it will however have to be very flexible). Another problem is that there is no prioritization applied to the requirements. Therefore, different individuals prioritize them independently based on their own priorities and product requirements. I personally prioritize scalability and timeliness, and really have no use for the security requirement, because I don't envision having to deploy CE-FE communications over an open network. Other opinions may differ. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 21:49:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17592 for ; Mon, 24 Nov 2003 21:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTH3-0003iq-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 21:49:57 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOTH2-0003im-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 21:49:56 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C56C6F@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 21:49:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61851983 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 21:49:55 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 21:49:55 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAP2nt327479 for ; Mon, 24 Nov 2003 21:49:55 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id hAP2nsB58715 for ; Mon, 24 Nov 2003 21:49:54 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id VAA06862 for ; Mon, 24 Nov 2003 21:49:54 -0500 (EST) References: Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1069728593.30919.38.camel@newcastle.torrentnet.com> Date: Mon, 24 Nov 2003 21:49:54 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Here is a contrived, but representative example of the type of problem I think that ForCES needs to be able to solve to make it more useful for me than a home-grown solution. Imagine a NE with one (active) CE and 64 FEs, each forwarding global routes. 64K external prefixes are currently reachable via peer A. Suddenly the peering to A fails, and now half the prefixes are reachable via peer B and the other half via peer C. No matter how cleverly you have designed your datastructures, in the general case you are going to have to update at least 32K table entries. Suppose you can pack 64 table updates/ForCES packet (~1500 byte packet with ~24 byte entries). Then the CE will have to send 500 packets/FE * 64 FEs = 32K packets if ForCES is restricted to unicast transport. That works out to about 400 Mbits, which will take 400 msec to transmit at full blast assuming the CE is attached via gigabit Ethernet. Meanwhile the NE might be forwarding several gigabits worth of traffic into a black hole. This solution simply doesn't meet my timeliness requirements. So I can choose to hope that the number of FEs in my NE increases slower than Moore's Law, I can choose to try and come up with a proprietary mechanism for splitting this update load across several CEs, or I can choose to explore whether multicast can be utilized to minimize the update latency. For the moment I have chosen the latter, but I am willing to listen to arguments as to why that is the wrong choice. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 22:31:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18573 for ; Mon, 24 Nov 2003 22:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTvW-0004Gf-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:31:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOTvV-0004GZ-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:31:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C56CEE@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 22:31:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61855806 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 22:31:43 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 22:31:43 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112419305168:8646 ; Mon, 24 Nov 2003 19:30:51 -0800 References: <52D13A805349A249960B9943E5590BD80195EB86@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/24/2003 07:30:52 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/24/2003 07:30:54 PM, Serialize complete at 11/24/2003 07:30:54 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069731099.1038.70.camel@jzny.localdomain> Date: Mon, 24 Nov 2003 22:31:39 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD80195EB86@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2003-11-24 at 19:53, Putzolu, David wrote: > [chair hat off] > Jamal Hadi Salim wrote > > David Putzolu wrote > > > > Ok, thanks for providing this because it cleared some confusion as to > > what angle you are looking at things. > > We are being bitten by lack of some NPF document again (i saw your > > description before in my brief glance of an NPF doc at MPLS). As i > > mentioned the need for NPF documents is to at least understand what > one > > is arguing against. We would have saved a lot of bandwith on this > > thread. > > I used XML because it is a well known and fairly understandable > way of expressing structured information. I didn't base the > example on any NPF materials. Likely this is a case of some > NPF proposal using XML and my example using XML both for the > same reasons: it is useful :) > I'll take your word for it. > > > > In the multicast case, I assume each FE would have a different set > > > of IDs for the LFBs (perhaps the IPv4 FIB LFB would be #17 on > > > FE#1, but would be #12 on FE#2. So just multicasting the above > > > message would not make any sense. > > > > Why would the LFBID change depending on whether it was unicast or > > multicast? The LFBID would stay pretty static across FEs, > > and is probably issued by IANA. > > I assume IANA will issue LFB *type* identifiers - so there would Thats what i thought you meant. > indeed be a single one for IPv4 FIB type. I had also assumed that > individual FEs will instantiate LFBs of each type one or more > times, with assigned instance identifiers. For those familiar with > OO, this is equivalent to the difference between declaring classes > and instantiating objects. > > More concretely: > FE1 has two IPv4 FIBs (IANA FIB type ID = 37): FIB1 (instance ID=17) and > > FIB2 (instance ID=21). > FE2 has one IPv4 FIB (IANA FIB type ID = 37): FIB3 (instance ID=12) and > FIB4 (instance ID=23). > The goal is to add an entry to FIB1 and FIB4, but not FIB2 or > FIB3, and to use multicast to do it. > > Using netlink2 terminology, I'd be worried about > multicasting a RTM_NEWROUTE command to both FEs, because > it would affect all 4 FIBs. You must have missed the table Id then. Look at section 8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template" > Adding the PID attribute and having > it map to instance identifiers to the mcast message doesn't seem > to help, because in a multicast message the identical PID value > would be sent to both FE recipients. > Refer to above and see if it makes sense to you. > One solution to allow type-based (as opposed to instance-based) > addressing is to stipulate that multicast can only be used when > there is exactly one instance of each LFB type on every > FE. This solves the problem, but it narrows the utility of > multicast significantly. > I think you missed some details refer to above and post again. > > > I am begining to understand where all the confusion was coming from. > > I have to say i found it strange when i saw mentions of > > multicast groups per LFB that were posted earlier. Please make those > > NPF documents available. > > The most relevant NPF document (and the only one I've consulted > while participating in this discussion) is the NPF IPv4 > forwarding API, which can be found at: > http://www.npforum.org/techinfo/IPv4_IA.pdf > Thanks - I will look at this; definetely not the same set of docs i was refering to. > However, my concern about IANA-defined LFB type identifiers > vs. runtime assigned LFB instance identifiers in the context > of multicast is independent of the NPF docs. > Its hard to tell when you are still hiding documents ;-> > I'm probably missing something here - I'm not a netlink2 expert - > and there is probably a way to address the concern above > while using multicast and still allowing multiple instances > of each LFB type per FE, without requiring an explosion > of multicast groups. However, I couldn't find it in my readings > or recollection, so please help me out here by pointing it out! > I am responding because i think you are sincere in trying to understand this. I am hoping you will at least refer to the sections of the netlink2 draft i am refering to. I think you are mixing two things: 1) Netlink2 PIDs which can be mapped to entities that can be addressed; these could be FEs, CEs, LFB proxies, LFBs each of which could be a unicast, logical, broadcast or multicast 2) the type field; this is of the format LFB_CMD - example RTM_NEWROUTE which translates that the netlink2 message is directed at an IPV4/6 fwding LFB and it is an add operation. Assume for simplicity, all FEs and a single CE are on the same multicast group (say UDP address 224.x.y.z/port 4312). now lets look at your example: ----------------------- FE1 has two IPv4 FIBs (IANA FIB type ID = 37): FIB1 (instance ID=17) and FIB2 (instance ID=21). FE2 has one IPv4 FIB (IANA FIB type ID = 37): FIB3 (instance ID=12) and FIB4 (instance ID=23). The goal is to add an entry to FIB1 and FIB4, but not FIB2 or FIB3, and to use multicast to do it. ----------------------- There are more than one way to skin this cat. IANA FIB type ID = 37 is mapped into the RTM_* Essentially theres a decimal 37 and a 0(define for NEWROUTE) in the bitmap that represents the type field. [1 represents DELROUTE and 2 GETROUTE] - to add a route, use RTM_NEWROUTE * several ways to skin this cat in terms of PID: You can direct it at the all FEs PID, a all-RTM-LFBS pid etc Now that you have define your target above, you need to target something within the RTM LFB. This is where section 8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template" comes in. - call FIB1 table ID 1 - call FIB2 table ID 2 You can send a single message to add both or two separate message one targeting FIB 1 and another targeting FIB 2. Refer to section 7.5.4 "Batching" Case1: Single message --------------------- You put two templates as in 8.4.2.1 one for each FIB into the single netlink2 message as defined in section 7.5.4 of the form: NLMSGHDR:OET:STFIB1:STFIB2 where STFIB1 is the service template for FIB1 and the other for FIB2. Case2: two messages ------------------- NLMSGHDR:OET:STFB1 followed by NLMSGHDR:OET:STFIB2. You could put both messages in the same Netlink2 PDU as described in section 7.5.4. So far so good? Observe that the transport used is multicast requires that we send a single message to a single socket. The above addressing doesnt have to change if you used TCP unireplicate to FE1 and another to FE2. You just send the same copy to the two FEs on two different unicast sockets. The effort is just a little more ;-> I just wanted to clarify how this is done. I am sure you have other questions. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 22:38:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18754 for ; Mon, 24 Nov 2003 22:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOU2M-0004M8-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:38:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOU2M-0004M5-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:38:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C56D37@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 22:38:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61856532 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 22:38:45 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 22:38:45 -0500 Received: from LOCALHOST ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112419375512:8653 ; Mon, 24 Nov 2003 19:37:55 -0800 References: <52D13A805349A249960B9943E5590BD80195EB86@orsmsx409.jf.intel.com> <1069731099.1038.70.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/24/2003 07:37:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/24/2003 07:37:56 PM, Serialize complete at 11/24/2003 07:37:56 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069731523.1041.75.camel@jzny.localdomain> Date: Mon, 24 Nov 2003 22:38:43 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069731099.1038.70.camel@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2003-11-24 at 22:31, Jamal Hadi Salim wrote: > 8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template" comes in. > > - call FIB1 table ID 1 > - call FIB2 table ID 2 > > You can send a single message to add both or two separate message > one targeting FIB 1 and another targeting FIB 2. -> Sorry, i think you meant address FIB4 instead of FIB2; s/FIB 2/FIB 4/g The example still holds. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Nov 24 22:55:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19176 for ; Mon, 24 Nov 2003 22:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOUIe-0004Yh-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:55:40 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOUId-0004Ye-00 for forces-archive@IETF.ORG; Mon, 24 Nov 2003 22:55:39 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C56C69@cherry.ease.lsoft.com>; Mon, 24 Nov 2003 22:55:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61857323 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 22:55:39 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Nov 2003 22:55:39 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5885563 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Nov 2003 22:55:37 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031124224933.01a02020@localhost> Date: Mon, 24 Nov 2003 22:55:36 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES transport requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069728593.30919.38.camel@newcastle.torrentnet.com> Precedence: list Actually, based on the responsiveness requirements for IP routing, the time constraints for this are not very bad at all. Taking even several seconds to adjust for BGP failure, and black holing traffic in the mean time. Is quite acceptable. Taking even 10 seconds is probably okay. The routing system is actually designed to respond slightly slowly. (Responding too fast to events produces very interesting problems of its own.) For example, when using GigE thorugh a switch (hence not having physical link down detection) the time to detect a neighbor failure is itself several 10s of seconds. Worrying about 1 second of response time to an event that takes 30 seconds to detect does not seem necessary. There are contexts where this is not desirable. In those cases, one takes a completely different approach. Because if small number of seconds is too slow, then one is trying for 50 msec, and one should think about the problem completely differently. (For example, one could create backup FIBs with ones second choices already pre-loaded. Yes, I know that this is a limitted solution. I am not trying to solve the problem, merely to suggest that if it matters one approaches it differently.) Yours, Joel M. Halpern At 09:49 PM 11/24/2003 -0500, you wrote: >Here is a contrived, but representative example of the type of problem I >think that ForCES needs to be able to solve to make it more useful for >me than a home-grown solution. > >Imagine a NE with one (active) CE and 64 FEs, each forwarding global >routes. 64K external prefixes are currently reachable via peer A. >Suddenly the peering to A fails, and now half the prefixes are reachable >via peer B and the other half via peer C. No matter how cleverly you >have designed your datastructures, in the general case you are going to >have to update at least 32K table entries. > >Suppose you can pack 64 table updates/ForCES packet (~1500 byte packet >with ~24 byte entries). Then the CE will have to send 500 packets/FE * >64 FEs = 32K packets if ForCES is restricted to unicast transport. That >works out to about 400 Mbits, which will take 400 msec to transmit at >full blast assuming the CE is attached via gigabit Ethernet. Meanwhile >the NE might be forwarding several gigabits worth of traffic into a >black hole. > >This solution simply doesn't meet my timeliness requirements. So I can >choose to hope that the number of FEs in my NE increases slower than >Moore's Law, I can choose to try and come up with a proprietary >mechanism for splitting this update load across several CEs, or I can >choose to explore whether multicast can be utilized to minimize the >update latency. > >For the moment I have chosen the latter, but I am willing to listen to >arguments as to why that is the wrong choice. > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 01:54:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23165 for ; Tue, 25 Nov 2003 01:54:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOX6I-0006dh-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 01:55:06 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOX6H-0006de-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 01:55:05 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C573CF@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 1:55:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61878431 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 01:55:04 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 01:55:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: ForCES transport requirements Thread-Index: AcOzCDFSgIfKxZLPSBaVSFBo16OYgwAGBHgA Approved-By: Tal Anker Message-ID: Date: Tue, 25 Nov 2003 08:55:13 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: ForCES transport requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, I aggree that the motivation described for having multicast in this case = is a bit weak, but the example is excellent though... In the same = example, I'd expect the time it takes to update the FE's would be more = then the 0.4 sec that Steven's calculation suggest, as this was an = "lower" bound... What I am concerned about in this scenario that during = the time it would take the CE to process (prepare send and handle = reliability) the 32K messages, the NE is suppose to participate in other = duties... (supporting management sessions, participating in control = protocol, etc). If we can minimize the amount of processing from 64*500 = to someting on the order of 500 (plus MAYBE some retransmissions) then = the CE would be more available to its other duties... IMHO, this does = make multicast a very nice thing to have here... - Tal=20 -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Tuesday, November 25, 2003 5:56 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES transport requirements Actually, based on the responsiveness requirements for IP routing, the = time constraints for this are not very bad at all. Taking even several seconds to adjust for BGP failure, and black holing traffic in the mean time. Is quite acceptable. Taking even 10 seconds = is probably okay. The routing system is actually designed to respond = slightly slowly. (Responding too fast to events produces very interesting = problems of its own.) For example, when using GigE thorugh a switch (hence not having physical link down detection) the time to detect a neighbor = failure is itself several 10s of seconds. Worrying about 1 second of response = time to an event that takes 30 seconds to detect does not seem necessary. There are contexts where this is not desirable. In those cases, one = takes a completely different approach. Because if small number of seconds is = too slow, then one is trying for 50 msec, and one should think about the problem completely differently. (For example, one could create backup = FIBs with ones second choices already pre-loaded. Yes, I know that this is a limitted solution. I am not trying to solve the problem, merely to = suggest that if it matters one approaches it differently.) Yours, Joel M. Halpern At 09:49 PM 11/24/2003 -0500, you wrote: >Here is a contrived, but representative example of the type of problem = I >think that ForCES needs to be able to solve to make it more useful for >me than a home-grown solution. > >Imagine a NE with one (active) CE and 64 FEs, each forwarding global >routes. 64K external prefixes are currently reachable via peer A. >Suddenly the peering to A fails, and now half the prefixes are = reachable >via peer B and the other half via peer C. No matter how cleverly you >have designed your datastructures, in the general case you are going to >have to update at least 32K table entries. > >Suppose you can pack 64 table updates/ForCES packet (~1500 byte packet >with ~24 byte entries). Then the CE will have to send 500 packets/FE * >64 FEs =3D 32K packets if ForCES is restricted to unicast transport. = That >works out to about 400 Mbits, which will take 400 msec to transmit at >full blast assuming the CE is attached via gigabit Ethernet. Meanwhile >the NE might be forwarding several gigabits worth of traffic into a >black hole. > >This solution simply doesn't meet my timeliness requirements. So I can >choose to hope that the number of FEs in my NE increases slower than >Moore's Law, I can choose to try and come up with a proprietary >mechanism for splitting this update load across several CEs, or I can >choose to explore whether multicast can be utilized to minimize the >update latency. > >For the moment I have chosen the latter, but I am willing to listen to >arguments as to why that is the wrong choice. > > >Regards, > >=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 >Steven L. Blake >Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 02:01:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24987 for ; Tue, 25 Nov 2003 02:01:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOXCo-0006i1-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 02:01:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOXCn-0006hy-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 02:01:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C573F6@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 2:01:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61878795 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 02:01:06 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 02:01:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOy+snn3AgC1TRvQYaJlT7h3D9ZeQAJnWOQ Approved-By: Tal Anker Message-ID: Date: Tue, 25 Nov 2003 09:01:17 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I have to say that I also have the security requirements at a very low = priority for forces... I also expect the CE-FE communication to be = deployed on _internal_ links, where security is not really an issue = (while preventing from external traffic from the open network from being = considered as CE-FE control traffic is quite easy to be done using other = mechanisms...). Since the security mechanisms can be later incorporated, should they be = considered as critical at these phase to prevent from having multicast = for the CE-FE communication? - Tal -----Original Message----- From: Steven Blake [mailto:slblake@torrentnet.com] Sent: Tuesday, November 25, 2003 4:20 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES transport requirements WAS (Re: Support for = multicast in the ForCES protocol On Mon, 2003-11-24 at 15:35, Khosravi, Hormuzd M wrote: > Hi Tal > > There is already a ForCES Requirements draft which has been approved = for > RFC. > Pls see... > = http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx > t > This has a section on protocol requirements. The problem with this draft (IMHO) is that it specifies a very broad range of requirements, and it is not clear that they can all be satisfied simultaneously using the same protocol techniques (which is not to say that they cannot be satisfied using the same protocol, it will however have to be very flexible). Another problem is that there is no prioritization applied to the requirements. Therefore, different individuals prioritize them independently based on their own priorities and product requirements. I personally prioritize scalability and timeliness, and really have no use for the security requirement, because I don't envision having to deploy CE-FE communications over an open network. Other opinions may differ. Regards, =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 Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 05:45:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11741 for ; Tue, 25 Nov 2003 05:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOahG-0001fo-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 05:45:30 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOahE-0001fl-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 05:45:29 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C5765F@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 5:45:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61885993 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 05:45:28 -0500 Received: from 195.212.29.139 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 05:45:27 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.uk.ibm.com (8.12.10/8.12.10) with ESMTP id hAPAgZAf059712 for ; Tue, 25 Nov 2003 10:42:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPAYpuK220282 for ; Tue, 25 Nov 2003 11:34:51 +0100 Received: from zurich.ibm.com (dhcp69-114.zurich.ibm.com [9.4.69.114]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA39948; Tue, 25 Nov 2003 11:34:51 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <3FC1C145.1030602@zurich.ibm.com> <3FC25914.E513A7CA@alcatel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020200090306010304030208" Approved-By: Patrick Droz Message-ID: <3FC33044.2080504@zurich.ibm.com> Date: Tue, 25 Nov 2003 11:34:44 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC25914.E513A7CA@alcatel.com> Precedence: list This is a cryptographically signed message in MIME format. --------------ms020200090306010304030208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [chair hat off] Alex Audu wrote: Hi Alex, see my comments inline. > Hello Patrick, > > Please my comments in-line.. > > Regards, > Alex. > > Patrick Droz wrote: > > >>[chair hat off] >> >>see comments inline >> >>Alex Audu wrote: >> >> >>>Hi All, >>> >>>All this talk about the need and benefits of multicast certainly makes ones >>>feel it is a cure all for what is being termed as the ailment in ForCEs' >>>requirements. >>> >>>Look, it has to be told that you can't do multicast on the cheap. And >>>you have >>>to answer some key questions if you really want to sell multicast in a >>>critical >>>environment,..viz: >>> >>>1) How would you guarrantee the relaible delivery of the messages being >>> blasted to all the targets? What if the messages don't arrive at all >>>their >>> intended targets? How do you recover from this? This suggests you need >>> a reliable multicast mechanism. I am not sure you can do this over UDP >>> as it is currently being done in NetLink2. That is only good for >>>un-reliable >>> multicast. I am not sure if you can trust critical configuration >>>messages >>> like routing table information or basic LFB service/tree structure >>>messages >>> over such an unreliable mechanism. >>> >>>2) How do you deal with the issue of security, given that we don't have >>>secure >>> multicast yet? I have seen some people call for broadcast >>>capability also. >>> One result of multicast/broadcast is you run the risk of a >>>potential attacker >>> listening in on say, the routing information being blasted to the >>>FEs. I don't >>> think multicasting over UDP has an answer to this. >>> >>> >>>There is also this myth that all the FEs will have the same routing >>>information >> >>could you please provide some evidence of this? Keep in mind we are >>moving from a centralized (single routing table) to a distributed >>router architecture. Why should it change that the routing table >>should be much different. Or do you want to go into the discussion >>of how you avoid routing loops? >> > > > One of the benefits of distributing the NE is the ability to handle many more > routes,..many more than the current core routers are capable of. Route > table sizes start becoming a problem at that scale. Storing partial routes > in a logically hierarchical distributed entities can help. Of course, you have > to assign the default routes appropriately to prevent routing loops. > can you proof this statement? For what reason do you need such big routing tables. I have not see much growth of routing table sizes. A distributed router has to provide forwarding an classification performance. I have a hard time that you have to distribute a router because of the forwarding table size. Overall you need exactly the same amount of memory. Why should a packet coming in on port A and heading for DA X being routed differently than a packet arriving on port B and also heading to DA X? Regards, Patrick > >>>always. I submit that this is not true. One of the problems ForCEs is >>>meant to >>>solve is scalability. This certainly relates to the abilty to manage the >>>rapid >>>growth of routing table sizes by distributing the routing information as >>>partial >>>routes into various FE groups. Granted there is still some scaling issues >>>here,..but is definitely not as bad as people have been making it to be. >>> >>> ..more comments in-line... >>> >>>Regards, >>>Alex. >> >>Regards, >>Patrick >> >> >>>In a message dated 11/22/2003 12:03:24 PM Central Standard Time, >>>hadi@znyx.com writes: >>> >>> >>> >>>>Continuation of the last thread with a change in topic - i think these >>>>are the real issues that need to be addressed instead of the distraction >>>>to "multicast is evil". >>>> >>>>Lets really list the requirements needed for a successful underlying >>>>transport protocol that will serve ForCES well. i may be >>>>missing some - but i hope to get challenged so i can add to them; >>>>I am thinking of turning this into a draft so people read it first and >>>>then post. >>>>My previous email has some more claims which i will assume here. >>>> >>>>I. ForCES mechanisms requiring reliability: >>>> >>>>a) time limit very sensitive (in other words obsolence period is >>>>faster): >>>>Example table updates; >>>>I have argued TCP doesnt qualify in my previous email. SCTP-PR may >>>>qualify. >>>>Something like what netlink2 over UDP qualifies because it gives control >>>>to netlink2 to make such decisions. >>> >>> >>> >>>How can you have reliable communcation over UDP? >>> >>> >>>>b) time limit best effort (obsolence takes longer) >>>>Sample apps: File transfers,etc. >>>>TCP qualifies but AFAIK, we dont have this need. >>>> >>>>II. mechanisms capable of tolerating unreliability: Example psamp. >>>>TCP doesnt qualify. >>>>something(like netlink2) over UDP or SCTP-PR. >>> >>> >>> >>>Why do you say TCP doesn't qualify here? Any application that can live >>>with un-reliable transport can sure do better with a relaible one. >>> >>> >>>>III. mechanisms that prefer timeliness over reliability: Ex heartbeats >>>>something (like netlink2) over UDP or SCTP-PR. >>>> >>>>Clearly in the bigger picture TCP is not the best protocol. >>>>UDP and SCTP-PR qualify partially merely because they dont hinder >>>>progress not because they have some magic. Another non-IETF protocol >>>>that would qualify is TIPC. I havent carefully studied DCCP but i >>>>believe it also has a fit. I will exclude it because its not there yet. >>>> >>>>So, to summarize: the transport protocol that meets all the requirements >>>>For Forces has not been born. >>>> >>>>Choosing TCP is choosing an answer and then trying to justify the >>>>questions that it brings. It does sound like peer pressure instead of >>>>looking at requirements and then deciding what you need to do. >>>>I think we recognized this in netlink2 and made it clear that the choice >>>>of underlying protocol chosen is up to the pre-association phase. >>>>We compensate for "missing features" depending on the transport choice >>>>(read the draft). >>>>It's very few lines of code to provide that luxury. So the cost is low. >>>> >>>>Now on the choice of netlink2 UDP vs SCTP-PR >>>> >>>>1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available >>>>Netlink2 can run over it. For now we choose to be standalone: We can run >>>>over IP, over UDP or over ethernet, you take your pick. >>> >>> >>> >>>I believe SCTP-PR is now in IESG queue. Even when it is available, you have >>>to run it in a reliable mode to guarantee that those critical configuration >>>messages get to their destination safely. And it still doesn't buy you >>>security. >>> >>> >>> >>>>2) UDP provides multicast (and broadcast). SCTP-PR does not. >>>>Since SCTP has turned to be a swiss knife (or maybe a multi faceted >>>>beast), i am sure it will soon as well support multicast;-> >>>> >>>>If multicast is there - we will use it. Sans that we will do something >>>>multicast like (Jon calls it unireplicate i think). >>>>All the three cauthors have had pleasant experiences using multicast for >>>>ForCES like. We think it is a good thing to have. But we will not >>>>torture you if you dont have multicast or broadcast ;-> >>>> >>>>Why Multicast is useful: >>>>-- >>>>I must apologize since i have to repeat this. >>>>In the simple case of a single multicast wire: each of the CEs or FEs >>>>opens a single multicast socket/channel. >>>> >>>>Why is this good: >>>> >>>>1) Bandwidth is less used >>>>a)because one or more CEs can send a single message to all FEs. >>>>I really dont want to be teaching people the hows but i will provide one >>>>example which David or maybe it was Joel didnt seem to make sense out of >>>>(but one that i have successfuly used)[1] >>>>b) you can reduce the number of packets further by limiting on >>>>ACKs (partial acks) >>>> >>>>2) RAM on the embedded CE or FE is used less. There are less sockets >>>>open and less messages being built >>>> >>>>3) CPU is preserved more. >>>>Since there are fewer messages to process and fewer (socket states) >>>>states to track. >>> >>> >>> >>>As far as I am concerned, the more critical resource CPU-wise is FE. The >>>mutlicast scheme Netlink2 proposes blasts all every packet to every FE. >>>Each FE has to do work to filter out which packet doesn't belong to it. >>>Thus, >>>the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles >>>that should be best used in forwarding packets. >>> >>> >>> >>>>4) The ability for all listeners on the wire to see message exchanges >>>>even when not directed at them provides a cheap way to synchronize. >>> >>> >>> >>>And of course, if this is a malicious node, it will gladly gleam as much >>>information >>>as is enough to mount an attack. This is why secure multicast is necessary. >>> >>> >>>>5) At a transport level, (not the forces transaction level), having >>>>access to multicast provides location transparency. >>>> >>>>6) A lot of switch fabrics (shared memory designs or otherwise) >>>>interconnecting FEs and CES have multicast capabilities; so it is good >>>>if we can take advantage of it where possible. >>>> >>>>The above is the simple case, by induction you could extend the >>>>reasoning to the case where you have X sockets. >>>> >>>>I dont want to preach multicast as panacea; we address some of the >>>>limitations in the draft; however, i want it to be available when i need >>>>it and not shoved down the toilet. >>>> >>>>So far apart from Joel (who implemented on ATM) on real boxes and Ram >>>>(who did something very specific that needs unicast) the rest of the >>>>arguements i have seen are from people who see the need for this >>>>feature. You can choose to ignore it - and you may be influenced by some >>>>implementation you are familiar with - thats your loss. I do think TCP >>>>is valid for some cases (low latency and congestion), but i wouldnt >>>>claim it to be the answer weve all been waiting for. >>>>Again let me reiterate that Netlink2 does not need to have multicast (it >>>>is a MAY) but would love to have it when it is available. We can run on >>>>your favorite protocol TCP ;-> >>>> >>>>cheers, >>>>jamal >>>> >>>>[1] I will give the example in another email - this one is already >>>>getting too long. >>> >>> >>> >>-- >> Dr. Patrick Droz | dro@zurich.ibm.com >> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro >> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 >> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms020200090306010304030208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjUx MDM0NDRaMCMGCSqGSIb3DQEJBDEWBBQnhvJdt0cOcbDTKZkr8MxB4r68/DBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgCr4J1jQDjATNbgXNuReA5EGdS/hE0fp4iXF ZlzMPXjYQVhtQ+jXByge6wrmru3VveqwwGKzfcIEzc9rw22emGP+mTEMg/jfiaBDTpt4u/gl 71YyA1IID4jV7tMQPB/KShKZu1daDUi6Obr9qijwAa1imRJUsTLTBvs7gr5788ybAAAAAAAA --------------ms020200090306010304030208-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 05:53:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12087 for ; Tue, 25 Nov 2003 05:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaom-0001qr-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 05:53:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOaol-0001qi-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 05:53:15 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C57636@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 5:53:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61886181 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 05:53:14 -0500 Received: from 195.212.29.156 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 05:53:13 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAPAr7wj064998 for ; Tue, 25 Nov 2003 10:53:10 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPAnBZF184638 for ; Tue, 25 Nov 2003 11:49:12 +0100 Received: from zurich.ibm.com (dhcp69-114.zurich.ibm.com [9.4.69.114]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA64348; Tue, 25 Nov 2003 11:49:11 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0F54AF0@orsmsx410.jf.intel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000504040305060504010208" Approved-By: Patrick Droz Message-ID: <3FC333A0.3090903@zurich.ibm.com> Date: Tue, 25 Nov 2003 11:49:04 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0F54AF0@orsmsx410.jf.intel.com> Precedence: list This is a cryptographically signed message in MIME format. --------------ms000504040305060504010208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [chair hat off] Hormuzd, I think you are still missing something. Khosravi, Hormuzd M wrote: > Patrick, > > Pls see my comments below... > > -----Original Message----- > > [chair hat off] > > Hormuzd, > > Khosravi, Hormuzd M wrote: > > >>I don't see why this has to be a religious debate. >>No body is saying "unicast is good, multicast is evil" >>This should not be the approach for making technical decisions. >>Unicast and multicast both have their merits and drawbacks >>and we have to select one that best meets our needs. > > > why you say one? why is it not both? > [HK] The reason to choose one is driven by simplicity and > interoperability. When you say choose both, you mean certain > control messages from CE-to-FE such as route updates use multicast > and the rest use unicast ? What does this mean in terms of > Interoperable solutions ? What does this complexity buy you ? > It would be better to say either use Unicast or use Multicast > for all control messages. However, from the discussion so far > doesn't seem like multicast can be used efficiently or in all > cases, without using unicast as well. > this statement is con correct to my mind. There are certain things like route updates that go to all the ports. So in this case you would use multicast. For firewalling rules which in many case go only to one port you would use multicast. The combination of both makes the protocol scalable and future proof. The point about interpretability I don't get. Simplicity is a good objective but not if it goes with the price of less flexibility and scalability. > >>Unicast has been working well for a long time in client/server, >>Master/slave type of environment. Multicast fits well for >>Peer-to-peer environment. ForCES is clearly a master/slave > > > why is it not a master and many slaves? > [HK] Sure, that's a given. Any client-server architecture has > One server and many clients or one master and many slaves. > Does that automatically mean using multicast ? If this was > the case then all client-server architectures would be using > Multicast to improve performance. The claims being made regarding > scalability are analogous to saying that a web-server cannot > handle hundreds of clients and will need multicast to scale. what a strange example. Does a Web server send exactly the same stuff to all its clients. I already stressed in several mails that ForCES will in many cases run box internal maybe over Switch or a PCI bus. Most switches I have seen have unicast and multicast capabilities included so why do you want to prevent people from making use of this functionality? > Even a Linux box with a single P3 processor can easily scale to > Hundreds of web clients. I need not mention some of the high > end servers using multiple processors which can easily handle > Hundreds of thousands or even millions of clients. > Do you agree ? > as I said above you are comparing oranges and apples. > >>environment, where the CE is the master or controller and >>the FE is the slave or the element being controlled. Hopefully, >>there should be no disagreement on this basic idea. In addition, >>we have certain reliability and security requirements that need >>to be fulfilled. > > > I agree on this as long as you also mention that we usually will > have a small number of masters but maybe a very large number of > slaves. > [HK] Sure, I agree. Same as above. > > >>On the issue of scalability let me try to give an example which >>will bring to light the importance of congestion control. OSPF has >>been stated as one of the main examples of a protocol which uses >>multicast as one of its transports in multicast enabled networks. >>One of the current OSPF WG drafts... >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt >>Talks about recommendations for improving OSPF scalability in large >>networks. It specifically recommends prioritization and congestion >>avoidance procedures to help improve the scalability. This draft is >>not just based on implementation, but also deployment experience by a >>large operator (AT&T). >> > > > how can you compare OSPF with ForCES? OSPF is a protocol that is > deployed over many nodes in general. ForCES will be in many cases > just used inside a single box. Could you please elaborate and tell > us what is the relationship between ForCES and OSPF. > > [HK] I completely agree, OSPF is very different and is used for > exchanging information between routing peers. I have seen OSPF > being used as a primary example of a protocol which uses multicast, > and motivating the use of multicast in ForCES based on it. > As you said OSPF is very different and is probably not a good analogy. > in the ForCES context OSPF is completely irrelevant and I have a hard tim why you even mention it here. > However, even if you take OSPF as an example for motivating ForCES, > there are issues with OSPF such as Congestion Control which were > not considered in its initial design but are being discovered after > years of deployment experience. If anything, we can learn from > the experience and wisdom out there and avoid making similar mistakes > in our protocol design. > I think OSPF has nothing at all to do with ForCES. It is used completely differently in a different environment. Regards, Patrick > > > Regards, > Hormuzd > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms000504040305060504010208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjUx MDQ5MDRaMCMGCSqGSIb3DQEJBDEWBBQDl06AzTZjUt9DARR/4K5VBhbfwDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgEPoJzpOC4jAWoyGxiDs7RglviCY9Kiv+d0u YIH7QQniV0b95lcWpeVFT916NFxeCb3G1/EyJweR2ueNVvfMxatkkTrvHce88MtFAy6PrMNJ kjzt1sAMDg1QcdU8SxPu3KocFWvP+L4M1bhS+8cBcFb7FmtS2JBUTrXQ8rZKCc0BAAAAAAAA --------------ms000504040305060504010208-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 09:52:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19733 for ; Tue, 25 Nov 2003 09:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeYx-0006AT-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 09:53:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOeYw-0006AQ-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 09:53:10 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C57BEC@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 9:53:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61932390 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 09:53:08 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 09:53:07 -0500 Received: from wwm1([218.108.154.87]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm153fc38b61; Tue, 25 Nov 2003 22:51:33 +0800 References: <5.1.0.14.0.20031119232704.018bfeb0@localhost> <3FBC9FF7.4080608@zurich.ibm.com> <008801c3b0b2$a8a50480$7b19fea9@wwm1> <3FC22900.3040905@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <009e01c3b363$9e8f6e00$010aa8c0@wwm1> Date: Tue, 25 Nov 2003 22:51:32 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpQbHMgc2VlIGlubGluZSByZXBseS4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206ICJSb2JlcnQgSGFhcyIgPHJoYUB6dXJpY2guaWJtLmNvbT4NClRvOiA8 Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyNCwg MjAwMyAxMTo1MSBQTQ0KU3ViamVjdDogUmU6IFN1cHBvcnQgZm9yIG11bHRpY2FzdCBpbiB0aGUg Rm9yQ0VTIHByb3RvY29sDQoNCg0KSGkgV2VpbWluZywNCg0KV2VpbWluZyBXYW5nIHdyb3RlOg0K DQo+SGkgUm9iLA0KPg0KPkkgcmVtZW1iZXIgd2UndiAgaGFkIGEgc2hvcnQgZGlzY3Vzc2lvbiBv biB0aGUgYnJvYWRjYXN0L211bHRpY2FzdCBpc3N1ZSBpbiBNaW5uLg0KPkkgYWdyZWUgdGhhdCBp dCdzIG5vdCBqdXN0IGFzIHNpbXBsZSBhcyB0byBhcnJhbmdlIEZFIElEcywgYnV0IEkgc3RpbGwg dGhpbmsgdGhhdCB0aGUgbGVmdA0KPmlzIGluIHRoZSBlbmNhcHN1bGF0aW9uIHNjb3BlLiAgTWF5 YmUgd2UgbmVlZCBhIHNwZWNpZmljIGRlZmluaXRpb24gZG9jdW1lbnQgZm9yIHRoaXMNCj4gc2Nv cGUuIA0KPiAgDQo+DQpDb3VsZCB5b3UgZWxhYm9yYXRlIHdoYXQgZW5jYXBzdWxhdGlvbiBzY29w ZSBtZWFucyA/DQoNCltSRV0gSSd2IGp1c3QgcG9zdGVkIGEgbWFpbCBvbiB0aGlzLiBQbHMgcmVm ZXIgdGhlcmUuDQoNCj4gSSBhbHNvIGFyZ3VlIHRoYXQgdGhlIGhvb2tzIGluIEZvckNFUyBwcm90 b2NvbCBmb3IgdGhlIG11bHRpY2FzdCBlbmNhcHN1bGF0aW9uDQo+c2hvdWxkIGJlIGxpbWl0ZWQg dG8gRkUgSURzIGluc3RlYWQgb2YgTEZCIHR5cGVzLCBsZWF2aW5nIGxhdGVyIGFzIGhvb2tzIG9u bHkgaW5zaWRlIG9uZSBGRS4gDQo+Rm9yIEknbSBzdGlsbCBub3Qgc3VyZSBob3cgYW4gTEZCIHR5 cGUgY2FuIGJlIHVzZWQgZGlyZWN0bHkgYXMgaG9va3MgZm9yIHRoZSBtdWx0aWNhc3QsIGl0IHNl ZW1zDQo+YSBsaXR0bGUgY2FzZSBzcGVjaWZpYy4gTWF5YmUgSSBtaXNzIHNvbWV0aGluZy4gDQo+ VGhhbmsgeW91Lg0KPiAgDQo+DQpJIHdhcyBjb25zaWRlcmluZyB0aGUgYmFzaWMgc2NlbmFyaW8g b2YgYSBkaXN0cmlidXRlZCByb3V0ZXIgZm9yIHdoaWNoIGEgDQpmb3J3YXJkaW5nIHRhYmxlIG11 c3QgYmUgcmVwbGljYXRlZCBhbmQgbWFpbnRhaW5lZCBvdmVyIG1hbnkgRkVzLiANCkltYWdpbmUg YSBDRSBjYW4gcHJvZHVjZSBhIG1lc3NhZ2Ugc3VjaCBhcyAic2VuZCB0aGlzIGZvcndhcmRpbmcg DQp0YWJsZS91cGRhdGVzIHRvIGFsbCBMRkJzIHRoYXQgcGVmb3JtIElQdjQgZm9yd2FyZGluZyAo b3B0aW9uYWw6IGluIGEgDQpwYXJ0aWN1bGFyIHZpcnR1YWwgbmV0d29yaykiLiAgVGhpcyBpcyB3 aHkgSSBjb25zaWRlciB0aGlzICJhZGRyZXNzaW5nIA0KYnkgdHlwZSIgYSBiYXNpYyBmdW5jdGlv bmFsaXR5IHRoYXQgdGhlIEZvckNFUyBwcm90b2NvbCBzaG91bGQgc3VwcHBvcnQsIA0KYXMgaXQg Z3JlYXRseSBzaW1wbGlmaWVzIGhvdyB0byB1c2UgdGhlIHByb3RvY29sLiBJbmRlZWQsIHRoZXJl IGlzIG5vIA0KbmVlZCBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIGZpcnN0IGZpZ3VyZSBvdXQgdGhl IHNwZWNpZmljIExGQiBJRHMgdGhhdCANCmhhdmUgYmVlbiBhc3NpZ25lZCB0byB0aGUgSVB2NCBM RkIsIG5vciB0aGUgcGFydGljdWxhciBGRSBJRHMuDQoNCltSRV1JIHRoaW5rIHdlJ3YgY29tZSB0 byB0aGUgc2FtZSBxdWVzdGlvbiBhcyBKYW1hbCBhbmQgRGF2aWQgYXJlIGRpc2N1c3NpbmcuIEkn bCByZWFkIHlvdXIgZG9jdW1lbnQgbW9yZQ0KdG8gdW5kZXJzdGFuZCBpdC4gIA0KDQpSZWdhcmRz LA0KLVJvYmVydA0KDQoNCg0KPldlaW1pbmcNCj4NCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KPkZyb206ICJSb2JlcnQgSGFhcyIgPHJoYUB6dXJpY2guaWJtLmNvbT4NCj5UbzogPEZP UkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NCj5TZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjAs IDIwMDMgNzowNSBQTQ0KPlN1YmplY3Q6IFJlOiBTdXBwb3J0IGZvciBtdWx0aWNhc3QgaW4gdGhl IEZvckNFUyBwcm90b2NvbA0KPg0KPg0KPkpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4NCj4gIA0K Pg0KPj5UaGlzIGlzIG9uZSBvZiB0aGUgY29tcGxleGl0aWVzLiAgV2hpbGUgdGhlcmUgaXMgYSBs b3Qgb2YgdXNlZnVsDQo+PmV4cGVyaW1lbnRhbCB3b3JrIG9uIHJlbGlhYmxlIGFuZCBzZWN1cmVk IG11bHRpY2FzdCB0cmFuc3BvcnQsIEkgZG8gbm90DQo+PmJlbGlldmUgdGhhdCB0aGVyZSBpcyBh bnkgZW5naW5lZXJpbmcgZ3JhZGUgd29yayB0aGF0IGFkZHJlc3MgYm90aCB0aG9zZQ0KPj5yZXF1 aXJlbWVudHMuICBBbmQgd2UgYXJlIG9ibGlnZWQgdG8gbWVldCBib3RoIG9mIHRob3NlIG5lZWRz Lg0KPj5BbmQgY29tcGFyZWQgd2l0aCBUQ1AgLyBTQ1RQLCB0aGVyZSBhcmUgbm90IHdpZGUgc3By ZWFkLCBlYXNpbHkgDQo+PmF2YWlsYWJsZSwNCj4+d2VsbCB3cnVuZyBvdXQgaW1wbGVtZW50YXRp b25zIG9mIHRob3NlIHByb3RvY29scy4NCj4+SGVuY2UsIHB1dHRpbmcgYSBkZXBlbmRlbmN5IG9u IHN1Y2ggd29yayBpbnRvIEZvckNFUyBpbnRyb2R1Y2VzIA0KPj5zaWduaWZpY2FudA0KPj5yaXNr IGFuZCBjb21wbGV4aXR5LiANCj4+ICAgIA0KPj4NCj4NCj5JIGRvbid0IHRoaW5rIHdlIGFyZSB0 YWxraW5nIGFib3V0IHB1dHRpbmcgYSBkZXBlbmRlbmN5IG9uIFJNVCBoZXJlLiANCj5SYXRoZXIg d2UgYXJlIGVuc3VyaW5nIHRoYXQgdGhlIG5lY2Vzc2FyeSBob29rcyBhcmUgaW4gdGhlIEZvckNF UyANCj5wcm90b2NvbCBzbyBpdCBjYW4gbWFrZSB1c2Ugb2Ygc29tZSBmb3JtIG9mIG11bHRpY2Fz dCB0cmFuc3BvcnQuDQo+DQo+QW5kIHRvIGRvIHRoaXMsIHdlIG5lZWQgdG8gaGF2ZSBzb21lIGZv cm0gb2YgZ3JvdXAgYWRkcmVzc2luZyBhdCB0aGUgDQo+Rm9yQ0VTIHByb3RvY29sIGxldmVsLiBI YXZpbmcgc3BlbnQgc29tZSBjeWNsZXMgb24gdGhpcywgSSBjYW4gc2F5IGl0IA0KPnJlcXVpcmVz IGEgYml0IG1vcmUgdGhhbiAicmVhcnJhbmdpbmcgdGhlIEZFIElEIGJpdHMgdG8gaGF2ZSBzb21l IA0KPmdyb3VwLWxpa2UgbWVhbmluZyBhZnRlciB0aGUgRm9yQ0VTIHByb3RvY29sIGhhcyBhbHJl YWR5IGJlZW4gZGVzaWduZWQiIA0KPihJIHRoaW5rIEkgaGVhcmQgc3RoIGFsb25nIHRoZXNlIGxp bmVzIG9uIHRoZSBsaXN0KS4NCj4NCj5DaGVlcnMsDQo+LVJvYmVydA0KPg0KPiAgDQo+DQo+Pllv dXJzLA0KPj5Kb2VsIE0uIEhhbHBlcm4NCj4+DQo+PkF0IDAxOjUyIEFNIDExLzIwLzIwMDMgKzAy MDAsIHlvdSB3cm90ZToNCj4+DQo+PiAgICANCj4+DQo+Pj5PbmUgbGFzdCBpc3N1ZS4uLiB0aGUg c2VtYW50aWNzIG5lZWRlZCBmcm9tIHRoZSB0cmFuc3BvcnQgbGF5ZXIgDQo+Pj5zaG91bGQgYmUN Cj4+PmNhcmVmdWxseSBkZWZpbmVkLCBhcyByZWd1bGFyIG11bHRpY2FzdCBpcyBub3QgcmVsaWFi bGUsIGFuZCBJIGV4cGVjdCANCj4+PnRoZQ0KPj4+cHJvdG9jb2wgdG8gcmVseSBvbiBzb21lIHJl bGlhYmxlIHRyYW5zcG9ydCBpbiBvcmRlciB0byBrbm93IHRoZSBDRS1GRQ0KPj4+dHJhbnNhY3Rp b24gaXMgY29tbWl0ZWQuLi4gdGhlIFJNVCBXRyBoYWQgZGVmaW5lZCB0b29scyBmb3IgcmVsaWFi bGUNCj4+Pm11bHRpY2FzdCB0aGF0IGNhbiBiZSBkZXBsb3llZCBoZXJlLi4uDQo+Pj4NCj4+Pi0g VGFsDQo+Pj4gICAgICANCj4+Pg0KPj4NCj4+ICAgIA0KPj4NCj4NCj4gIA0KPg0KDQotLSANClJv YmVydCBIYWFzDQpJQk0gWnVyaWNoIFJlc2VhcmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2Ug NA0KQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAg ZmF4ICs0MS0xLTcyNC04NTc4ICBodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGENCg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 10:13:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21508 for ; Tue, 25 Nov 2003 10:13:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOesW-0006T3-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 10:13:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOesW-0006T0-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 10:13:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00C57D31@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 10:13:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61933171 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 10:13:22 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 10:13:17 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5890615 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 10:13:16 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031125100426.01952720@localhost> Date: Tue, 25 Nov 2003 10:13:12 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Transport assumptions and "hooks?" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list In reading (and probably accidentally inflaming) the discussion of multicast support, I realized I was making assumptions about the requirements. Reading the requirements draft, it is not explicit about certain things. A lot of my concerns about multicast are driven by my believe that any transport we specify must support 1) reliability (specified explicitly in the requirements draft, and provided by all proposals one way or another) 2) congestion control (explicitly required when there is more than one "hop") 3) flow control (I have been severely burned by assuming I did not need flow control in my control protocols. You can get amazing messes if the CE can overrun the FE, or the reverse.) 4) security (required, with an out for "in-box") Note that I have found that flow control needs to be thought about even for in-box solutions. Some folks have asked that we allow multicast over UDP, with app level retransmission. Without addressing the other elements of the list, I do nto believe that this is a sensible solution for us to allow. And allowing those other elements adds a great deal of complexity. There are some cases where multicast would be nice to have. Hooks which do not compromise the soundness of the protocol, and which allow for multicast to be added easily later make sense. So we probably should allow for multiple simultaneous transports. We probably should make sure messages include sending and receiving entity identification. We probably want to make the identifier space big / structured enough taht we can add various kinds of logical / multi-entity identifiers in the future. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 11:10:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24928 for ; Tue, 25 Nov 2003 11:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfmE-00007N-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:10:58 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOfmD-00007K-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:10:58 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C57F3B@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 11:10:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61942007 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 11:10:54 -0500 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 11:10:54 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAPGAkIi032404 for ; Tue, 25 Nov 2003 16:10:46 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPGAiZF142306 for ; Tue, 25 Nov 2003 17:10:46 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA52254 for ; Tue, 25 Nov 2003 17:10:44 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id hAPGAkIi032404 Approved-By: Robert Haas Message-ID: <3FC37F04.605@zurich.ibm.com> Date: Tue, 25 Nov 2003 17:10:44 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable In order to reach a consensus before we are exhausted posting on the=20 list, let me cristallize what could help unlock the situation. I presume we should be able to reach consensus on sth like (remains to=20 be defined in more detail): ForCES transport --------------------- a) An FE MUST support UDP (or raw media encapsulation) as ForCES=20 transport if the FE is targeted at the local scope env. b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 targeted at the global scope environment. c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 ForCES transport if the FE is targeted at both local and global scopes. (the same applies for the CE) FEs/CEs that support TCP will support UDP as well (I have never seen an=20 IP stack that offers TCP without UDP). Note that this does not prevent=20 from using TCP in the local scope if the FEs and CEs support it. Thus=20 TCP-proponents should be satisfied. In addition, could we reach consensus on sth like: ForCES group addressing ------------------------------ d) FEs and CEs MUST support group addressing in the ForCES protocol. Nobody is forced to USE such a group addressing (one can stick to=20 unicast ForCES-addressing and TCP transport in all cases). But if one=20 sees that group addressing fits ones needs (and many have voiced it on=20 the list), then one should be able to use it. Ultimately (and this is=20 probably best so), it's the user writing software in the CE who decides=20 what she/he wants to use. Note that the phrasing in a), b), c), and d) is meant to satisfy=20 interoperability. Not my ego. I have the impression that a number of participants in this WG,=20 including other protocol draft authors, tend to agree on these items.=20 Who would not agree (and on what) ? --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 11:34:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25698 for ; Tue, 25 Nov 2003 11:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOg98-0000Vv-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:34:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOg97-0000Vs-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:34:37 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C57FB4@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 11:34:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61944565 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 11:34:35 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 11:34:35 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPGYYOf007153 for ; Tue, 25 Nov 2003 10:34:34 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <1069728593.30919.38.camel@newcastle.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC38498.D682113C@alcatel.com> Date: Tue, 25 Nov 2003 10:34:32 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast intheForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Multicasting certainly helps. In the ForCEs environment, it has to be secure and reliable to be really useful. You have to expect packet loss/damage due to collision if you are multicasting over UDP. And If you have to re-transmit even one packet, that really knocks a hole into your overall time gain. This will always be an issue untill the a solution for relaible secure multicast is found. Meanwhile, you could do multicasting at ForCES protocol level (by doing multi-unicasts). This is not a bad solution. All your unicasts are protected by the underlining reliability and security mechanisms. And it will be much faster than than trying to send all the messages to the targets from the application layer. Some have suggested that a typical deployement environment for ForCES will be one of zero hop. Certainly, if you are doing zero hop NE, you can worry less about security issues. But you still have to worry about reliability and in-order delivery of messages, especially if the LFBs you are configuring are stateful. But of course, any solution we come up with must be applicable to one/two-hop scenarios also. That is a ForCES requirement. Regards, Alex. Steven Blake wrote: > Here is a contrived, but representative example of the type of problem I > think that ForCES needs to be able to solve to make it more useful for > me than a home-grown solution. > > Imagine a NE with one (active) CE and 64 FEs, each forwarding global > routes. 64K external prefixes are currently reachable via peer A. > Suddenly the peering to A fails, and now half the prefixes are reachable > via peer B and the other half via peer C. No matter how cleverly you > have designed your datastructures, in the general case you are going to > have to update at least 32K table entries. > > Suppose you can pack 64 table updates/ForCES packet (~1500 byte packet > with ~24 byte entries). Then the CE will have to send 500 packets/FE * > 64 FEs = 32K packets if ForCES is restricted to unicast transport. That > works out to about 400 Mbits, which will take 400 msec to transmit at > full blast assuming the CE is attached via gigabit Ethernet. Meanwhile > the NE might be forwarding several gigabits worth of traffic into a > black hole. > > This solution simply doesn't meet my timeliness requirements. So I can > choose to hope that the number of FEs in my NE increases slower than > Moore's Law, I can choose to try and come up with a proprietary > mechanism for splitting this update load across several CEs, or I can > choose to explore whether multicast can be utilized to minimize the > update latency. > > For the moment I have chosen the latter, but I am willing to listen to > arguments as to why that is the wrong choice. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 11:42:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26169 for ; Tue, 25 Nov 2003 11:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGa-0000hY-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:42:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOgGa-0000hU-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 11:42:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C57F60@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 11:42:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61945068 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 11:42:16 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 11:42:16 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPGgEOf008777 for ; Tue, 25 Nov 2003 10:42:15 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC38665.C9C26C63@alcatel.com> Date: Tue, 25 Nov 2003 10:42:13 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast inthe ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Once you distribute CEs and FEs such that they are no longer co-located, you have to worry about security. The RPSEC group is currently specifying the requirements for secure routing protocols. If you expose the interconnect between CEs and FEs as ForCES does, then you have to address how your ForCES protocol solution is not going to make the routing protocol security worse. Else, such a solution won't fly in IETF. Regards, Alex. Tal Anker wrote: > I have to say that I also have the security requirements at a very low priority for forces... I also expect the CE-FE communication to be deployed on _internal_ links, where security is not really an issue (while preventing from external traffic from the open network from being considered as CE-FE control traffic is quite easy to be done using other mechanisms...). > Since the security mechanisms can be later incorporated, should they be considered as critical at these phase to prevent from having multicast for the CE-FE communication? > > - Tal > > -----Original Message----- > From: Steven Blake [mailto:slblake@torrentnet.com] > Sent: Tuesday, November 25, 2003 4:20 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol > > On Mon, 2003-11-24 at 15:35, Khosravi, Hormuzd M wrote: > > > Hi Tal > > > > There is already a ForCES Requirements draft which has been approved for > > RFC. > > Pls see... > > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx > > t > > This has a section on protocol requirements. > > The problem with this draft (IMHO) is that it specifies a very broad > range of requirements, and it is not clear that they can all be > satisfied simultaneously using the same protocol techniques (which is > not to say that they cannot be satisfied using the same protocol, it > will however have to be very flexible). > > Another problem is that there is no prioritization applied to the > requirements. Therefore, different individuals prioritize them > independently based on their own priorities and product requirements. > > I personally prioritize scalability and timeliness, and really have no > use for the security requirement, because I don't envision having to > deploy CE-FE communications over an open network. Other opinions may > differ. > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 12:59:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29657 for ; Tue, 25 Nov 2003 12:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhTB-00025i-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 12:59:25 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOhTA-00025f-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 12:59:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C57F9A@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 12:59:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61952892 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 12:59:22 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 12:59:18 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPHxGOf026129 for ; Tue, 25 Nov 2003 11:59:17 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <3FC1C145.1030602@zurich.ibm.com> <3FC25914.E513A7CA@alcatel.com> <3FC33044.2080504@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC39874.4C89599@alcatel.com> Date: Tue, 25 Nov 2003 11:59:16 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicast intheForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Patrick, The growth rate of routing table size has been of interest in the research community and industry for some time. And research is activly on-going at finding ways to contain that growth. See for example: http://www.antc.uoregon.edu/route-views/dynamics/ Certainly the routing table gorws as the number of route peers increases. This particularly the case with table-driven IP routing where each machine employes an IP Routing table that sotre information about possible destinations and how to reach them. Using the network portion of a destination address instead of the complete host address makes routing efficient and keeps routing tables small. This is the essence of Next-Hop Routing where a routing table table contains (N,R) (where N is the Ip address of the destination network and R is the IP address of the next router along the path to N. Router R is called the next hop. There are various other methods including partitioning the CORE into partial cores that reside in separate sites and using default routes to point to the peer site. Of course, this results into a routing loops,..and that is not what we are talking about here. I would rather not say anymore about this, but you can certainly partition the routing table in an NE into a tree with the root residing in the CE. This is a form of hierarchical routing. Sure, it may take longer to resolve certain routes. See also http://www-rp.lip6.fr/~ridoux/Manuel-NS2/node319.html http://www.research.att.com/~jrex/papers/filter.pdf Regards, Alex. Patrick Droz wrote: > [chair hat off] > > Alex Audu wrote: > > Hi Alex, > > see my comments inline. > > > Hello Patrick, > > > > Please my comments in-line.. > > > > Regards, > > Alex. > > > > Patrick Droz wrote: > > > > > >>[chair hat off] > >> > >>see comments inline > >> > >>Alex Audu wrote: > >> > >> > >>>Hi All, > >>> > >>>All this talk about the need and benefits of multicast certainly makes ones > >>>feel it is a cure all for what is being termed as the ailment in ForCEs' > >>>requirements. > >>> > >>>Look, it has to be told that you can't do multicast on the cheap. And > >>>you have > >>>to answer some key questions if you really want to sell multicast in a > >>>critical > >>>environment,..viz: > >>> > >>>1) How would you guarrantee the relaible delivery of the messages being > >>> blasted to all the targets? What if the messages don't arrive at all > >>>their > >>> intended targets? How do you recover from this? This suggests you need > >>> a reliable multicast mechanism. I am not sure you can do this over UDP > >>> as it is currently being done in NetLink2. That is only good for > >>>un-reliable > >>> multicast. I am not sure if you can trust critical configuration > >>>messages > >>> like routing table information or basic LFB service/tree structure > >>>messages > >>> over such an unreliable mechanism. > >>> > >>>2) How do you deal with the issue of security, given that we don't have > >>>secure > >>> multicast yet? I have seen some people call for broadcast > >>>capability also. > >>> One result of multicast/broadcast is you run the risk of a > >>>potential attacker > >>> listening in on say, the routing information being blasted to the > >>>FEs. I don't > >>> think multicasting over UDP has an answer to this. > >>> > >>> > >>>There is also this myth that all the FEs will have the same routing > >>>information > >> > >>could you please provide some evidence of this? Keep in mind we are > >>moving from a centralized (single routing table) to a distributed > >>router architecture. Why should it change that the routing table > >>should be much different. Or do you want to go into the discussion > >>of how you avoid routing loops? > >> > > > > > > One of the benefits of distributing the NE is the ability to handle many more > > routes,..many more than the current core routers are capable of. Route > > table sizes start becoming a problem at that scale. Storing partial routes > > in a logically hierarchical distributed entities can help. Of course, you have > > to assign the default routes appropriately to prevent routing loops. > > > > can you proof this statement? For what reason do you need such big > routing tables. I have not see much growth of routing table sizes. > A distributed router has to provide forwarding an classification > performance. I have a hard time that you have to distribute a router > because of the forwarding table size. Overall you need exactly the > same amount of memory. Why should a packet coming in on port A and > heading for DA X being routed differently than a packet arriving on > port B and also heading to DA X? > > Regards, > Patrick > > > > >>>always. I submit that this is not true. One of the problems ForCEs is > >>>meant to > >>>solve is scalability. This certainly relates to the abilty to manage the > >>>rapid > >>>growth of routing table sizes by distributing the routing information as > >>>partial > >>>routes into various FE groups. Granted there is still some scaling issues > >>>here,..but is definitely not as bad as people have been making it to be. > >>> > >>> ..more comments in-line... > >>> > >>>Regards, > >>>Alex. > >> > >>Regards, > >>Patrick > >> > >> > >>>In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > >>>hadi@znyx.com writes: > >>> > >>> > >>> > >>>>Continuation of the last thread with a change in topic - i think these > >>>>are the real issues that need to be addressed instead of the distraction > >>>>to "multicast is evil". > >>>> > >>>>Lets really list the requirements needed for a successful underlying > >>>>transport protocol that will serve ForCES well. i may be > >>>>missing some - but i hope to get challenged so i can add to them; > >>>>I am thinking of turning this into a draft so people read it first and > >>>>then post. > >>>>My previous email has some more claims which i will assume here. > >>>> > >>>>I. ForCES mechanisms requiring reliability: > >>>> > >>>>a) time limit very sensitive (in other words obsolence period is > >>>>faster): > >>>>Example table updates; > >>>>I have argued TCP doesnt qualify in my previous email. SCTP-PR may > >>>>qualify. > >>>>Something like what netlink2 over UDP qualifies because it gives control > >>>>to netlink2 to make such decisions. > >>> > >>> > >>> > >>>How can you have reliable communcation over UDP? > >>> > >>> > >>>>b) time limit best effort (obsolence takes longer) > >>>>Sample apps: File transfers,etc. > >>>>TCP qualifies but AFAIK, we dont have this need. > >>>> > >>>>II. mechanisms capable of tolerating unreliability: Example psamp. > >>>>TCP doesnt qualify. > >>>>something(like netlink2) over UDP or SCTP-PR. > >>> > >>> > >>> > >>>Why do you say TCP doesn't qualify here? Any application that can live > >>>with un-reliable transport can sure do better with a relaible one. > >>> > >>> > >>>>III. mechanisms that prefer timeliness over reliability: Ex heartbeats > >>>>something (like netlink2) over UDP or SCTP-PR. > >>>> > >>>>Clearly in the bigger picture TCP is not the best protocol. > >>>>UDP and SCTP-PR qualify partially merely because they dont hinder > >>>>progress not because they have some magic. Another non-IETF protocol > >>>>that would qualify is TIPC. I havent carefully studied DCCP but i > >>>>believe it also has a fit. I will exclude it because its not there yet. > >>>> > >>>>So, to summarize: the transport protocol that meets all the requirements > >>>>For Forces has not been born. > >>>> > >>>>Choosing TCP is choosing an answer and then trying to justify the > >>>>questions that it brings. It does sound like peer pressure instead of > >>>>looking at requirements and then deciding what you need to do. > >>>>I think we recognized this in netlink2 and made it clear that the choice > >>>>of underlying protocol chosen is up to the pre-association phase. > >>>>We compensate for "missing features" depending on the transport choice > >>>>(read the draft). > >>>>It's very few lines of code to provide that luxury. So the cost is low. > >>>> > >>>>Now on the choice of netlink2 UDP vs SCTP-PR > >>>> > >>>>1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > >>>>Netlink2 can run over it. For now we choose to be standalone: We can run > >>>>over IP, over UDP or over ethernet, you take your pick. > >>> > >>> > >>> > >>>I believe SCTP-PR is now in IESG queue. Even when it is available, you have > >>>to run it in a reliable mode to guarantee that those critical configuration > >>>messages get to their destination safely. And it still doesn't buy you > >>>security. > >>> > >>> > >>> > >>>>2) UDP provides multicast (and broadcast). SCTP-PR does not. > >>>>Since SCTP has turned to be a swiss knife (or maybe a multi faceted > >>>>beast), i am sure it will soon as well support multicast;-> > >>>> > >>>>If multicast is there - we will use it. Sans that we will do something > >>>>multicast like (Jon calls it unireplicate i think). > >>>>All the three cauthors have had pleasant experiences using multicast for > >>>>ForCES like. We think it is a good thing to have. But we will not > >>>>torture you if you dont have multicast or broadcast ;-> > >>>> > >>>>Why Multicast is useful: > >>>>-- > >>>>I must apologize since i have to repeat this. > >>>>In the simple case of a single multicast wire: each of the CEs or FEs > >>>>opens a single multicast socket/channel. > >>>> > >>>>Why is this good: > >>>> > >>>>1) Bandwidth is less used > >>>>a)because one or more CEs can send a single message to all FEs. > >>>>I really dont want to be teaching people the hows but i will provide one > >>>>example which David or maybe it was Joel didnt seem to make sense out of > >>>>(but one that i have successfuly used)[1] > >>>>b) you can reduce the number of packets further by limiting on > >>>>ACKs (partial acks) > >>>> > >>>>2) RAM on the embedded CE or FE is used less. There are less sockets > >>>>open and less messages being built > >>>> > >>>>3) CPU is preserved more. > >>>>Since there are fewer messages to process and fewer (socket states) > >>>>states to track. > >>> > >>> > >>> > >>>As far as I am concerned, the more critical resource CPU-wise is FE. The > >>>mutlicast scheme Netlink2 proposes blasts all every packet to every FE. > >>>Each FE has to do work to filter out which packet doesn't belong to it. > >>>Thus, > >>>the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles > >>>that should be best used in forwarding packets. > >>> > >>> > >>> > >>>>4) The ability for all listeners on the wire to see message exchanges > >>>>even when not directed at them provides a cheap way to synchronize. > >>> > >>> > >>> > >>>And of course, if this is a malicious node, it will gladly gleam as much > >>>information > >>>as is enough to mount an attack. This is why secure multicast is necessary. > >>> > >>> > >>>>5) At a transport level, (not the forces transaction level), having > >>>>access to multicast provides location transparency. > >>>> > >>>>6) A lot of switch fabrics (shared memory designs or otherwise) > >>>>interconnecting FEs and CES have multicast capabilities; so it is good > >>>>if we can take advantage of it where possible. > >>>> > >>>>The above is the simple case, by induction you could extend the > >>>>reasoning to the case where you have X sockets. > >>>> > >>>>I dont want to preach multicast as panacea; we address some of the > >>>>limitations in the draft; however, i want it to be available when i need > >>>>it and not shoved down the toilet. > >>>> > >>>>So far apart from Joel (who implemented on ATM) on real boxes and Ram > >>>>(who did something very specific that needs unicast) the rest of the > >>>>arguements i have seen are from people who see the need for this > >>>>feature. You can choose to ignore it - and you may be influenced by some > >>>>implementation you are familiar with - thats your loss. I do think TCP > >>>>is valid for some cases (low latency and congestion), but i wouldnt > >>>>claim it to be the answer weve all been waiting for. > >>>>Again let me reiterate that Netlink2 does not need to have multicast (it > >>>>is a MAY) but would love to have it when it is available. We can run on > >>>>your favorite protocol TCP ;-> > >>>> > >>>>cheers, > >>>>jamal > >>>> > >>>>[1] I will give the example in another email - this one is already > >>>>getting too long. > >>> > >>> > >>> > >>-- > >> Dr. Patrick Droz | dro@zurich.ibm.com > >> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > >> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > >> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 13:09:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00037 for ; Tue, 25 Nov 2003 13:09:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhdY-0002Eb-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:10:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOhdU-0002ET-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:10:04 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C581AA@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 13:10:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61954031 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 13:09:59 -0500 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 13:09:58 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAPI9vPg076154 for ; Tue, 25 Nov 2003 18:09:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPI9vuK279596 for ; Tue, 25 Nov 2003 19:09:57 +0100 Received: from zurich.ibm.com (sig-9-145-225-183.de.ibm.com [9.145.225.183]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA21728; Tue, 25 Nov 2003 19:09:40 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <3FC1C145.1030602@zurich.ibm.com> <3FC25914.E513A7CA@alcatel.com> <3FC33044.2080504@zurich.ibm.com> <3FC39874.4C89599@alcatel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020504010700060002070300" Approved-By: Patrick Droz Message-ID: <3FC39ADE.8020305@zurich.ibm.com> Date: Tue, 25 Nov 2003 19:09:34 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: ForCES transport requirements WAS (Re: Support for multicast intheForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC39874.4C89599@alcatel.com> Precedence: list This is a cryptographically signed message in MIME format. --------------ms020504010700060002070300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [chair hat off] yes, I know you can partition the routing table but many routers don't do that. Also keep in mind that you still have to have the full routing info at the CE for all the packets that cannot be handled at the FE (e.g. IP option handling). Regards, Patrick Alex Audu wrote: > Hi Patrick, > > The growth rate of routing table size has been of interest in the research > community and industry for some time. And research is activly on-going > at finding ways to contain that growth. See for example: > > http://www.antc.uoregon.edu/route-views/dynamics/ > > Certainly the routing table gorws as the number of route peers increases. This > particularly the case with table-driven IP routing where each machine employes > an IP Routing table that sotre information about possible destinations and how > to reach them. > > Using the network portion of a destination address instead of the complete > host address makes routing efficient and keeps routing tables small. This is > the essence of Next-Hop Routing where a routing table table contains (N,R) > (where N is the Ip address of the destination network and R is the IP address > of the next router along the path to N. Router R is called the next hop. There > are various other methods including partitioning the CORE into partial cores > that reside in separate sites and using default routes to point to the peer site. > Of course, this results into a routing loops,..and that is not what we are talking > about here. > > I would rather not say anymore about this, but you can certainly partition the > routing table in an NE into a tree with the root residing in the CE. This is a form > of hierarchical routing. Sure, it may take longer to resolve certain routes. > > See also > http://www-rp.lip6.fr/~ridoux/Manuel-NS2/node319.html > http://www.research.att.com/~jrex/papers/filter.pdf > > Regards, > Alex. > > Patrick Droz wrote: > > >>[chair hat off] >> >>Alex Audu wrote: >> >>Hi Alex, >> >>see my comments inline. >> >> >>>Hello Patrick, >>> >>>Please my comments in-line.. >>> >>>Regards, >>>Alex. >>> >>>Patrick Droz wrote: >>> >>> >>> >>>>[chair hat off] >>>> >>>>see comments inline >>>> >>>>Alex Audu wrote: >>>> >>>> >>>> >>>>>Hi All, >>>>> >>>>>All this talk about the need and benefits of multicast certainly makes ones >>>>>feel it is a cure all for what is being termed as the ailment in ForCEs' >>>>>requirements. >>>>> >>>>>Look, it has to be told that you can't do multicast on the cheap. And >>>>>you have >>>>>to answer some key questions if you really want to sell multicast in a >>>>>critical >>>>>environment,..viz: >>>>> >>>>>1) How would you guarrantee the relaible delivery of the messages being >>>>> blasted to all the targets? What if the messages don't arrive at all >>>>>their >>>>> intended targets? How do you recover from this? This suggests you need >>>>> a reliable multicast mechanism. I am not sure you can do this over UDP >>>>> as it is currently being done in NetLink2. That is only good for >>>>>un-reliable >>>>> multicast. I am not sure if you can trust critical configuration >>>>>messages >>>>> like routing table information or basic LFB service/tree structure >>>>>messages >>>>> over such an unreliable mechanism. >>>>> >>>>>2) How do you deal with the issue of security, given that we don't have >>>>>secure >>>>> multicast yet? I have seen some people call for broadcast >>>>>capability also. >>>>> One result of multicast/broadcast is you run the risk of a >>>>>potential attacker >>>>> listening in on say, the routing information being blasted to the >>>>>FEs. I don't >>>>> think multicasting over UDP has an answer to this. >>>>> >>>>> >>>>>There is also this myth that all the FEs will have the same routing >>>>>information >>>> >>>>could you please provide some evidence of this? Keep in mind we are >>>>moving from a centralized (single routing table) to a distributed >>>>router architecture. Why should it change that the routing table >>>>should be much different. Or do you want to go into the discussion >>>>of how you avoid routing loops? >>>> >>> >>> >>>One of the benefits of distributing the NE is the ability to handle many more >>>routes,..many more than the current core routers are capable of. Route >>>table sizes start becoming a problem at that scale. Storing partial routes >>>in a logically hierarchical distributed entities can help. Of course, you have >>>to assign the default routes appropriately to prevent routing loops. >>> >> >>can you proof this statement? For what reason do you need such big >>routing tables. I have not see much growth of routing table sizes. >>A distributed router has to provide forwarding an classification >>performance. I have a hard time that you have to distribute a router >>because of the forwarding table size. Overall you need exactly the >>same amount of memory. Why should a packet coming in on port A and >>heading for DA X being routed differently than a packet arriving on >>port B and also heading to DA X? >> >>Regards, >>Patrick >> >> >>>>>always. I submit that this is not true. One of the problems ForCEs is >>>>>meant to >>>>>solve is scalability. This certainly relates to the abilty to manage the >>>>>rapid >>>>>growth of routing table sizes by distributing the routing information as >>>>>partial >>>>>routes into various FE groups. Granted there is still some scaling issues >>>>>here,..but is definitely not as bad as people have been making it to be. >>>>> >>>>> ..more comments in-line... >>>>> >>>>>Regards, >>>>>Alex. >>>> >>>>Regards, >>>>Patrick >>>> >>>> >>>> >>>>>In a message dated 11/22/2003 12:03:24 PM Central Standard Time, >>>>>hadi@znyx.com writes: >>>>> >>>>> >>>>> >>>>> >>>>>>Continuation of the last thread with a change in topic - i think these >>>>>>are the real issues that need to be addressed instead of the distraction >>>>>>to "multicast is evil". >>>>>> >>>>>>Lets really list the requirements needed for a successful underlying >>>>>>transport protocol that will serve ForCES well. i may be >>>>>>missing some - but i hope to get challenged so i can add to them; >>>>>>I am thinking of turning this into a draft so people read it first and >>>>>>then post. >>>>>>My previous email has some more claims which i will assume here. >>>>>> >>>>>>I. ForCES mechanisms requiring reliability: >>>>>> >>>>>>a) time limit very sensitive (in other words obsolence period is >>>>>>faster): >>>>>>Example table updates; >>>>>>I have argued TCP doesnt qualify in my previous email. SCTP-PR may >>>>>>qualify. >>>>>>Something like what netlink2 over UDP qualifies because it gives control >>>>>>to netlink2 to make such decisions. >>>>> >>>>> >>>>> >>>>>How can you have reliable communcation over UDP? >>>>> >>>>> >>>>> >>>>>>b) time limit best effort (obsolence takes longer) >>>>>>Sample apps: File transfers,etc. >>>>>>TCP qualifies but AFAIK, we dont have this need. >>>>>> >>>>>>II. mechanisms capable of tolerating unreliability: Example psamp. >>>>>>TCP doesnt qualify. >>>>>>something(like netlink2) over UDP or SCTP-PR. >>>>> >>>>> >>>>> >>>>>Why do you say TCP doesn't qualify here? Any application that can live >>>>>with un-reliable transport can sure do better with a relaible one. >>>>> >>>>> >>>>> >>>>>>III. mechanisms that prefer timeliness over reliability: Ex heartbeats >>>>>>something (like netlink2) over UDP or SCTP-PR. >>>>>> >>>>>>Clearly in the bigger picture TCP is not the best protocol. >>>>>>UDP and SCTP-PR qualify partially merely because they dont hinder >>>>>>progress not because they have some magic. Another non-IETF protocol >>>>>>that would qualify is TIPC. I havent carefully studied DCCP but i >>>>>>believe it also has a fit. I will exclude it because its not there yet. >>>>>> >>>>>>So, to summarize: the transport protocol that meets all the requirements >>>>>>For Forces has not been born. >>>>>> >>>>>>Choosing TCP is choosing an answer and then trying to justify the >>>>>>questions that it brings. It does sound like peer pressure instead of >>>>>>looking at requirements and then deciding what you need to do. >>>>>>I think we recognized this in netlink2 and made it clear that the choice >>>>>>of underlying protocol chosen is up to the pre-association phase. >>>>>>We compensate for "missing features" depending on the transport choice >>>>>>(read the draft). >>>>>>It's very few lines of code to provide that luxury. So the cost is low. >>>>>> >>>>>>Now on the choice of netlink2 UDP vs SCTP-PR >>>>>> >>>>>>1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available >>>>>>Netlink2 can run over it. For now we choose to be standalone: We can run >>>>>>over IP, over UDP or over ethernet, you take your pick. >>>>> >>>>> >>>>> >>>>>I believe SCTP-PR is now in IESG queue. Even when it is available, you have >>>>>to run it in a reliable mode to guarantee that those critical configuration >>>>>messages get to their destination safely. And it still doesn't buy you >>>>>security. >>>>> >>>>> >>>>> >>>>> >>>>>>2) UDP provides multicast (and broadcast). SCTP-PR does not. >>>>>>Since SCTP has turned to be a swiss knife (or maybe a multi faceted >>>>>>beast), i am sure it will soon as well support multicast;-> >>>>>> >>>>>>If multicast is there - we will use it. Sans that we will do something >>>>>>multicast like (Jon calls it unireplicate i think). >>>>>>All the three cauthors have had pleasant experiences using multicast for >>>>>>ForCES like. We think it is a good thing to have. But we will not >>>>>>torture you if you dont have multicast or broadcast ;-> >>>>>> >>>>>>Why Multicast is useful: >>>>>>-- >>>>>>I must apologize since i have to repeat this. >>>>>>In the simple case of a single multicast wire: each of the CEs or FEs >>>>>>opens a single multicast socket/channel. >>>>>> >>>>>>Why is this good: >>>>>> >>>>>>1) Bandwidth is less used >>>>>>a)because one or more CEs can send a single message to all FEs. >>>>>>I really dont want to be teaching people the hows but i will provide one >>>>>>example which David or maybe it was Joel didnt seem to make sense out of >>>>>>(but one that i have successfuly used)[1] >>>>>>b) you can reduce the number of packets further by limiting on >>>>>>ACKs (partial acks) >>>>>> >>>>>>2) RAM on the embedded CE or FE is used less. There are less sockets >>>>>>open and less messages being built >>>>>> >>>>>>3) CPU is preserved more. >>>>>>Since there are fewer messages to process and fewer (socket states) >>>>>>states to track. >>>>> >>>>> >>>>> >>>>>As far as I am concerned, the more critical resource CPU-wise is FE. The >>>>>mutlicast scheme Netlink2 proposes blasts all every packet to every FE. >>>>>Each FE has to do work to filter out which packet doesn't belong to it. >>>>>Thus, >>>>>the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles >>>>>that should be best used in forwarding packets. >>>>> >>>>> >>>>> >>>>> >>>>>>4) The ability for all listeners on the wire to see message exchanges >>>>>>even when not directed at them provides a cheap way to synchronize. >>>>> >>>>> >>>>> >>>>>And of course, if this is a malicious node, it will gladly gleam as much >>>>>information >>>>>as is enough to mount an attack. This is why secure multicast is necessary. >>>>> >>>>> >>>>> >>>>>>5) At a transport level, (not the forces transaction level), having >>>>>>access to multicast provides location transparency. >>>>>> >>>>>>6) A lot of switch fabrics (shared memory designs or otherwise) >>>>>>interconnecting FEs and CES have multicast capabilities; so it is good >>>>>>if we can take advantage of it where possible. >>>>>> >>>>>>The above is the simple case, by induction you could extend the >>>>>>reasoning to the case where you have X sockets. >>>>>> >>>>>>I dont want to preach multicast as panacea; we address some of the >>>>>>limitations in the draft; however, i want it to be available when i need >>>>>>it and not shoved down the toilet. >>>>>> >>>>>>So far apart from Joel (who implemented on ATM) on real boxes and Ram >>>>>>(who did something very specific that needs unicast) the rest of the >>>>>>arguements i have seen are from people who see the need for this >>>>>>feature. You can choose to ignore it - and you may be influenced by some >>>>>>implementation you are familiar with - thats your loss. I do think TCP >>>>>>is valid for some cases (low latency and congestion), but i wouldnt >>>>>>claim it to be the answer weve all been waiting for. >>>>>>Again let me reiterate that Netlink2 does not need to have multicast (it >>>>>>is a MAY) but would love to have it when it is available. We can run on >>>>>>your favorite protocol TCP ;-> >>>>>> >>>>>>cheers, >>>>>>jamal >>>>>> >>>>>>[1] I will give the example in another email - this one is already >>>>>>getting too long. >>>>> >>>>> >>>>> >>>>-- >>>> Dr. Patrick Droz | dro@zurich.ibm.com >>>> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro >>>> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 >>>> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 >>> >>> >>> >>-- >> Dr. Patrick Droz | dro@zurich.ibm.com >> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro >> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 >> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms020504010700060002070300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMjUx ODA5MzRaMCMGCSqGSIb3DQEJBDEWBBQxOFBIOF9ujgnqfXqCz4KfLnNDIzBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgCaSjgQMDaLPzeOcLp+EiAKh6EsbTTnRM5bz CQ6/18lUq0o/52EMZ6LRVi5MFApa96eHe70Bx9sjW9z3A5Pj0fhEKCrXRg9ZwQEg6s3aiBzN HwocYys+FCVS9IIJqtQ+phgPtJ/3mea+d8iwo7zX+g/vjxxCA8sO37ae4jr/gvaoAAAAAAAA --------------ms020504010700060002070300-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 13:21:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00433 for ; Tue, 25 Nov 2003 13:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOhoT-0002Ny-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:21:25 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOhoS-0002Np-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:21:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C58246@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 13:21:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61954882 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 13:21:21 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 13:21:17 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPILDcb021134 for ; Tue, 25 Nov 2003 12:21:13 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <128.35da4563.2cf2ab23@aol.com> <3FC1C145.1030602@zurich.ibm.com> <3FC25914.E513A7CA@alcatel.com> <3FC33044.2080504@zurich.ibm.com> <3FC39874.4C89599@alcatel.com> <3FC39ADE.8020305@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC39D8F.FFCFE3CD@alcatel.com> Date: Tue, 25 Nov 2003 12:21:03 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES transport requirements WAS (Re: Support for multicastintheForCE... To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes, the full routing table could be in the CE but not in the FEs. The issue was the time it takes to blast the full routing table to each of the FEs, but I am saying, it doesn't have to be that way. You can take the scalability that ForCES provides and partition the routing tables into smaller sizes that are blasted to the FEs. And of course, that also means that the route partitions are not necessarily the same in all the FEs. This implies you can't blindly multicast routing tables to all the FEs The other issue is the routing table in the CE may not have to be the full table. But that is another research topic. Regards, Alex. Patrick Droz wrote: > [chair hat off] > > yes, I know you can partition the routing table but many routers > don't do that. Also keep in mind that you still have to have the > full routing info at the CE for all the packets that cannot be > handled at the FE (e.g. IP option handling). > > Regards, > Patrick > > Alex Audu wrote: > > > Hi Patrick, > > > > The growth rate of routing table size has been of interest in the research > > community and industry for some time. And research is activly on-going > > at finding ways to contain that growth. See for example: > > > > http://www.antc.uoregon.edu/route-views/dynamics/ > > > > Certainly the routing table gorws as the number of route peers increases. This > > particularly the case with table-driven IP routing where each machine employes > > an IP Routing table that sotre information about possible destinations and how > > to reach them. > > > > Using the network portion of a destination address instead of the complete > > host address makes routing efficient and keeps routing tables small. This is > > the essence of Next-Hop Routing where a routing table table contains (N,R) > > (where N is the Ip address of the destination network and R is the IP address > > of the next router along the path to N. Router R is called the next hop. There > > are various other methods including partitioning the CORE into partial cores > > that reside in separate sites and using default routes to point to the peer site. > > Of course, this results into a routing loops,..and that is not what we are talking > > about here. > > > > I would rather not say anymore about this, but you can certainly partition the > > routing table in an NE into a tree with the root residing in the CE. This is a form > > of hierarchical routing. Sure, it may take longer to resolve certain routes. > > > > See also > > http://www-rp.lip6.fr/~ridoux/Manuel-NS2/node319.html > > http://www.research.att.com/~jrex/papers/filter.pdf > > > > Regards, > > Alex. > > > > Patrick Droz wrote: > > > > > >>[chair hat off] > >> > >>Alex Audu wrote: > >> > >>Hi Alex, > >> > >>see my comments inline. > >> > >> > >>>Hello Patrick, > >>> > >>>Please my comments in-line.. > >>> > >>>Regards, > >>>Alex. > >>> > >>>Patrick Droz wrote: > >>> > >>> > >>> > >>>>[chair hat off] > >>>> > >>>>see comments inline > >>>> > >>>>Alex Audu wrote: > >>>> > >>>> > >>>> > >>>>>Hi All, > >>>>> > >>>>>All this talk about the need and benefits of multicast certainly makes ones > >>>>>feel it is a cure all for what is being termed as the ailment in ForCEs' > >>>>>requirements. > >>>>> > >>>>>Look, it has to be told that you can't do multicast on the cheap. And > >>>>>you have > >>>>>to answer some key questions if you really want to sell multicast in a > >>>>>critical > >>>>>environment,..viz: > >>>>> > >>>>>1) How would you guarrantee the relaible delivery of the messages being > >>>>> blasted to all the targets? What if the messages don't arrive at all > >>>>>their > >>>>> intended targets? How do you recover from this? This suggests you need > >>>>> a reliable multicast mechanism. I am not sure you can do this over UDP > >>>>> as it is currently being done in NetLink2. That is only good for > >>>>>un-reliable > >>>>> multicast. I am not sure if you can trust critical configuration > >>>>>messages > >>>>> like routing table information or basic LFB service/tree structure > >>>>>messages > >>>>> over such an unreliable mechanism. > >>>>> > >>>>>2) How do you deal with the issue of security, given that we don't have > >>>>>secure > >>>>> multicast yet? I have seen some people call for broadcast > >>>>>capability also. > >>>>> One result of multicast/broadcast is you run the risk of a > >>>>>potential attacker > >>>>> listening in on say, the routing information being blasted to the > >>>>>FEs. I don't > >>>>> think multicasting over UDP has an answer to this. > >>>>> > >>>>> > >>>>>There is also this myth that all the FEs will have the same routing > >>>>>information > >>>> > >>>>could you please provide some evidence of this? Keep in mind we are > >>>>moving from a centralized (single routing table) to a distributed > >>>>router architecture. Why should it change that the routing table > >>>>should be much different. Or do you want to go into the discussion > >>>>of how you avoid routing loops? > >>>> > >>> > >>> > >>>One of the benefits of distributing the NE is the ability to handle many more > >>>routes,..many more than the current core routers are capable of. Route > >>>table sizes start becoming a problem at that scale. Storing partial routes > >>>in a logically hierarchical distributed entities can help. Of course, you have > >>>to assign the default routes appropriately to prevent routing loops. > >>> > >> > >>can you proof this statement? For what reason do you need such big > >>routing tables. I have not see much growth of routing table sizes. > >>A distributed router has to provide forwarding an classification > >>performance. I have a hard time that you have to distribute a router > >>because of the forwarding table size. Overall you need exactly the > >>same amount of memory. Why should a packet coming in on port A and > >>heading for DA X being routed differently than a packet arriving on > >>port B and also heading to DA X? > >> > >>Regards, > >>Patrick > >> > >> > >>>>>always. I submit that this is not true. One of the problems ForCEs is > >>>>>meant to > >>>>>solve is scalability. This certainly relates to the abilty to manage the > >>>>>rapid > >>>>>growth of routing table sizes by distributing the routing information as > >>>>>partial > >>>>>routes into various FE groups. Granted there is still some scaling issues > >>>>>here,..but is definitely not as bad as people have been making it to be. > >>>>> > >>>>> ..more comments in-line... > >>>>> > >>>>>Regards, > >>>>>Alex. > >>>> > >>>>Regards, > >>>>Patrick > >>>> > >>>> > >>>> > >>>>>In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > >>>>>hadi@znyx.com writes: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Continuation of the last thread with a change in topic - i think these > >>>>>>are the real issues that need to be addressed instead of the distraction > >>>>>>to "multicast is evil". > >>>>>> > >>>>>>Lets really list the requirements needed for a successful underlying > >>>>>>transport protocol that will serve ForCES well. i may be > >>>>>>missing some - but i hope to get challenged so i can add to them; > >>>>>>I am thinking of turning this into a draft so people read it first and > >>>>>>then post. > >>>>>>My previous email has some more claims which i will assume here. > >>>>>> > >>>>>>I. ForCES mechanisms requiring reliability: > >>>>>> > >>>>>>a) time limit very sensitive (in other words obsolence period is > >>>>>>faster): > >>>>>>Example table updates; > >>>>>>I have argued TCP doesnt qualify in my previous email. SCTP-PR may > >>>>>>qualify. > >>>>>>Something like what netlink2 over UDP qualifies because it gives control > >>>>>>to netlink2 to make such decisions. > >>>>> > >>>>> > >>>>> > >>>>>How can you have reliable communcation over UDP? > >>>>> > >>>>> > >>>>> > >>>>>>b) time limit best effort (obsolence takes longer) > >>>>>>Sample apps: File transfers,etc. > >>>>>>TCP qualifies but AFAIK, we dont have this need. > >>>>>> > >>>>>>II. mechanisms capable of tolerating unreliability: Example psamp. > >>>>>>TCP doesnt qualify. > >>>>>>something(like netlink2) over UDP or SCTP-PR. > >>>>> > >>>>> > >>>>> > >>>>>Why do you say TCP doesn't qualify here? Any application that can live > >>>>>with un-reliable transport can sure do better with a relaible one. > >>>>> > >>>>> > >>>>> > >>>>>>III. mechanisms that prefer timeliness over reliability: Ex heartbeats > >>>>>>something (like netlink2) over UDP or SCTP-PR. > >>>>>> > >>>>>>Clearly in the bigger picture TCP is not the best protocol. > >>>>>>UDP and SCTP-PR qualify partially merely because they dont hinder > >>>>>>progress not because they have some magic. Another non-IETF protocol > >>>>>>that would qualify is TIPC. I havent carefully studied DCCP but i > >>>>>>believe it also has a fit. I will exclude it because its not there yet. > >>>>>> > >>>>>>So, to summarize: the transport protocol that meets all the requirements > >>>>>>For Forces has not been born. > >>>>>> > >>>>>>Choosing TCP is choosing an answer and then trying to justify the > >>>>>>questions that it brings. It does sound like peer pressure instead of > >>>>>>looking at requirements and then deciding what you need to do. > >>>>>>I think we recognized this in netlink2 and made it clear that the choice > >>>>>>of underlying protocol chosen is up to the pre-association phase. > >>>>>>We compensate for "missing features" depending on the transport choice > >>>>>>(read the draft). > >>>>>>It's very few lines of code to provide that luxury. So the cost is low. > >>>>>> > >>>>>>Now on the choice of netlink2 UDP vs SCTP-PR > >>>>>> > >>>>>>1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > >>>>>>Netlink2 can run over it. For now we choose to be standalone: We can run > >>>>>>over IP, over UDP or over ethernet, you take your pick. > >>>>> > >>>>> > >>>>> > >>>>>I believe SCTP-PR is now in IESG queue. Even when it is available, you have > >>>>>to run it in a reliable mode to guarantee that those critical configuration > >>>>>messages get to their destination safely. And it still doesn't buy you > >>>>>security. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>2) UDP provides multicast (and broadcast). SCTP-PR does not. > >>>>>>Since SCTP has turned to be a swiss knife (or maybe a multi faceted > >>>>>>beast), i am sure it will soon as well support multicast;-> > >>>>>> > >>>>>>If multicast is there - we will use it. Sans that we will do something > >>>>>>multicast like (Jon calls it unireplicate i think). > >>>>>>All the three cauthors have had pleasant experiences using multicast for > >>>>>>ForCES like. We think it is a good thing to have. But we will not > >>>>>>torture you if you dont have multicast or broadcast ;-> > >>>>>> > >>>>>>Why Multicast is useful: > >>>>>>-- > >>>>>>I must apologize since i have to repeat this. > >>>>>>In the simple case of a single multicast wire: each of the CEs or FEs > >>>>>>opens a single multicast socket/channel. > >>>>>> > >>>>>>Why is this good: > >>>>>> > >>>>>>1) Bandwidth is less used > >>>>>>a)because one or more CEs can send a single message to all FEs. > >>>>>>I really dont want to be teaching people the hows but i will provide one > >>>>>>example which David or maybe it was Joel didnt seem to make sense out of > >>>>>>(but one that i have successfuly used)[1] > >>>>>>b) you can reduce the number of packets further by limiting on > >>>>>>ACKs (partial acks) > >>>>>> > >>>>>>2) RAM on the embedded CE or FE is used less. There are less sockets > >>>>>>open and less messages being built > >>>>>> > >>>>>>3) CPU is preserved more. > >>>>>>Since there are fewer messages to process and fewer (socket states) > >>>>>>states to track. > >>>>> > >>>>> > >>>>> > >>>>>As far as I am concerned, the more critical resource CPU-wise is FE. The > >>>>>mutlicast scheme Netlink2 proposes blasts all every packet to every FE. > >>>>>Each FE has to do work to filter out which packet doesn't belong to it. > >>>>>Thus, > >>>>>the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles > >>>>>that should be best used in forwarding packets. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>4) The ability for all listeners on the wire to see message exchanges > >>>>>>even when not directed at them provides a cheap way to synchronize. > >>>>> > >>>>> > >>>>> > >>>>>And of course, if this is a malicious node, it will gladly gleam as much > >>>>>information > >>>>>as is enough to mount an attack. This is why secure multicast is necessary. > >>>>> > >>>>> > >>>>> > >>>>>>5) At a transport level, (not the forces transaction level), having > >>>>>>access to multicast provides location transparency. > >>>>>> > >>>>>>6) A lot of switch fabrics (shared memory designs or otherwise) > >>>>>>interconnecting FEs and CES have multicast capabilities; so it is good > >>>>>>if we can take advantage of it where possible. > >>>>>> > >>>>>>The above is the simple case, by induction you could extend the > >>>>>>reasoning to the case where you have X sockets. > >>>>>> > >>>>>>I dont want to preach multicast as panacea; we address some of the > >>>>>>limitations in the draft; however, i want it to be available when i need > >>>>>>it and not shoved down the toilet. > >>>>>> > >>>>>>So far apart from Joel (who implemented on ATM) on real boxes and Ram > >>>>>>(who did something very specific that needs unicast) the rest of the > >>>>>>arguements i have seen are from people who see the need for this > >>>>>>feature. You can choose to ignore it - and you may be influenced by some > >>>>>>implementation you are familiar with - thats your loss. I do think TCP > >>>>>>is valid for some cases (low latency and congestion), but i wouldnt > >>>>>>claim it to be the answer weve all been waiting for. > >>>>>>Again let me reiterate that Netlink2 does not need to have multicast (it > >>>>>>is a MAY) but would love to have it when it is available. We can run on > >>>>>>your favorite protocol TCP ;-> > >>>>>> > >>>>>>cheers, > >>>>>>jamal > >>>>>> > >>>>>>[1] I will give the example in another email - this one is already > >>>>>>getting too long. > >>>>> > >>>>> > >>>>> > >>>>-- > >>>> Dr. Patrick Droz | dro@zurich.ibm.com > >>>> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > >>>> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > >>>> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > >>> > >>> > >>> > >>-- > >> Dr. Patrick Droz | dro@zurich.ibm.com > >> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > >> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > >> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 13:37:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01160 for ; Tue, 25 Nov 2003 13:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOi47-0002b2-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:37:35 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOi46-0002au-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 13:37:34 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C58289@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 13:37:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61956257 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 13:36:53 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 13:36:53 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5891358 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 13:36:48 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031125133228.01a68130@localhost> Date: Tue, 25 Nov 2003 13:36:42 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC37F04.605@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: quoted-printable I see two kinds of problems with this: 1) Given that an FE being design can not ensure where it will be deployed,= =20 it follows that all FEs (and CEs) would have to support both UDP and TCP /= =20 SCTP transport. (I do not believe that "targeted" is a useful or=20 meaningful attribute of an FE or a CE.) 2) If we are going to support UDP, we need to specify the retransmission=20 (including backoff), flow control, and congestion reaction algorithms. On a related note, I do not know what it means to say that FEs and CEs MUST= =20 support group addressing. This could mean the simple statement that the=20 messages must contain higher level target IDs. It could mean that we must= =20 have mechanisms to manage the configuration and use of group addresses. It= =20 could mean any number of things. Yours, Joel M. Halpern At 05:10 PM 11/25/2003 +0100, you wrote: >In order to reach a consensus before we are exhausted posting on the list,= =20 >let me cristallize what could help unlock the situation. > >I presume we should be able to reach consensus on sth like (remains to be= =20 >defined in more detail): > >ForCES transport >--------------------- >a) An FE MUST support UDP (or raw media encapsulation) as ForCES transport= =20 >if the FE is targeted at the local scope env. >b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 >targeted at the global scope environment. >c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 >ForCES transport if the FE is targeted at both local and global scopes. > (the same applies for the CE) > >FEs/CEs that support TCP will support UDP as well (I have never seen an IP= =20 >stack that offers TCP without UDP). Note that this does not prevent from=20 >using TCP in the local scope if the FEs and CEs support it. Thus=20 >TCP-proponents should be satisfied. > > >In addition, could we reach consensus on sth like: > >ForCES group addressing >------------------------------ >d) FEs and CEs MUST support group addressing in the ForCES protocol. > >Nobody is forced to USE such a group addressing (one can stick to unicast= =20 >ForCES-addressing and TCP transport in all cases). But if one sees that=20 >group addressing fits ones needs (and many have voiced it on the list),=20 >then one should be able to use it. Ultimately (and this is probably best=20 >so), it's the user writing software in the CE who decides what she/he=20 >wants to use. > >Note that the phrasing in a), b), c), and d) is meant to satisfy=20 >interoperability. Not my ego. > >I have the impression that a number of participants in this WG, including= =20 >other protocol draft authors, tend to agree on these items. Who would not= =20 >agree (and on what) ? > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 14:28:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03653 for ; Tue, 25 Nov 2003 14:28:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOirj-0003ZW-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:28:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOirj-0003ZT-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:28:51 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00C581F6@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 14:28:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61959869 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 14:28:49 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 14:28:47 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAPJTZGT005163 for ; Tue, 25 Nov 2003 19:29:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAPJMnX13548 for ; Tue, 25 Nov 2003 19:22:49 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112511284519015 for ; Tue, 25 Nov 2003 11:28:45 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 11:28:45 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOzQlhK7nCvLfjTSSmFe+L8ccYgUgAQc7xg X-OriginalArrivalTime: 25 Nov 2003 19:28:45.0521 (UTC) FILETIME=[57BA9410:01C3B38A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54C68@orsmsx410.jf.intel.com> Date: Tue, 25 Nov 2003 11:28:45 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Patrick, Let me try to explain my point again. Some of the examples I presented below are similar to examples=20 that I have heard for multicast support in the past (OSPF). There are some technical issues with using multicast that should be flushed out before deciding to use it as a transport option... 1) Reliability including congestion control. I know congestion control is not a requirement in the local scope but I do believe it is important and have heard lots of folks including Ads (Alex Zinin) arguing for this during our Requirements team discussion on reliability. 2) Command bundling and how this can be done efficiently using multicast. (Note: sending one message of size 3x is not more efficient than sending 3 messages of size x. Actually, you will probably spend more time encapsulating/decapsulating a big message(3x above).) 3) FE responses to CE requests, or FE-to-CE messages being sent without swamping all FEs with these messages (in case multicast is used) I will not mention Security since it don't believe that is as important in the local scope, atleast not as much as the above. Now, let me try to answer the question of applicability of multicast. Lets say 90% of ForCES deployment is in the local scope (rack). Lets say 80% of those backplanes or interconnects in the rack support multicast. Assuming about 40% of these systems have several dozens of FEs in which case Multicast adds some reasonable value over unicast. (For hundreds of FEs, the % of systems is going to be less that 10%.) Now lets say 60% of your configuration information is routing information which is same across all FEs. Finally, only 60% of the time you will Not use "command bundling" when downloading this information. If you do the math, it comes to about 90*80*40*60*60 =3D 10.3% of use cases where multicast is applicable and has reasonable value over unicast. So when you are trying to come up with a tradeoff of complexity, interoperability issues of adding multicast vs efficiency it provides, you need to find the number of use cases where it can be applied, which is around 10%.=20 Do you agree ? I will be happy to change these numbers based on real Market or implementation information, Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 14:38:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04497 for ; Tue, 25 Nov 2003 14:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOj1Z-0003uK-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:39:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOj1Z-0003uH-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:39:01 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C5826B@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 14:39:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61961321 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 14:39:00 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 14:39:00 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAPJcwBs021022 for ; Tue, 25 Nov 2003 19:38:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPJcwZF254030 for ; Tue, 25 Nov 2003 20:38:58 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA25910 for ; Tue, 25 Nov 2003 20:38:57 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20031125133228.01a68130@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Robert Haas Message-ID: <3FC3AFD1.9060809@zurich.ibm.com> Date: Tue, 25 Nov 2003 20:38:57 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031125133228.01a68130@localhost> Precedence: list Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > I see two kinds of problems with this: > 1) Given that an FE being design can not ensure where it will be > deployed, it follows that all FEs (and CEs) would have to support both > UDP and TCP / SCTP transport. (I do not believe that "targeted" is a > useful or meaningful attribute of an FE or a CE.) You could also argue that some FE manufacturers will only address the local scope market, because the FE they make is meant to be attached to a switching fabric to which the CE is also attached. Since most of the argument until now was due to the mixing of local/global scopes, I thought it is useful to address them separately, even if we end up having FEs supporting both (most likely case). > > 2) If we are going to support UDP, we need to specify the > retransmission (including backoff), flow control, and congestion > reaction algorithms. You should consider also that there exist backpressure mechanisms in switching fabrics that can help achieving this. And we don't need to specify complex algorithms to start with. Probably we'll never need to. > > On a related note, I do not know what it means to say that FEs and CEs > MUST support group addressing. This could mean the simple statement > that the messages must contain higher level target IDs. It could mean > that we must have mechanisms to manage the configuration and use of > group addresses. It could mean any number of things. Therefore the point behind my attempt to first agree on what we want, and then discuss how to provide it. From your answer I conclude that you consider group addressing should NOT be part of ForCES and that TCP is the only tolerable transport. I am curious what others think of this attempt to reach some consensus. -- Robert Haas From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 14:41:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04570 for ; Tue, 25 Nov 2003 14:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOj45-0003vM-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:41:37 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOj44-0003vJ-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:41:36 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00C583BA@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 14:41:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61961447 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 14:41:35 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 14:41:35 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAPJfvao004859 for ; Tue, 25 Nov 2003 19:41:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAPJZa427714 for ; Tue, 25 Nov 2003 19:35:36 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112511413200594 for ; Tue, 25 Nov 2003 11:41:32 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 11:41:32 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] towards consensus: ForCES transport and group addressing Thread-Index: AcOzgzWhgXCbkS3AQQWEFZq/0qsuRwAB1M+g X-OriginalArrivalTime: 25 Nov 2003 19:41:32.0458 (UTC) FILETIME=[20DBE0A0:01C3B38C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54C70@orsmsx410.jf.intel.com> Date: Tue, 25 Nov 2003 11:41:31 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Robert, I agree with Joel, I think it will be a big mistake to reach a consensus without answering all the technical issues that have been raised with = multicast, Namely 1) reliability including CC, 2) command bundling, 3) message = explosion at FEs. In order to have a Interoperable solution, these issues have to = be explicitly addressed. (See my email to Patrick) Although, Security seems less important at the moment, once the draft = reaches The Security Directorate for review, you will realize its importance as = well :-) Just one more thing, in the US we will be having Thanksgiving holidays = from Thursday to Sunday so a lot of folks are on vacation this week. It will = be courteous to wait till next week so that most folks are back at work = before=20 rushing into any decisions. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, November 25, 2003 10:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] towards consensus: ForCES transport and group = addressing I see two kinds of problems with this: 1) Given that an FE being design can not ensure where it will be = deployed,=20 it follows that all FEs (and CEs) would have to support both UDP and TCP = /=20 SCTP transport. (I do not believe that "targeted" is a useful or=20 meaningful attribute of an FE or a CE.) 2) If we are going to support UDP, we need to specify the retransmission = (including backoff), flow control, and congestion reaction algorithms. On a related note, I do not know what it means to say that FEs and CEs = MUST=20 support group addressing. This could mean the simple statement that the = messages must contain higher level target IDs. It could mean that we = must=20 have mechanisms to manage the configuration and use of group addresses. = It=20 could mean any number of things. Yours, Joel M. Halpern At 05:10 PM 11/25/2003 +0100, you wrote: >In order to reach a consensus before we are exhausted posting on the = list,=20 >let me cristallize what could help unlock the situation. > >I presume we should be able to reach consensus on sth like (remains to = be=20 >defined in more detail): > >ForCES transport >--------------------- >a) An FE MUST support UDP (or raw media encapsulation) as ForCES = transport=20 >if the FE is targeted at the local scope env. >b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 >targeted at the global scope environment. >c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 >ForCES transport if the FE is targeted at both local and global scopes. > (the same applies for the CE) > >FEs/CEs that support TCP will support UDP as well (I have never seen an = IP=20 >stack that offers TCP without UDP). Note that this does not prevent = from=20 >using TCP in the local scope if the FEs and CEs support it. Thus=20 >TCP-proponents should be satisfied. > > >In addition, could we reach consensus on sth like: > >ForCES group addressing >------------------------------ >d) FEs and CEs MUST support group addressing in the ForCES protocol. > >Nobody is forced to USE such a group addressing (one can stick to = unicast=20 >ForCES-addressing and TCP transport in all cases). But if one sees that = >group addressing fits ones needs (and many have voiced it on the list), = >then one should be able to use it. Ultimately (and this is probably = best=20 >so), it's the user writing software in the CE who decides what she/he=20 >wants to use. > >Note that the phrasing in a), b), c), and d) is meant to satisfy=20 >interoperability. Not my ego. > >I have the impression that a number of participants in this WG, = including=20 >other protocol draft authors, tend to agree on these items. Who would = not=20 >agree (and on what) ? > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 14:52:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05092 for ; Tue, 25 Nov 2003 14:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjEk-00048i-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:52:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOjEk-00048f-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 14:52:38 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00C583D8@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 14:52:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61961989 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 14:52:38 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 14:52:37 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPJqaLS026410 for ; Tue, 25 Nov 2003 13:52:37 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds951.usa.alcatel.com id hAPJqaLS026410 Approved-By: Alex Audu Message-ID: <3FC3B303.5A930BB8@alcatel.com> Date: Tue, 25 Nov 2003 13:52:36 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable All the agreed upon must-have features of ForCES have been documented in the requiremnents document. So, why make a new set of requirements at this stage? Regards, Alex. Robert Haas wrote: > In order to reach a consensus before we are exhausted posting on the > list, let me cristallize what could help unlock the situation. > > I presume we should be able to reach consensus on sth like (remains to > be defined in more detail): > > ForCES transport > --------------------- > a) An FE MUST support UDP (or raw media encapsulation) as ForCES > transport if the FE is targeted at the local scope env. > b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is > targeted at the global scope environment. > c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as > ForCES transport if the FE is targeted at both local and global scopes. > (the same applies for the CE) > > FEs/CEs that support TCP will support UDP as well (I have never seen an > IP stack that offers TCP without UDP). Note that this does not prevent > from using TCP in the local scope if the FEs and CEs support it. Thus > TCP-proponents should be satisfied. > > In addition, could we reach consensus on sth like: > > ForCES group addressing > ------------------------------ > d) FEs and CEs MUST support group addressing in the ForCES protocol. > > Nobody is forced to USE such a group addressing (one can stick to > unicast ForCES-addressing and TCP transport in all cases). But if one > sees that group addressing fits ones needs (and many have voiced it on > the list), then one should be able to use it. Ultimately (and this is > probably best so), it's the user writing software in the CE who decides > what she/he wants to use. > > Note that the phrasing in a), b), c), and d) is meant to satisfy > interoperability. Not my ego. > > I have the impression that a number of participants in this WG, > including other protocol draft authors, tend to agree on these items. > Who would not agree (and on what) ? > > -- > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 15:04:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05558 for ; Tue, 25 Nov 2003 15:04:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjQ1-0004QK-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:04:17 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOjQ0-0004QG-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:04:17 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C58266@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:04:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61963366 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:04:15 -0500 Received: from 195.212.29.156 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:04:14 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAPK3qwj082134 for ; Tue, 25 Nov 2003 20:03:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAPK3gZF254848 for ; Tue, 25 Nov 2003 21:03:42 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA58742 for ; Tue, 25 Nov 2003 21:03:41 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id hAPK3qwj082134 Approved-By: Robert Haas Message-ID: <3FC3B59D.4050409@zurich.ibm.com> Date: Tue, 25 Nov 2003 21:03:41 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3B303.5A930BB8@alcatel.com> Precedence: list Content-Transfer-Encoding: quoted-printable Alex, You should not view what I sent as protocol requirements, rather as=20 actual answers to the requirements. I am fully OK with the draft=20 requirements, but this does not make us progress much. What's your=20 answer in that case ? -Robert Alex Audu wrote: >All the agreed upon must-have features of ForCES have been documented >in the requiremnents document. So, why make a new set of requirements at >this stage? > >Regards, >Alex. > >Robert Haas wrote: > > =20 > >>In order to reach a consensus before we are exhausted posting on the >>list, let me cristallize what could help unlock the situation. >> >>I presume we should be able to reach consensus on sth like (remains to >>be defined in more detail): >> >>ForCES transport >>--------------------- >> a) An FE MUST support UDP (or raw media encapsulation) as ForCES >>transport if the FE is targeted at the local scope env. >> b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is >>targeted at the global scope environment. >> c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as >>ForCES transport if the FE is targeted at both local and global scopes. >> (the same applies for the CE) >> >>FEs/CEs that support TCP will support UDP as well (I have never seen an >>IP stack that offers TCP without UDP). Note that this does not prevent >>from using TCP in the local scope if the FEs and CEs support it. Thus >>TCP-proponents should be satisfied. >> >>In addition, could we reach consensus on sth like: >> >>ForCES group addressing >>------------------------------ >> d) FEs and CEs MUST support group addressing in the ForCES protocol. >> >>Nobody is forced to USE such a group addressing (one can stick to >>unicast ForCES-addressing and TCP transport in all cases). But if one >>sees that group addressing fits ones needs (and many have voiced it on >>the list), then one should be able to use it. Ultimately (and this is >>probably best so), it's the user writing software in the CE who decides >>what she/he wants to use. >> >>Note that the phrasing in a), b), c), and d) is meant to satisfy >>interoperability. Not my ego. >> >>I have the impression that a number of participants in this WG, >>including other protocol draft authors, tend to agree on these items. >>Who would not agree (and on what) ? >> >>-- >>Robert Haas >>IBM Zurich Research Laboratory >>S=E4umerstrasse 4 >>CH-8803 R=FCschlikon/Switzerland >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a >> =20 >> > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 15:29:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08042 for ; Tue, 25 Nov 2003 15:29:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjoR-000546-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:29:31 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOjoQ-00053u-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:29:30 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C58454@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:29:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61965223 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:29:24 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:29:24 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112512283392:9455 ; Tue, 25 Nov 2003 12:28:33 -0800 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 12:28:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 12:28:35 PM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Approved-By: Jamal Hadi Salim Message-ID: <1069792162.1032.581.camel@jzny.localdomain> Date: Tue, 25 Nov 2003 15:29:22 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3B303.5A930BB8@alcatel.com> Precedence: list Content-Transfer-Encoding: base64 U2luY2UgeW91IGludm9rZSB0aGUgcmVxdWlyZW1lbnRzIGFuZCBjaGFydGVyIGF0IGV2ZXJ5IG9w cG9ydHVuaXR5LA0KbGV0IG1lIHJlbWluZCB5b3UgeW91ciBmYXZvcml0ZSBzZWN0aW9uLCBvbiBy ZWxpYWJpbGl0eSwgYXBvbG9naWVzIHRvDQpvdGhlciBwZW9wbGUsIHNvIHdoaWNoIHBhcnQgcmVq ZWN0cyBoYXZpbmcgYm90aCBVRFAgYW5kIFRDUD8NCg0KLS0tLS0tLS0tLS0tLS0tDQogNilSZWxp YWJpbGl0eSANCiAgIGEpIFRoZSBGb3JDRVMgcHJvdG9jb2wgd2lsbCBiZSB1c2VkIHRvIHRyYW5z cG9ydCBpbmZvcm1hdGlvbiB0aGF0IA0KICAgICByZXF1aXJlcyB2YXJ5aW5nIGxldmVscyBvZiBy ZWxpYWJpbGl0eS4gQnkgc3RyaWN0IG9yIHJvYnVzdCANCiAgICAgcmVsaWFiaWxpdHkgaW4gdGhp cyByZXF1aXJlbWVudCB3ZSBtZWFuLCBubyBsb3NzZXMsIG5vIGNvcnJ1cHRpb24sIA0KICAgICBu byByZS1vcmRlcmluZyBvZiBpbmZvcm1hdGlvbiBiZWluZyB0cmFuc3BvcnRlZCBhbmQgZGVsaXZl cnkgaW4gYSANCiAgICAgdGltZWx5IGZhc2hpb24uIA0KICAgYikgU29tZSBpbmZvcm1hdGlvbiBv ciBwYXlsb2Fkcywgc3VjaCBhcyByZWRpcmVjdGVkIHBhY2tldHMgb3IgcGFja2V0IA0KICAgICBz YW1wbGluZywgbWF5IG5vdCByZXF1aXJlIHJvYnVzdCByZWxpYWJpbGl0eSAoY2FuIHRvbGVyYXRl IHNvbWUgDQogICAgIGRlZ3JlZSBvZiBsb3NzZXMpLiBGb3IgaW5mb3JtYXRpb24gb2YgdGhpcyBz b3J0LCBGb3JDRVMgTVVTVCBOT1QgDQogICAgIGJlIHJlc3RyaWN0ZWQgdG8gc3RyaWN0IHJlbGlh YmlsaXR5LiANCiAgIGMpIFBheWxvYWRzIHN1Y2ggYXMgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv biwgZS5nLiBBQ0xzLCBGSUIgDQogICAgIGVudHJpZXMsIG9yIEZFIGNhcGFiaWxpdHkgaW5mb3Jt YXRpb24gKGRlc2NyaWJlZCBpbiBzZWN0aW9uIDcsIA0KICAgICAoMSkpIGFyZSBtaXNzaW9uIGNy aXRpY2FsIGFuZCBtdXN0IGJlIGRlbGl2ZXJlZCBpbiBhIHJvYnVzdCANCiAgICAgcmVsaWFibGUg ZmFzaGlvbi4gVGh1cywgZm9yIGluZm9ybWF0aW9uIG9mIHRoaXMgc29ydCwgRm9yQ0VTIE1VU1Qg DQogICAgIGVpdGhlciBwcm92aWRlIGJ1aWx0LWluIHByb3RvY29sIG1lY2hhbmlzbXMgb3IgdXNl IGEgcmVsaWFibGUgDQogICAgIHRyYW5zcG9ydCBwcm90b2NvbCBmb3IgYWNoaWV2aW5nIHJvYnVz dC9zdHJpY3QgcmVsaWFiaWxpdHkuIA0KICAgZCkgU29tZSBpbmZvcm1hdGlvbiBvciBwYXlsb2Fk cywgc3VjaCBhcyBoZWFydGJlYXQgcGFja2V0cyB0aGF0IG1heSANCiAgICAgYmUgdXNlZCB0byBk ZXRlY3QgbG9zcyBvZiBhc3NvY2lhdGlvbiBiZXR3ZWVuIENFIGFuZCBGRXMgKHNlZSANCiAgICAg c2VjdGlvbiA3LCAoOCkpLCBtYXkgcHJlZmVyIHRpbWVsaW5lc3Mgb3ZlciByZWxpYWJsZSBkZWxp dmVyeS4gRm9yIA0KICAgICBpbmZvcm1hdGlvbiBvZiB0aGlzIHNvcnQsIEZvckNFUyBNVVNUIE5P VCBiZSByZXN0cmljdGVkIHRvIHN0cmljdCANCiAgICAgcmVsaWFiaWxpdHkuIA0KICAgZSkgV2hl biBGb3JDRVMgaXMgY2FycmllZCBvdmVyIG11bHRpLWhvcCBJUCBuZXR3b3JrcywgaXQgaXMgYSAN CiAgICAgcmVxdWlyZW1lbnQgdGhhdCBGb3JDRVMgTVVTVCB1c2UgYSBbUkZDMjkxNF0tY29tcGxp YW50IHRyYW5zcG9ydCANCiAgICAgcHJvdG9jb2wuIA0KICAgZikgSW4gY2FzZXMgd2hlcmUgRm9y Q0VTIGlzIG5vdCBydW5uaW5nIG92ZXIgYW4gSVAgbmV0d29yayBzdWNoIGFzIGFuIA0KICAgICBF dGhlcm5ldCBvciBjZWxsIGZhYnJpYyBiZXR3ZWVuIENFIGFuZCBGRSwgdGhlbiByZWxpYWJpbGl0 eSBzdGlsbCANCiAgICAgTVVTVCBiZSBwcm92aWRlZCB3aGVuIGNhcnJ5aW5nIGNyaXRpY2FsIGlu Zm9ybWF0aW9uIG9mIHRoZSB0eXBlcyANCiAgICAgc3BlY2lmaWVkIGluIChjKSBhYm92ZSwgZWl0 aGVyIGJ5IHRoZSB1bmRlcmx5aW5nIGxpbmsvbmV0d29yay8gDQogICAgIHRyYW5zcG9ydCBsYXll cnMgb3IgYnkgYnVpbHQtaW4gcHJvdG9jb2wgbWVjaGFuaXNtcy4gDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KY2hlZXJzLA0KamFtYWwNCg0KT24gVHVlLCAyMDAzLTExLTI1 IGF0IDE0OjUyLCBBbGV4IEF1ZHUgd3JvdGU6DQo+IEFsbCB0aGUgYWdyZWVkIHVwb24gbXVzdC1o YXZlIGZlYXR1cmVzIG9mIEZvckNFUyBoYXZlIGJlZW4gZG9jdW1lbnRlZA0KPiBpbiB0aGUgcmVx dWlyZW1uZW50cyBkb2N1bWVudC4gU28sIHdoeSBtYWtlIGEgbmV3IHNldCBvZiByZXF1aXJlbWVu dHMgYXQNCj4gdGhpcyBzdGFnZT8NCj4gDQo+IFJlZ2FyZHMsDQo+IEFsZXguDQo+IA0KPiBSb2Jl cnQgSGFhcyB3cm90ZToNCj4gDQo+ID4gSW4gb3JkZXIgdG8gcmVhY2ggYSBjb25zZW5zdXMgYmVm b3JlIHdlIGFyZSBleGhhdXN0ZWQgcG9zdGluZyBvbiB0aGUNCj4gPiBsaXN0LCBsZXQgbWUgY3Jp c3RhbGxpemUgd2hhdCBjb3VsZCBoZWxwIHVubG9jayB0aGUgc2l0dWF0aW9uLg0KPiA+DQo+ID4g SSBwcmVzdW1lIHdlIHNob3VsZCBiZSBhYmxlIHRvIHJlYWNoIGNvbnNlbnN1cyBvbiBzdGggbGlr ZSAocmVtYWlucyB0bw0KPiA+IGJlIGRlZmluZWQgaW4gbW9yZSBkZXRhaWwpOg0KPiA+DQo+ID4g Rm9yQ0VTIHRyYW5zcG9ydA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICBhKSBBbiBG RSBNVVNUIHN1cHBvcnQgVURQIChvciByYXcgbWVkaWEgZW5jYXBzdWxhdGlvbikgYXMgRm9yQ0VT DQo+ID4gdHJhbnNwb3J0IGlmIHRoZSBGRSBpcyB0YXJnZXRlZCBhdCB0aGUgbG9jYWwgc2NvcGUg ZW52Lg0KPiA+ICBiKSBBbiBGRSBNVVNUIHN1cHBvcnQgVENQIChvciBTQ1RQKSBhcyBGb3JDRVMg dHJhbnNwb3J0IGlmIHRoZSBGRSBpcw0KPiA+IHRhcmdldGVkIGF0IHRoZSBnbG9iYWwgc2NvcGUg ZW52aXJvbm1lbnQuDQo+ID4gIGMpIEFuIEZFIE1VU1Qgc3VwcG9ydCBUQ1AgKG9yIFNDVFApIEFO RCBVRFAgKG9yIHJhdyBtZWRpYSBlbmNhcHMuKSBhcw0KPiA+IEZvckNFUyB0cmFuc3BvcnQgaWYg dGhlIEZFIGlzIHRhcmdldGVkIGF0IGJvdGggbG9jYWwgYW5kIGdsb2JhbCBzY29wZXMuDQo+ID4g ICAodGhlIHNhbWUgYXBwbGllcyBmb3IgdGhlIENFKQ0KPiA+DQo+ID4gRkVzL0NFcyB0aGF0IHN1 cHBvcnQgVENQIHdpbGwgc3VwcG9ydCBVRFAgYXMgd2VsbCAoSSBoYXZlIG5ldmVyIHNlZW4gYW4N Cj4gPiBJUCBzdGFjayB0aGF0IG9mZmVycyBUQ1Agd2l0aG91dCBVRFApLiBOb3RlIHRoYXQgdGhp cyBkb2VzIG5vdCBwcmV2ZW50DQo+ID4gZnJvbSB1c2luZyBUQ1AgaW4gdGhlIGxvY2FsIHNjb3Bl IGlmIHRoZSBGRXMgYW5kIENFcyBzdXBwb3J0IGl0LiBUaHVzDQo+ID4gVENQLXByb3BvbmVudHMg c2hvdWxkIGJlIHNhdGlzZmllZC4NCj4gPg0KPiA+IEluIGFkZGl0aW9uLCBjb3VsZCB3ZSByZWFj aCBjb25zZW5zdXMgb24gc3RoIGxpa2U6DQo+ID4NCj4gPiBGb3JDRVMgZ3JvdXAgYWRkcmVzc2lu Zw0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICBkKSBGRXMgYW5kIENF cyBNVVNUIHN1cHBvcnQgZ3JvdXAgYWRkcmVzc2luZyBpbiB0aGUgRm9yQ0VTIHByb3RvY29sLg0K PiA+DQo+ID4gTm9ib2R5IGlzIGZvcmNlZCB0byBVU0Ugc3VjaCBhIGdyb3VwIGFkZHJlc3Npbmcg KG9uZSBjYW4gc3RpY2sgdG8NCj4gPiB1bmljYXN0IEZvckNFUy1hZGRyZXNzaW5nIGFuZCBUQ1Ag dHJhbnNwb3J0IGluIGFsbCBjYXNlcykuIEJ1dCBpZiBvbmUNCj4gPiBzZWVzIHRoYXQgZ3JvdXAg YWRkcmVzc2luZyBmaXRzIG9uZXMgbmVlZHMgKGFuZCBtYW55IGhhdmUgdm9pY2VkIGl0IG9uDQo+ ID4gdGhlIGxpc3QpLCB0aGVuIG9uZSBzaG91bGQgYmUgYWJsZSB0byB1c2UgaXQuIFVsdGltYXRl bHkgKGFuZCB0aGlzIGlzDQo+ID4gcHJvYmFibHkgYmVzdCBzbyksIGl0J3MgdGhlIHVzZXIgd3Jp dGluZyBzb2Z0d2FyZSBpbiB0aGUgQ0Ugd2hvIGRlY2lkZXMNCj4gPiB3aGF0IHNoZS9oZSB3YW50 cyB0byB1c2UuDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlIHBocmFzaW5nIGluIGEpLCBiKSwgYyks IGFuZCBkKSBpcyBtZWFudCB0byBzYXRpc2Z5DQo+ID4gaW50ZXJvcGVyYWJpbGl0eS4gTm90IG15 IGVnby4NCj4gPg0KPiA+IEkgaGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IGEgbnVtYmVyIG9mIHBh cnRpY2lwYW50cyBpbiB0aGlzIFdHLA0KPiA+IGluY2x1ZGluZyBvdGhlciBwcm90b2NvbCBkcmFm dCBhdXRob3JzLCB0ZW5kIHRvIGFncmVlIG9uIHRoZXNlIGl0ZW1zLg0KPiA+IFdobyB3b3VsZCBu b3QgYWdyZWUgKGFuZCBvbiB3aGF0KSA/DQo+ID4NCj4gPiAtLQ0KPiA+IFJvYmVydCBIYWFzDQo+ ID4gSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+ID4gU+R1bWVyc3RyYXNzZSA0DQo+ ID4gQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQo+ID4gcGhvbmUgKzQxLTEtNzI0LTg2 OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoN Cg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 15:40:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08568 for ; Tue, 25 Nov 2003 15:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjz5-0005P9-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:40:31 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOjz5-0005P5-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 15:40:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C584AB@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 15:40:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61966965 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 15:40:30 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 15:40:30 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112512393806:9472 ; Tue, 25 Nov 2003 12:39:38 -0800 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 12:39:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 12:39:40 PM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Approved-By: Jamal Hadi Salim Message-ID: <1069792826.1030.627.camel@jzny.localdomain> Date: Tue, 25 Nov 2003 15:40:26 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3B59D.4050409@zurich.ibm.com> Precedence: list Content-Transfer-Encoding: base64 DQoNCkkgdGhpbmsgd2Ugc2hvdWxkIHB1bGwgdGhpcyBjb252ZXJzYXRpb24gdG8gdGhlIElFU0cg c28gd2UgY2FuIHB1bGwgYmFjaw0KdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBiZWNhdXNlIG9idmlv dXNseSBpdCBkb2VzbnQgbWVldCB0aGUgcmVxdWlyZW1lbnRzDQp0aGF0IG1vc3QgcGVvcGxlIG5l ZWQuIFRoaXMgaXMgcHJlY2lzZWx5IHdoYXQgaSB3YXMgd29ycmllZCBhYm91dCB3aGVuDQp5b3Ug aGF2ZSBIb3JtdXpkIGVkaXRpbmcgdGhlIGRyYWZ0IGFuZCB0cnlpbmcgdG8gYmUgYSBsYXd5ZXIg YXQgdGhlIHNhbWUNCnRpbWUuDQoNCkRvIHlvdSBrbm93IGhvdyBpIGNhbiBkbyB0aGF0Pw0KDQpj aGVlcnMsDQpqYW1hbA0KDQpPbiBUdWUsIDIwMDMtMTEtMjUgYXQgMTU6MDMsIFJvYmVydCBIYWFz IHdyb3RlOg0KPiBBbGV4LA0KPiBZb3Ugc2hvdWxkIG5vdCB2aWV3IHdoYXQgSSBzZW50IGFzIHBy b3RvY29sIHJlcXVpcmVtZW50cywgcmF0aGVyIGFzIA0KPiBhY3R1YWwgYW5zd2VycyB0byB0aGUg cmVxdWlyZW1lbnRzLiBJIGFtIGZ1bGx5IE9LIHdpdGggdGhlIGRyYWZ0IA0KPiByZXF1aXJlbWVu dHMsIGJ1dCB0aGlzIGRvZXMgbm90IG1ha2UgdXMgcHJvZ3Jlc3MgbXVjaC4gV2hhdCdzIHlvdXIg DQo+IGFuc3dlciBpbiB0aGF0IGNhc2UgPw0KPiANCj4gLVJvYmVydA0KPiANCj4gQWxleCBBdWR1 IHdyb3RlOg0KPiANCj4gPkFsbCB0aGUgYWdyZWVkIHVwb24gbXVzdC1oYXZlIGZlYXR1cmVzIG9m IEZvckNFUyBoYXZlIGJlZW4gZG9jdW1lbnRlZA0KPiA+aW4gdGhlIHJlcXVpcmVtbmVudHMgZG9j dW1lbnQuIFNvLCB3aHkgbWFrZSBhIG5ldyBzZXQgb2YgcmVxdWlyZW1lbnRzIGF0DQo+ID50aGlz IHN0YWdlPw0KPiA+DQo+ID5SZWdhcmRzLA0KPiA+QWxleC4NCj4gPg0KPiA+Um9iZXJ0IEhhYXMg d3JvdGU6DQo+ID4NCj4gPiAgDQo+ID4NCj4gPj5JbiBvcmRlciB0byByZWFjaCBhIGNvbnNlbnN1 cyBiZWZvcmUgd2UgYXJlIGV4aGF1c3RlZCBwb3N0aW5nIG9uIHRoZQ0KPiA+Pmxpc3QsIGxldCBt ZSBjcmlzdGFsbGl6ZSB3aGF0IGNvdWxkIGhlbHAgdW5sb2NrIHRoZSBzaXR1YXRpb24uDQo+ID4+ DQo+ID4+SSBwcmVzdW1lIHdlIHNob3VsZCBiZSBhYmxlIHRvIHJlYWNoIGNvbnNlbnN1cyBvbiBz dGggbGlrZSAocmVtYWlucyB0bw0KPiA+PmJlIGRlZmluZWQgaW4gbW9yZSBkZXRhaWwpOg0KPiA+ Pg0KPiA+PkZvckNFUyB0cmFuc3BvcnQNCj4gPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4g YSkgQW4gRkUgTVVTVCBzdXBwb3J0IFVEUCAob3IgcmF3IG1lZGlhIGVuY2Fwc3VsYXRpb24pIGFz IEZvckNFUw0KPiA+PnRyYW5zcG9ydCBpZiB0aGUgRkUgaXMgdGFyZ2V0ZWQgYXQgdGhlIGxvY2Fs IHNjb3BlIGVudi4NCj4gPj4gYikgQW4gRkUgTVVTVCBzdXBwb3J0IFRDUCAob3IgU0NUUCkgYXMg Rm9yQ0VTIHRyYW5zcG9ydCBpZiB0aGUgRkUgaXMNCj4gPj50YXJnZXRlZCBhdCB0aGUgZ2xvYmFs IHNjb3BlIGVudmlyb25tZW50Lg0KPiA+PiBjKSBBbiBGRSBNVVNUIHN1cHBvcnQgVENQIChvciBT Q1RQKSBBTkQgVURQIChvciByYXcgbWVkaWEgZW5jYXBzLikgYXMNCj4gPj5Gb3JDRVMgdHJhbnNw b3J0IGlmIHRoZSBGRSBpcyB0YXJnZXRlZCBhdCBib3RoIGxvY2FsIGFuZCBnbG9iYWwgc2NvcGVz Lg0KPiA+PiAgKHRoZSBzYW1lIGFwcGxpZXMgZm9yIHRoZSBDRSkNCj4gPj4NCj4gPj5GRXMvQ0Vz IHRoYXQgc3VwcG9ydCBUQ1Agd2lsbCBzdXBwb3J0IFVEUCBhcyB3ZWxsIChJIGhhdmUgbmV2ZXIg c2VlbiBhbg0KPiA+PklQIHN0YWNrIHRoYXQgb2ZmZXJzIFRDUCB3aXRob3V0IFVEUCkuIE5vdGUg dGhhdCB0aGlzIGRvZXMgbm90IHByZXZlbnQNCj4gPj5mcm9tIHVzaW5nIFRDUCBpbiB0aGUgbG9j YWwgc2NvcGUgaWYgdGhlIEZFcyBhbmQgQ0VzIHN1cHBvcnQgaXQuIFRodXMNCj4gPj5UQ1AtcHJv cG9uZW50cyBzaG91bGQgYmUgc2F0aXNmaWVkLg0KPiA+Pg0KPiA+PkluIGFkZGl0aW9uLCBjb3Vs ZCB3ZSByZWFjaCBjb25zZW5zdXMgb24gc3RoIGxpa2U6DQo+ID4+DQo+ID4+Rm9yQ0VTIGdyb3Vw IGFkZHJlc3NpbmcNCj4gPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gZCkg RkVzIGFuZCBDRXMgTVVTVCBzdXBwb3J0IGdyb3VwIGFkZHJlc3NpbmcgaW4gdGhlIEZvckNFUyBw cm90b2NvbC4NCj4gPj4NCj4gPj5Ob2JvZHkgaXMgZm9yY2VkIHRvIFVTRSBzdWNoIGEgZ3JvdXAg YWRkcmVzc2luZyAob25lIGNhbiBzdGljayB0bw0KPiA+PnVuaWNhc3QgRm9yQ0VTLWFkZHJlc3Np bmcgYW5kIFRDUCB0cmFuc3BvcnQgaW4gYWxsIGNhc2VzKS4gQnV0IGlmIG9uZQ0KPiA+PnNlZXMg dGhhdCBncm91cCBhZGRyZXNzaW5nIGZpdHMgb25lcyBuZWVkcyAoYW5kIG1hbnkgaGF2ZSB2b2lj ZWQgaXQgb24NCj4gPj50aGUgbGlzdCksIHRoZW4gb25lIHNob3VsZCBiZSBhYmxlIHRvIHVzZSBp dC4gVWx0aW1hdGVseSAoYW5kIHRoaXMgaXMNCj4gPj5wcm9iYWJseSBiZXN0IHNvKSwgaXQncyB0 aGUgdXNlciB3cml0aW5nIHNvZnR3YXJlIGluIHRoZSBDRSB3aG8gZGVjaWRlcw0KPiA+PndoYXQg c2hlL2hlIHdhbnRzIHRvIHVzZS4NCj4gPj4NCj4gPj5Ob3RlIHRoYXQgdGhlIHBocmFzaW5nIGlu IGEpLCBiKSwgYyksIGFuZCBkKSBpcyBtZWFudCB0byBzYXRpc2Z5DQo+ID4+aW50ZXJvcGVyYWJp bGl0eS4gTm90IG15IGVnby4NCj4gPj4NCj4gPj5JIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCBh IG51bWJlciBvZiBwYXJ0aWNpcGFudHMgaW4gdGhpcyBXRywNCj4gPj5pbmNsdWRpbmcgb3RoZXIg cHJvdG9jb2wgZHJhZnQgYXV0aG9ycywgdGVuZCB0byBhZ3JlZSBvbiB0aGVzZSBpdGVtcy4NCj4g Pj5XaG8gd291bGQgbm90IGFncmVlIChhbmQgb24gd2hhdCkgPw0KPiA+Pg0KPiA+Pi0tDQo+ID4+ Um9iZXJ0IEhhYXMNCj4gPj5JQk0gWnVyaWNoIFJlc2VhcmNoIExhYm9yYXRvcnkNCj4gPj5T5HVt ZXJzdHJhc3NlIDQNCj4gPj5DSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gPj5waG9u ZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICBodHRwOi8vd3d3Lnp1cmljaC5p Ym0uY29tL35yaGENCj4gPj4gICAgDQo+ID4+DQo+ID4NCj4gPg0KPiA+ICANCj4gPg0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:04:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10155 for ; Tue, 25 Nov 2003 16:04:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkMw-0006Gk-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:05:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOkMv-0006Gg-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:05:09 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C5840F@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:05:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61968702 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:04:59 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:04:58 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAPL5Hao003851 for ; Tue, 25 Nov 2003 21:05:17 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAPKwu426429 for ; Tue, 25 Nov 2003 20:58:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112513045217301 for ; Tue, 25 Nov 2003 13:04:52 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 13:04:52 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol Thread-Index: AcOy+p9TGe2HonjZSiKtT5vEpdrhUgAlgmhg X-OriginalArrivalTime: 25 Nov 2003 21:04:52.0256 (UTC) FILETIME=[C4F88200:01C3B397] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54C97@orsmsx410.jf.intel.com> Date: Tue, 25 Nov 2003 13:04:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Steve, The reason why the requirements are broad is cause we hope the ForCES applicability and deployment will be broad. There are systems that will use ForCES for several dozens or hundreds of FEs, there are also other systems that will use ForCES for say less than 20 FEs. Majority of the systems=20 are of the latter type in the current market, just as majority of the systems are of local scope (rack). On the issue of scalability, there are no. numbers if you notice, it just relates to size of fields in the protocol messages. If you have a 10 bit FE identifier, it satisfies this requirement (1K FEs). On the issue of reliability & timeliness, this was beaten to death by the=20 Requirements Team. (Unfortunately, none of the emails were made public since one of the members objected to repeating the same arguments, which seemed like a valid point at that time. In retrospect, I wish they were made public !) We had received strong feedback from the IESG that our initial reliability=20 requirement was too weak and we should make it stronger cause its very=20 important for any implementation. That's why you see 6 points and atleast one of them clearly states the importance of congestion control in the Multihop scenario. Although, CC was also considered important in the local scope by many members, including the ADs this was arguable and hence not made an explicit req for the local case. As regards timeliness, based on Patrick's email clarifying this to the Requirements team it merely means that a CE should know when a route was successfully downloaded on a FE, (protocol response) and no one argued against that. I don't want to quote Patrick or any of the other members since this was private conversation, however I see that this is being interpreted differently by different people and I know Jamal has very different thoughts on this. If you take timeliness to be a measure of routes/sec, it is very difficult to come up with a number which will satisfy all systems. Atleast for routing protocols, as Joel pointed out this is very relaxed and can easily be in the order of multiple seconds without causing any problems. (This is not to say that it should be in that order or that you cannot obtain hundred thousand routes/sec using unicast) We also received strong feedback from the Security Directorate, but I wont get into that right now :) Hope this helps clarify the requirements, regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake Sent: Monday, November 24, 2003 6:20 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol On Mon, 2003-11-24 at 15:35, Khosravi, Hormuzd M wrote: > Hi Tal > > There is already a ForCES Requirements draft which has been approved for > RFC. > Pls see... > http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx > t > This has a section on protocol requirements. The problem with this draft (IMHO) is that it specifies a very broad range of requirements, and it is not clear that they can all be satisfied simultaneously using the same protocol techniques (which is not to say that they cannot be satisfied using the same protocol, it will however have to be very flexible). Another problem is that there is no prioritization applied to the requirements. Therefore, different individuals prioritize them independently based on their own priorities and product requirements. I personally prioritize scalability and timeliness, and really have no use for the security requirement, because I don't envision having to deploy CE-FE communications over an open network. Other opinions may differ. Regards, =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 Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:17:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11043 for ; Tue, 25 Nov 2003 16:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkYe-0006ay-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:17:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOkYc-0006av-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:17:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00C583F6@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:17:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61969401 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:17:13 -0500 Received: from 209.226.175.52 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:17:08 -0500 Received: from develSPavel ([67.69.27.58]) by tomts8-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031125211636.ZFVM4112.tomts8-srv.bellnexxia.net@develSPavel> for ; Tue, 25 Nov 2003 16:16:36 -0500 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <006e01c3b399$c9996f70$a401a8c0@toronto.chantrynetworks.com> Date: Tue, 25 Nov 2003 16:18:43 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: ForCES transport requirements WAS (Re: Support for multicastintheForCE... To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC39D8F.FFCFE3CD@alcatel.com> Precedence: list Content-Transfer-Encoding: 7bit On a multi-blade NE architectures an FE can be an ingress or egress with respect to the data flow of a routed packet. Typically, the actual route look up is done on the ingress card. This means that every FE has to know about all the routes that are reachable through the other n-1 FEs (where n is the total number of FEs). Assuming a balanced distribution of reachable networks per egress FE, it might not be worth the effort of partitioning the routing table (not mentioning the cost) in order to eliminate only 1/n of the routes, especially if multicast/broadcast is available. Things become a bit more interesting when an actual implementation decides to use the information in the forwarding table on both ingress and egress FEs (I am not going to justify this though). As Patrick mentioned, there is the case of exception (e.g. IP option) processing. The amount of exception traffic could also be considerable; due to deeper packet inspection and more complicate processing rules it might require a lot of processing power. Therefore, there is a tendency in the new core router designs (running tens of interfaces at multigigabit rates) of providing a slow (exception) path processing on a CPU that is tightly coupled to the data path engines on the FE. Although there still going to be exception traffic that can only be processed at CE, this solution reduces considerable the load on the CE and provides a good scalability mechanism. This would be another case (some would consider it an exception!?) where global distribution of the forwarding table would be required. Regards, Sandy -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: November 25, 2003 1:21 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES transport requirements WAS (Re: Support for multicastintheForCE... Yes, the full routing table could be in the CE but not in the FEs. The issue was the time it takes to blast the full routing table to each of the FEs, but I am saying, it doesn't have to be that way. You can take the scalability that ForCES provides and partition the routing tables into smaller sizes that are blasted to the FEs. And of course, that also means that the route partitions are not necessarily the same in all the FEs. This implies you can't blindly multicast routing tables to all the FEs The other issue is the routing table in the CE may not have to be the full table. But that is another research topic. Regards, Alex. Patrick Droz wrote: > [chair hat off] > > yes, I know you can partition the routing table but many routers > don't do that. Also keep in mind that you still have to have the > full routing info at the CE for all the packets that cannot be > handled at the FE (e.g. IP option handling). > > Regards, > Patrick > > Alex Audu wrote: > > > Hi Patrick, > > > > The growth rate of routing table size has been of interest in the research > > community and industry for some time. And research is activly on-going > > at finding ways to contain that growth. See for example: > > > > http://www.antc.uoregon.edu/route-views/dynamics/ > > > > Certainly the routing table gorws as the number of route peers increases. This > > particularly the case with table-driven IP routing where each machine employes > > an IP Routing table that sotre information about possible destinations and how > > to reach them. > > > > Using the network portion of a destination address instead of the complete > > host address makes routing efficient and keeps routing tables small. This is > > the essence of Next-Hop Routing where a routing table table contains (N,R) > > (where N is the Ip address of the destination network and R is the IP address > > of the next router along the path to N. Router R is called the next hop. There > > are various other methods including partitioning the CORE into partial cores > > that reside in separate sites and using default routes to point to the peer site. > > Of course, this results into a routing loops,..and that is not what we are talking > > about here. > > > > I would rather not say anymore about this, but you can certainly partition the > > routing table in an NE into a tree with the root residing in the CE. This is a form > > of hierarchical routing. Sure, it may take longer to resolve certain routes. > > > > See also > > http://www-rp.lip6.fr/~ridoux/Manuel-NS2/node319.html > > http://www.research.att.com/~jrex/papers/filter.pdf > > > > Regards, > > Alex. > > > > Patrick Droz wrote: > > > > > >>[chair hat off] > >> > >>Alex Audu wrote: > >> > >>Hi Alex, > >> > >>see my comments inline. > >> > >> > >>>Hello Patrick, > >>> > >>>Please my comments in-line.. > >>> > >>>Regards, > >>>Alex. > >>> > >>>Patrick Droz wrote: > >>> > >>> > >>> > >>>>[chair hat off] > >>>> > >>>>see comments inline > >>>> > >>>>Alex Audu wrote: > >>>> > >>>> > >>>> > >>>>>Hi All, > >>>>> > >>>>>All this talk about the need and benefits of multicast certainly makes ones > >>>>>feel it is a cure all for what is being termed as the ailment in ForCEs' > >>>>>requirements. > >>>>> > >>>>>Look, it has to be told that you can't do multicast on the cheap. And > >>>>>you have > >>>>>to answer some key questions if you really want to sell multicast in a > >>>>>critical > >>>>>environment,..viz: > >>>>> > >>>>>1) How would you guarrantee the relaible delivery of the messages being > >>>>> blasted to all the targets? What if the messages don't arrive at all > >>>>>their > >>>>> intended targets? How do you recover from this? This suggests you need > >>>>> a reliable multicast mechanism. I am not sure you can do this over UDP > >>>>> as it is currently being done in NetLink2. That is only good for > >>>>>un-reliable > >>>>> multicast. I am not sure if you can trust critical configuration > >>>>>messages > >>>>> like routing table information or basic LFB service/tree structure > >>>>>messages > >>>>> over such an unreliable mechanism. > >>>>> > >>>>>2) How do you deal with the issue of security, given that we don't have > >>>>>secure > >>>>> multicast yet? I have seen some people call for broadcast > >>>>>capability also. > >>>>> One result of multicast/broadcast is you run the risk of a > >>>>>potential attacker > >>>>> listening in on say, the routing information being blasted to the > >>>>>FEs. I don't > >>>>> think multicasting over UDP has an answer to this. > >>>>> > >>>>> > >>>>>There is also this myth that all the FEs will have the same routing > >>>>>information > >>>> > >>>>could you please provide some evidence of this? Keep in mind we are > >>>>moving from a centralized (single routing table) to a distributed > >>>>router architecture. Why should it change that the routing table > >>>>should be much different. Or do you want to go into the discussion > >>>>of how you avoid routing loops? > >>>> > >>> > >>> > >>>One of the benefits of distributing the NE is the ability to handle many more > >>>routes,..many more than the current core routers are capable of. Route > >>>table sizes start becoming a problem at that scale. Storing partial routes > >>>in a logically hierarchical distributed entities can help. Of course, you have > >>>to assign the default routes appropriately to prevent routing loops. > >>> > >> > >>can you proof this statement? For what reason do you need such big > >>routing tables. I have not see much growth of routing table sizes. > >>A distributed router has to provide forwarding an classification > >>performance. I have a hard time that you have to distribute a router > >>because of the forwarding table size. Overall you need exactly the > >>same amount of memory. Why should a packet coming in on port A and > >>heading for DA X being routed differently than a packet arriving on > >>port B and also heading to DA X? > >> > >>Regards, > >>Patrick > >> > >> > >>>>>always. I submit that this is not true. One of the problems ForCEs is > >>>>>meant to > >>>>>solve is scalability. This certainly relates to the abilty to manage the > >>>>>rapid > >>>>>growth of routing table sizes by distributing the routing information as > >>>>>partial > >>>>>routes into various FE groups. Granted there is still some scaling issues > >>>>>here,..but is definitely not as bad as people have been making it to be. > >>>>> > >>>>> ..more comments in-line... > >>>>> > >>>>>Regards, > >>>>>Alex. > >>>> > >>>>Regards, > >>>>Patrick > >>>> > >>>> > >>>> > >>>>>In a message dated 11/22/2003 12:03:24 PM Central Standard Time, > >>>>>hadi@znyx.com writes: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Continuation of the last thread with a change in topic - i think these > >>>>>>are the real issues that need to be addressed instead of the distraction > >>>>>>to "multicast is evil". > >>>>>> > >>>>>>Lets really list the requirements needed for a successful underlying > >>>>>>transport protocol that will serve ForCES well. i may be > >>>>>>missing some - but i hope to get challenged so i can add to them; > >>>>>>I am thinking of turning this into a draft so people read it first and > >>>>>>then post. > >>>>>>My previous email has some more claims which i will assume here. > >>>>>> > >>>>>>I. ForCES mechanisms requiring reliability: > >>>>>> > >>>>>>a) time limit very sensitive (in other words obsolence period is > >>>>>>faster): > >>>>>>Example table updates; > >>>>>>I have argued TCP doesnt qualify in my previous email. SCTP-PR may > >>>>>>qualify. > >>>>>>Something like what netlink2 over UDP qualifies because it gives control > >>>>>>to netlink2 to make such decisions. > >>>>> > >>>>> > >>>>> > >>>>>How can you have reliable communcation over UDP? > >>>>> > >>>>> > >>>>> > >>>>>>b) time limit best effort (obsolence takes longer) > >>>>>>Sample apps: File transfers,etc. > >>>>>>TCP qualifies but AFAIK, we dont have this need. > >>>>>> > >>>>>>II. mechanisms capable of tolerating unreliability: Example psamp. > >>>>>>TCP doesnt qualify. > >>>>>>something(like netlink2) over UDP or SCTP-PR. > >>>>> > >>>>> > >>>>> > >>>>>Why do you say TCP doesn't qualify here? Any application that can live > >>>>>with un-reliable transport can sure do better with a relaible one. > >>>>> > >>>>> > >>>>> > >>>>>>III. mechanisms that prefer timeliness over reliability: Ex heartbeats > >>>>>>something (like netlink2) over UDP or SCTP-PR. > >>>>>> > >>>>>>Clearly in the bigger picture TCP is not the best protocol. > >>>>>>UDP and SCTP-PR qualify partially merely because they dont hinder > >>>>>>progress not because they have some magic. Another non-IETF protocol > >>>>>>that would qualify is TIPC. I havent carefully studied DCCP but i > >>>>>>believe it also has a fit. I will exclude it because its not there yet. > >>>>>> > >>>>>>So, to summarize: the transport protocol that meets all the requirements > >>>>>>For Forces has not been born. > >>>>>> > >>>>>>Choosing TCP is choosing an answer and then trying to justify the > >>>>>>questions that it brings. It does sound like peer pressure instead of > >>>>>>looking at requirements and then deciding what you need to do. > >>>>>>I think we recognized this in netlink2 and made it clear that the choice > >>>>>>of underlying protocol chosen is up to the pre-association phase. > >>>>>>We compensate for "missing features" depending on the transport choice > >>>>>>(read the draft). > >>>>>>It's very few lines of code to provide that luxury. So the cost is low. > >>>>>> > >>>>>>Now on the choice of netlink2 UDP vs SCTP-PR > >>>>>> > >>>>>>1) UDP is here today. SCTP-PR is not. When SCTP-PR becomes available > >>>>>>Netlink2 can run over it. For now we choose to be standalone: We can run > >>>>>>over IP, over UDP or over ethernet, you take your pick. > >>>>> > >>>>> > >>>>> > >>>>>I believe SCTP-PR is now in IESG queue. Even when it is available, you have > >>>>>to run it in a reliable mode to guarantee that those critical configuration > >>>>>messages get to their destination safely. And it still doesn't buy you > >>>>>security. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>2) UDP provides multicast (and broadcast). SCTP-PR does not. > >>>>>>Since SCTP has turned to be a swiss knife (or maybe a multi faceted > >>>>>>beast), i am sure it will soon as well support multicast;-> > >>>>>> > >>>>>>If multicast is there - we will use it. Sans that we will do something > >>>>>>multicast like (Jon calls it unireplicate i think). > >>>>>>All the three cauthors have had pleasant experiences using multicast for > >>>>>>ForCES like. We think it is a good thing to have. But we will not > >>>>>>torture you if you dont have multicast or broadcast ;-> > >>>>>> > >>>>>>Why Multicast is useful: > >>>>>>-- > >>>>>>I must apologize since i have to repeat this. > >>>>>>In the simple case of a single multicast wire: each of the CEs or FEs > >>>>>>opens a single multicast socket/channel. > >>>>>> > >>>>>>Why is this good: > >>>>>> > >>>>>>1) Bandwidth is less used > >>>>>>a)because one or more CEs can send a single message to all FEs. > >>>>>>I really dont want to be teaching people the hows but i will provide one > >>>>>>example which David or maybe it was Joel didnt seem to make sense out of > >>>>>>(but one that i have successfuly used)[1] > >>>>>>b) you can reduce the number of packets further by limiting on > >>>>>>ACKs (partial acks) > >>>>>> > >>>>>>2) RAM on the embedded CE or FE is used less. There are less sockets > >>>>>>open and less messages being built > >>>>>> > >>>>>>3) CPU is preserved more. > >>>>>>Since there are fewer messages to process and fewer (socket states) > >>>>>>states to track. > >>>>> > >>>>> > >>>>> > >>>>>As far as I am concerned, the more critical resource CPU-wise is FE. The > >>>>>mutlicast scheme Netlink2 proposes blasts all every packet to every FE. > >>>>>Each FE has to do work to filter out which packet doesn't belong to it. > >>>>>Thus, > >>>>>the FE spends a lot of CPU cycles filtering off unwanted packets,..cycles > >>>>>that should be best used in forwarding packets. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>4) The ability for all listeners on the wire to see message exchanges > >>>>>>even when not directed at them provides a cheap way to synchronize. > >>>>> > >>>>> > >>>>> > >>>>>And of course, if this is a malicious node, it will gladly gleam as much > >>>>>information > >>>>>as is enough to mount an attack. This is why secure multicast is necessary. > >>>>> > >>>>> > >>>>> > >>>>>>5) At a transport level, (not the forces transaction level), having > >>>>>>access to multicast provides location transparency. > >>>>>> > >>>>>>6) A lot of switch fabrics (shared memory designs or otherwise) > >>>>>>interconnecting FEs and CES have multicast capabilities; so it is good > >>>>>>if we can take advantage of it where possible. > >>>>>> > >>>>>>The above is the simple case, by induction you could extend the > >>>>>>reasoning to the case where you have X sockets. > >>>>>> > >>>>>>I dont want to preach multicast as panacea; we address some of the > >>>>>>limitations in the draft; however, i want it to be available when i need > >>>>>>it and not shoved down the toilet. > >>>>>> > >>>>>>So far apart from Joel (who implemented on ATM) on real boxes and Ram > >>>>>>(who did something very specific that needs unicast) the rest of the > >>>>>>arguements i have seen are from people who see the need for this > >>>>>>feature. You can choose to ignore it - and you may be influenced by some > >>>>>>implementation you are familiar with - thats your loss. I do think TCP > >>>>>>is valid for some cases (low latency and congestion), but i wouldnt > >>>>>>claim it to be the answer weve all been waiting for. > >>>>>>Again let me reiterate that Netlink2 does not need to have multicast (it > >>>>>>is a MAY) but would love to have it when it is available. We can run on > >>>>>>your favorite protocol TCP ;-> > >>>>>> > >>>>>>cheers, > >>>>>>jamal > >>>>>> > >>>>>>[1] I will give the example in another email - this one is already > >>>>>>getting too long. > >>>>> > >>>>> > >>>>> > >>>>-- > >>>> Dr. Patrick Droz | dro@zurich.ibm.com > >>>> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > >>>> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > >>>> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > >>> > >>> > >>> > >>-- > >> Dr. Patrick Droz | dro@zurich.ibm.com > >> IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > >> Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > >> Rueschlikon/Switzerland | Fax. +41-1-724-85-78 > > > > > > > > -- > Dr. Patrick Droz | dro@zurich.ibm.com > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 > Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:17:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11059 for ; Tue, 25 Nov 2003 16:17:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkYy-0006bB-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:17:36 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOkYx-0006b8-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:17:35 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00C58690@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:17:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61969438 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:17:34 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:17:30 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPLHTLS009247 for ; Tue, 25 Nov 2003 15:17:29 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds951.usa.alcatel.com id hAPLHTLS009247 Approved-By: Alex Audu Message-ID: <3FC3C6E7.42CBB074@alcatel.com> Date: Tue, 25 Nov 2003 15:17:28 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Robert, I think what your suggestions smell like protocol requirements. However, = you can find answers/guidance to these suggestions/questions in the requirem= ents document. See the following: 6)Reliability a) The ForCES protocol will be used to transport information that requires varying levels of reliability. By strict or robust reliability in this requirement we mean, no losses, no corruption, no re-ordering of information being transported and delivery in a timely fashion. b) Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some degree of losses). For information of this sort, ForCES MUST NOT be restricted to strict reliability. c) Payloads such as configuration information, e.g. ACLs, FIB entries, or FE capability information (described in section 7, (1)) are mission critical and must be delivered in a robust reliable fashion. Thus, for information of this sort, ForCES MUST either provide built-in protocol mechanisms or use a reliable transport protocol for achieving robust/strict reliability. d) Some information or payloads, such as heartbeat packets that may be used to detect loss of association between CE and FEs (see section 7, (8)), may prefer timeliness over reliable delivery. For information of this sort, ForCES MUST NOT be restricted to strict reliability. e) When ForCES is carried over multi-hop IP networks, it is a requirement that ForCES MUST use a [RFC2914]-compliant transport protocol. f) In cases where ForCES is not running over an IP network such as an Ethernet or cell fabric between CE and FE, then reliability still MUST be provided when carrying critical information of the types specified in (c) above, either by the underlying link/network/ transport layers or by built-in protocol mechanisms. 7)Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 5, requirement# 1) Regards, Alex. Robert Haas wrote: > Alex, > You should not view what I sent as protocol requirements, rather as > actual answers to the requirements. I am fully OK with the draft > requirements, but this does not make us progress much. What's your > answer in that case ? > > -Robert > > Alex Audu wrote: > > >All the agreed upon must-have features of ForCES have been documented > >in the requiremnents document. So, why make a new set of requirements = at > >this stage? > > > >Regards, > >Alex. > > > >Robert Haas wrote: > > > > > > > >>In order to reach a consensus before we are exhausted posting on the > >>list, let me cristallize what could help unlock the situation. > >> > >>I presume we should be able to reach consensus on sth like (remains t= o > >>be defined in more detail): > >> > >>ForCES transport > >>--------------------- > >> a) An FE MUST support UDP (or raw media encapsulation) as ForCES > >>transport if the FE is targeted at the local scope env. > >> b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is > >>targeted at the global scope environment. > >> c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) a= s > >>ForCES transport if the FE is targeted at both local and global scope= s. > >> (the same applies for the CE) > >> > >>FEs/CEs that support TCP will support UDP as well (I have never seen = an > >>IP stack that offers TCP without UDP). Note that this does not preven= t > >>from using TCP in the local scope if the FEs and CEs support it. Thus > >>TCP-proponents should be satisfied. > >> > >>In addition, could we reach consensus on sth like: > >> > >>ForCES group addressing > >>------------------------------ > >> d) FEs and CEs MUST support group addressing in the ForCES protocol. > >> > >>Nobody is forced to USE such a group addressing (one can stick to > >>unicast ForCES-addressing and TCP transport in all cases). But if one > >>sees that group addressing fits ones needs (and many have voiced it o= n > >>the list), then one should be able to use it. Ultimately (and this is > >>probably best so), it's the user writing software in the CE who decid= es > >>what she/he wants to use. > >> > >>Note that the phrasing in a), b), c), and d) is meant to satisfy > >>interoperability. Not my ego. > >> > >>I have the impression that a number of participants in this WG, > >>including other protocol draft authors, tend to agree on these items. > >>Who would not agree (and on what) ? > >> > >>-- > >>Robert Haas > >>IBM Zurich Research Laboratory > >>S=E4umerstrasse 4 > >>CH-8803 R=FCschlikon/Switzerland > >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~= rha > >> > >> > > > > > > > > > > -- > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:30:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11689 for ; Tue, 25 Nov 2003 16:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkm1-0006sO-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:31:05 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOkm0-0006sK-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:31:05 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00C585CE@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:30:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61970485 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:30:56 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:30:51 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPLUoLS011118 for ; Tue, 25 Nov 2003 15:30:50 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <1069792162.1032.581.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds951.usa.alcatel.com id hAPLUoLS011118 Approved-By: Alex Audu Message-ID: <3FC3CA09.766203DA@alcatel.com> Date: Tue, 25 Nov 2003 15:30:49 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable You can use any CE/FE interconnect. But for any of your solution, you MUST explain how you achieve reliability and security to meet the requirements. Regards, Alex. Jamal Hadi Salim wrote: > Since you invoke the requirements and charter at every opportunity, > let me remind you your favorite section, on reliability, apologies to > other people, so which part rejects having both UDP and TCP? > > --------------- > 6)Reliability > a) The ForCES protocol will be used to transport information that > requires varying levels of reliability. By strict or robust > reliability in this requirement we mean, no losses, no corruption, > no re-ordering of information being transported and delivery in a > timely fashion. > b) Some information or payloads, such as redirected packets or packe= t > sampling, may not require robust reliability (can tolerate some > degree of losses). For information of this sort, ForCES MUST NOT > be restricted to strict reliability. > c) Payloads such as configuration information, e.g. ACLs, FIB > entries, or FE capability information (described in section 7, > (1)) are mission critical and must be delivered in a robust > reliable fashion. Thus, for information of this sort, ForCES MUST > either provide built-in protocol mechanisms or use a reliable > transport protocol for achieving robust/strict reliability. > d) Some information or payloads, such as heartbeat packets that may > be used to detect loss of association between CE and FEs (see > section 7, (8)), may prefer timeliness over reliable delivery. For > information of this sort, ForCES MUST NOT be restricted to strict > reliability. > e) When ForCES is carried over multi-hop IP networks, it is a > requirement that ForCES MUST use a [RFC2914]-compliant transport > protocol. > f) In cases where ForCES is not running over an IP network such as a= n > Ethernet or cell fabric between CE and FE, then reliability still > MUST be provided when carrying critical information of the types > specified in (c) above, either by the underlying link/network/ > transport layers or by built-in protocol mechanisms. > --------------------------------- > > cheers, > jamal > > On Tue, 2003-11-25 at 14:52, Alex Audu wrote: > > All the agreed upon must-have features of ForCES have been documented > > in the requiremnents document. So, why make a new set of requirements= at > > this stage? > > > > Regards, > > Alex. > > > > Robert Haas wrote: > > > > > In order to reach a consensus before we are exhausted posting on th= e > > > list, let me cristallize what could help unlock the situation. > > > > > > I presume we should be able to reach consensus on sth like (remains= to > > > be defined in more detail): > > > > > > ForCES transport > > > --------------------- > > > a) An FE MUST support UDP (or raw media encapsulation) as ForCES > > > transport if the FE is targeted at the local scope env. > > > b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE = is > > > targeted at the global scope environment. > > > c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.)= as > > > ForCES transport if the FE is targeted at both local and global sco= pes. > > > (the same applies for the CE) > > > > > > FEs/CEs that support TCP will support UDP as well (I have never see= n an > > > IP stack that offers TCP without UDP). Note that this does not prev= ent > > > from using TCP in the local scope if the FEs and CEs support it. Th= us > > > TCP-proponents should be satisfied. > > > > > > In addition, could we reach consensus on sth like: > > > > > > ForCES group addressing > > > ------------------------------ > > > d) FEs and CEs MUST support group addressing in the ForCES protoco= l. > > > > > > Nobody is forced to USE such a group addressing (one can stick to > > > unicast ForCES-addressing and TCP transport in all cases). But if o= ne > > > sees that group addressing fits ones needs (and many have voiced it= on > > > the list), then one should be able to use it. Ultimately (and this = is > > > probably best so), it's the user writing software in the CE who dec= ides > > > what she/he wants to use. > > > > > > Note that the phrasing in a), b), c), and d) is meant to satisfy > > > interoperability. Not my ego. > > > > > > I have the impression that a number of participants in this WG, > > > including other protocol draft authors, tend to agree on these item= s. > > > Who would not agree (and on what) ? > > > > > > -- > > > Robert Haas > > > IBM Zurich Research Laboratory > > > S=E4umerstrasse 4 > > > CH-8803 R=FCschlikon/Switzerland > > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com= /~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:40:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12269 for ; Tue, 25 Nov 2003 16:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkv2-00079Q-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:40:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOkv1-00079N-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:40:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C5850D@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:40:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61971548 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:40:23 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:40:18 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPLeHcb021474 for ; Tue, 25 Nov 2003 15:40:17 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds953.usa.alcatel.com id hAPLeHcb021474 Approved-By: Alex Audu Message-ID: <3FC3CC3F.E431D3BA@alcatel.com> Date: Tue, 25 Nov 2003 15:40:16 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Jamal, This is a strange way of solving problems. Definitely the ForCES requirements predate any protocols being proposed to satisfy the said requirements. At least, that is what should take place. What I think you are proposing is a problem definition to fit the solution you have provided. This is quite interesting, and I don't think it is the bes= t problem solving approach. Sometimes this approach works, but often times, it doesn't. I believe this is one of those times it fails. Regards, Alex. Jamal Hadi Salim wrote: > I think we should pull this conversation to the IESG so we can pull bac= k > the requirements draft because obviously it doesnt meet the requirement= s > that most people need. This is precisely what i was worried about when > you have Hormuzd editing the draft and trying to be a lawyer at the sam= e > time. > > Do you know how i can do that? > > cheers, > jamal > > On Tue, 2003-11-25 at 15:03, Robert Haas wrote: > > Alex, > > You should not view what I sent as protocol requirements, rather as > > actual answers to the requirements. I am fully OK with the draft > > requirements, but this does not make us progress much. What's your > > answer in that case ? > > > > -Robert > > > > Alex Audu wrote: > > > > >All the agreed upon must-have features of ForCES have been documente= d > > >in the requiremnents document. So, why make a new set of requirement= s at > > >this stage? > > > > > >Regards, > > >Alex. > > > > > >Robert Haas wrote: > > > > > > > > > > > >>In order to reach a consensus before we are exhausted posting on th= e > > >>list, let me cristallize what could help unlock the situation. > > >> > > >>I presume we should be able to reach consensus on sth like (remains= to > > >>be defined in more detail): > > >> > > >>ForCES transport > > >>--------------------- > > >> a) An FE MUST support UDP (or raw media encapsulation) as ForCES > > >>transport if the FE is targeted at the local scope env. > > >> b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE = is > > >>targeted at the global scope environment. > > >> c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.)= as > > >>ForCES transport if the FE is targeted at both local and global sco= pes. > > >> (the same applies for the CE) > > >> > > >>FEs/CEs that support TCP will support UDP as well (I have never see= n an > > >>IP stack that offers TCP without UDP). Note that this does not prev= ent > > >>from using TCP in the local scope if the FEs and CEs support it. Th= us > > >>TCP-proponents should be satisfied. > > >> > > >>In addition, could we reach consensus on sth like: > > >> > > >>ForCES group addressing > > >>------------------------------ > > >> d) FEs and CEs MUST support group addressing in the ForCES protoco= l. > > >> > > >>Nobody is forced to USE such a group addressing (one can stick to > > >>unicast ForCES-addressing and TCP transport in all cases). But if o= ne > > >>sees that group addressing fits ones needs (and many have voiced it= on > > >>the list), then one should be able to use it. Ultimately (and this = is > > >>probably best so), it's the user writing software in the CE who dec= ides > > >>what she/he wants to use. > > >> > > >>Note that the phrasing in a), b), c), and d) is meant to satisfy > > >>interoperability. Not my ego. > > >> > > >>I have the impression that a number of participants in this WG, > > >>including other protocol draft authors, tend to agree on these item= s. > > >>Who would not agree (and on what) ? > > >> > > >>-- > > >>Robert Haas > > >>IBM Zurich Research Laboratory > > >>S=E4umerstrasse 4 > > >>CH-8803 R=FCschlikon/Switzerland > > >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com= /~rha > > >> > > >> > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 16:59:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13076 for ; Tue, 25 Nov 2003 16:59:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlDo-0007d9-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:59:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOlDo-0007d6-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 16:59:48 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C586DC@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 16:59:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61972603 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 16:59:47 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 16:59:47 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112513585604:9591 ; Tue, 25 Nov 2003 13:58:56 -0800 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> <3FC3CC3F.E431D3BA@alcatel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 01:58:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 01:58:57 PM, Serialize complete at 11/25/2003 01:58:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069797584.1029.689.camel@jzny.localdomain> Date: Tue, 25 Nov 2003 16:59:44 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3CC3F.E431D3BA@alcatel.com> Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2003-11-25 at 16:40, Alex Audu wrote: > Hi Jamal, > > This is a strange way of solving problems. Definitely the ForCES > requirements predate any protocols being proposed to satisfy the > said requirements. At least, that is what should take place. I wouldnt say that was the case - and i think it this is the cause of all this pain we are going through. FACT was released much earlier on before the requirements draft was complete. A few months later, netlink2 followed. What i remember is netlink2 came out at the end. > What I > think you are proposing is a problem definition to fit the solution you > have provided. This is quite interesting, and I don't think it is the best > problem solving approach. Sometimes this approach works, but often times, > it doesn't. I believe this is one of those times it fails. The requirements were not collected then a proposal made. So i dont know what you mean by "this is one of the times it fails". Rather there was a proposal and requirements were spun around it. I am sure if i wasnt around the requirements would have read "FACT". I apologize for being so cynical - i am tired of these circular discusions. We obviously see a need for multicast and you dont - what baffles me is what scares you so much you want to kill it? If it is as bad as you claim - what is there to fear? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 17:56:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15526 for ; Tue, 25 Nov 2003 17:56:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOm71-0001ND-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 17:56:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOm70-0001NA-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 17:56:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00C587BC@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 17:56:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61979841 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 17:56:49 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 17:56:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAPMumLS023707 for ; Tue, 25 Nov 2003 16:56:48 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> <3FC3CC3F.E431D3BA@alcatel.com> <1069797584.1029.689.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC3DE2F.FC9C56DF@alcatel.com> Date: Tue, 25 Nov 2003 16:56:47 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Jamal, No one is proposing that any thing be "killed". And no one has written on this list (at least to my knowledge) that multicasting is a bad thing. Far from it. What I understand from the concerns raised is:."OK, explain how you intend to propose multicasting over UDP in the ForCES environment and yet meet all the critical requirements of ForCES (like reliability and security)". I don't think the solution to that is to go change the requirements. I mean, that process has long passed! Regards, Alex. Jamal Hadi Salim wrote: > On Tue, 2003-11-25 at 16:40, Alex Audu wrote: > > Hi Jamal, > > > > This is a strange way of solving problems. Definitely the ForCES > > requirements predate any protocols being proposed to satisfy the > > said requirements. At least, that is what should take place. > > I wouldnt say that was the case - and i think it this is the cause > of all this pain we are going through. FACT was released much earlier on > before the requirements draft was complete. A few months later, netlink2 > followed. What i remember is netlink2 came out at the end. > > > What I > > think you are proposing is a problem definition to fit the solution you > > have provided. This is quite interesting, and I don't think it is the best > > problem solving approach. Sometimes this approach works, but often times, > > it doesn't. I believe this is one of those times it fails. > > The requirements were not collected then a proposal made. > So i dont know what you mean by "this is one of the times it fails". > Rather there was a proposal and requirements were spun around it. > I am sure if i wasnt around the requirements would have read "FACT". > > I apologize for being so cynical - i am tired of these circular > discusions. We obviously see a need for multicast and you dont - what > baffles me is what scares you so much you want to kill it? > If it is as bad as you claim - what is there to fear? > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 19:06:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19012 for ; Tue, 25 Nov 2003 19:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOnCo-0002xJ-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 19:06:54 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOnCn-0002xF-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 19:06:53 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00C58841@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 19:06:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 61986241 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 19:06:51 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 19:06:50 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAQ07Dao013863 for ; Wed, 26 Nov 2003 00:07:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAQ00q424592 for ; Wed, 26 Nov 2003 00:00:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112516064819847 for ; Tue, 25 Nov 2003 16:06:48 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 16:06:49 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: towards consensus: ForCES transport and group addressing Thread-Index: AcOzbrs/XBhor1mrTg6rkGPtydWjWgAPlEDw X-OriginalArrivalTime: 26 Nov 2003 00:06:49.0000 (UTC) FILETIME=[2FDB7280:01C3B3B1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190B55@orsmsx410.jf.intel.com> Date: Tue, 25 Nov 2003 16:06:48 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable The only real use for UDP without other protocol mechanisms is for those = messages that don't require strict reliability. Given that, it seems of = little value to make UDP a requirement on the FE unless the additional = protocol mechanisms which make UDP reliable also become a requirement, = which would probably be unattractive to FE vendors.=20 The problem with this is that FEs probably have less CPU capacity than = the CE and adding another layer of protocol to the FEs to implement this = reliability could detract from the FE's ability to process packets. By = requiring support for multicast over UDP, the tradeoff is potentially = saving some CPU cycles on the CE, but consuming more cycles on the FE by = requiring additional protocol processing to provide the reliability = levels required (or should be) for configuration messages. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Tuesday, November 25, 2003 8:11 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: towards consensus: ForCES transport and group addressing In order to reach a consensus before we are exhausted posting on the=20 list, let me cristallize what could help unlock the situation. I presume we should be able to reach consensus on sth like (remains to=20 be defined in more detail): ForCES transport --------------------- a) An FE MUST support UDP (or raw media encapsulation) as ForCES=20 transport if the FE is targeted at the local scope env. b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 targeted at the global scope environment. c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 ForCES transport if the FE is targeted at both local and global scopes. (the same applies for the CE) FEs/CEs that support TCP will support UDP as well (I have never seen an=20 IP stack that offers TCP without UDP). Note that this does not prevent=20 from using TCP in the local scope if the FEs and CEs support it. Thus=20 TCP-proponents should be satisfied. In addition, could we reach consensus on sth like: ForCES group addressing ------------------------------ d) FEs and CEs MUST support group addressing in the ForCES protocol. Nobody is forced to USE such a group addressing (one can stick to=20 unicast ForCES-addressing and TCP transport in all cases). But if one=20 sees that group addressing fits ones needs (and many have voiced it on=20 the list), then one should be able to use it. Ultimately (and this is=20 probably best so), it's the user writing software in the CE who decides=20 what she/he wants to use. Note that the phrasing in a), b), c), and d) is meant to satisfy=20 interoperability. Not my ego. I have the impression that a number of participants in this WG,=20 including other protocol draft authors, tend to agree on these items.=20 Who would not agree (and on what) ? --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Nov 25 23:10:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23938 for ; Tue, 25 Nov 2003 23:10:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOr1D-0005xq-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 23:11:11 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOr1C-0005xm-00 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 23:11:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by manatick with esmtp (Exim 4.24) id 1AOr1E-0007i5-H5 for forces-archive@IETF.ORG; Tue, 25 Nov 2003 23:11:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C58C2A@cherry.ease.lsoft.com>; Tue, 25 Nov 2003 22:35:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62004539 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Nov 2003 22:35:51 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Nov 2003 22:35:51 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112519345979:9906 ; Tue, 25 Nov 2003 19:34:59 -0800 References: <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> <3FC3CC3F.E431D3BA@alcatel.com> <1069797584.1029.689.camel@jzny.localdomain> <3FC3DE2F.FC9C56DF@alcatel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 07:35:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/25/2003 07:35:01 PM, Serialize complete at 11/25/2003 07:35:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069817748.1083.26.camel@jzny.localdomain> Date: Tue, 25 Nov 2003 22:35:48 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3FC3DE2F.FC9C56DF@alcatel.com> Precedence: list Content-Transfer-Encoding: 7bit So, Alex ... if we showed you how to do that are you gonna stop these circular arguements or will you be looking for something new? ;-> [Reminds me of a canadian politician who once stood in parliament waving a piece of paper saying that the paper had proof the internet had porn. This was back in the very early 90s - porn, huh? It happens that porn was a great contributor to internet growth and technology. Unfortunately through the wonders of democracy the guy ended up getting elected as premier of ontario]. I guess the moral of the tale is: I am now pretty sure noone arguing against multicast has actually understood the scope of the problem. I will give you a hint: the tree has a depth of one (ttl == 1). Multicast packets dont cross routers. Draw yourself a diagram; a line to represent the physical wire then attach nodes(CEs/FEs) to it. Now investigate this problem for reliability, congestion control and come back with a list of protocols that handle this scope _very well_. Dont bother going to the RMT WG. They talk about multicast packets crossing routers there mostly. Ask google - she will list plenty for you; just pick one you like. cheers, jamal On Tue, 2003-11-25 at 17:56, Alex Audu wrote: > Hi Jamal, > > No one is proposing that any thing be "killed". And no one has written on > this list (at least to my knowledge) that multicasting is a bad thing. Far from > it. What I understand from the concerns raised is:."OK, explain how you > intend to propose multicasting over UDP in the ForCES environment and > yet meet all the critical requirements of ForCES (like reliability and > security)". > > I don't think the solution to that is to go change the requirements. I mean, > that > process has long passed! > > Regards, > Alex. > > Jamal Hadi Salim wrote: > > > On Tue, 2003-11-25 at 16:40, Alex Audu wrote: > > > Hi Jamal, > > > > > > This is a strange way of solving problems. Definitely the ForCES > > > requirements predate any protocols being proposed to satisfy the > > > said requirements. At least, that is what should take place. > > > > I wouldnt say that was the case - and i think it this is the cause > > of all this pain we are going through. FACT was released much earlier on > > before the requirements draft was complete. A few months later, netlink2 > > followed. What i remember is netlink2 came out at the end. > > > > > What I > > > think you are proposing is a problem definition to fit the solution you > > > have provided. This is quite interesting, and I don't think it is the best > > > problem solving approach. Sometimes this approach works, but often times, > > > it doesn't. I believe this is one of those times it fails. > > > > The requirements were not collected then a proposal made. > > So i dont know what you mean by "this is one of the times it fails". > > Rather there was a proposal and requirements were spun around it. > > I am sure if i wasnt around the requirements would have read "FACT". > > > > I apologize for being so cynical - i am tired of these circular > > discusions. We obviously see a need for multicast and you dont - what > > baffles me is what scares you so much you want to kill it? > > If it is as bad as you claim - what is there to fear? > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 06:38:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02970 for ; Wed, 26 Nov 2003 06:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOy0L-00041K-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 06:38:45 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AOy0K-00041H-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 06:38:44 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00C596E8@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 6:38:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62060654 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 06:38:44 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 06:38:44 -0500 Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOy0J-0006oU-8a for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 11:38:43 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Approved-By: avri Message-ID: <082D5732-2005-11D8-A38A-000393CC2112@psg.com> Date: Wed, 26 Nov 2003 20:38:19 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069817748.1083.26.camel@jzny.localdomain> Precedence: list Content-Transfer-Encoding: 7bit hi, I just came back from a bit of vacation and had the pleasure of reading through the many messages that compose the multicast thread. Made for an exciting couple of hours on a dreary day. Though the thread baffles me. - it is as if 2 of the 3 contending protocols are fighting for supremacy on the subject of multicast support. With 3 protocols in contention it is difficult to understand the positioning and posturing. - I do not understand in what way multicast support is a criteria for choosing a protocol. As I understand the requirements it is neither required not precluded by the requirements. From the arguments it seems like there may be cases where it comes in useful, though there seem to be issues that need to be resolved in other cases. As one of those who is not committed to any of the protocols, I don't see it as a necessary criteria for choosing and believe that it should be optional whether a protocol uses multicast as long as it meets the other requirements. In many ways it seems as though it may be more of an implementation issue then a protocol selection criteria. a. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 09:31:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08010 for ; Wed, 26 Nov 2003 09:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0hl-0006GQ-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 09:31:45 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP0hl-0006Fg-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 09:31:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00C598E6@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 9:31:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62069649 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 09:31:43 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 09:31:43 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5893701 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 09:31:42 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <3FC3DE2F.FC9C56DF@alcatel.com> <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> <3FC3CC3F.E431D3BA@alcatel.com> <1069797584.1029.689.camel@jzny.localdomain> <3FC3DE2F.FC9C56DF@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20031126092708.0196aab0@localhost> Date: Wed, 26 Nov 2003 09:31:36 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1069817748.1083.26.camel@jzny.localdomain> Precedence: list There are two dimensions that I see still needing attention: 1) Even with only one "hop", reliability, congestion control, flow control, and security still need to be addressed. I might agree that for in-box the last may be skipped. The rest apply anyway. (The reason many existing backplane mechanisms do not worry about such things is that the relationship between the control processor, the control load, the backplane capacity, and the forwarding blade capacity are carefully engineered. That can not be assumed in a standard for use in mixed-vendor environments.) 2) Based on experience in multiple working groups, work aimed at one limitted scope tends to get applied to other scopes. I suppose that one could try to put in mechanisms to actually control the scope that can be applied. But that is quite complex in its own right. Yours, Joel M. Halpern At 10:35 PM 11/25/2003 -0500, you wrote: >Now >investigate this problem for reliability, congestion control and come >back with a list of protocols that handle this scope _very well_. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 10:04:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09575 for ; Wed, 26 Nov 2003 10:04:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Dq-0006mC-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 10:04:54 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Dp-0006m8-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 10:04:53 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00C5984C@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 10:04:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62071129 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 10:04:46 -0500 Received: from 209.226.175.111 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 10:04:46 -0500 Received: from develSPavel ([67.69.27.58]) by tomts44-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031126150442.JHHY29580.tomts44-srv.bellnexxia.net@develSPavel> for ; Wed, 26 Nov 2003 10:04:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Approved-By: Sandy Pavel Message-ID: <000501c3b42e$f00fabc0$a401a8c0@toronto.chantrynetworks.com> Date: Wed, 26 Nov 2003 10:06:56 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Sandy Pavel Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B55@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: quoted-printable If I understand well your message here is: use only TCP because it has built in reliability and don't use UDP because building reliability on top of UDP would take too many cycles from the FE CPU. There are a few problems with this: - the TCP reliability does not come for free. Both CE and FE CPUs have to spend cycles on it. - no matter how one would turn the problem, communication reliability can only be insured with some sort of feedback. - does not make much difference, in terms of number of CPU cycles, where they are spent: at the transport protocol level or at the application level. Therefore your arguments do not hold at all. TCP has the advantage of allowing for a simpler application programming paradigm (including maybe simpler protocol state machines). But we should not forget that TCP does not behave very well in a congested network ( the backoff mechanism will reduce the amount of TCP traffic favouring the other traffic). All this imposes more restrictive requirements on the actual traffic management for the medium used for CE-FE communication. (please see the literature on this subject) As a real world example, consider two protocols that have been proposed for traffic engineering in MPLS: RSVP-TE and CR_LDP. CR-LDP uses TCP for transport reliability; RSVP uses only application (protocol) level reliability (when it uses it). Political considerations aside, RSVP-TE is doing well, CR-LDP less so. One of the major problems I have noticed is that the overly complicated and cumbersome reliability mechanism (very intelligent otherwise) provided by TCP is very slow compared with an application level mechanism tailored to the problem at hand. Again, I am not asking to take my word for it; please consult the literature that provides more rigorous results.=20 I am not arguing against TCP (I guess it is too late for this) but we should be careful when we argue in favour of TCP just because it has reliability implemented. Regards, Sandy -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M Sent: November 25, 2003 7:07 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: towards consensus: ForCES transport and group addressing The only real use for UDP without other protocol mechanisms is for those messages that don't require strict reliability. Given that, it seems of little value to make UDP a requirement on the FE unless the additional protocol mechanisms which make UDP reliable also become a requirement, which would probably be unattractive to FE vendors.=20 The problem with this is that FEs probably have less CPU capacity than the CE and adding another layer of protocol to the FEs to implement this reliability could detract from the FE's ability to process packets. By requiring support for multicast over UDP, the tradeoff is potentially saving some CPU cycles on the CE, but consuming more cycles on the FE by requiring additional protocol processing to provide the reliability levels required (or should be) for configuration messages. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Tuesday, November 25, 2003 8:11 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: towards consensus: ForCES transport and group addressing In order to reach a consensus before we are exhausted posting on the=20 list, let me cristallize what could help unlock the situation. I presume we should be able to reach consensus on sth like (remains to=20 be defined in more detail): ForCES transport --------------------- a) An FE MUST support UDP (or raw media encapsulation) as ForCES=20 transport if the FE is targeted at the local scope env. b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 targeted at the global scope environment. c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 ForCES transport if the FE is targeted at both local and global scopes. (the same applies for the CE) FEs/CEs that support TCP will support UDP as well (I have never seen an=20 IP stack that offers TCP without UDP). Note that this does not prevent=20 from using TCP in the local scope if the FEs and CEs support it. Thus=20 TCP-proponents should be satisfied. In addition, could we reach consensus on sth like: ForCES group addressing ------------------------------ d) FEs and CEs MUST support group addressing in the ForCES protocol. Nobody is forced to USE such a group addressing (one can stick to=20 unicast ForCES-addressing and TCP transport in all cases). But if one=20 sees that group addressing fits ones needs (and many have voiced it on=20 the list), then one should be able to use it. Ultimately (and this is=20 probably best so), it's the user writing software in the CE who decides=20 what she/he wants to use. Note that the phrasing in a), b), c), and d) is meant to satisfy=20 interoperability. Not my ego. I have the impression that a number of participants in this WG,=20 including other protocol draft authors, tend to agree on these items.=20 Who would not agree (and on what) ? --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 13:25:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20553 for ; Wed, 26 Nov 2003 13:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4MB-0002Ps-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 13:25:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP4M9-0002Pp-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 13:25:41 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C59E87@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 13:25:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62095836 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 13:25:35 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 13:25:35 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAQIPYRJ071908 for ; Wed, 26 Nov 2003 18:25:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAQIPYJj224712 for ; Wed, 26 Nov 2003 19:25:34 +0100 Received: from zurich.ibm.com (dhcp69-127.zurich.ibm.com [9.4.69.127]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA65042 for ; Wed, 26 Nov 2003 19:25:33 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0190B55@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id hAQIPYRJ071908 Approved-By: Robert Haas Message-ID: <3FC4F01D.7090909@zurich.ibm.com> Date: Wed, 26 Nov 2003 19:25:33 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B55@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: quoted-printable At the risk of being redundant with Sandy's answer: Deleganes, Ellen M wrote: >The only real use for UDP without other protocol mechanisms is for those= messages that don't require strict reliability. Given that, it seems of = little value to make UDP a requirement on the FE unless the additional pr= otocol mechanisms which make UDP reliable also become a requirement, whic= h would probably be unattractive to FE vendors.=20 > =20 > Whether UDP or TCP is used, or any other >transport< protocol, ForCES=20 must anyway provide the means for >application< level reliability (Alex=20 keeps pointing me to the reliability req section, but this has been=20 taken care of since the FIRST netlink2 draft). In the local scope (i.e., some high-speed interconnect, switch, etc),=20 Internet-like packet loss is not expected. Or the interconnect is badly=20 designed (i.e., lack of backpressure mechanisms). >The problem with this is that FEs probably have less CPU capacity than t= he CE and adding another layer of protocol to the FEs to implement this r= eliability could detract from the FE's ability to process packets. By req= uiring support for multicast over UDP, the tradeoff is potentially saving= some CPU cycles on the CE, but consuming more cycles on the FE by requir= ing additional protocol processing to provide the reliability levels requ= ired (or should be) for configuration messages. > This additional layer is required anyway, it's part of ForCES. So I=20 don't see where is the problem. Actually, what I proposed would even=20 save cycles by avoiding unnecessary TCP mechanims in the local scope. >Regards, >Ellen > >-----Original Message----- >From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EAS= E.LSOFT.COM] On Behalf Of Robert Haas >Sent: Tuesday, November 25, 2003 8:11 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: towards consensus: ForCES transport and group addressing > >In order to reach a consensus before we are exhausted posting on the=20 >list, let me cristallize what could help unlock the situation. > >I presume we should be able to reach consensus on sth like (remains to=20 >be defined in more detail): > >ForCES transport >--------------------- > a) An FE MUST support UDP (or raw media encapsulation) as ForCES=20 >transport if the FE is targeted at the local scope env. > b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 >targeted at the global scope environment. > c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 >ForCES transport if the FE is targeted at both local and global scopes. > (the same applies for the CE) > >FEs/CEs that support TCP will support UDP as well (I have never seen an=20 >IP stack that offers TCP without UDP). Note that this does not prevent=20 >from using TCP in the local scope if the FEs and CEs support it. Thus=20 >TCP-proponents should be satisfied. > > >In addition, could we reach consensus on sth like: > >ForCES group addressing >------------------------------ > d) FEs and CEs MUST support group addressing in the ForCES protocol. > >Nobody is forced to USE such a group addressing (one can stick to=20 >unicast ForCES-addressing and TCP transport in all cases). But if one=20 >sees that group addressing fits ones needs (and many have voiced it on=20 >the list), then one should be able to use it. Ultimately (and this is=20 >probably best so), it's the user writing software in the CE who decides=20 >what she/he wants to use. > >Note that the phrasing in a), b), c), and d) is meant to satisfy=20 >interoperability. Not my ego. > >I have the impression that a number of participants in this WG,=20 >including other protocol draft authors, tend to agree on these items.=20 >Who would not agree (and on what) ? > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 13:54:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21437 for ; Wed, 26 Nov 2003 13:54:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4oM-0002kZ-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 13:54:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP4oL-0002kJ-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 13:54:49 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00C59F14@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 13:54:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62098061 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 13:54:44 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 13:54:44 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAQItWZH027219 for ; Wed, 26 Nov 2003 18:55:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAQImhh14719 for ; Wed, 26 Nov 2003 18:48:43 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112610544027954 for ; Wed, 26 Nov 2003 10:54:40 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Nov 2003 10:54:39 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] towards consensus: ForCES transport and group addressing Thread-Index: AcO0EeA/F59iF6MtRkCC5njRuvOY3QAOfIfQ X-OriginalArrivalTime: 26 Nov 2003 18:54:39.0863 (UTC) FILETIME=[BED5B070:01C3B44E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54E58@orsmsx410.jf.intel.com> Date: Wed, 26 Nov 2003 10:54:39 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Avri Nice to see your email. You hit the nail right on the head! This thread started last week with Steve's email on the applicability of multicast to ForCES and asking for neutral opinion on that. Unfortunately, it has turned into a Netlink2 vs. FACT or any other protocol debate. That was Not the intent of Steve's email, neither has it been the intent of any of the FACT authors. We didn't even respond to any emails initially for a couple of days so that all views on this topic can be heard. I completely agree that Multicast is Not the deciding criteria for any protocol, at best it is a transport option. This is what most of the neural folks said as well, it is a good option to have at the transport level. However, before deciding on using it as an option, and definitely before Mandating it, we need to think about and crystallize the technical details around it. This is what I have been trying to do and I believe this is what Joel and David are also asking for. Some of the technical issues include 1) reliability (including CC), 2) command bundling, 3) FE-to-CE communication, 4) security. Security is probably not as important as the first 3 but still needs to be addressed.=20 Now here is where instead of discussing the technical issues in a neutral fashion, its turned into...Netlink2 can do this and provide mechanisms for that. But I have seen very little specific details on this and the more we think about specifics the more we will realize that multicast comes at the cost of a lot of complexity and interoperability issues and at best can only be an optional transport. Thanks & Happy Thanksgiving to everyone in the US ! Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of avri Sent: Wednesday, November 26, 2003 3:38 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] towards consensus: ForCES transport and group addressing hi, I just came back from a bit of vacation and had the pleasure of reading through the many messages that compose the multicast thread. Made for an exciting couple of hours on a dreary day. Though the thread baffles me. - it is as if 2 of the 3 contending protocols are fighting for supremacy on the subject of multicast support. With 3 protocols in contention it is difficult to understand the positioning and posturing. - I do not understand in what way multicast support is a criteria for choosing a protocol. As I understand the requirements it is neither required not precluded by the requirements. From the arguments it seems like there may be cases where it comes in useful, though there seem to be issues that need to be resolved in other cases. As one of those who is not committed to any of the protocols, I don't see it as a necessary criteria for choosing and believe that it should be optional whether a protocol uses multicast as long as it meets the other requirements. In many ways it seems as though it may be more of an implementation issue then a protocol selection criteria. a. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 14:26:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23015 for ; Wed, 26 Nov 2003 14:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP5JT-0003JY-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 14:26:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP5JS-0003Iw-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 14:26:58 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00C59EB0@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 14:26:57 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62100693 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 14:26:55 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 14:26:55 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAQJRiZH022515 for ; Wed, 26 Nov 2003 19:27:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAQJKth19929 for ; Wed, 26 Nov 2003 19:20:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003112611265108759 for ; Wed, 26 Nov 2003 11:26:51 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Nov 2003 11:26:51 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: towards consensus: ForCES transport and group addressing Thread-Index: AcO0SrqQ1t6Pk/CjRfqFpShmfELVowABXtdQ X-OriginalArrivalTime: 26 Nov 2003 19:26:51.0973 (UTC) FILETIME=[3E764750:01C3B453] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190B59@orsmsx410.jf.intel.com> Date: Wed, 26 Nov 2003 11:26:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I agree that in the local case that the packet loss and corruption is = significantly lower than in the internet. However, that doesn't mean you = can ignore the problem. You still need some reliability mechanisms - a = number of the proprietary high-speed interconnects have HW reliability = mechanisms (ACK, retransmit, sequence numbering, etc.) built in, even = though they expect to experience a very low level of packet loss. I would assume that the reliability of the underlying transport would = have an effect on the amount of application-level reliability built into = ForCES. If you make the base assumption that the underlying transport = has little to no reliability, it seems like the reliability mechanisms = that would need to be added to ForCES may be overkill and additional = overhead for a transport that has some reliability already built in. =20 The difficulty that I have with multicast is that adding reliability is = complex. Reliable multicast is still in the experimental stage in the = IETF and is a difficult problem to solve. Other high-speed interconnect = activities that I've been involved with had reliable multicast as a = desired feature, but ended up punting on it because of the complexity. = So far the use cases and benefits don't seem to justify the additional = effort. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Wednesday, November 26, 2003 10:26 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: towards consensus: ForCES transport and group addressing At the risk of being redundant with Sandy's answer: Deleganes, Ellen M wrote: >The only real use for UDP without other protocol mechanisms is for = those messages that don't require strict reliability. Given that, it = seems of little value to make UDP a requirement on the FE unless the = additional protocol mechanisms which make UDP reliable also become a = requirement, which would probably be unattractive to FE vendors.=20 > =20 > Whether UDP or TCP is used, or any other >transport< protocol, ForCES=20 must anyway provide the means for >application< level reliability (Alex=20 keeps pointing me to the reliability req section, but this has been=20 taken care of since the FIRST netlink2 draft). In the local scope (i.e., some high-speed interconnect, switch, etc),=20 Internet-like packet loss is not expected. Or the interconnect is badly=20 designed (i.e., lack of backpressure mechanisms). >The problem with this is that FEs probably have less CPU capacity than = the CE and adding another layer of protocol to the FEs to implement this = reliability could detract from the FE's ability to process packets. By = requiring support for multicast over UDP, the tradeoff is potentially = saving some CPU cycles on the CE, but consuming more cycles on the FE by = requiring additional protocol processing to provide the reliability = levels required (or should be) for configuration messages. > This additional layer is required anyway, it's part of ForCES. So I=20 don't see where is the problem. Actually, what I proposed would even=20 save cycles by avoiding unnecessary TCP mechanims in the local scope. >Regards, >Ellen > >-----Original Message----- >From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >Sent: Tuesday, November 25, 2003 8:11 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: towards consensus: ForCES transport and group addressing > >In order to reach a consensus before we are exhausted posting on the=20 >list, let me cristallize what could help unlock the situation. > >I presume we should be able to reach consensus on sth like (remains to=20 >be defined in more detail): > >ForCES transport >--------------------- > a) An FE MUST support UDP (or raw media encapsulation) as ForCES=20 >transport if the FE is targeted at the local scope env. > b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is=20 >targeted at the global scope environment. > c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as=20 >ForCES transport if the FE is targeted at both local and global scopes. > (the same applies for the CE) > >FEs/CEs that support TCP will support UDP as well (I have never seen an = >IP stack that offers TCP without UDP). Note that this does not prevent=20 >from using TCP in the local scope if the FEs and CEs support it. Thus=20 >TCP-proponents should be satisfied. > > >In addition, could we reach consensus on sth like: > >ForCES group addressing >------------------------------ > d) FEs and CEs MUST support group addressing in the ForCES protocol. > >Nobody is forced to USE such a group addressing (one can stick to=20 >unicast ForCES-addressing and TCP transport in all cases). But if one=20 >sees that group addressing fits ones needs (and many have voiced it on=20 >the list), then one should be able to use it. Ultimately (and this is=20 >probably best so), it's the user writing software in the CE who decides = >what she/he wants to use. > >Note that the phrasing in a), b), c), and d) is meant to satisfy=20 >interoperability. Not my ego. > >I have the impression that a number of participants in this WG,=20 >including other protocol draft authors, tend to agree on these items.=20 >Who would not agree (and on what) ? > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 16:32:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28952 for ; Wed, 26 Nov 2003 16:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7Hc-000573-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 16:33:12 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP7Hb-000570-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 16:33:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00C5A1F7@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 16:33:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62111625 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 16:33:09 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 16:33:09 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAQLX8LS002173 for ; Wed, 26 Nov 2003 15:33:08 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B0F54C97@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3FC51C10.60CE36FD@alcatel.com> Date: Wed, 26 Nov 2003 15:33:04 -0600 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: ForCES IETF58 Minutes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hey Hormuzd, Would you happen a copy of teh FORCES Minutes from IETF58? I am not sure I've seen it mailed out. Please send me a copy if you have it. Thanks, Alex. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 16:45:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29438 for ; Wed, 26 Nov 2003 16:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7UC-0005Gd-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 16:46:12 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP7UB-0005Ga-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 16:46:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C5A295@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 16:46:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62112363 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 16:45:54 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 16:45:54 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAQLkHQ7009499 for ; Wed, 26 Nov 2003 21:46:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAQLdth07106 for ; Wed, 26 Nov 2003 21:39:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003112613455208656 for ; Wed, 26 Nov 2003 13:45:52 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Nov 2003 13:45:51 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3B466.A94FCB12" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: yes Thread-Topic: [FORCES] ForCES IETF58 Minutes Thread-Index: AcO0ZOgVCaeJ5rX1TGa6Z772rUVKXAAAJeMQ X-OriginalArrivalTime: 26 Nov 2003 21:45:51.0879 (UTC) FILETIME=[A96EF170:01C3B466] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0F54EB0@orsmsx410.jf.intel.com> Date: Wed, 26 Nov 2003 13:45:51 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES IETF58 Minutes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B466.A94FCB12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex I have sent a copy of the minutes to the chairs and so has Lily. I guess they will be combined and sent out in sometime. BTW, I have attached my copy with this email, but it is not complete. (missed some of the initial discussion) Hope this helps, Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: Wednesday, November 26, 2003 1:33 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] ForCES IETF58 Minutes Hey Hormuzd, Would you happen a copy of teh FORCES Minutes from IETF58? I am not sure I've seen it mailed out. Please send me a copy if you have it. Thanks, Alex. ------_=_NextPart_001_01C3B466.A94FCB12 Content-Type: text/plain; name="ForCES-Minutes.txt" Content-Description: ForCES-Minutes.txt Content-Disposition: attachment; filename="ForCES-Minutes.txt" Content-Transfer-Encoding: base64 Rm9yQ0VTIFdHIE1lZXRpbmcgLSBJRVRGIDU4DQoNCg0KTWV0YWRhdGEgLSBBbGFuIERla29rDQoN ClJvYmVydCBIYWFzIC0gSXMgdGhpcyB0aGUgZXh0ZXJuYWwgbWV0YWRhdGEgPyBJdCBzZWVtcyBs aWtlIHRoYXQNCkFsYW4gRCAtIHByb3ZpZGVkIGNsYXJpZmljYXRpb24NCg0KDQpNT2RlbCBQcmVz ZW50YXRpb24gLSBTdGV2ZSBCLg0KDQpPcGVuIElzc3Vlcw0KSW50ZXItRkUgVG9wb2xvZ3kNCg0K TEZCIHJlY29uZmlnIC0gRkUgbWlnaHQgYmUgaW5vcGVyYXRpb25hbCBkdXJpbmcgcmVjb25maWd1 cmF0aW9uaA0KSm9lbCAtIEZFIHN0YXRlIGRvZXNudCBuZWVkIHRvIGJlIGtub3cgYnkgQ0UgDQpE YXZpZCAtIElzbnQgdGhpcyBpbXAgPw0KSm9lbCAtIE9wZXJhdG9yIG5lZWRzIHRvIGtub3cgdGhp cyBidXQgbm90IHRoZSBwcm90b2NvbA0KSmFtYWwgLSBBZ3JlZSB3aXRoIEpvZWwNCg0KDQpHUk1Q IC0gV2VpbWluZyBXYW5nDQoNCkRvcyBBdHRhY2tzIC0gRGF0YSwgQ09udHJvbCBjaGFubmVsIHdp dGggc2NoZWR1bGluZyBtZWNoYW5pc21zDQoNCkpvZWwgLSBXaGF0IHlvdSBoYXZlIGRlZmluZWQg aXMgTEZCcyA/IFRoaXMgc2hvdWxkIGJlIGRlZmluZWQgDQppbiB0aGUgRkUgTW9kZWwgYW5kIG5v dCBpbiB0aGUgbW9kZWwuDQpMaWx5IC0gdHJhbnNsYXRlZCB0aGlzIHRvIFdXDQpKT2VsIC0gVGhl IGRhdGEgY2hhbm5lbCwgY29udHJvbCBjaGFubmVsIGFwcHJvYWNoZXMgaGF2ZSBiZWVuIGRlZmlu ZWQNCmluIG90aGVyIHByb3RvY29scy4gV2UgZG9udCBuZWVkIHRvIGRlZmluZSBzY2hlZHVsaW5n IG1lY2hhbmlzbXMNCmFzIHBhcnQgb2YgdGhlIHByb3RvY29sLCB3ZSBjYW4gcmVjb21tZW5kIHRo aXMgbm90IGltcG9zZSBpdC4NCldXIC0gdGhlIHNsYXZlIG1vZHVsZSBuZWVkcyB0byBiZSBtb3Vu dGVkIGJlZm9yZSB0aGUgcHJvdG9jb2wNCg0KVG9wb2xvZ3kgUmVwIGZvciBNb2RlbCAtIFdlaW1p bmcgV2FuZw0KDQpQYWNrZXQgRmxvdyBJZCBjb25jZXB0DQoNCkpvZWwgLSB0aGVyZSBhcmUgbm8g YnVmZmVycywgZG9udCBrbm93IHdoYXQgeW91IG1lYW4gdG8gYWxsb2NhdGUNCmZvciBJRHMgPw0K V1cgLSBwcm92aWRlZCBzb21lIGV4cGxhbmF0aW9uDQpKb2VsIC0gbm90IHNhdGlzZmllZCwgbmVl ZCBmdXJ0aGVyIGNsYXJpZmljYXRpb24NCg0KTmV0bGluazIgcHJvdG9jb2wgLSBTdGV2ZSBCLg0K DQpObyBxdWVzdGlvbnMNCg0KRkFDVCBwcm90b2NvbCAtIFJhbSBHb3BhbA0KDQpTY2FsYWJpbGl0 eSAtDQoNClJhbSAtIG11bHRpY2FzdCBkb2VzbnQgYWx3YXlzIHdvcmsgZm9yIHNjYWxhYmlsaXR5 DQpKYW1hbCAtIGRvbnQgYWdyZWUNCg0KSmFtYWwgLSB3aGF0cyB0aGUgcmVhc29uIG9mIGhhdmlu ZyBtdWx0aXBsZSBwcmlvcml0aWVzID8NClJhbSAtIGdhdmUgYW4gZXhhbXBsZQ0KDQpMaW51eCBU cmFmZmljIENvbnRyb2wgRXh0ZW5zaW9ucyAmIEZvckNFUyBNb2RlbCAtIEphbWFsIEguDQoNCk1v ZGVsIG92ZXJ2aWV3DQpDbGFzc2lmaWVyIExGQnMNCkFjdGlvbiBJbnN0YW5jZSBMRkJzDQpBY3Rp b24gTEZCcw0KQ0UgSGlnaCBMZXZlbCB2aWV3OiBDT25maWcNCkxGQiBBY3Rpb24gSW5zdGFuY2Ug aW50ZXJjb25uZWN0DQoNCk5vIHF1ZXN0aW9ucw0KDQoNCg0K ------_=_NextPart_001_01C3B466.A94FCB12-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 17:28:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00759 for ; Wed, 26 Nov 2003 17:28:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP89O-0005pm-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 17:28:46 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP89O-0005pj-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 17:28:46 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C5A2EF@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 17:28:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62114992 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 17:28:45 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 17:28:45 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112614275327:10717 ; Wed, 26 Nov 2003 14:27:53 -0800 References: <9CB758BBEE58754F8F33234D75B9F4B0190B59@orsmsx410.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/26/2003 02:27:53 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/26/2003 02:27:54 PM, Serialize complete at 11/26/2003 02:27:54 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069885722.1022.302.camel@jzny.localdomain> Date: Wed, 26 Nov 2003 17:28:42 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0190B59@orsmsx410.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Ellen, On Wed, 2003-11-26 at 14:26, Deleganes, Ellen M wrote: > Other high-speed interconnect activities that I've been involved with > had reliable multicast as a desired feature, but ended up punting on > it because of the complexity. Can you explain this a little more? Was the reliable mcast being built into the hardware or you meant the s/ware that rides on top? Are you able to describe details of how this setup looked like? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 18:08:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02792 for ; Wed, 26 Nov 2003 18:08:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP8mG-0006RR-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 18:08:56 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AP8mG-0006RO-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 18:08:56 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00C5A471@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 18:08:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62118270 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 18:08:55 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 18:08:55 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003112615080270:10747 ; Wed, 26 Nov 2003 15:08:02 -0800 References: <3FC3DE2F.FC9C56DF@alcatel.com> <3FC37F04.605@zurich.ibm.com> <3FC3B303.5A930BB8@alcatel.com> <3FC3B59D.4050409@zurich.ibm.com> <1069792826.1030.627.camel@jzny.localdomain> <3FC3CC3F.E431D3BA@alcatel.com> <1069797584.1029.689.camel@jzny.localdomain> <3FC3DE2F.FC9C56DF@alcatel.com> <5.1.0.14.0.20031126092708.0196aab0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/26/2003 03:08:03 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/26/2003 03:08:04 PM, Serialize complete at 11/26/2003 03:08:04 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1069888131.1024.326.camel@jzny.localdomain> Date: Wed, 26 Nov 2003 18:08:51 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: towards consensus: ForCES transport and group addressing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20031126092708.0196aab0@localhost> Precedence: list Content-Transfer-Encoding: 7bit We strongly believe that multicast is very important. The authors of the netlink2 draft will address all these issues in the next release. We hope this will close this discussion and give people interested in using multicast the opportunity to do so. cheers, jamal On Wed, 2003-11-26 at 09:31, Joel M. Halpern wrote: > There are two dimensions that I see still needing attention: > 1) Even with only one "hop", reliability, congestion control, flow control, > and security still need to be addressed. I might agree that for in-box the > last may be skipped. The rest apply anyway. (The reason many existing > backplane mechanisms do not worry about such things is that the > relationship between the control processor, the control load, the backplane > capacity, and the forwarding blade capacity are carefully engineered. That > can not be assumed in a standard for use in mixed-vendor environments.) > > 2) Based on experience in multiple working groups, work aimed at one > limitted scope tends to get applied to other scopes. I suppose that one > could try to put in mechanisms to actually control the scope that can be > applied. But that is quite complex in its own right. > > Yours, > Joel M. Halpern > > At 10:35 PM 11/25/2003 -0500, you wrote: > >Now > >investigate this problem for reliability, congestion control and come > >back with a list of protocols that handle this scope _very well_. From owner-forces@PEACH.EASE.LSOFT.COM Wed Nov 26 21:40:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09463 for ; Wed, 26 Nov 2003 21:40:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APC4x-0001EO-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 21:40:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1APC4w-0001EL-00 for forces-archive@IETF.ORG; Wed, 26 Nov 2003 21:40:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C5A6B1@cherry.ease.lsoft.com>; Wed, 26 Nov 2003 21:40:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62133212 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Nov 2003 21:40:25 -0500 Received: from 61.175.198.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Nov 2003 21:40:24 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 27 Nov 2003 10:49:16 +0800 References: <9CB758BBEE58754F8F33234D75B9F4B0F54EB0@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <038001c3b48f$f84832b0$845c21d2@Necom.hzic.edu.cn> Date: Thu, 27 Nov 2003 10:41:33 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: ForCES IETF58 Minutes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 Rm9yQ0VTIFdHIE1lZXRpbmcgLSBJRVRGIDU4DQoNCg0KTWV0YWRhdGEgLSBBbGFuIERla29rDQoN ClJvYmVydCBIYWFzIC0gSXMgdGhpcyB0aGUgZXh0ZXJuYWwgbWV0YWRhdGEgPyBJdCBzZWVtcyBs aWtlIHRoYXQNCkFsYW4gRCAtIHByb3ZpZGVkIGNsYXJpZmljYXRpb24NCg0KDQpIaSBIb3JtdXpk LA0KT24gdGhlIG1pbnV0ZXMsDQo+Sk9lbCAtIFRoZSBkYXRhIGNoYW5uZWwsIGNvbnRyb2wgY2hh bm5lbCBhcHByb2FjaGVzIGhhdmUgYmVlbiBkZWZpbmVkDQo+aW4gb3RoZXIgcHJvdG9jb2xzLiBX ZSBkb250IG5lZWQgdG8gZGVmaW5lIHNjaGVkdWxpbmcgbWVjaGFuaXNtcw0KPmFzIHBhcnQgb2Yg dGhlIHByb3RvY29sLCB3ZSBjYW4gcmVjb21tZW5kIHRoaXMgbm90IGltcG9zZSBpdC4NCj5XVyAt IHRoZSBzbGF2ZSBtb2R1bGUgbmVlZHMgdG8gYmUgbW91bnRlZCBiZWZvcmUgdGhlIHByb3RvY29s DQoNCkkgdGhpbmsgSSd2IHNhaWQgInRoZSBzbGF2ZSBtb2R1bGUgbmVlZHMgdG8gYmUgbW91bnRl ZCBiZWZvcmUgdGhlIEZFIG1vZGVsIg0KDQpUaGFuayB5b3UuDQpXZWltaW5nIA0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 27 18:00:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21070 for ; Thu, 27 Nov 2003 18:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APV8B-0006Cr-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 18:01:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1APV8A-0006Cm-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 18:01:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C5B9CD@cherry.ease.lsoft.com>; Thu, 27 Nov 2003 18:01:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62223035 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Nov 2003 18:00:59 -0500 Received: from 80.74.106.236 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Nov 2003 18:00:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Thread-Topic: Transport assumptions and "hooks?" Thread-Index: AcOzZxzpnrvx2wfnTR+3ZPA/dFIrMwB0TvDt Approved-By: Tal Anker Message-ID: Date: Fri, 28 Nov 2003 01:01:09 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Tal Anker Subject: Re: Transport assumptions and "hooks?" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 R29pbmcgb3ZlciB0aGUgbGFzdCBjb3VwbGUgb2YgZGF5cyBtZXNzYWdlcyAob2YgdGhpcyB0aHJl YWQpLCBKb2VsJ3MgZW1haWwgYmVsb3cgc2VlbXMsIElNSE8sIHRoZSBtb3N0IHJlYXNvbmFibGUg d2F5IHRvIGdvLi4uIEl0IHNlZW1zIHRoYXQgdGhpcyBhbGxvd3MgZm9yIGVpdGhlciB0Y3AvdWRw L3JlbGlhYmxlLW1jYXN0L2NvbWJpbmF0aW9uLW9mLWFsbCwgd2hpY2ggc2hvdWxkIGJyaW5nIGJh Y2sgcGVhY2UgOi0pDQogDQpTbywgaWYgdGhlIGFib3ZlIGlzIGFjY2VwdGVkIChJIGRvIG5vdCB0 aGluayBJIGhhdmUgc2VlbiByZXBsaWVzIHRvIHRoZSBiZWxvdyBtZXNzYWdlKSwgSSBndWVzcyB0 aGUgcmVxdWlyZW1lbnQgZHJhZnQgc2hvdWxkIGJlIHVwZGF0ZWQ/DQogDQotIFRhbA0KIA0KIA0K IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogSm9lbCBNLiBIYWxwZXJu IFttYWlsdG86am9lbEBzdGV2ZWNyb2NrZXIuY29tXSANCglTZW50OiBUdWUgMTEvMjUvMjAwMyA1 OjEzIFBNIA0KCVRvOiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00gDQoJQ2M6IA0KCVN1Ympl Y3Q6IFRyYW5zcG9ydCBhc3N1bXB0aW9ucyBhbmQgImhvb2tzPyINCgkNCgkNCg0KCUluIHJlYWRp bmcgKGFuZCBwcm9iYWJseSBhY2NpZGVudGFsbHkgaW5mbGFtaW5nKSB0aGUgZGlzY3Vzc2lvbiBv Zg0KCW11bHRpY2FzdCBzdXBwb3J0LCBJIHJlYWxpemVkIEkgd2FzIG1ha2luZyBhc3N1bXB0aW9u cyBhYm91dCB0aGUgcmVxdWlyZW1lbnRzLg0KCVJlYWRpbmcgdGhlIHJlcXVpcmVtZW50cyBkcmFm dCwgaXQgaXMgbm90IGV4cGxpY2l0IGFib3V0IGNlcnRhaW4gdGhpbmdzLg0KCQ0KCUEgbG90IG9m IG15IGNvbmNlcm5zIGFib3V0IG11bHRpY2FzdCBhcmUgZHJpdmVuIGJ5IG15IGJlbGlldmUgdGhh dCBhbnkNCgl0cmFuc3BvcnQgd2Ugc3BlY2lmeSBtdXN0IHN1cHBvcnQNCgkxKSByZWxpYWJpbGl0 eSAoc3BlY2lmaWVkIGV4cGxpY2l0bHkgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwgYW5kDQoJ cHJvdmlkZWQgYnkgYWxsIHByb3Bvc2FscyBvbmUgd2F5IG9yIGFub3RoZXIpDQoJMikgY29uZ2Vz dGlvbiBjb250cm9sIChleHBsaWNpdGx5IHJlcXVpcmVkIHdoZW4gdGhlcmUgaXMgbW9yZSB0aGFu IG9uZSAiaG9wIikNCgkzKSBmbG93IGNvbnRyb2wgKEkgaGF2ZSBiZWVuIHNldmVyZWx5IGJ1cm5l ZCBieSBhc3N1bWluZyBJIGRpZCBub3QgbmVlZA0KCWZsb3cgY29udHJvbCBpbiBteSBjb250cm9s IHByb3RvY29scy4gIFlvdSBjYW4gZ2V0IGFtYXppbmcgbWVzc2VzIGlmIHRoZSBDRQ0KCWNhbiBv dmVycnVuIHRoZSBGRSwgb3IgdGhlIHJldmVyc2UuKQ0KCTQpIHNlY3VyaXR5IChyZXF1aXJlZCwg d2l0aCBhbiBvdXQgZm9yICJpbi1ib3giKQ0KCQ0KCU5vdGUgdGhhdCBJIGhhdmUgZm91bmQgdGhh dCBmbG93IGNvbnRyb2wgbmVlZHMgdG8gYmUgdGhvdWdodCBhYm91dCBldmVuIGZvcg0KCWluLWJv eCBzb2x1dGlvbnMuDQoJU29tZSBmb2xrcyBoYXZlIGFza2VkIHRoYXQgd2UgYWxsb3cgbXVsdGlj YXN0IG92ZXIgVURQLCB3aXRoIGFwcCBsZXZlbA0KCXJldHJhbnNtaXNzaW9uLiAgV2l0aG91dCBh ZGRyZXNzaW5nIHRoZSBvdGhlciBlbGVtZW50cyBvZiB0aGUgbGlzdCwgSSBkbw0KCW50byBiZWxp ZXZlIHRoYXQgdGhpcyBpcyBhIHNlbnNpYmxlIHNvbHV0aW9uIGZvciB1cyB0byBhbGxvdy4NCglB bmQgYWxsb3dpbmcgdGhvc2Ugb3RoZXIgZWxlbWVudHMgYWRkcyBhIGdyZWF0IGRlYWwgb2YgY29t cGxleGl0eS4NCgkNCglUaGVyZSBhcmUgc29tZSBjYXNlcyB3aGVyZSBtdWx0aWNhc3Qgd291bGQg YmUgbmljZSB0byBoYXZlLiAgSG9va3Mgd2hpY2ggZG8NCglub3QgY29tcHJvbWlzZSB0aGUgc291 bmRuZXNzIG9mIHRoZSBwcm90b2NvbCwgYW5kIHdoaWNoIGFsbG93IGZvciBtdWx0aWNhc3QNCgl0 byBiZSBhZGRlZCBlYXNpbHkgbGF0ZXIgbWFrZSBzZW5zZS4NCglTbyB3ZSBwcm9iYWJseSBzaG91 bGQgYWxsb3cgZm9yIG11bHRpcGxlIHNpbXVsdGFuZW91cyB0cmFuc3BvcnRzLg0KCVdlIHByb2Jh Ymx5IHNob3VsZCBtYWtlIHN1cmUgbWVzc2FnZXMgaW5jbHVkZSBzZW5kaW5nIGFuZCByZWNlaXZp bmcgZW50aXR5DQoJaWRlbnRpZmljYXRpb24uDQoJV2UgcHJvYmFibHkgd2FudCB0byBtYWtlIHRo ZSBpZGVudGlmaWVyIHNwYWNlIGJpZyAvIHN0cnVjdHVyZWQgZW5vdWdoIHRhaHQNCgl3ZSBjYW4g YWRkIHZhcmlvdXMga2luZHMgb2YgbG9naWNhbCAvIG11bHRpLWVudGl0eSBpZGVudGlmaWVycyBp biB0aGUgZnV0dXJlLg0KCQ0KCVlvdXJzLA0KCUpvZWwgTS4gSGFscGVybg0KCQ0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 27 18:04:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21280 for ; Thu, 27 Nov 2003 18:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APVBn-0006Fj-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 18:04:47 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1APVBm-0006Fg-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 18:04:46 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00C5BAC9@cherry.ease.lsoft.com>; Thu, 27 Nov 2003 18:04:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62223360 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Nov 2003 18:04:46 -0500 Received: from 198.24.6.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Nov 2003 18:04:46 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id hARN4kWm025101 for ; Thu, 27 Nov 2003 17:04:46 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Nov 2003 17:04:43 -0600 Received: from ericsson.com (142.133.72.81 [142.133.72.81]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XHG6DFFB; Thu, 27 Nov 2003 18:04:40 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr, de, no, nn, sv, MIME-Version: 1.0 References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Jon Maloy Message-ID: <3FC68303.3050007@ericsson.com> Date: Thu, 27 Nov 2003 18:04:35 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Re: Transport assumptions and "hooks?" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Difficult to disagree with both of you. /Jon Tal Anker wrote: >Going over the last couple of days messages (of this thread), Joel's email below seems, IMHO, the most reasonable way to go... It seems that this allows for either tcp/udp/reliable-mcast/combination-of-all, which should bring back peace :-) > >So, if the above is accepted (I do not think I have seen replies to the below message), I guess the requirement draft should be updated? > >- Tal > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Tue 11/25/2003 5:13 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Cc: > Subject: Transport assumptions and "hooks?" > > > > In reading (and probably accidentally inflaming) the discussion of > multicast support, I realized I was making assumptions about the requirements. > Reading the requirements draft, it is not explicit about certain things. > > A lot of my concerns about multicast are driven by my believe that any > transport we specify must support > 1) reliability (specified explicitly in the requirements draft, and > provided by all proposals one way or another) > 2) congestion control (explicitly required when there is more than one "hop") > 3) flow control (I have been severely burned by assuming I did not need > flow control in my control protocols. You can get amazing messes if the CE > can overrun the FE, or the reverse.) > 4) security (required, with an out for "in-box") > > Note that I have found that flow control needs to be thought about even for > in-box solutions. > Some folks have asked that we allow multicast over UDP, with app level > retransmission. Without addressing the other elements of the list, I do > nto believe that this is a sensible solution for us to allow. > And allowing those other elements adds a great deal of complexity. > > There are some cases where multicast would be nice to have. Hooks which do > not compromise the soundness of the protocol, and which allow for multicast > to be added easily later make sense. > So we probably should allow for multiple simultaneous transports. > We probably should make sure messages include sending and receiving entity > identification. > We probably want to make the identifier space big / structured enough taht > we can add various kinds of logical / multi-entity identifiers in the future. > > Yours, > Joel M. Halpern > > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Nov 27 19:11:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23516 for ; Thu, 27 Nov 2003 19:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APWE4-00079i-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 19:11:12 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1APWE3-00079f-00 for forces-archive@IETF.ORG; Thu, 27 Nov 2003 19:11:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C5BC44@cherry.ease.lsoft.com>; Thu, 27 Nov 2003 19:11:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 62238153 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Nov 2003 19:11:09 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Nov 2003 19:11:09 -0500 Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APWE0-000AAp-3v for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Nov 2003 00:11:08 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Approved-By: avri Message-ID: <4CED57AD-2137-11D8-A38A-000393CC2112@psg.com> Date: Fri, 28 Nov 2003 09:10:40 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: Transport assumptions and "hooks?" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I don't see a need to change the requirements to make this happen. The requirements, and caveats, already exist for reliability, congestion control, flow control and security. So anything that functions within those constraints should be allowed. a. On fredag, nov 28, 2003, at 08:01 Asia/Seoul, Tal Anker wrote: > Going over the last couple of days messages (of this thread), Joel's > email below seems, IMHO, the most reasonable way to go... It seems > that this allows for either tcp/udp/reliable-mcast/combination-of-all, > which should bring back peace :-) > > So, if the above is accepted (I do not think I have seen replies to > the below message), I guess the requirement draft should be updated? > > - Tal > > > > > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Tue 11/25/2003 5:13 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Cc: > Subject: Transport assumptions and "hooks?" > > > > In reading (and probably accidentally inflaming) the discussion of > multicast support, I realized I was making assumptions about the > requirements. > Reading the requirements draft, it is not explicit about certain > things. > > A lot of my concerns about multicast are driven by my believe that any > transport we specify must support > 1) reliability (specified explicitly in the requirements draft, and > provided by all proposals one way or another) > 2) congestion control (explicitly required when there is more than > one "hop") > 3) flow control (I have been severely burned by assuming I did not > need > flow control in my control protocols. You can get amazing messes if > the CE > can overrun the FE, or the reverse.) > 4) security (required, with an out for "in-box") > > Note that I have found that flow control needs to be thought about > even for > in-box solutions. > Some folks have asked that we allow multicast over UDP, with app level > retransmission. Without addressing the other elements of the list, I > do > nto believe that this is a sensible solution for us to allow. > And allowing those other elements adds a great deal of complexity. > > There are some cases where multicast would be nice to have. Hooks > which do > not compromise the soundness of the protocol, and which allow for > multicast > to be added easily later make sense. > So we probably should allow for multiple simultaneous transports. > We probably should make sure messages include sending and receiving > entity > identification. > We probably want to make the identifier space big / structured enough > taht > we can add various kinds of logical / multi-entity identifiers in the > future. > > Yours, > Joel M. Halpern > >