From exim@www1.ietf.org Mon Mar 1 00:27:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05636 for ; Mon, 1 Mar 2004 00:27:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfwk-00059U-Fz for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 00:26:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215QUps019803 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 00:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfwk-00059K-CV for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05587 for ; Mon, 1 Mar 2004 00:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfwi-0002CP-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfvy-00026b-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:25:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfvH-00020D-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfvJ-0004xU-OR; Mon, 01 Mar 2004 00:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfup-0004q9-J1 for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 00:24:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05453 for ; Mon, 1 Mar 2004 00:24:28 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfun-0001yK-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:24:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axftw-0001sb-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:23:37 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AxftD-0001kd-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:22:51 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Mon, 1 Mar 2004 13:33:46 +0800 Received: from 218.37.214.230 ( [218.37.214.230]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Mon, 1 Mar 2004 13:33:46 +0800 Message-ID: <1078119226.4042cb4231d8c@mail.hzic.edu.cn> Date: Mon, 1 Mar 2004 13:33:46 +0800 To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Nice having seen you in Seoul. Pls check the reply in the body. Thank you. Weiming >----- Original Message ----- >From: Khosravi, Hormuzd M >To: Wang,Weiming ; forces-protocol@ietf.org >Sent: Monday, March 01, 2004 12:02 PM >Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia > > >Weiming, > >After going thru all the emails on this topic, seems like most protocol authors as well as non-authors except yourself agree that there should be separate transports for C & D channel. > [WangRe] This actually does not mean much. I think it is techniques instead of votes which can resolve the problem. >2 good reasons have been given for this: different reliability and robustness against DoS attacks. You agree with the first but not with the latter. > [WangRe] Yes, my idea is that to use separate channel can supply different reliability, but cannot supply any extra awards for DoS. >The problem with implementing scheduling at the protocol level and sending all the messages over a single TCP channel is that the app or protocol scheduling has little control over the TCP queues inside the OS. So scheduling at the protocol level will not help during a DoS attack once the TCP queue inside the OS if full. > [WangRe] The reality from our experiments is definitely not what you said. Scheduling at protocol layer can prevent DoS very well. We'll show the test results tomorrow. Could you have some reason why "the app or protocol scheduling has little control over the TCP queues inside the OS". Remember that the packets at TCP queues are supplied by app layer. >This is the reason why most people on this list are suggesting using different transports or multiple channels for D and C channel. > [WangRe] I suppose half of the replies mainly pay attention to the reliability problem when they support the separation of C and D channel. >We can discuss this further during the meeting if you like. > [WangRe] Yes that's a good idea if you also like. >BTW, I have been receiving many duplicate emails from you, but am not seeing all the other emails. There might be some problems with this mailing list. > [WangRe] I hope the mailing list will not limit the length of one email within 40k, for it's easy to overload when HTML format is used. >Regards > >Hormuzd > ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 00:54:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07379 for ; Mon, 1 Mar 2004 00:54:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgMu-0008PO-T8 for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 00:53:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215rWKq032321 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 00:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgMu-0008PE-PV for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:53:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07369 for ; Mon, 1 Mar 2004 00:53:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgMs-0005HW-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:53:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgM1-0005CT-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:52:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgLP-00056n-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 00:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgLR-0008IM-Qh; Mon, 01 Mar 2004 00:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgL3-0008Ho-OT for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 00:51:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07247 for ; Mon, 1 Mar 2004 00:51:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgL0-00055K-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:51:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgK6-00050P-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:50:39 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AxgJk-0004uf-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 00:50:16 -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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i215rHeC013373; Mon, 1 Mar 2004 05:53:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i215iN7Z003529; Mon, 1 Mar 2004 05:44:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022921494528638 ; Sun, 29 Feb 2004 21:49: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.6713); Sun, 29 Feb 2004 21:49: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 Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Date: Sun, 29 Feb 2004 21:49:45 -0800 Message-ID: <52D13A805349A249960B9943E5590BD8027C6034@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcP/TY9g/9ogfPmcTousz4Wsmsz3+AAAmNJw From: "Putzolu, David" To: , X-OriginalArrivalTime: 01 Mar 2004 05:49:46.0337 (UTC) FILETIME=[008FE510:01C3FF51] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I hope the mailing list will not limit the length of one=20 > email within 40k, for=20 > it's easy to overload when HTML format is used. 40k was the default, I suspect because the IETF doesn't want their servers overloaded. Several emails where in the 40-55k range, so I've gone ahead and upped it to 60k. If that is still too small I'll see about increasing it further. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 01:46:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09218 for ; Mon, 1 Mar 2004 01:46:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhBD-0005ab-HS for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 01:45:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i216jVOI021479 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 01:45:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhBD-0005aM-8k for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:45:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09185 for ; Mon, 1 Mar 2004 01:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhBA-0001yo-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:45:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhAF-0001u4-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:44:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axh9i-0001pD-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axh9l-0005Wt-H1; Mon, 01 Mar 2004 01:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axh9F-0005WL-Aj for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 01:43:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09115 for ; Mon, 1 Mar 2004 01:43:27 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axh9C-0001ni-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:43:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axh8H-0001ib-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:42:30 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1Axh7N-0001cZ-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:41:34 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 1 Mar 2004 14:52:34 +0800 Received: from 218.37.214.230 ( [218.37.214.230]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Mon, 1 Mar 2004 14:52:34 +0800 Message-ID: <1078123954.4042ddba3953d@mail.hzic.edu.cn> Date: Mon, 1 Mar 2004 14:52:34 +0800 To: "\"Khosravi, Hormuzd M\" ;alex.audu"@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia References: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, It seems a good and reasonable idea. Hi David, Thank you very much for the change. Cheers, Weiming Quoting "Khosravi, Hormuzd M" : > Hi All > > > > I was thinking about the issue of transport(s) for the ForCES protocol > which is probably one of the most important and might be quite > contentious. > > One way to resolve this and make some progress is to separate this from > the ForCES base protocol, let us consider having 2 drafts...one which > > defines the base protocol assuming a reliable transport and the second > which defines how the base protocol will work over different reliable as > well as > > unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. The > base protocol can concentrate on the basic protocol messages needed for > > control, configuration, capability exchange, etc. as well as other > transactioning semantics (2-phase commit), etc. The 2nd draft, say on > 'encapsulation > > for the base protocol' can discuss the details of providing reliability > over unreliable transports using some encapsulation header or TLV, etc. > and how > > the base protocol will work over different transports. > > We will eventually need to mandate 1 or minimum set of transports for > the protocol, but that can be decided later. In the mean time we can > continue > > making progress on both drafts. How does that sound to you guys ? > > > > Let us know. > > > > > > Regards > > Hormuzd > > > > ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 01:47:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09257 for ; Mon, 1 Mar 2004 01:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhC9-0005br-Vt for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 01:46:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i216kT7e021557 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 01:46:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhC9-0005bc-Qk for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:46:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09250 for ; Mon, 1 Mar 2004 01:46:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhC6-00023P-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhBC-0001zJ-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:45:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhAi-0001uW-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 01:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhAk-0005ZH-Lu; Mon, 01 Mar 2004 01:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhAH-0005Y5-6R for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 01:44:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09158 for ; Mon, 1 Mar 2004 01:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhAD-0001tb-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:44:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axh9I-0001ox-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:43:33 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Axh8s-0001jY-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 01:43:06 -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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i216k6eC001222; Mon, 1 Mar 2004 06:46:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i216b27h021318; Mon, 1 Mar 2004 06:37:17 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022922423400476 ; Sun, 29 Feb 2004 22:42:34 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 Feb 2004 22:42: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 Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Date: Sun, 29 Feb 2004 22:42:34 -0800 Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0022EEDBE@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcP/TY9g/9ogfPmcTousz4Wsmsz3+AAAmNJwAAIK87A= From: "Deleganes, Ellen M" To: "Putzolu, David" , , X-OriginalArrivalTime: 01 Mar 2004 06:42:34.0859 (UTC) FILETIME=[6125FBB0:01C3FF58] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I suggest including just the sections that you are replying to, rather than include the whole thread. It is getting difficult to follow some of the discussions because of the length of the emails.=20 Regards, Ellen -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Sunday, February 29, 2004 9:50 PM To: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia > I hope the mailing list will not limit the length of one=20 > email within 40k, for=20 > it's easy to overload when HTML format is used. 40k was the default, I suspect because the IETF doesn't want their servers overloaded. Several emails where in the 40-55k range, so I've gone ahead and upped it to 60k. If that is still too small I'll see about increasing it further. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 02:17:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22841 for ; Mon, 1 Mar 2004 02:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhfK-0004lO-Aa for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 02:16:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i217GcSo018303 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 02:16:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhfI-0004l6-70 for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:16:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22387 for ; Mon, 1 Mar 2004 02:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhfE-0005fF-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxheQ-0005ZJ-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:15:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axhdk-0005Sx-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhdn-0004Ow-2A; Mon, 01 Mar 2004 02:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhdI-0004Eq-Kc for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 02:14:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20709 for ; Mon, 1 Mar 2004 02:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhdE-0005P5-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhcN-0005HR-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:13:36 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Axhbb-00054G-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:12:47 -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.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i217EGg9025121 for ; Mon, 1 Mar 2004 07:14:16 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i2176r7Z031466 for ; Mon, 1 Mar 2004 07:06:59 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022923121602921 for ; Sun, 29 Feb 2004 23:12: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.6713); Sun, 29 Feb 2004 23:12:17 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FF5C.871A3CCE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Date: Sun, 29 Feb 2004 23:12:16 -0800 Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0022EEDC0@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcP9hXd0GW0+30RfSJKQLAdtD6yARABvKssAAAX8YRA= From: "Deleganes, Ellen M" To: "Khosravi, Hormuzd M" Cc: X-OriginalArrivalTime: 01 Mar 2004 07:12:17.0011 (UTC) FILETIME=[8764CC30:01C3FF5C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FF5C.871A3CCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hormudz, =20 Separating the protocol into two separate drafts is a good idea. I suspect the items that you suggest for the first draft are not as contentious (basic protocol messages needed for control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc.) and the team will be able to make faster progress.=20 =20 By separating the encapsulation part into a 2nd draft seems reasonable. The second draft should have concrete details about how the ForCES protocol maps to the transport (or transports). Since this is a mapping document, the transports should be named so you don't have to specify the assumptions on the transport, they can be deduced from the mapping description and understanding of the transport protocol. =20 Regards, Ellen =20 ------_=_NextPart_001_01C3FF5C.871A3CCE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hormudz,

 

Separating the protocol into two = separate drafts is a good idea. I suspect the items that you suggest for the = first draft are not as contentious (basic protocol messages needed for control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc.) and the team will be able to make = faster progress.

 

By separating the encapsulation = part into a 2nd draft seems reasonable. The second draft should have = concrete details about how the ForCES protocol maps to the transport (or = transports). Since this is a mapping document, the transports should be named so you = don’t have to specify the assumptions on the transport, they can be deduced = from the mapping description and understanding of the transport = protocol.

 

Regards,

Ellen

 

------_=_NextPart_001_01C3FF5C.871A3CCE-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 02:53:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26539 for ; Mon, 1 Mar 2004 02:53:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiEC-0003Zl-C4 for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 02:52:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i217qekx013722 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 02:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiEA-0003ZD-1g for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:52:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26523 for ; Mon, 1 Mar 2004 02:52:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiE6-0001bC-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiDF-0001Vw-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:51:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiCc-0001QQ-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 02:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiCf-0003LF-GG; Mon, 01 Mar 2004 02:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiC5-0003JY-NU for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 02:50:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26356 for ; Mon, 1 Mar 2004 02:50:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiC1-0001P7-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:50:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiB6-0001L3-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:49:29 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AxiAR-0001Cl-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 02:48:47 -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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i217oGg9006836 for ; Mon, 1 Mar 2004 07:50:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i217nuQT027284 for ; Mon, 1 Mar 2004 07:49:56 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022923481526964 for ; Sun, 29 Feb 2004 23:48:15 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 Feb 2004 23:48:16 -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 Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Date: Sun, 29 Feb 2004 23:48:16 -0800 Message-ID: <52D13A805349A249960B9943E5590BD8027C603B@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcP9hXd0GW0+30RfSJKQLAdtD6yARABvKssAAAX8YRAAAbI+4A== From: "Putzolu, David" To: "Deleganes, Ellen M" , "Khosravi, Hormuzd M" Cc: X-OriginalArrivalTime: 01 Mar 2004 07:48:16.0494 (UTC) FILETIME=[8E8BC0E0:01C3FF61] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is an interesting idea but I suggest first=20 applying as a way to structure work of the design team before deciding whether to apply it to draft=20 structure itself. I.e. have the design team focus on areas of common=20 protocol messages, then have the design team focus on=20 transports. Note that only 19 days are left before the report-out=20 is expected on whether a merge is possible or not. =20 So we need to work fast! :) -David ________________________________ From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Deleganes, Ellen M Sent: Monday, March 01, 2004 4:12 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia =09 =09 Hormudz, =20 Separating the protocol into two separate drafts is a good idea. I suspect the items that you suggest for the first draft are not as contentious (basic protocol messages needed for control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc.) and the team will be able to make faster progress.=20 =20 By separating the encapsulation part into a 2nd draft seems reasonable. The second draft should have concrete details about how the ForCES protocol maps to the transport (or transports). Since this is a mapping document, the transports should be named so you don't have to specify the assumptions on the transport, they can be deduced from the mapping description and understanding of the transport protocol. =20 Regards, Ellen _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 1 23:57:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01388 for ; Mon, 1 Mar 2004 23:57:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1y4-0003OA-If for forces-protocol-archive@odin.ietf.org; Mon, 01 Mar 2004 23:57:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224vKjs013020 for forces-protocol-archive@odin.ietf.org; Mon, 1 Mar 2004 23:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1y4-0003Nv-Ag for forces-protocol-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:57:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01384 for ; Mon, 1 Mar 2004 23:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1y2-0002h3-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 23:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1xK-0002bF-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 23:56:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1wm-0002Tc-00 for forces-protocol-web-archive@ietf.org; Mon, 01 Mar 2004 23:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1wn-0003JX-I7; Mon, 01 Mar 2004 23:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1wK-0003Ie-Ej for forces-protocol@optimus.ietf.org; Mon, 01 Mar 2004 23:55:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01182 for ; Mon, 1 Mar 2004 23:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1wI-0002RL-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 23:55:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1vU-0002Gz-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 23:54:40 -0500 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1uU-00022X-00 for forces-protocol@ietf.org; Mon, 01 Mar 2004 23:53:38 -0500 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: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i224r6N2001358 for ; Tue, 2 Mar 2004 04:53: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.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i224sDY2014892 for ; Tue, 2 Mar 2004 04:54:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030120530513216 for ; Mon, 01 Mar 2004 20:53:05 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Mar 2004 20:53:05 -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 Date: Mon, 1 Mar 2004 20:53:05 -0800 Message-ID: <52D13A805349A249960B9943E5590BD8027C65A1@orsmsx409.jf.intel.com> Thread-Topic: Proposed ForCES Protocol Milestone update Thread-Index: AcQAEjt3uZCttWO7Rsq/cHlTjdTVsg== From: "Putzolu, David" To: X-OriginalArrivalTime: 02 Mar 2004 04:53:05.0554 (UTC) FILETIME=[3FF35720:01C40012] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Proposed ForCES Protocol Milestone update Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, Patrick & I are in the process of updating the WG milestones. Since this mailing list has most of the protocol participants I am checking here first before sending final dates to the ADs for approval. Please review the following protocol-relevant proposed dates and let me know if you have suggestions for changes. Protocol selection - acceptance of working group -00: Jun'04 Protocol selection - working group last call: Mar'05 Thanks, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 06:40:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04204 for ; Tue, 2 Mar 2004 06:40:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8FS-0000it-Dn for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 06:39:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22BdgTl002776 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 06:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8FR-0000ih-R5 for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 06:39:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04155 for ; Tue, 2 Mar 2004 06:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8FN-0007SQ-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:39:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8EN-0007JL-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:38:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8Dm-0007Bg-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:37:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8Dp-0000dn-KL; Tue, 02 Mar 2004 06:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7Rn-00037j-9z for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 05:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02243 for ; Tue, 2 Mar 2004 05:48:19 -0500 (EST) From: donglg@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay7Rj-0000ye-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 05:48:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay7Qk-0000s3-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 05:47:19 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1Ay7OC-0000ZP-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 05:44:40 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 2 Mar 2004 18:55:32 +0800 Received: from 218.37.211.228 ( [218.37.211.228]) as user donglg@localhost by mail.hzic.edu.cn with HTTP; Tue, 2 Mar 2004 18:55:31 +0800 Message-ID: <1078224931.4044682cc3fb5@mail.hzic.edu.cn> To: david.putzolu@intel.com Cc: FORCES@PEACH.EASE.LSOFT.COM, forces-protocol@ietf.org, lidefeng@huawei.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1078224931d5a268a3ea1176d35fba781154ebbb08" User-Agent: Internet Messaging Program (IMP) 3.1 Subject: [Forces-protocol] (no subject) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 18:55:31 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This message is in MIME format. ---MOQ1078224931d5a268a3ea1176d35fba781154ebbb08 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit hi, David, I am attaching the pdf file of my presentation in today's conference. Please check it. best regards Dong, Ligang _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------------------------------------------------- This mail sent through HUCNIC Webmail system. ---MOQ1078224931d5a268a3ea1176d35fba781154ebbb08 Content-Type: application/pdf; name="testbed_dong.pdf" Content-Disposition: attachment; filename="testbed_dong.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjUxNiAwIG9iaiA8PC9MaW5lYXJpemVkIDEvTCAxNzkzNDYvTyA1MjAv RSAxOTM3OC9OIDIxL1QgMTY4OTc4L0ggWyA2NjkgNTYyXT4+DWVuZG9iag0gICAgICAgICAgICAg DQp4cmVmDQo1MTYgMTgNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTQxOSAwMDAwMCBuDQow MDAwMDAwNjY5IDAwMDAwIG4NCjAwMDAwMDE3MTIgMDAwMDAgbg0KMDAwMDAwMTg1NyAwMDAwMCBu DQowMDAwMDAyMTk4IDAwMDAwIG4NCjAwMDAwMDIyMzQgMDAwMDAgbg0KMDAwMDAwMjI4MSAwMDAw MCBuDQowMDAwMDAyMzU4IDAwMDAwIG4NCjAwMDAwMDMzMzEgMDAwMDAgbg0KMDAwMDAwMzg2NSAw MDAwMCBuDQowMDAwMDA0MzE0IDAwMDAwIG4NCjAwMDAwMDQ1NDMgMDAwMDAgbg0KMDAwMDAwNDc4 OSAwMDAwMCBuDQowMDAwMDA3MzQ1IDAwMDAwIG4NCjAwMDAwMTY1MTUgMDAwMDAgbg0KMDAwMDAx OTE4NSAwMDAwMCBuDQowMDAwMDAxMjMxIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNTM0L1By ZXYgMTY4OTY2L1hSZWZTdG0gMTIzMS9Sb290IDUxNyAwIFIvSW5mbyA4MCAwIFIvSURbPGRmODcy YzM5YmI0OThhOWQ1MTFiZGU2ODliNjQzMmQxPjxmY2RlNmMxZGIyOTAwNzQ1OTljNmRkZWVlMzk0 N2U0OT5dPj4NCnN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgICAgICAgIA0KNTE4IDAgb2JqPDwvTGVu Z3RoIDQ3NC9GaWx0ZXIvRmxhdGVEZWNvZGUvQyA2NjEvTCA2NDUvUyA1NTY+PnN0cmVhbQ0KeNpi YGBgYmBgqWNgYWBgFWQQZEAAQQZWBjagOMcBAUEwl0GBQf5HV9phhQSBD+wxKw0YQHpVmKwYtBX4 FaR2iKxgnMdyjUGW4XDD5gcKAuIayXd+bH1fE/f74vvqB18b4OZyGLEJsPhbMnV7HHbieeIh4SDs seiMicIRhiceksyXNDbzcjrA2Ft9DSDiSt0GF5oFmCcqpPCjKeYwZLAUYnP40qUDNI2RU7a0TVF4 ksZmH5C4CL9CCljcQcAGYsg1pwRzWQbHDpfHFzwW3ap9dtZAgVmQ+ZxLY7sa63SPRWcNkE02nqiQ yAA12YHPlfkE1Bks/EAbIc5gBOldiMVJIkBdDgwMxsblHWBPl1c0wCgmJWVzkCiEbmBgNnEHcY2N XUCyzMYQrhKEy8AolpYO4gsqKUE0K6lDjBQUFCyv6ADqZxQUFDZLQzaZgQHCVTYGc8EqwerEILQQ 2AiQIEnxCZQ3YGByBdF8QKwE9pgKAx/jFmEBBgZuhiVWE2oa5zKz8CqVKa/T1OC8oH+gkOmFZNLp xgTGH4wP5BpOM/7hYGBu4GNiYL8ApJgVWBxgicKTganhFtgBDAzWQOzCwBSrDqRZGRiUNwNpLgbW dz/fvJZf6gAQYABM/7H/DQplbmRzdHJlYW0NZW5kb2JqDTUzMyAwIG9iajw8L1NpemUgNTE2L0xl bmd0aCAzOC9GaWx0ZXIvRmxhdGVEZWNvZGUvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDMvUHJlZGlj dG9yIDEyPj4vV1sxIDEgMV0vVHlwZS9YUmVmL0luZGV4WzgxIDQzNV0+PnN0cmVhbQ0KeNpiYnJh YGJgYBzFgwUzzh0Ng9H4GMWj8TEaH6RhgAADAETOB9MNCmVuZHN0cmVhbQ1lbmRvYmoNNTE3IDAg b2JqPDwvUGFnZXMgNzUgMCBSL1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDczIDAgUi9TdHJ1Y3RU cmVlUm9vdCA4MSAwIFIvTWV0YWRhdGEgNzkgMCBSL09DUHJvcGVydGllczw8L0Q8PC9PcmRlcltd L1JCR3JvdXBzW10+Pi9PQ0dzWzUxOSAwIFJdPj4vUGllY2VJbmZvPDwvTWFya2VkUERGPDwvTGFz dE1vZGlmaWVkKEQ6MjAwNDAzMDIxODI3MDQpPj4+Pi9MYXN0TW9kaWZpZWQoRDoyMDA0MDMwMjE4 MjcwNCkvTWFya0luZm88PC9NYXJrZWQgdHJ1ZS9MZXR0ZXJzcGFjZUZsYWdzIDA+Pj4+DWVuZG9i ag01MTkgMCBvYmo8PC9UeXBlL09DRy9OYW1lKEJhY2tncm91bmQpL1VzYWdlPDwvQ3JlYXRvcklu Zm88PC9DcmVhdG9yKEFjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBQb3dlclBvaW50KT4+L1BhZ2VF bGVtZW50PDwvU3ViVHlwZS9CRz4+Pj4+Pg1lbmRvYmoNNTIwIDAgb2JqPDwvQ29udGVudHMgNTI0 IDAgUi9UeXBlL1BhZ2UvUGFyZW50IDc2IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4 NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1 MjEgMCBSL0NTMSA1MjIgMCBSPj4vRm9udDw8L1RUMCA1MjUgMCBSL1RUMSA1MjYgMCBSPj4vWE9i amVjdDw8L0ltMSA1MjkgMCBSL0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VD L0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDUxOSAw IFI+Pj4+L1N0cnVjdFBhcmVudHMgMD4+DWVuZG9iag01MjEgMCBvYmpbL0lDQ0Jhc2VkIDUzMSAw IFJdDWVuZG9iag01MjIgMCBvYmpbL0luZGV4ZWQgNTIxIDAgUiAyNTUgNTMyIDAgUl0NZW5kb2Jq DTUyMyAwIG9iajw8L1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlL09QIGZhbHNlL1NNIDAuMDIvb3Ag ZmFsc2UvT1BNIDE+Pg1lbmRvYmoNNTI0IDAgb2JqPDwvTGVuZ3RoIDkwMy9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSImEVV1T2zgUffevuE87sENkfVmyZjqdBcN06ZDdlHiHB+DB6ziJO7FN HXdp+fV7ZCeUr4QwRJJzj865517J4XHblfMs7+jDhzD9eVdQOMkWZZ11ZVNTeHLS/KBraZlUFDkW CUGRiZmzzsVkY4kn3Dm6DY+7LsuXxYyuw7S5A7Dpuqai8KKYdxRelotlR7cfP56cJhSEfycUjhNO wyqZcsrXxJmO4lhiNPhYjDHWimid14GgEpGfELlYB0JbpmMygnHo0ZKTxX9bBPPgWxAZ/NjL2/w+ ivRjwNXvVA+EyZR4/0fT5K+AMxvRPcU0xpOvJOgzXd9ymtFurmnwBTDnpDCQyp0WXjq3OhKDZPkU KBzjkkS8kbk31wGoZY/0qAErH7FSK6E8WaRdbxuGLdJwzlEj7cF+JmIWO3ye4rmRVgMolJURRuD5 M26pX3BvdQuvGErFq1QHXmN2834LOIkI6iOrHI2sYVb7SDzVeCphlfPgiPIqCM8rTqcNPMZWtKEx zosTOuottZKk3ex9NkYj9V/hdJmhidHM4+T8lCxtes6zS2zgNVmw93mBWiF90k49ZRYD81v7xdv9 3tESTh4hfAvZ9JvP5CQNwjQFPaXzYAQvOdeU5tTPrKP03kema4KXGB+wSlt8ydjLHg0DlspX37ss uUEPIoO0Cg6OKS3W3b/F7DD9GuwBqUixiFvhetT8vWijcQvETvfRTUufLscTmrRN1+TNyoPP0lfJ i23yQ8biacayz3jIVWpQaj/xt4zBWqM9uR6k3RzM2mzeje6zejGaN21erEeLtrobccG6H93N4Q52 uYcdVdsY7mfPNCgtUVxfEqF9x3BU2su4KBcQsLHpdbD0nnEx1OB0dxh6RikTqcHHekE3B3dtsS7q rmhvDo/ooihpuiyPKKtndFWUVbmH1GCGCjrZ73YFfUe0ww21xw0l3iqGsoJJbC5I4oSgw3HgN/WA 7tXijyorV2z5UOasmH1neb2zEmZ/Hzxj1UL7G9zgeOGSwJVhTc+aNKtVsSiomdN5jS6ohnfUb3S2 KvKubeoyp7Ma766iaGHZLhv0u00xzO1LWZHALe2dFrFj9tGMP+H5w7L5/qJEv8IVupTHakjin7r8 r2jXZffT55E0VVWgnY9owi5ZssR7d4fq6N2D9KaVUCqsw8sNDceU42bounHW5kscD9wbXD9l/F+A AQCQpNL1DQplbmRzdHJlYW0NZW5kb2JqDTUyNSAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9X aW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvVGFob21hLUJvbGQvRmlyc3RDaGFyIDMyL0xhc3RDaGFy IDE1MC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDUyNyAwIFIvV2lkdGhzWzI5MyAw IDQ4OSAwIDAgMTE5OSAwIDAgNDU0IDQ1NCAwIDgxOCAzMTMgNDMxIDMxMyA1NzcgNjM3IDYzNyA2 MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3IDM2MyAwIDAgODE4IDAgMCAwIDY4NSA2ODYg NjY3IDc1NyA2MTUgNTgxIDc0NSA3NjQgNDgzIDAgMCA1NzIgODkzIDc3MSA3NzAgNjU3IDAgNzI2 IDYzMyA2MTIgNzM5IDY3NSAxMDI4IDAgNjcwIDAgMCAwIDAgMCAwIDAgNTk5IDYzMiA1MjcgNjI5 IDU5NCAzODIgNjI5IDY0MCAzMDIgMCA2MDMgMzAyIDk1NCA2NDAgNjE3IDYyOSA2MjkgNDM0IDUx NSA0MTYgNjQwIDU3OSA4OTAgNjA0IDU3NiA1MjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAxMDAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDg5IDAgMCA2MzddPj4NZW5kb2JqDTUyNiAwIG9iajw8 L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvVGltZXNOZXdSb21h blBTLUJvbGRNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1N1YnR5cGUvVHJ1ZVR5cGUvRm9u dERlc2NyaXB0b3IgNTI4IDAgUi9XaWR0aHNbMjUwIDAgMCAwIDAgMCA4MzMgMCAzMzMgMzMzIDAg MCAyNTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDkzMCAwIDY2NyA3MjIgNzIyIDY2NyA2MTEgMCA3NzggMzg5IDAgMCA2NjcgOTQ0IDAgMCA2MTEg MCA3MjIgNTU2IDY2NyA3MjIgMCAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1 NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5 IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NF0+Pg1lbmRvYmoNNTI3IDAgb2JqPDwvVHlwZS9G b250RGVzY3JpcHRvci9Gb250QkJveFstNjk4IC0yMDggMTYyNSAxMDY1XS9Gb250TmFtZS9UYWhv bWEtQm9sZC9GbGFncyAzMi9TdGVtViAxNzAvQ2FwSGVpZ2h0IDczNC9YSGVpZ2h0IDU0Ni9Bc2Nl bnQgMTAwMC9EZXNjZW50IC0yMDYvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFRhaG9tYSkvRm9u dFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwPj4NZW5kb2JqDTUyOCAwIG9iajw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vRm9udE5hbWUvVGlt ZXNOZXdSb21hblBTLUJvbGRNVC9GbGFncyAzNC9TdGVtViAxMzYvQ2FwSGVpZ2h0IDY1Ni9YSGVp Z2h0IDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFRp bWVzIE5ldyBSb21hbikvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwPj4NZW5kb2Jq DTUyOSAwIG9iajw8L0xlbmd0aCAyNDAwL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCAxNjUvSGVp Z2h0IDUwL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDUyMiAwIFIvVHlwZS9YT2JqZWN0 L1N1YnR5cGUvSW1hZ2U+PnN0cmVhbQ0KSInsV9mSozoW1MKiFclgLPAC//+XN48ksKu6ZqIjJmJu PzTlcGGtqTx5FjH29/n7/H3+Pn/Ow4WUTX6kaP9tMD8+QNj1vdJKa6VU3zXyj8PJRUMAFbAJ0XT0 3ney5f82ro+HtwSxl8JYZ6131pu2A85O/jkouQSirhV+CPEyDsNgBxdNK4G7+VNs3speK27sFIbo piGMU5jkZAVnnVaN+Lfh5QcYrx2TcXBjcF4ab4wPZpLcOc5h8j8BJW/6a8PdECcrRYhxxF+0XrIw WcfZn4FSEkbvXLQGUgyGQ6Lejc4YC3lKflU/6bL/PZeS8yz/d4i87a49gzsH5kdHC/K8exsGa9wl etZe1a+A1C391vLN7bZI9u2QfNb41vNv+2TbqCvjdnIyDJ4WsAExKABVG9FGgdJfe1FRcikqxtva /aclv5xovt2S1Gld1nVRtQ2zFVPrTf96pjX9RLzs762UzPsAywrDuXXRBcuN58w5xiygX/VhcL2u WpSt14a91+votfDdpC8Gntfb+Sx5Q93SETXal8/j5B2oES/fgLaNtsxAiGaQDN4TWAgu+NBGvLIY 5BQCN9e+TluwVTYV/qe06LqLWml/DcMykbBPX1cXzVLxgUmiL58vNQfw5uMwqSsgb2rGwl9Aiv4u +WCtiNAkHCcw4UOAitwovRCjDz4aorLAAYLbXP8TzmOHDGC+LeI9BGurRMxkRLpBYsispNsqy/T1 hMKblLXLemqmvv4TJCnSjJMNkfExWM/sODrEIMN8sI4F1w7R8nCtYShzoJioTMx1jwMkGXQp4Fsx ZxbXbO/1bUDY+sozkEVWFUmyfT5xOpSRPpQA1w5tiCOHFxsESh4Bj5NrBz4MjrfR2DgyeVfZ7/uy I8GpROa15IK2CjIV8E2GeJh1/SQGhKfSAV9Kc5lI54CZb8uS1NsWp7UNj86aCGceIos2M8MgUSPA IbPBD87zUTXga12r/tfCkeyXzBCHCZkS+uyas2gX1VVJrupDfX2ZnQrT5D35YNeGJraZ6lv6zB9S 3aV0cA7L2ukC/RE1+QP7j5eRecfRzZ1u8uT8SJU9QdF+AMkVFAWrLqSrucoA0iMFqNO3T/1R05oU 0HSNWos70SjCnFinQEXxG/4GOXI/DN7CYdwowBk3SIsBI6Lxk0VGl24AoQDZVsEsEOaaxJUskpHe 1o8wc2o15Z0W6pxJJRUl0a1b8mYa1GVkAFncK9HAmVUaD5SNHpGiB+M8c+PonUAwd20Y0YWIHp2H KEeADJrsVbBkl8XuC5oo9My3X55TUek29wkw5hoUycU0xdLMncryI5DFvbKG5wqxn5sTZOTBRW89 t5epjd4IuBAbEZehxsvkQWhwgJ1BzjnaIUAW7vLqTQVZ2FzSB8iGeCIt3LRYc4biuUEv307UVT9a OkWuo6t/dV+YjMQkH2NrY0S6cRblhRvJc5iIJFleQPIuk/kRJWGn6giLKj41nyBBF5Cv2cvJ7LQn XltdZl8bhbCNp2OlhQb0y3nEdMoYILlBSQZN+nih6MPEGBAZhRDIiEHISFE0a5LVYJHa5QMkssZM 1CysS2ecpNRG4FMJlRnk0pUw24ueDrl0bYvtZMEDNYJAPr9dDNwfqb5Rg5R0pXFMwrupKThEzCxb eDdKOISgwFwBWWiirdLploodYZwS+vzmohpxwf9FzFmTujhQX/WX+kO5BVmJBbo62FnBIAR5uLUT saVgDveJI4ozVL2Ue6KEMsOE5jGDLEGo66m6KPYrIHk6QNb4Pb/j4SKJ5kaXgZl5dmpyPUGm46WC JGudIPsrXHcYJdgClaOwEKiEAAYhL5ODJI0zQRgK5qzWBYoYI3pkJktRIiKQOUQtb8dB51odakVE rDkfSnj7TY0CcwWZGS4gu4801XY6MrhG6xF1wjCNRiIUjeDRD9NkGErLaUJldKW0WP2FFEgg1z4n FFWDX3Zd8vxb3ZLOcbqYLCAblHHp4PssMA4mc1AtyMkqJ0h4jmGDc9Al42G6wEnIe2ScLqSAsXVk 7ah7Uc0H2REF/UESQHZqPZjE6dfqqAQyZZnq4kGVtmyPOSOVX0FSDIWiqJQiYS1nKoW94SjhElrS IvR3QQXkgAw3W2jTIz5Z3Ct0xw/JEbS16Q+LoZKeS/Bh8I5UOMjrA82ilOp5daECkheqM+vH9YGQ dTJrRtOp5jLmzIui04PBFQe3sAG1ONLLcBkuwOjo/oCsYwbOoyZrVyktzUxqqSVhYrUjV909ZYt+ WY5QcHCVjVCMy+ezDj7vHzkylQjRnXr9LCmlukbkwCmi3CkhyMpg6WpjRitH1B4sZCKp8qaEs9a0 pZaUdMcOkL9eTeaP9IjA9L646XrY91CKQV3KtXkN9ctZ9eeTdRr1RIgXC1emlHhQ7GB/uDn8atT1 9tDKWkCXX0cJQMnss/47jJj0+zrI1Ufx1VHV9HFV5O374st7JKF+7r7eJEWvYWiEIBZMiLCwMcYH N9rWSyaC5HFW5xSe1vmX6y1dnMSvjT+Me/c1/6Xzh6eFwSFLxv0EpN7a6JyjNOmoYsOV8a67HyD8 n5+2UTOhdGPEtcZ74w1HgRlw2aELJDDKx5M92DN/Hs/XY3s+tm3Lja+NmvCSv3P/9nixBw1oMIbh J9vo18YYPuhpHtSeO9hje1Hr9ipfZQ6mbzRo+wDJM0oi0ck4oLwYrEE8N2DUmOudBLk/2M62/fnY AWrHB0B3anztWCz35jGPvaH+DW84yAPv5e+5bU8aiVEYns9HQ+ikOzqeNIi+no8XfudmzHh851Lf QZuHsZ0ZRsft4IQ3LNyJR872fdtp/cdOCMEGe+4CMLER3rYC8okP+p/4LlthJ2qhXoxr912APsJJ M9DCXnvDaE06R/6i4+HMWO2VB31FKYFytJAebO0sbg2hZa2/3uEzwMi2zNJOjGBbcPoiSNT4Bknf 1P+g4xCLT2KS+MQBCVw2757JfD4xjYA8y7pb/XoUa+zQQKH7y8NFB5h3G0QuKQHbg8UZps5+TXhI W9vGgWsnDveMTdDBiV/aH+tugkDmT6aZWMstFSTOt1ex1ZnZQls1fbZTeaE9vnsPhAmY8/1+vzqr 3XW+z7PqG/FTHHl92oHeXy96e34/eR3w+vLzeUaKJzrEz3Ne/0gWqzADKM5Z2Dk4ODk4QQBY57IB nYivrBsYwMjKysQCA8xMrIPPhYMWAAQYAJ5L7lsKDQplbmRzdHJlYW0NZW5kb2JqDTUzMCAwIG9i ajw8L0xlbmd0aCA5MDEzL0ZpbHRlci9GbGF0ZURlY29kZS9XaWR0aCAyMDkvSGVpZ2h0IDEwNy9C aXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MjEgMCBSL1R5cGUvWE9iamVjdC9TdWJ0eXBl L0ltYWdlPj5zdHJlYW0NCkiJ7JcJVBT3Hcf7Xvteo61Gjp2Z3Z2dPWYGwWjQNq1GTbyCRBQxGn2x vDxvrUbNaYAFZndhIXgQTyTR5LXGqLGm9UhftNF4EJukidaDY0UUlRsUlnuBvfqbGUDE6GJdwDj/ z5s37P73P7PDzGe/v//P5UIgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBCIRx2n0wm7tq3X ruIerxGPJU632+V+JHAh3ySA0+V21tbZTn935VRGXkbvbd+cvlJXZxOsQzzmQLhcuFCo0nK/9Vk1 AIvy6Y2tv9+7mEKfmVUsJB0KuscceMrwrAcNTVJq4tWMUc0Yen4D4enAhGxLCVJOCgjKlQwKFpXr Bd945XQcE2jKySl1o8oqAZByiB4GKYfoYZByiB6m55Wj7mpSkHKSooeVUzFGnDGTd1qHlJMUPaUc BxvJJDyti4qjwsfoViiYBKScNOnBlONkrHk+FVkm81umnuXHJiHlpElPKWeEWAvWReXgpF3Wd5H6 T/5IOanSYykHjm0hx1llPnk4Ga5djLNmdduKTqkz6AITkHISwYvKaeiOTYGx1SjaoGYNEHEBdOxp YuCPOHOW0I3TLpezidC6qliTkk3wpxMUQe9lIeWkgZdTjhX24B5t1DAGiuUo1ghqydikZFXoUSLI pJp0HtcqGdMAdjU4+Qf67WmahZwyLFUzqTArHy7G6eztO4LoZroh5UA2Tli8JRJsAs6Y+wWsHqtb YcFVs9Tzt5FjMnHKqAr7mhiUQ5DXMMIhe8Lt98sKwr/6YjavXG/fEER349WUM4pBB8rhbJIv+x68 HUxHD6WjUlShN3BiHRlyhqCtWP88XJGLKU7Kg7IxtVPWp8a/3zb1+CvZBUJhRdI95ni9feBXaIwp nppyDtfm4FQBjldhA2qwJ88R2kOK4Ku4Yqfy2UBaP0H72hfyYY1Yv0OKYaPUK+VByVmWUqScFPCe chwlvCAZk47mjsoHuf1+4Zb9yo094cT6fEewMzXzxmuX/0CwelUExXC7FMMdsr5H5UMmapf56sxa 1LFKBi+mHCWs4kA8FWMYrXtjrjpyJTXzU+UIt+zXx4lBFG2g6XgLRn2LB1RiPtBEvKyZjzFJ0MyS Oo5BykkGL6acsInLOehSTTLWDGn2Lc7sVg7fQI7frRixgppZh/WHartQHalgTQSTKAajSouUkxDe X8uxIB50rwY/Nmmmeq5V9uR0zYJQ7dI8XJlJUDbsN9GqCJCNYMyQe+IhJK+cCSknEbylHJ9XNN+r Cm+NOJv4jG7VZYxcQ4a8pF54gdBAEwHNQgXmP0r3un+AWcw3OAQ6XJUOKSchvJ1yonIQcclQRosw bJUqIoMIysWVh+VDbLJ+hRgGymGsueNRSDlJ4fXCCpucTXhB+1oBjlllPuWY7/vkBIxJDNcuaZb1 zcUVf9S+A4UVKSdZvK0c3z74sslxqnCbf58DiqGjdG/I2GQ5mziYjsolyFycDKbfBSeRcpKlO1KO YBOnaRZtU4wK0y7xZ5Oge6UYo5Ix7pf//rj8qYF0rIJBykmX7lBOwxiUrAljk0jG1DEAaSaeZWIp IQmRcpLFq8oZhT6U48srywlqcR0nUPzW2TeknNTwonIatjXiePdog4oWDfS8IeUkhTeVoyHBYNlm wJR6eBs4xKyg9OCemjVQLFIO0YrXlKMNQj01YSp90BDz62/uS0w+PPL59xWtp+WQcgiRril355KM 5mAyoYqVKWMg0HBVrEITR+riId/8iZhZs/9SVFLtFjh7voAJNJLaOFRYEe3cRzlhtc+paa7dOoKK 8yWiIcTCp334TvSB1PUnUtYejeUOzV+0a+z4TTJl9LLle5ub7aJvlVX1i5ftUajjPa7okHKSwlPK cWIHCu7hZCyp4154cUtSylff/+d6YZG1ytpQU9tYU9tguVRmNB2mA43HvraIvjkczg2bTmgCTEod 11Z2kXIIHg/K0XwHKqfiwIqFf95jsZS57+RURt7cBTtHj9mgHWhK3XBCHLRaG+bM3+mLR6l0cDjo akQph2jnfsqxBpXW4C+PmTz1g3PnC0SdXC6n+KKkrHbhkt3wKUHF+mBRYVPTa+tsMN7U1DLjlY8G YFHt1VmNlEN04L5rOU6m0I94bv2Rr3I6+MYfUlZRYzIfITXxciqW1MK0mLT0DHHOoX9eVLNGWMJp RN9YPujub13XlHP23E15MB7ZC3tEuVM5Ts1yoiQqbby/IubtqP119U2iCaJsLXbHlq2ntAEmyDeK Nig0HPQUn3z6vegbiIcpYkBCjadk67pybuEiAafL8VPPF0Yc4rU9XEby54G98C1dP0TY3Lff8niW EOa42hcn//cV/0zplHIaRuxPDX5E9ISJm6EvaE03oZ7aWxx7/nZ22PDVvkQMpeOl8sFjJkWk37xV B5/W1NqmTEv3w6PVnmLtgZSDxwNnbmxsvkee8A/abrdDI2O3d92We8DrwkvT1dltsS/cIod4oGfl nK2+3bxV29DQ/HBX/PPjrsJqpHScnzxm8dI9dcLarH3x9sOZGxNCN4NRSm28hjVAxPkSUXMW7Kyu bhQnpKw+6otHQ7Og8dSidl05GKmvb46cs2NT2kkh6DrrIP4Wsi2lL83cnpld/BCh4RRPLoaqh6nC ZNjBzKKSml27z1qrG9y3z+EBOKq6umHR0s+Cf5fyj4PnpRZ0nZSDpy9T6s3JR9ojH/40N9vXrT+u pjm5qlVLpZbDFPqEpCMOB9x2/s5bckufCk6Wq+N4aWmDtworjNTVNYVP37Zm3TH+U+ft8Y5czCyG n8Ol3LJO1arTtLtH7vrU1dxkv5Rbfq/5d4/kX6vcmp5RWdXgaeYd/9QHH34zfdb2RluLswtf0Z3P vxdwd1AO0glT6p8bt/FyXrm7Q759tvfM4GEpGKkXyiUHbQUs80ImpeXn32qf9vcD5wgyVgWysUaq y7J1UbmIGdvWisq1DcL++vXKoiKreIWgXOjkrT+euXHt+i2rkLqutgdXXGK9mn8TfjXiYF29rays BkpgYWGVzdYCgyWlNfnXbgm/HZ4TJ3M545e5lyuqqlrTu7y89urVm42NLeIZ6huaSuEMDkdhURWU xUZb88XMIvFUQEFhZUFBZbstcPF5Vypqaho7/mtw1Mq39s1+9a/tBaKkpBousqmp7Svq+a+AvCws ssKK4jGzDv6drKxiCChQTqaMGRuyqaCwSvxpwe5qfsUrkTuggJJQTGk+uEi+7EavePPzeqGtcDrF nsI+b9Eu6FsfyLQHUm5N6rE2vV1Q8V+d90nolLSRz69f+dbnsITLvVw+fHTqxMlbZ8z6+Jln127/ +N8w+UZB5ezIHS+GpU17efuYCRv37vsvDB784sL4kM3R+oPjQjZypi/Nyf8KCUsbF7IlYvpHxSXV FkvZ8JGpQU8nT5qavv/QBfjqBYv/x315eEVx7XH8H3jnncSnARGWJYixJLErGhuKqHgwdo3JM3bR Z4mx0BYWRUDAxroIyLpKkd6lSJPisoCUpQpKX0qUsrSl7szyfjN3ZtjFxBxyHuflcFlmd8q9c8vn fn/fX6DxNo/v9/qsM3L38hZBCy/T38J2s7CJ3bSVf/FSRJFECj+Aq96+wRPmgTv3+Jjt9r74awSo ZXZOHbz34I/Cfx/xe1P5ntkI+RLpN0uc5n5zEwYF/MNdk20eu+AVG939n72GB+ISy2Ah4BXE0TJ6 CPaLcgIW829eSJVrBpXTYnFmaFvz+OlIy+EfRmrFidHU4Wjq2rANyLTCANIKq1Xr7kqKmxjJh6+e nsF1m3gzWZzJR46IfR0yuSUnRpRdw/fIXL3+3ocPPbDiK7+74+ySUlAoPWketM3ME8TBRyg2XHM3 JqY0v1B67GSA2S7voYGRuIRy/XkOHp5ZsXFlUTGl0GxUTElKatXSlW4JLyo6O/uPnwra+4MQBPND W290TMni5a6BIYXQArAN/LS19WVn187/1snRJTkhsSI8QlJYJF2z4X5Dgyw5rXK9sXtObl2WqGaj Ca+8rCUgKB/2ckFhw/PnZdW17cQOJQfV3TN45nzw3oOC+voOX/+85atuR0QVFxQ2mp8N2bLdS94/ /CK5Qn/ujfu89Ji40sgIiUIxRWBDhUCurGX+Qqd/Trews49jeKuuaTfZ7vE5kQ5wUQYKQgdp7IlT gbIuOTwAYUVGGBgiHolz6iCh0NazmyTkQDoYlUP5ngLD09IqbbnxhmvvQlfBCZiYelSSXg6i2KIV LqlpVXsPCKJji1HkkssHQc3iE8uTkt8Yb+UzcRBKUVHzI0E2IOcfQCgM1z7+9JlgdMv0+4dPnuYw T5ru8AoOLczOqYV3tf5GxfTi0mYjkwc1dW02ts9XrL5z2SLq0uVIQA5ohAB67NQzI+MHqS/foc7j dL7j4Jhw9kKoYkSxY5d3cGgBagoCq+kOz5jnxakvq0B4e3sHR6mNjaPM5P9CyP+8kCrXyp7DhU03 NEwtROrLt18tcNDQttGlswANbWu9OdwnvrnogcDg/GMnA5k54XtlzWTZsPQnCzlQuXu8dGbpwQKZ mnmGRUreVH3YbPqwQdr5rrrNaDPv7TuihcSkimWGbmCNIMxZWMagKrl59SAmlVXv4xMrYFkhCKLr 5udCbGxje3qGIOF9FkQgZ20be/R4ALp77kLYKRq/dzXti1e4inPrROK6rWYPm1sp5EpKmo1IN8Lz yDAx5QNmcLGrq7+jo6+btHDw0vmLnELCCkep9IdA7rpDAoANp6fMg3/5NQI1JSmWLjd0A5+TnFK1 ZbsHNIKsCwJ1qhBHDB+89+x59o8EIjRwGOmhn55O++Karj7FmybLGsLrNcsYOTmfYNo3bnnwy9VI xpw4OidB3jF5yJnt9D79nyCIWRlZ1RmvqkXZtV8vdgYpAClbstIVDH9F5W/LVrk+EojBPu3e//jQ 4acjIxg4upWrb0fFQMySnjgduGPPo6EhBYRRY1MPBrk1RvccXZIaGzvBFjreejE8jN3np2/YxEvP rBbl1AWFFCxd4QpHaOHSlagNxrz29r70jHdg3ppaumhOmr5bf7ehoSMnrx7U1VsgKiltBvxevapJ SnkTEFhQWt769SLnJ745aHRI5Wzt4xDYvv6vlxvejoyWQGA9ey50m9nDgcGh5/HlGzfzyCBCTgjF 3BQpMKi8/HrY7Cina26Wbd7Gn65pxQJ9M+Dq6NlN07DcbMrPya1HM5yZVb1wmcv0mdYoHKD0wZIT O13LWlefq6tvx4LjbDvyQ+DEnm3PJqCC3MT6jyLvp5EbHBoBh/nzcf/DR/0OH/Pfc0CQlFIZn1Bx xSIyNFxy/WZCQEA+7AUA4+SZ4KMnAiA+klkeUTcnp/785XC4+FiYO0AG09f5DS5uKUxghVOIg0/9 8tz5GbBx5H2g9ApPb9GR4/6hEYQugeu4ahF95HjAQ8/Mzm6CgZKyFhe3VJlMjl7RIO1wcExEBJaV t1y+GnX4mK+njwj8LcgvoAV1/QJyIZtQGZQyPKrYR5BN96Hx4uWIn08GeAvESCQBPyeXZLl8quWq qBBzWNoMaRehb90D23d6z9CyJDJTcG4alhChwN9imBJNDmxeyFghyLIN7EEuRkk/DEcvH5GGDgdU jk0bPxbCSZ+ro8+dpmlluOoO3zPTcO0dLd3foe4TyJE9VI7+WVGSllL1ghLH0OjULirpx8hAhfaL +hPYqEqtj1pQvUIJD9O9scbp+2o9p0aDow9TZXwt4jlMrcaUKzC09+97wXjAD3FevY6+vTabM4vN maZhsXSlq+CxmBGEzFfVy1a5zZhpBZIFREVESdDSwTErqxquzNKzBWHUpajjsghuCZE0mO/wRCiG BBPkcdbEkVN+tO7kwqN1QStORitVGAgDhBFH6qKSukhhQHkj4kC1wFwfq6IcRVTiKm9FkCnpfpKx DnFFscQQiAy/2ilZBaNHpKSRU6rUQu9n7k7VgqHFgTG63U7+x2dXZs91ANsTEibpJ8ITUUZGFI63 kmexbWayOARL+iB0NnfvpdHIEVMEfviz6RYQcDV1bGZoWX/+xTXWl3aQuPE9Mjtl/aHhRQYLHLRY HDaFmd0EkMMREjh1QqIyztqoQkU/hr5xWlgwHJ3g6g8QDDC/kWfC6Nfg6rfI5saqq/5gMkqcgoY6 ZyAf2y0U2zTyuEpTzKDIWR3XzwmUv7NIkuPBMQX8EaKRlFKx/wehrX2COLcWw8YEPyxCMn+hEyQI hFsjIfmXpuWFS+HM/oUvMPD7DgjnLHDQ++o6ePv1m9zPXwpLTqscGVYUSRrXGvFmaFkx1ScWWNXm EKcWdSyFG1tTEghqBfGxEaqyStVSIUl1uREEGDUvDHKqNXBMZfLoR3D8d2inM4U/KGP00+/FaeZw JS16E0SO0cwJIId/1O3JLwRyOPax8yFKWUXrj4d9gRawdmx1SPTm2KdlVNGRjKrb3tEHRrq7ewCd 1tS0nzkfAtmuli7nL2esQ8OKoOACkbhW/S4lKXCtq6efx898wM9g/BJOgamqVUhVEK7jpJK5qFRv H1NdEGgc8lnyKYyKuLRSMWDSPFMvgg4XFjXZOyTeuPnC2SX59v2XN52T7K7HuT/IkHXJ6T2CqbBK xfGengEfoRhSOdXgq6QHwWwfqhI9ZjQIqBISViTKrqOiPXMXx3FcZZD0FOFMf+lZm2z8oFudXfKe 3sFxsJWUtpy/EAamTlPHGsHGMlCLhrPYtgbzbnj5vOrolI/bvVKpDCDZvV8A1TW0OZDGfoK3P0Wu t3dw63ZPx1svxssEyVtf//C+g8IDh4TRsaWj6mYep5eATC6ID2MDmJ2iVP2tVNLWjtQXHKN+Ey8a bWzs2LnvccWb1tGxTIEOkXQAZSQXrTJ8V1W99xGKnvrlmZ8LmfetI1AnEGYHhhT09Q6o9BOnfSZV mppli5e75ubW013DyE1NfhirSZM+qtJn1NUdu7wdXZPpflJ3x+K9WkZG+Vh6CKMos5pc5IiY2Or/ 7HVbW69CoRgYHJE2yeISyn464qfzJVdjlg2L9F1sMiNQ/bD1uZraNksMXZ1ckv7LfJW4NXVl8b+h 881XpzMuY52OTjsuxXEFEZBVFCwgsrkhbqN2rNQFCoiMIiKBJGxhRwFBBATcEFBxX1gUQQTZEpZA CFkgBBKSyPzuuwFZbDv9Wp15X+A777x3zz33vt89v995/LS1oVHU8EZUUSXIyq44cDBnmSELRPzZ DHDx5IG/FHIKxZCdQ/yZsJKR913dor6VqyMePmrW6Sb3tuMY6ueviR+C2XqKtA6JVErOFE4WO7Ks o1NGP++kiUYmT6Qvr2AQlWpYo9GlXXhmbBrRyu8dHtaqhzUTZ9bRucYuzLLciFVZKXgXbQpHj5bE CX56xJxcEkNZpfStyUN07+d62teMvfahIfeypmP2X0/8ZV7QSuPwpSvDwJi/m+bz2Sw/AjYAZg7p PWdOgZweLbOPf8o0C9Nm+KKn+OTTo5B56CAAV4rVWV8EMoj9VZDb4BQXxnQr8YkPklMfhZwtOfh9 7pvGHngOfJc9Y47/Ns/0ri456iGHe2er53lf/8K61ySaUqmO4NwuLq0PPlNyPOgavng4pywjs+KH gMITJ67jy+bmPffcnX4u7Sm+xdCQOjn1scfW84FB14BkDL+U8/zvi4KtbWP8jl/p7JIHnylubhHD LxL1nWWVbvFMCwy63tJC0hD19Pv4F+bkvjh0OC+cfUs5RDovfeFkvnv2pUroW6FQBlszrE1Mebxt Z/rZiBJwKD0XzyoEB71zsJDLBS+EXXLjNWxewkMfv8Kg4Bvov/DOjZt1iJyQ9GjP/szSWw0UHsrB YeTsuTP9O++cJ09bqXOja3JoONkumXwwmndvm1faUd+CmpoO+hRlwfto3nav9H3fZmNseMTtC1kV 9BEv8UFc/IOpX+E3h1xNrXDe/FOfTDsGtPz+s2N/mOk7fTaB2SgkAgjkvoAxFXXwBAAwUHpQa2hI p//ZH7doaSnSmBcCJ/WnvxhyA0MbHONYDOR27MqwtI7+l3euiQU3IOg6PLv+mfmn2f5OLslt7RJe 3AOTNZwNjgmmFpw9+7L6FUODSpWjc+Le/dnuW8+vtYu9/7Bp/TfxTpuSdu29YGLGOeJT8P3RfDvH OGMzdktr7+v6bnuHOJv1PJRoXgLZ+RMni2bM9jM15wLhza3iJUas8goBsgoJLV5txt7gFL/anOt9 OFel0oIa5s4P8tqVuWtv5spV4bfvvtGXi1HGvMhArrNTDrv0Vr3V2mgX9xQLmyj4RxgN7LE9zdQi 0taOB3jz+b1ICSp67/6LK1axLmSTd7jRZQZLQw8eyrV3inNxS5H3EWrOzq1abcFBJpZro5zdktsE EjidXVNY7NsEQgn3jddw7J3izawiPXdmSGVK5aB6976L6x14ZpaRCw1CwG44ifaO8ch1YEBlbhPN 5pR9BMjVvur8alEwMDPz50TXB/oxkAuidWlc6zcKOYXK3jGBxSaQc9t67uRpIuqqnrcvNQzr6pZ3 dsoMjSNQ33Dwl68KF7STPddotK6bU339r6hUGkubmFMhN+EEo0kkA+ZWkZfzXzAYeAFGljEy3sUj JSz8llQ2qBgg1el0aImRaQRDcHLrdbG0PoBeFy0JfVXXBXEOpInF/XAODqrtHeL/fapI3KOYO//k 63qyBBRDyBI9073V6ysCOXNOt0iOIStNIoJOFb2sFcbG3f9y4SnAwNf/qsf283S9yFPQLgWxlt4m 3Rm0n6llJAyUIyfXZBhDQ8PAxvWiuqbmnoWLT1dUttG5fPyuuHqkMstJjYm7V14pWLzsTGOzmBKu 156swz6XUUJt1sfSxOycEl7Wdvb3DwKWGZnlSamPza0j+/tVHwNytcKvFpxGO/A/wds7yP0EsTrG hzOQA+tFx9wjYuBlh6kFt5UvaWrqWWHEAquiLrl4JI+Jkwhu2XavDLl8EBUgj8EYLolEYWUbW3Tz FeyCwup1Drw+RsbvPZAdGlY6ODiMWgoVdMy3wMo2Gv7Gph7ztVGVVURTIZTBstCGBhHedN98bmwi 8OmO3Rk94v4Fi0P4gl54IqPvbHJP1suiUVmelV2JLysS9UuliiUrzvoHXgMIMy9WFhfXAw8ACXA7 FhPEumJVeHk5mTc9s9yMgRyLXeq16wKMAaXqm40J+VeqH9xvMjJhQ37TUQAhCimmc92SAsjl51ev teONxYQgwTZ2C/vQyHjtueC2OcXFPVUmU+LRlau1C/9xBuAvLnk98lG0HIj1bwuCiXibEzgTyu2j /6Z/HvD53BOvfqTK9aPKOcRTYgU/cqPuwqiubjcxB+R6G5vEyw1ZXUJZya16GHyGWbRanfvWc/6B V1EQ0Hrk5FbRbe+VKCxtY24UEcjl579Yt4EHIMEG17C5d548a0UFqG/ovpT73MKaQA5lBKWpooI/ wvQpBsvOospdyqtabcaBeIMTrcEGp8TgkJuinr75X4cgH8KAkWWb3JNGIadfBboqYzOusKsPPRrY nxtVRlNClUa23kfynF2ThxgFiNUL2iTLjVlPGW2WlqGHXBj7lqcXA7mBIXDl5cLqlpbe+QYh5ZV8 Gso3oBBcDGOTRzIkHLqPr5eG4tQweYyA8Q8cvERORMxdQ5OILZ7p12/U0oHoHJeuOLtoyRmRSPGh S9xbfZXr/HLBqT/O+gHNAtMpfOzf9NkBc+YFvqoTjoxK7vHpocoRYqWQ23YOkoZADlXOnMvnS4GK ZUas1laCNE7UHWMisRLMLLl79mcpFGqlUgVcXcqtpAAAsVoTyNXhJq+g2taeRxURhF8E905VVTsU GoC6e1/WAoPgwms14DjvI5eXr2I5u6WgNhquZj+r4CMrUKexKZnI1Dzy0OFctVoDqC8wOM1nIMeJ LHPxIJ/+LSG0US2XTbWcDPbTcgGQDCFnYxfjtSdjQKFCE7FtRzraN6t1sQcO5UDqGJtxcAQI5NKf rLHSEys0PzmDAyjdCRcZgQctR5dsaRvt7JbU1kb2wdElKSxCr+VWMXmusY709MrAiRsh4uQ8BO3N 4rpOYR+FHJgdU4DBR0vch61yuFQqtUAgxQlt5YtBDXy+BDb2sFXAGPpbMQzyVED/w09f7qVO8jLj f/efBuGTRxjOBOllbH2cVv1YOq8Eumt0vROWjLqH4gDpC7u7u18mVzI5a9BvAhL43O0d0mG1ljaG aBlwrkU9CrqZWq0WJAU1SEPhtlMoG1CqYSsGVJ1CuU5L5sIxl0oJxUikA8hErdJA50NO05hoDVDi NFrSIwwRFiNOgKSxSQQM04mQBgQY8kE0ZNjV3Td+BfhDYkgYIpOeIxgtLeIOBoFjF0Y1N4txCjQa XXuHbHCI5NnXTwaSsDIleJmsgmyIHAFpKFTapmYxbUxojYLElTHbReCkVDc1iTGQPkXjg/a24EpN DO++kSk7KvouQ9m3rdZF43jqIffBEfd25P/mGmvxJqb3dvTpZGPi2MnO8Z5JKx1nj/f/VIT/fqLx M07d5PErem9u74080fjRfRgfaupTMPgmd4jGG/QWPc6+b7Ox3xtdkn38CpkhOt2U/f/NL50+vJbW /xFCbThGWupnptdN2ECd/hj8h/0y62kiiuL4J/DJr6Ix6oNG4wYElyDKokHRiNEEDJtAjImKCO4g 4AZFETcKshZbkEYp1A15sLKEtFW2oGyBCjjtzNQz9965baHhrZq05xdoZs6c3k57/3P+5/AvQgOQ 7/cX41VLjSipdG3fRPJVA/98hTLwQ3e9t0bHV0DLF3OoAtrdvoFxfVvv5u2FvyYc7sAPDj5IIABJ EKjSeGn1qMWTpwhGcTFqUk6niz0dsgx+BPYEtjI3uwAHqp3RB0eGTPAmmelK+V9ccEIaHbhk/oFI YKBPtCi63rQPXMh9nZun7+yywi/f2WWrqPwgK5VzucME6kZIwQFJiHujHtTU9nipnRUibQ0EJVVa SrLNPplw7EnsYU362bq5uQWa1mm2wbOzW+nei6LjNDdIwy+r9e10cnX+tTZW0Ugw94o+PLJ0f0x5 yT0TKZK0XIqovIDA7MnbXNz8lGZQVw2013CXbGq2bNlWlJBYCV2rm2w/vFq+jeUVGKDPTM2sM3Xa uIQeV308fvIpHJAG3knvkd688e1gWuYr5rkS8+vunqGdESUg6R9D0/ybZmTV6Vv7oL+F2W2KdO+o tdCA6lzOyzfcvG08lvSst3+Mq2Jicu78Jd2q1elHj1fB7Mkl9+nz910RJc0tFlVafB233tB3Jq1W jTM9l1WYz1/QpWbUNDR9Je2fEszKrr9VaNS1fDsYr3GQ8VBmnovKC2bodGD/PrFu47Ubt417oh5m ZNUzaZG9f6ntvpirKy3tgE6PDQtEMHb7RHRMeUpqjSAo7ZyoxnWveyFIZUwXdzgWd4SXZOU0Jp16 cSBOA4WRCjL7XGNY5N21GwqgZqpuTo0VCWLoLODWtVjWrC9IPFEVtvs+CGl+/g/VDJim+YPt58/Z DpMVxgHWbsFIS9Rlfm/fHlY8MjJNJKfgV3J9/ePrNl4/fKTyYKxm09ZbwyRfqXI5DUXF7+6XmU6n VDtdIhtnscQFOzCpzC8IMYc07cYB1uenvHyo6eJDBBUP7zDJbOtubevPv9r6Qvtl3/6y0dEZ7+SG JkvSqedeTamcfEZbrjHTCBRSKG50weRUbfkjJZ6SVnvxcosoElv9J1MT8h+B3Z+cckARkyTWjI2M zpjN9pX3HVTa3Py18E671frL44lkNVBgd/eQ7GaLC4JgMg06HHSqlWemf3d0DIqi4sU9PcNW6yQc zDoWDYb+3/MCESkaa/AjiqLMyhirVKTgrCQ5Kk422zK98XzJe/QEdZHC6HVJQVyymssFd6FUOAl7 ueCHVSdVM0tO/b1BYpeokIiEWA9Gr5CR1LMg15uvaXri/JWvjAQ10op/y7J9VCGpQU/bTxJEmUnR s476xuXr+3wKqi4EoMLgfbvktekr776PJr2V4leWntOlWpZQaCFMIDZ+meT85+CgiiAIgiAIgiAI giAIgiAIgiAIgiAIgoQEfwcA726HCQoNCmVuZHN0cmVhbQ1lbmRvYmoNNTMxIDAgb2JqPDwvTGVu Z3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5hdGUvRGV2aWNlUkdCPj5zdHJl 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+woNCmVuZHN0cmVhbQ1lbmRvYmoNNTMyIDAgb2JqPDwvTGVuZ3RoIDEyMy9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIn6////379/vn//+fnztzdv3v769fvJkye3b985 d+7c/v0H3rz+eWjfuy3rXz+4/3VS16NL5z8tX/giLfrG3OmPGyvur1l9bPnyFfz8/F1dXZmZmTY2 NnPm7Hm2deunmzd/vX9/saxsm4oKwygYBYMYAAQYAOsHRiIKDQplbmRzdHJlYW0NZW5kb2JqDTEg MCBvYmo8PC9Db250ZW50cyAyIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDc2IDAgUi9Sb3RhdGUgOTAv TWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwv Q29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NTMSA1MjIgMCBSPj4vRm9udDw8L1RUMiA1MjUgMCBS L1RUMCA1MSAwIFIvVFQxIDQ5IDAgUj4+L1hPYmplY3Q8PC9JbTEgNTIgMCBSL0ltMiA1MjkgMCBS L0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRl PDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDUxOSAwIFI+Pj4+L1N0cnVjdFBhcmVu dHMgMT4+DWVuZG9iag0yIDAgb2JqPDwvTGVuZ3RoIDExNTIwL0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpIiZRXWW+cxxF8318xj7EAfjv3ARgGLEoIFFiJEy7gB0UPDEVJNExSFjfw8etTPdPd M0tJDixBXG1xjj6qq3v233483ry9vDqar7/eH377cG3231++u7m7PN7c35n906f3v5pXvmw+mNS2 5JxJuW6ttFZNqR6Ibc283n97PF5evb9+Y17tD/cfsPH+eLy/Nfvvrt8ezf5fN+/eH83rb755+uzc 7Pb/ODf7l+fWjG/nF9ZcPRi7xVSrx2fGn4LPiu/BmIeru50zN1j5V6x897BzsWyxmuw2C3uit6bg 38fr3dvdz7uU8ctuHv/+LEVd8MMTczcuPL8wtv81F+d/39mtJPOLqeYlkB+NM38zr15b88Z8+a6L 3T+xrTXvMky1LToy3ZaY3DDZrxtd26w3rrKZf+jr2Bh930m7xl6ve30MLtBlKbYeNnzIzmytRY4i bab/ubrVhj/rfpt9idjoQvEJn9hvT+728dHdYrcji2Gp+8TVcW/OX7735501LsH6VEIzZyVvJdJK oBGoR6gabU7m6na3f3FrzbN7xBhHGb4mNzLOxdRDWrzxhc9+/hJE6j/2F+8vQWKQ+eX5i2c4nDnX bw9+szHjqrMUtmj5dg9Tkajg1tvduP1zZ8b1TA+jyM8Cj3qs6BqE1MQW1vP8l8/Lcl4OPfG1cPA/ 8XD/vW5ysolZTPF5etjtDwcYYA5Iszlc4ReHX+i3hweDrODzd4I+4keIG0rkbHxgiy2b6wFpfsOl yOzhdveX8/u74/Xd8avDj7vnB7bhu6f3b35TO7zasRGdO6VtaGG1yIlFiDTcOhsf+OryViPujsuV //Y+0X2LXzjCjyPOQDtrc3cN/3Owtzv4hYN9wsEujoNf3B0/3r/571UXtuO9OVw/HP9z/eYPfAt/ xrcZ7cfGgPPJWp//vKNRHLWl/b+zT3x9/uuH6483t0jdg4G37Ko58fWUhEl8jSVstRChM9Wboxjf drSkrqpAUyD0p47mIGjB2sxoclT7HS0TDU3Q2qg0TtBiWToen1DDXPv52z5v2WMvftq9fYJUBjQw kuzQsiXljbaAKz3+sTY0Orq3hLwF7Irke60bRL6gVmzjS1GjrptSIBulW1ez7PW4sbAdNbF/xdOW DsWtIqVU33ErjSp9oHyi91sQlysCMVCIYwMaGEW3Ka5Mf9GKS6/f4iCPxSoaIiAP4pIRBMHeYSZK PjdycaARC23aXBGDHKS6X239zGIllRzbSco7ZKnYcivTmYIRwfWctLp5zRSELXcInYNTSsb2RNPC hSpDjE4PdVtLY23ZQumQlSy3PG0kSebb8+bE8dzY8twoJ2wAhhmEMrc4I4QBgikJCc9JDs0ctwyF HBkH5NlMBNXTjYSmrdDVdlIUUBwGgWBJkgOUrga7YpWrIccIJdgVohwXxUUQDPzjnRRIUKZJIOmw EcgaxLzE3Ml1yT/QnDs0+D2g0aszsquVOb0jJqh3ectktKXJj/2Q1pHRAVNijgItjNYlinULnfsZ ZMiBIb4dI8HcjqNgJvihpTSTDX5EqQWwgse94pfy95Js/H7cA4gsxynNTZGwI0JAmVGfV6nYUwXI KxtjTzOs14SSscgePJ83JJ6VCXU9AfBSVCwvzhVWj0z8SQxRXVGyR9oRyITvUUyt4mNeeFrmLOYR r0dno4T0xqwK6T41zS6eZgkJXgBaOITCurSwF5DH3rTIEkEIXEonqzjoGMLW2HHNJkfOMDaEMse2 ZdEloMSMSOq1RB1T4WwJSagbw6IfUfQD4211kkQcH05TzXwKZQlWlPIKaeowpugcwixCakXjXpo0 l1bE8UNjaBoG1Thq5hoGLy77vJwwqEvtQiUS9Tuy58Mip14cRxPhnKpqeit8cF0C3FKts4owuIck 9zohDlrNtAbHo8lMU3DuSJ2LiylWuOQCN4pCb5VxnFuCaDtrnF1SbKnhQrK0c3doeGah2IMfpPPD aJvnlDDVH91sitRci/px6y1h9ohpoXVLEavwoOdNtx0CRWvxQ6gosU7oZtMbyX9qWTIQObAESXUL aRP1p9PCTehPfmmuI/UJ/WmGsbHphA7Fq/S87N81DNVxcE7RoK5I80BvyUWunjNB7t811joGkc3q MDoaip5cYzsaF09C407D22a58Z+ECuigP8V0hAqtlUdBBF8rDT2YBNkuZda8tDugWmb9FTa2h1nk LfBsQ2zQ1kgh6axhflEgfQeU1RPS4FF8iEbLpNJwDGYupRUllIkf55QDlMTHZeYjUWFozFqDQKXQ 7WKHTiModO2FrYi0+jhbC1A/BGXaXCSoftFvoFzI9ILVuNY+bEDR5vYquoCZWDUEKCcAw7OkufYu GSpXCNLKgYe66sgElL3BTlHxZIcwQHC7WNN3HvRxa+X4JBQqTxRhJpjQLuzcApNVYQyzBRJK2QxO Xx6J1CD3AEj2CEpF9HtQI4E2FBREzzX+zl0XY75UarI63SL4MtMT2tU8aeKSzdoMZuII5XbiZ7ES KuZ8Cc1yqCQ5jPAnGvnJbKfpTRBZYgeagaQjQZ0nEdUZyDi5jE4gA31CFwihc9PN0S1hRV54nbzt JZhPV4G3vklvkZpIsDTUDnUZShSOkV2YIs0g+VlPbTyqktdplR5KujCL6lPzGxCsiyOobnLNK6Nh lwYCKN5d3GR5O14RdTToOOkGlMz2aXILUOpsUB75MdLi0LCuaFrVcgzINyag5TZ6ZkomPA3U3aww lY4co7cDakNpRbfzQikiUoFefD5xJMtQFylRgijP0c6igKucZ0xO09qhhdFrP6Ck8pi0jGPJu96a xtA2uh2Rgks+1klGyh2vXLJILBxGJj+jAI7Q3Jdme0rELx4tk8o6sZTLKHH/TZDhwiNtZQIBYpYu U66QPmtGUBssxxi6rVLeygMP0/mIrG1SkHn2DylAehwFEYkssoa3RFNF0Nm3LImwUd9KjqSIhTL0 zNPwp4d6GYJo+hAJlCdRXAzyxAeayfUOL5mhF0KaUikHFtGXIZVlKUxAJNmYRVwbj0uCeKTCOMLJ n4parQh0kHGxOn3MEModCe9V6VMdHTmgwUVldaILJTg2NersoFBZlJa+zzFc5B2QssjqCwDjjCqg lUGO0Kw+K4qBxoua0OA5Ugo0NfcJJqMloUwnDDVWVxJzaEBbljEbGr8ZiTZjIMutLH2uP5Hg3BJD 8KunpVAapV+gExT6jcZUOlDB1C0mFw4E6nvJfCd2oSqSosCWIckFdTljU5lexbWFwo1ek8U7IWuj HBVqB8JAqrGu5QVypK5pryrUAVQb0OCAlCmFQNhfqKe8OlMf0qylm9qMK6FdNguUeN400Tna0bmj w5TAz5x+Vc9pCXHSk4KFeyDEU+0cV2TB2KOZUS0pUGm1FAEZKlFCPWneY+BDSCVyGnUouPZVKy8J QrVlcMbjWnFCoBL9UsReogd00spyGZcYlrG26lVBE9yHWycnzJExsKqQDWmZ5LGp2+9kux3Rm1pD rwq+J9CkMSx9+2RnDf01D1d3u0AvsyH9NKUHc7uLbsx8bZn76YE6IJ1IXRBRpoXyPHFDFlrU+whi WWjL+8LNsg7z4ea4hP30y0V+MaI+5vvByVOQ0F6cBNFoQHGQALjETzTSnqoGJRl56qyviAokYYag 6WPB6cQIJdRXLVBR3KKlHNFr6blVs3bGBfof3VWSbDmM467SJ6iwNetQef9tgxIB0u9XRS7yP4Rt iRMIDD2iz8kwAvVErMVIJsUbLsjxMPROdyZCQz1j+dxZWM/7e7XDgJGCRf0KEowqLyXVyIaFXpZX o0a2tUEgD7R8ZHqZcjOmzF9zGjNirg753GOIouhLRNvDk4EsnLZsAzA2EBaXfqeDMs9xgXj5DINB 3PfN5OENDqh8p9kflws9alLl05AIP6VebWr2jBc3qecVCV3S7GD8Vt2a+sXcI7MK9Ta0hg4rQnBQ QIAKuGBarxrQEQTQG10iUFUB6Dk9eN4gHwHjF3ZrbxyB3BWQhCZXAN1ygZ3WOmJIU9Lm0UuUZnbn eiWUxzCYEmgtyts2XqbAFBivNobX3aTa0TjNNFs5v2nb2mznt8hzyjEa+gY6rhJU/0GbHfH1SLS0 OY+EPEIAPzhlgK6EaFBqrgBxOc3YND9y9eeI1sH7cx3hK1KbIoyRRnReyQeIm7oNNVjffp1RWVFA fp0+mSGI8LO80A74MaM9mkQ00OhMxdETR+FU4wpbJMwIIO9/oH7q2LwJ9svSlff1MqGQGlL73tYE +hJyLYt5ibzcsgKi1DPIBSCGbb3e6a7pao2ertdsoTfVdBANT5gYDW2lsAOqO1b5LaD1dSYo9yk1 RlOFjRDm7XR2MiB1X+t68I1FgYXtGQPxaEYtsHbsq5oZwXjPmUPVzYvQKRFuHOZsbCqN6cDX4lll 0ynw8+Difi7sHfxhW7yw5cqkj8nB2HfvuabXdMI4vYMA3v46cGo6osxFNhKhazSBeodCrSnm0tUo 0/dUgroUmKF1E1UiDUVua+hcg7wbgUo/QQn7CAG9PVooKgMy+X17p7o7NX3zCLqNY5r5F5J3Q/f6 /Lh+AhAi5j1c0SuzBwlrDquXGDBAxlc9iT/T+LfbgIrYTOjesvWQmob2c4JmG4gX0rYFqeHRxBvd V4fIRoMXBOaypCexApHsxRhJZpl0xoPDrUmDaPbtMtLoPKJ7oCovUN9PIEBftcBs1QLQMBBqMbN2 w87VHQ8uzjvI2K+jUACJRIByU4EiObPmvS4U997kFdsY7HWgR2FM35X4TWEyQwtYAf2QlUqwtfiS Wn+uwJgrBsrMiwezQ3lH4OuRa7QiUKy+6QtK70pWAzrLolxNGW8kC6jVSEY5BAZdunXJcuRnhPJe Y/AG45rnuYpU0/o8kpsh9s16zPJxBX/cyLEr7//Zv2NX0lTitSv3/n0keUuS/Cp6FF3XN4da/xTd jOfLKsXrj0QLysBQXu28uT/DZ92wntTY60S3SrwLyFbZqinFGiig0TZRtfaZAeet1dPRnZdH6eL0 KOhKF2i8vNV0RpmNyc1T6lomwFgwZQSvl5t5rQUf/Y+Huzz2gf5WzSsLI/qfZ2FxeX3xPeNF9dO/ zE47bamYShnA4MWPQXpI7eYBp9f71CGbq6LcrmRhCvt2cYd+HnR/dcl9JVUWm+LjHP3cGfMZTWaf 4ywD7TpEg+WJXSuoAJClf6W9n+IdnwVEl9lTMxcS0SphTd6amEQaHui+La6xdmhuJkLL0CAFU9PE qH52tPMlyqZGKWr8JxgYaD/IYgnMc+By4VElwIBqYFKtCsv3cgRHSjYT1j5dXH6yFbS9kuyMRkQV ZA6eq/1yT/hqsVrN77ZZSaOTNgb3ipYXILUrxmRp6DMaLB5UMBUf/tIKiHWxXPF8oJ2Wuxd17aQt 9Kxtg8QGLgB3ckW/M/2H1Ll0i2vnf3fzvXR542fiYTJijcuswKBEri8fw93kVdyv1atB2qbTxvzD H2bzUn2J9pinWPeDUjBBeRvG68ka+NFweorNdmZfn76yEHrij5ADeLD/dAy+FeJkcSeM56P8qi74 sk2N+iHIXLs+60eerRP3opCy4UF2clO/N4dZWPGY5UYjFAuKJEZJCuxJ6vaa1JlM6m9/nAZCD7SN U37/d50geykVia4q5TColex6vHZSh9+6/RiU3CN5izlPGtQ60BQLV5/nKdX6g4o2TH+0c4/a3y9U YnZNmt7RQXHi3CthAMkmQOweJZygJvnT07IH+o5vq8C99tMpCgQZMJ7qabQBnZI+QUqtch+Z7Ofl 4HqZqjcdi6CEKjXt7sgcW5U2NpR0Az/ZD6JLmwtVZi5Twa5Gsu7wmoP1FkuXqe+xiSPpAUCnB9I0 Aio/s2I2sBw/NM796xW1Pa3UMhjSbaYy6DwCkiW1SzHBpZ4Oz5cqjxzYDsp6960gmEArbcnT7bTd J6tIC7pP3D2pR9MUTh5ZI/+dk7+au537unk1ud1lS2tSA5PxZxOKC19bOhiSLyPcQhxb2slue6I7 SmMb1R5TUt5DioByRv5Ap83ze6EraiJxoM7N6DoNZ4iiOpP4KuzWurwnQtiglUPk1dM5FoskWaXI xxiIWkMtYbzUHCG+MIcliS/f7BjhLKuXQTS6KJTxc5spFY1FaYtmD5gTdNuxb4D6zuimSR1iVyYX 822H/6Hj4b0i5BvG9WlefaQnROxlQ0AexjwEhN9P6i1fFUj16MTmfezuMhsCPzJ/fHFn4iLRDxqj T0UCLTplUXWgSn8Oqkm66opWuBmT6SlE4WLq/Oo9tc08bIJahvu4U91mLPZ09IrxsRhfojsNBiPP ZRaKMuchqrfyg5k4+kSdsNj9gDI/lb+QEU/bMcn+1Odql9gARUoWOQXxksUWFRXS8iRGIYpZqBEX 38/p97NrMh6bU5vbBATMmXhi6IHaQNmmSlf3XQu0pRh9QdYkOeNOYJLIxzpk9yGXRRELNDe9F9uW IpcVUNdShnqiDuHh5lqaQMYNRioBY/aq55nhv2P6l/63scx8qodwddRNwkFJc9h2garhykroHXBb 352QwtXrpv1e+hTsAWfjqVvjePrM59Nnzpwf9JLLfBOZ/gR0Ija5xBKiW16PFHvf11BJnsjaqhxp Jd0Y279vHxpAZNQkr8rksOJ1FQeohwnB71Ut+/AgNIfHjcu0u9XV9rWcDgU/vxRLHI6dRNVOxCZf Zs3xko1VLzxx9ulKivDuGfSb6MrY7NVCTSgbvvmF/kta/8fKQArQxLs7H/87iLGSoJsnp+OdPBoy bUwJSBNZBokXqEIG6mO+Z1ACUEsioNzLvnD3CpoE6vsL6KLEM8LD7ytw4neIls52BcoW7mxWnKod UhqjWzu+/ziUhDwe9ESvaZvqd1aW6db3aY669lk9Ed6VXKuFlzPJZV+sPLqRlVb5CDPesXw07faj 31SXepbaepJqBjXcVpybKrnKBy61iKGuTOdM01PPTMy0Jo2M7N20TAF59WbjMBb24awpmPeEjKfk iAAZc9qL03+TgHpKdSGZ4ipRlnKKP9PGTly1QrnZBZWFV5UirVrG2Cj19OZKO9ZyMJnriLmytVGX KLNyu+oni16E1WKzuC9Bl6guNlXopWjlypW05ke+Oxms5WOPB7vaNkqlmqK/S7o549mfKP3Z/aS8 V3LqfuOanPSSsjYvsF4m90aza+IINe0O85MafLfPxPkwgI54ijwKsDxv9Zef2qG2xJ+OmMKLSp37 zXTmbXZAHql6GFDumnKf8tQP7LYnkcphN4NG4kt82KAiWvRE7JTroNAkasi1K+3oSU0ZV51KzUhf /FL8XbzORH24lfx36c3l5vjwqA9N76mn+lnwgBj+3ZrtP/ONQDy8vDojPFgZbex5f8ehsa5L2hgK r79pgCb9JCTx7K5+jtJNy7gsmaDtjsI2vVxaMOC+LiHRX32kcgc3/isJ18PE1nKEcLxY5E5qqI5a kpOREMOi9laHFlAPA7UyZReVxAa9m+39H8UMyC+YFTNQLyZQuYDar/LQVTpJDagoGijd4IxGADpd QSvqwVGug4YOf1WJ8tv+gI7kmSkzg0uzpv2PJ050y6trX1jn9+sfn4o13yzQgVn1gefLPYXrUEsX mWe6a+Nd/Qo12tsi9ihrNCOO8uLURHnmGcafB+vvu53EKB1nOZe0E0Phbxs++08nVO7L2t1NRkPh rKh1ufUa0fGAnPOz1kyojR3bWUWUjQLqa+2T/UrxW5Pmq1UFJnFajss5WnoxdelICVfff7qyKGn7 E1KTyI6q0gHZiNWEHrKoQd4u+THasUw2owQHONsuigwjCxmqxb4Aq2SS6od6gkFF36CtQRI1KQBy yyRKg1OS7QlOrl5t338g5HjKocE5uevvQ+4/W+CPDTUPI0V+5eS/X5Qd06VvsGt0RHukCkVX5VAs fv8/3dWOZEmS4/Q5Rcsj+f9znjEbrVbZ+5st6CRBRmattdD5UBHhThIEQd71L+fonFqXK8+1dP55 R3XS3VWge0JXCb5DOY0Jq7gYAZPzAZAwIMRLxDWNseUr75pgw3tkR1+P7REj7+zFcd1Q5sGH+onK 4H+ahMlhlnkia+x4HKNtWI1jyt3x0p4Z3eRpLU8SQtOhuravOlIAV791qOFpVvwlx//Pttj5/vE0 KB3cie7UxZcb0LGYZWCN706FCz+nzUcqTbK7WpmH3Q9lZ0jF1BB7RwGJRYwzWJJ0HkTNAGReIO9m Y9Amz8i+5Hw8KOo7dWNLdkig6l+0QMYj2XGHhN/ikGD9mXfcw5wlnqIRQBiX36LftHBn6G5Kywyf IwSw9cELMSq3ghWOEqiHu2NFErnkiktWet1S+lN1U0MA7ee7pkhnW0HT6SDSZa2WQ3ZzKoqM/PaN D5CtSzGAzjfT/qERFljuZWGN1PTF10mgOQUmWEAZxqhvmYukFncXWPxuiv9wHcyop6CHf5dIiIbZ OUqTbq0u9og35x07uxtodNxOfIr0xLOpB9J3U7P46TsZht8tr8octJpJC8BKH2tZKJuzJY0a4X8f 370CXSJykPcIaySuC6LDT0c518d6cjhbeFAo89tHaqrr4U7hAxeQG/ubhP6qul5TV/zhcx7M4ly7 PoOB8pBZnhvQm+IcV+4dzAHqS8GKGOSm01E9dw5vcEmUDo1JVW9RornodmowaXLTAuqrX0Zb1Cd9 Ia0k4hRs0+ih2HOleVRu/YXNv7w/ovWnupy8N83N4JPlSmj+6H4Skxeqqeaq216Hn4tJspE/w5Wl VQqoEDBPSEAxN1VPApLxeP17z7Xez3VtD827VQQhKsBTdOUVEZ0/EigSQqpMb+i4zPAhB4g86TS7 xpOuS2yJzhLLxLWRcoqekVVCksJDuw8GmcX+rpvfagYJkAl4QIP1qqncndRq0T041yPr6Y44sH3L jTa7aoiit60/VxrJ53kztFnMt+NCNG4aruuZfVGAH4NbzjZ7OPzGsyVlCmHL9oBTVGh9f0DZnNCH zjxuf2uoiet6YUNy+5B///Mk7W8Deyd5jmm1dUomHRdV0vF6qnsKcWs+GWKy2bvZMG3nzscw7fc7 rNzioPmirf3wVItzN9uq5S160oaSnl3uze2LObjFyZdz8yOJL7VFTK3ZWSx1aJNdt0nRn4BOLK3t eXKBeFeBXuZ2vZE5rI1KEUGZZaBKsd1KKABQFSlBISrmCapFK2jMdd9bd0Of8ru+4wrKdGMLavaF GuQFevfvZ4d5GEHDrQzJ2m4tBTZt3RI0Als8qodXBKoyKCj7vW8e1T8rQrPAEgp9GtOf3e4FuRh8 TqOxEDQK35mwdF8xEucbGNpf/drLQA0mnvor3xCUfn48eD1VMXWR33eZGsL7DQQyKU+McGiyPMpn ZppMm6RZyV0c8xy77eCnLK3y4AlvidX2WApPSOKqes6Nuqxupmg/QvrKOZyGoB7N4ZomQPtRz3KA 3dNuCpJRo7l+Ckoacv0UlDTE+jnGg3SebWmTdwivCUhuDoieYVeRKbng8h1p45/x+f3Q4j21u+mK hMicA/VUpnTs5zW/UFAkTea9nGHS9D5d9tY7lQhuP9n9XtMnk8RDWgD1y/dg2H6DbUtP8uZXRthG R7Hc2x3q7smLAvU7XvMFxwe5PMjt6BxvTvH/ToLbXi7eomA3v9Ml5wd67fRkc+9iPGlQA7VsAiWD 79aKy4f89e316cko3refvHTw3cOQkm2417yzoM1XiYS2yNM9vH9JNz0u8e2GQAO1XmOrxgXQlNXv pGP9072X7Eenv+1uFlBdf3s8szS/4wd9e9GDjAezTPZ4HDLLNiMpt3GHLKgHc0jEWY7YLYnPu3mW K444kxqf0JyHl5y1ksHRaILakOlhJ2dFU3blQaMoCnq0DC7ls3ZPWur8WTGjmpa3sf1mVWO8VIq2 fwFNuf0o9wazHvZ/NCHeJpXzZS+/UCJ7mMXlKGnNcwtk10rseOj5aK5AU+Xa62bIihsCGar/q+fP zMitWAcj2fh8qmga2lDqvbiMZIMNlnLQJptkwvfM9eUZoDr0nEQqJFYoPh7qsiGoEAOxBVegn8az SYEQtC396KRoSb3hkyTXn5vKGOfwr/6s0gWDNm7anAJAg4Poa/tojO730e5Gp//lWtWzJ/fT10vi oAVaPlQTzVgPDVZj/1BSiQHclvlzPoZQSnS0I/BXEKV6iYCSpmLitB5AWTixMNONZkYtdVLu/fvZ 5fxqXk6Jl0c1r4dUZhpkUUoXv3had8qJCJDBRCEglAkxXxoolMadr6DG0LJT+O095dMnBV5OaATQ oeOjHM4KQa1q5XI9keYwLtZCf+a9hcvzQqkeNUnMZd5aUj7ov3JGOLWddcdZBzTqrO1VR8grSuBH dU6QWTXBbGu8YUKKC+0d/XI1dqDME96zOVlLUrfi6pbrYeKeU4dpo7qydufsk3JqZ6yR0+xsWCMm uowwWbK2uTcZNV7emPCzLLcYGFssJ/42/19GGmzj/R7pjuYZSszyWSpDTH4JtsGcEFD1PLc+vyS/ 6VgKv5hMJlCpl6TEt7TL3a0kI3y55xVpWjv66JqIfJjXuuYL1r1h84CqFAnKc+DAdONYN+bzwOKq y80XXRa4oEePmpbdB3mUZ5hBWMgKfY2gL3ZBaYeB+lEh5xld1L6HyuvhRRLERejImrPu+JyMMScQ 3TEgo9+1ASYW1cMbbOZxnObfM5ppptyvD3+2mvOUWOyjRYz5Nw8lJXBLLV5JaIrhvEcup3h7bbSS NiVsB4tUoPfdumkCYjF2952yhA2SjeUS5Uq16/sdq4EuRPkR7EzeOelz2K/EJeZzsZ7N7+WwxtlD sS72ZwTLM3MPaP6MA8Wf4EtIs959ybH6GAJXK72kPd2i61b1IC4xw1RC0FiWhmmuoJHjYZZW0O1u GiWVj65wuWh87VOn71zakdWqPIcGEeZwzEa9aLH6TBSd+jA1NGjeUaGiDgx6bQgZPzl0CQRERkJF vVqhfoK6Ck1anTFMpGcI0+AiBxlVQgO64/12dX9PGUF3tAhCMVcNdGnMVXVuRyRIw7RIdmw2k9ti ScvmnG5UcDpLBzTd0bVqLop0CnHuN4MlRCfl5Ar6eZ0zOB+1dISXtFYCqoyS3J/0+Bh5UfLDWMOV yJ1sm0p+Q+5vqyFmZ9nBK/GDabRK+G+Kl5Sn4bMjTWbJqd0pTfGU/zTxpVC7uwXh8EJFhdWAGP4s 7zfzJhy6/jmGCLTSKljDJg7GpBfUGMJcAhKHp6VgE4LrnRRmMdEq9WcHDG2KGPNjNHc5eJASNmpi DF/vlzI7QwSBzh8fBeQDexjd++W0Dvsw+hH5eN7Bs9g3KZyavC8vgrgVD7xPlZYVrOjzy8k+VLXD 5I63wjqd4sFGSpT0LCqnEPWsF69BcrSjuXf48AxbmXMn8QxoJ/tYbtngtvOMViqhtg/k10e0c3Ob IusEFb6dFz4cr9tkgUS0xAQ/PW731QA+uZuE//ff/6r/yH///O9//uc9cEb67J+Xg2YkniEJXa0b IFKz0+MBZVA9tqyVyFDZGStSmJ7d0UX4rpvzHa2a0BOuJX33hjD0yu68qbjtsyUKKy53PM1X7zyE 0HgpTUuoUNNEU1bKGjSWDMmOmFrgrbUthcw+k21wWkNWQnxw6KHR8t2HD1BMTJtl/XH4A/nCIbez WVZ9zLRqZmvoD1qAUd5QBBS5vU7wlhxE9D/Qt5C8/teuyRdG8EdjoNgDWoyBLQN0MOnb323dS8Np aelE/bOiHKUEBwWgIFXcZpHVOyZVnxSGTFYRNkVneCxww+YXWjNC6r96GLyKvTb3xayOVu8pcUv4 TRKhH9f6jhpRn/NZXwV6s7DHbiSQxdc/yhUohc+FY4TaAvLbjXDoSfhGpBJ3nExPd535yMjTmcR1 VvHPY5rX5ya6F17AO0/6on1/L/Z6vEi6ZwUYtP2gBu2r9ND8jY7Ev8I2mhwFiYJAnwzeyLHN4qw0 gPycfNNNUicGm5kF1LMTsLzt1Nc0Elnxx9VaJqkG5FZnhMV9DmYkG3AodT1WF6BdyRafoy/BRAtr vbXiaUy6Lb8uMWFdzv+xXe3IkuQ4zJ9TvCOk/pK9seacYuwaZ+8fsaBIgszqF+28QmemKBIEweRT mBuxx8zYoAeY0TOozLWBM0QJhZ0KbX5ReYLPmeUC7+5iGQAVJpuotrzN8bVo88mFMVsNyoeYfIr5 oH1PlvbalBPlhJwMmgqPqJGf2ZG0G3h2qHjZu6UmadahhMrlWG5BsjbRWGXbENcGj7K2jhjFHPGH zZX4+Utf34Z/fuSfGoukwn6bz0XDNscdV0pQJGO54SfDcKHeX2kEbfbNdqRmsJuf4LU9+Pr+VKqX ZHf/DFqVzMw17d/npQ/pHKBNz6EyJ2qndQZt4Dve8Sk9yLy0TMkXi/dLWPvOtWm/dwDyMZwDKPTq S/6OruqUplhcOsdYvuBXJv5wlKf7yKnTbvG56LUXIyT6sC1qj2kHtJu3asHDo04f/oiEPewgehpA blhAGm9doOMtz8faLJmGw71BJNdLB9S5NIOFQItKrtqfU9KUpL4CnWxcKhpQux4YxjkLtH2JKaAy 3zpy6JYzPw5deNbEo9YCcsclAlAsbly+9qE01miEzcH/lKj9ppt4nhDMPfW3U3M3UvMJhu3K4Isz bD8q3CVKszZ1tkYu17z5AUTNWN31Cgumln9VNlr3I1bzfCMVdJyLc8Xe7LqqpoG08DiTHaeOy6XU 3UCuh0sqIhCXPRrsZc6hR+kAPVzrVANWT4yjIV30/nlPWtnj2OslrTS0MkvNEZVvPWzRJwzCPH5j 2Qs89XPf1OQNAFD/6jxAvsL4zjF1LWHq7DdbGsdVeqS4adhAMUFejKJr7Ex3qGm2MVokypsumVsr dx6gK8St/MkLV8r4HEgQn6vsuJUi1xjBKWpZXCaTb3KmgqbsralMJl3m9G0DqOrMHGws2Vz9xStv uTWmSUd6aGyarhaCMqYXMp+c0B48H4v90OPS+K5ZzaeHds3HRyPQ7acBlQZ4pcIiHSGFgPyL0+8d EB3dVMUEkL9vhjabMT/Vh2yKDfPPS4p7HBVgXTXGVkFOXY202GZGkR3DXRjlFFDrb/aNTjkYQWmg bh9GiqOlfXTegEfVQ9JYGu3+ZsH9kWTRAG0VBlJeIMoFjS1QH0g7caCq99rWCKM4G6UtXSOBXu1b UT5AV+WSTAl077NXfmmG1qavz/AHiKH192bjFx0phsiYtHSJ7FrOk0VOlWiJ2fPaoTyPAS01gdRq QO6QSqrt4KqVX+9crWqKtPv8Bcppifh9qa2vquyvzQzQXfRaaKAnuwdLZX8zbX5S8I+7G5FnpoNH w1dxoYyLwoBFQtWmcehPeh5YOnqy2T0d8H4kwKTpryvSAXGs+0IxIptCO0iwphq/nSbzudwExMLu yoG2k7UZbjmA/mJicPQe4cv82RVN+ouX1X0AmbfhBe2iyQXaFMqteXUq+TCkvdn4GEleOr/Yw+aD X+64+ktkAg0ed9qfljSKnQA0tIClfyn/o4tBGkuA+p+mcTw667prVEmCv4ZB3xnS1M3tXGwltikM RVEFQCSiEaQ9USUxMvitYwEDVwS5nmg8vHK3jPOyGe5qTjQEKGnzMNMIM3e8yYKRW5R+TDPmrU1/ MIUJndXtKFDzREWpmzg/65t1k1tH3Za39PmTplj3eHl9hCbXz+lB/MYA5DGacnmrSsLdwX3XQItj jrxNG0mfC5nrAMrO2OL8zllAR6hEQns0LFAzPC1RcCuHWg0HCshMGcJiD+zn/g43e3ifJwYeFoeh 6Qj7tT2V7QlpxevW6a2EeQBaNZog0/HJiLApfEBN4nDF4GrENJK/P3dctRFG7DvBlnZ1Da2Zk/1c mbrsb+ZbZEW0kglpfEvsblBbMoCH7G41LbNLm2MYCc70KVVHtDbQy9KRVtHJmZK0/tCNAqUhBLq+ v6hETQoqkHfLTAEOL3/uGaA+j7yzcGvJa+6/091qv1S98YorGHAq95c8F9YlUJaTrb+jeJzg7EJM HtvMMhk39TAeLOldhgLUVrhcqV2dDjzE2dXCK+7mq2Lr0R0pxox+EUxph6Rta9frtT8327bIZdZG ZVqy6lJYu3vSAGNA7gMQyNOR9oEzfUJksQDqTdtSyVoSFpqDfShNPon2TDFxz0Cq4lZR3sKj1itV 1SDWY7P3Zuya6EijHFBr0q+EWnd7oab0TDOzoPo3T1L5LXMb0A6L98u796PPj/z7+d8//2p17j1m 99Xs420nUG5k9QKCqhsH1Lv+pkgcfaR5t21r1tllWFzoGG0hPgx/PHcgT1zdiTOeZmo5hY2mCEP2 PUQrjcAHr1ROsZhW8wFHrc07a6GZHEX3JpyDTSTQIX55ljBUQxYmIDXOwAv3IRzLh7AD3oKhqvEq rDN83HzCS8qDu+mDMwntNFpKtsoxGbHUIB3Kir1s7QAzk5gsm4qC8ot7GqUvWophwhQAO4nvd8kv LcqP/DNadJcm7nuf9KaYfjJcaSDbgadGmOCKWhLpN3eGYup01LrVCE+YsHQFKfbieCp3vEMNGE+/ v92CIDd3VrygdjOiqE+fUSZR21Gl4M++N8NfPiHzgyuRY1o5ZeN0pyEoDjH06olAJrL4y8e9oKaH YNxJHzWVSTvrGy3N2FqGntPS6fhbKyPb6dFP1luEebdDu2bhaltSxg+LXVLSt8smEsvcPYue/lhE ILW5Gvyn3lya1KBJIR5i+W1xmFxio80FjTavl1RpHRJiWOJk9+FHnyu5jwwpn+eHG0XScXDS9PXJ 46W43cmrE9B4NgxT1RUn/JdAJe7u5hGo2Q6RgfNlHEQteBCtvyQ5HST2FtWo6aDdbyVpUTHX7JpS 8xbTzgyzcMJHAVAxKGWkbmxsqplGKLdWUD5O79cCoF04q77l4UqIcMGmHdRYDdbnkqaoL/RzBFpq 4fyQRDgYLqPW8WiSMzO9FwMWEqsLgSxvlPXy7cluR2zfj0Lacbnqhyy+3kzds6EUtNr9ZjqqynB4 3Q9QV+lgIvJYWrUlmSm+egF92PvchyC2oR6FK2mxpkY6qv2mNLJL46lx99PyW+OJSC+vQtFMlmSg fGJLJEHSrUWtiWU2CVry5dwWax7iTSvYuRv9xhylFIe27FzuUAT1dfWJ4MHv5KjXW5fTeid6bwL1 YsJO/BjHU35u29cT2gjI94pNS2keQZgRpYXPKM4iZv7aC3nVu/ZGacWOtUKu4yTKh+Pqx2OPKLv4 Du4Mv6XN8nlu3SQyce0DlbadFhCJDnRNnwmUYKGPjZkabKuP80Mc0wojNK4IsUmBWEgIrrBm+3IB d7WCIQE2Xkf0PFJml37N0uX9JBpGMdgckVOtaoZW6ltWRypyoox1OZor6VffQWT8HUJoic/5vSn/ 79//+fnr/wIMALgS/kkNCmVuZHN0cmVhbQ1lbmRvYmoNMyAwIG9iajw8L0NvbnRlbnRzIDQgMCBS L1R5cGUvUGFnZS9QYXJlbnQgNzYgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0v Q3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDUyMSAw IFIvQ1MxIDUyMiAwIFI+Pi9Gb250PDwvVFQyIDUzIDAgUi9UVDAgNTEgMCBSL1RUMSA1MjUgMCBS Pj4vWE9iamVjdDw8L0ltMSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0wIDUzMCAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNTIzIDAgUj4+L1Byb3Bl cnRpZXM8PC9NQzAgNTE5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAyPj4NZW5kb2JqDTQgMCBvYmo8 PC9MZW5ndGggNzA1My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUV9luHMcVfZ+vqEdb AHtqXwDDgEkZgYIoGwnkwfIDQ1EiDQ0pkxMo9tfnVHVP1anqppJIkGZ4eO+tc2q5y/6Hp+P9h+ub o/juu/3Vb59vxf6v1x/vH66P948PYn9+/vhv8ZMOkzbCpckpJZyPUwopRRGiBiJTEj/vfzger2/u bt+Ln/ZXj5/h+Hg8Ph7E/k+3H45i//f7j3dH8fP335+/vhC7/V8uxP7thRTzTxeXUtw8CzlZF6PG p8efgM+In40QzzcPOyXuYfkHWH583ikbJhuFV5MEH6ulCPj3dLv7sPt15zx+Wegtvz9zthr845V4 mBe8uBSy/BWXF3/eySk48UVE8RbIL0KJP4qffpbivXh5rcvd3+CWklYeVGWyKlOXwTo1U9bsqNIk tVBxoflVrbOj1cUze82+uvpqa5TJizmbyrbh4+TppZQ4I5ud8zcVp5jwh/2l18HCUZmgHT7hL7u1 tR3WPvFWmTGYqpXUeV3vX173150UyoG9CyaJs+CnYLMlUAtUY6tSdnbi5rDbvzlI8foRe4xQYlnG p0xOWVe2NGihwxL7x7e4SOW//eXdNS4xLvPbizevEXy5c2V1oydpPZY6c2ayclldgyoOyiheXc2r ZzeNdbOUANJlO3Ik7JqwybCLnl28KceXfyfLKxl5DhTVieJyH7PS86vd/uoK64ircmBSGny9EWf1 +5dsevUssNn4/B0/XT3hP2MnLHk2f8BfhkkVnUlPYIEDuzrsvnnzcHx6fP+vm/LGj4/fXv2y+4qr yU8AJzv7Xt0+H/+Jd56dwFHNHGdiOnOUMznsKn4+mz84nE0KVxa7lqO909rPy79o71SYnEsuFYfX /83axCngOs/Wt58/Pf52uH04Zq8frzb3X7f9V3gSWuenhceo1ZIhcLp0CTeyh5qStFj7C3ggg6gh gyTsDe6cc3oySDOIhgsVo8tsF+wTY9FMyVuZUY33hLu5BVXP/FiD1VuIzdsTpM0YXp41puSGLTSf Sor5yYNLVJNL/kWUI1R1W1hldLc7f7WxEWvq63CHTTmXeBVROeSXL2KncUO0DGDpIlJycLPbBopn q2WWcKZd9s+vknYmVzgZpc/eG6idDHKtOMufIWRfqKJl8PKj8/iWOePNqOJe0U9sG1A6UTtNb1vR bIu0ZHMGzQVXL5Z+kjFKVTHY4cF6q4o3ZGo1r7+BxslqhxfupiC9m2sY5RxtbdmlfL6gkfSy+WvU TDqCpjhDxowBv0IohQSjUrEzDjm+HK/BzvkiYcHOIDUf9Bkycb7OLzjetXtg8LDdcA8qRlddojCF MO+IxWtRJeImalPEgZrlUoe8yy+iDhKMUbK7m5tY4wT2OMck5wceJ4VI5dlvoHHySaKw4Dcxlduo zWk7vJyMLse+wnA3nA35AIyLYb7FHgTK68S3EHPlOWyiGsePJJKdvQHhwZmfwBol59PK+WVTarBT 8L7o5ZRzQvOOIUGrPhEdOrTZaoVXGodsULFmd/k/5m6nUQVN6UpQ7fMZ4tzV0gmgEuFQXq7T5sU6 rZc6PVc/jfdmYt4ixJMJjEpRUqXZUSYfpbRzebp+uP702/P9s7h7fD6Kd99cHq6fjuf3x+elyG1E ciHTNbgCuEMoo/iWIz0/fjh+uX66FfcPz8frT59QoN99+5WiZ/+/otcq3M46h0ddzhqnjtyFb4dN VAWDtjCf6RneXm4559tCmRttBZolgwfqnIXJfMRbqHIoe7oEUwhQbh7ZIcn55ZltoVveYOLxA9rJ kruRe5QtATLqQ+5Qcu52ca67XqF5dNkSqStlfRmDwuVhMpob1JT84O/Kbhhaq7f1yDmu5CqOi9ba 5d6TGTDWuLL/WlfOS3BCox07DoeCRnT7tucr88XwJTJpk8gAIa1Qu2S/PgJqUKkPnWKyJcYUl9QR h4Yy3xZhS1vRHJFjB8ExDyduKdknug6pXAczHKbL5SnMZZhR+KGtsEMEk29ZR4AtmWyLysIaA0KJ LUUYZRWtISw5sZMb0CskP8rFLOODHeXi9Ro1dzOMajwkXfaWIqAr1doVaSSYbJlui0vSiAOjjS9F 2NBWNBebXNg6zYiXa89wQOiagst1rFOHNLHah4C+IsTVnqFPlXFUTLbM9xSVlNH6jDau5L+hq+hF pk3IYJ1aVGqMSeP5oFbEZEtcUpZruQnDC86NRfSDWkwa1rrh/TZL4koxSRetz2jjyhFGVUWrdZNC 2h7uM1DvzHg2aC1lqeidLnQOXquyGqNpwuMbI6BfcToOWZNtiS/FJW3EgdHGlyOstRXN6NzzjDCk LKBz+9YxNmgMlBvPEr1ocKs3jK5VGbdMJC0CXqBfvWGyJcYUl9QRB0YbX46w1lY0o8E11gx1OKMx mKEOO52nBDXeap377yFJa3RI0Y6Kga7OmCyJbY1Jumh1RhtT9l+rKmpRx4Md7rTKHdKqJClbbw7p Qjuo7YiBzehchozSWpDUkyHxrPFIEa3MaGPJ/qOeolLmlit12QM6UeetUuOZSDMF40ed0mFYTOPb lb7eQo4QMJSG8VzJlvhSXNJGHBhtfDnCWlvWjF5zSt4Nb9cm5NHkhuxs0QLkO9NrtskiO447AW+s Pbijy9VjO1kNG1eO2HTx6ow2phxhraqojegypR5ebUa90cP5WNT/5Fa60EFg6eGE8RKnFMYTthET hhxPmG2JMcUldcSB0caXI6y1Fc0emTGuThhoUKsTRl+AqW3UjB5ifddtQFesxlyVUW/tcM/YlhhT XFJHHAglvhRhQ1vWTNMEql5Eb2f7KQlVT6uM0oxiURX0POHUWYawOvV0vnVCqut0tqjPttzZLipG Ox3jgi6rd1jl2fmvNQ0TEmmliYP5tumkKWtzDGF14um863TEapsts21RWVlbn1DiShG2dPF0xGLb vEF0aTapwmiKIazOO533MhnR4mTZEa0xO1F1dUYbU44wShomI5baJg0m26aSJqvNL4TVSYe921TE YpttR7VGZVlt/Q6tXDnChq5hKmK9bdJgxm0qadpO0wshdcrp9qpORKy22XZcl5isqq3doZUn+29o 6iYiVtqmDGbbJpKmq80uDTvNON0u1WmIlZ4smWeLyJra2h1aeXYRRkXDNMRK23TBbNsk0lS1mYWw Ot10+1QnIdbabJlri8q62vodWrl2Eda6hkmI9bbJghm3KaRpa/MKYXWy6bzrFMR6my2zbVFZWVu/ QyvXLsJa1zAFsd42WzDjNoc0bad5hZA613S+ywTEWpslMz1FZE1t5Q6tLDv/taJuAmKdbbZgrm0O aapO8woh81DTOdbph2UuhszxFI3VtFU7tDLs/Ectw/TDGts0wVTb5NEUtRmFsDrNdN518mGhzZa5 tqisq63foZVrF2Gta5h8SC/NE8SYZo+qjaYUwuZhpnOtUw8tfzIknhSPNNHKHVpZdhHWioaph5W2 KYLptomjqWqzCWF1ium868TDYpsts21RWVlbv0Mr1y7CWtcw8bDeNkEw4zZtNG1tLiGsTjCdd512 WG+zZbYtKitr6zPauHKEDV1Z7/mrnRS5sdboV1Hco9FKyPL35rCbv4jnmwc8fFwQlztV9F+Tcfmp HMrDM6lHcRW9yNrF0+0Lbncdjv4hjcFmrITCbdcSbkO0k1cXC10jdmWkVtETtdJx9/HIs4sYUf+Q F3wfsaIlInKi8Tneh6/upkd9ULH0DsFPsky9HWoNOsYw3wPs1vJKyZZQsr382qJK5L/zEWqJSDLf F3ScOuH+i/+QXi67UuRIGN6fp6jlDBJF+m5LrV5AM9IsegUvgGZg6JlTgACpX3/+cKYzfjudxRG9 oogTGTeHIz5bvD/8BW8TsPZa4w8Pr39/dXl48ebjuy/vL7/88uL3V//87RIuv/768jfIqSVevn14 8fathfm3HyCH9eKyuTzHijHoS6gFB7JLlQik/zCQoXt7+Nub27uv31/+8f3b39/+9+H126nHqB6f khyu/iLX5s/LAxYhtrtDbnKXYj1TE12974akjw8Gt82KIpZiloMlEUjdhXp3+Nup1CHzpawWg5c7 OZd5e1386saiSLHOtRMpfQ96uiZrBk8k5aiwMoI06alUU2ULWhNrMVWsncqMvGl8WrPaqjyT8bd1 xsyKdTtJ7HACt7OsxtO7nSQ6O/zbSfpvuMPRcADCUpsKVy+aNVZgrnFbWx2lxsh9xjXA2sH9xJUy eAwJiEDLy5rdvpWHU1i/zQLOa1KqC8h2dUGIFBi6xHPd3a4UnKLCaCpLy7fUJxlLn+PALA7suTNX Z/I6Aeafw2zAjHTVHfp0/QWz4ERjUyd9JCmGLcgqbFI5sXJHirnkzZYyDjDGU6kF3AYbt0JoZHOp RvYR/mS610Kgr4u3tcdmUhBwxhHJWS45rdWRbqaxE6Gb2xH42qyjCC/GsiRuCLGxDwoH224rpV7/ JuWRon3Hmk3ajyRszT4WdFNsY4/0EgpjtoFW5LWgn2bhseHDTYW+SrAlWuXq3NbY4JJU3FYA4/N2 rVdF6lSD1eYXt5DTFOQJ1TslLfaLUHIeHCPkFAe3mx77BT6uDbf7BTrmaMY6kR55znFDhc438NUb 2/tWzc57kccK+c4bCPa+mxZ5xp5evBs9A+iLrTOPfasu+9b52LzjNeFz75qU2DnGh42D67w1X+96 0yTHFq+uJWQqOdrvCjKox6q+WU99Y/Rd41KGxC3ed8GXwTvpdv734bf7l0E6HjnrkX+dcewf03GJ 6w4n/6pL/u8ymgU62YqbcnXMOnormGHyOX9OZemnqEzyNZs7zHdAZKlU9ur15ePnb9/vMFn+aSZz AS82vM3cxZuMVeZrBR04FFceFVTp44PDNcagFCmix//qGbDUwhY6RaRq4USK8WjXs3XYB6ae14lU OgO/xIJ4TmEqom+9kUknW+xMqjH5RbaquyPVXMkC1cXbgEUQT6Uu4jXiWlat3nMpW6iENivZ7STB 2VHcThKcHebtJO1ZO9xOinHGaZJurA9dD1SE3RrbTHrkNIdt6WvcXrZqrh86bLz6obOYK3ELVBWx 4p3dqguYSqV20ly3GpWCUzyg0CW6tSpG3mEyOlQ6JbT552IWhTe2FhBlta2A4KdlqQVs0keSOmzm kMwmxXEZsXcmRdVaG4ATnSunUjk4b8wm1cjmUo3sI/yhp+sM9Rhba3eNImIzXOF0RDMXoRflaKTw GOdbJxylU0DjaSFtuTV5GwJN1I8V7bhdsYn6qYQtk8s2AzUgfNJmoOri4IMp28VDNxY3WsAUD0nm eWdBdTsLwtL1OgIxjV+fTS7JmKtzwUkLhu3qqu7WuS6j3VMdQV0AAvOxKlIAqssBgKlStGMAGRfG l026B0C6ewDYiMaOAQC+ivOHAHZdDqAsoIY6TroA5OUaxgBItwUArsqVtroAigUIpfEQVbcLoF3Z LgBA17K4QwCquwXAo5MDkMekGwIgXQoAMA3GKUMAqB4cxK0uLQDW3QNAazozBOCBXUuywxGQLgeA yx6zHY7AL/K4sGMApNsC0DHJAYDGMBDGCqhuF8A+ETkAQSQUMg8BqO4WwF2Yc8DxcHEFupUesQuX fEF/+Lis03vOcuWnWE4KDEKU7gmArVxB7h8ryF3sHZQzyxNYLhThhYyZqCDUSeHW2fJjwvWAaRMv EYPC1Ono81bUiOG1BLOWetPCditt83QfPj58eDbPxrRsnlAyDy6t+OuATsktYS3a569/vvv67z8+ /efy5fHdp/eXL+/+9b/3379JDad25GWZ8c7Fa1XGZ1rwWqsY/fnT96+fH1cr518XyQhNdsH1xK/F 2/o1eT07OfvTFG5lHvR0Jc+Vkka6sqgMzmTgM5Yq4ZGFE6mSI+zjYsW5jFjbYv0Fv07OqZS/x/4N xQ9Yz1KKyuNRd2BUllK2aoErA9QpuGczGaP2VuqJ6IDes1LdztKaHMHtLK3JId7Okp20we2kBGfo bUF2wjo9CM2kgt5WWJaQyy7wZaLOWflUZn+pIgVqVlT4tnX/3NPd4ZsiInpGgQEbqUPvXLeA6eF7 /jnM1v1VOswWsx6fpgFxVcqYbWPAgaQByVmqmG3h24d4KmXM5sjmUoZvCyg33jN8H0SAbwzPc/a2 sowP7D2TFlBPHtlbx4SSN19+hW/VpI4jTaVvvmVKDRySUgPpEjXYivRp+B5FLHn8vml2X/vr4t3A HBb3tWyIqMzBulvbWiRtUxzQ39p4tSYOzndNdg+NbOPgvKDlR+RTzeYaP8yBudEAV5gZM1fdzrlQ ih9zdwg++4N71W0BeERUwuAev92Ie7smO/cIKbUS7869w91NA2+z7u5c5yW59yCfA2+TLgcQsP7j 4eQ9OsflMQDSbQEE3BVfxgACTLnxzUW6XQAIK5sB+G2IV2/NIQDVbQG0ydi5R/RhfHHtmuxcByA7 j27bJ51z0n06a1uLMVQfGcray13WBkr+BdhGKFck50sH2+YesvmfRraAvYZRsvTUhg0Paq4ITos5 oOy4F8NqZ6nCAVk4kSp0BNnX2wqfSonRAjZXxDPSn0nZAo47pnQio6jQ68EfMiApZdu+57qkjKVl BsZVKUOa1nsuPdDbrGS3eWqTg7idJTc5yttZypNmuE0LcUZuAW/cnNfdqHt0JpUzzx23BQM/wemd lQ8jNkgYWIwVldsCFrDBAg6nuju3UTwEXiHCGaZK/jG5zQ2IYbwD17FN5IbjvvqBjpqM+Qz/Yti5 E5myGf6PfpJA51JmM45oLmViCxFHDJ52SmwHEcZtDsGcI1tAnyCMehCKbDMpJCGMyMYzQqGN771C G+tSu5GuYhtfL10/HJauH9KlBRTASBmPmMECHkcpm2GBky5bgIacl+9WWIC1I0Gw7ta5AX/2prY4 B4B2twd+It0ugAgHdgxABuza+V0AqtsCABWZMqIvug6raCQo0uUAQEs+NVd7AN5eXcxbWHsApLsH kNoA5gB8uBZTe7QLYNflAMBFoIOxAmAomW1DAKTbAqDBSQEEkIJbz4oCUN0uAIQ1MGQI6CG7Hha7 b5rNOajIOWnn3jlirxeic6667By0FE0es8erLIzOSXN3vw9Idh+l/9dTYve7Lrtvk7BzXsBCPb6p 3tPhLeCxlotZAsFbvA9v4a/Am8SNl90Ab5/uwVt8AryFgqapoydg96z3mqUAUnTqNtKQ8sb4JPVo plAfY9IZCRcoCScne031JSidkfF396O6BhjN9XPcIiCAqVvOl4DBL2dnS8TJmrpnfS5yUqr4OP38 8eHDs3suhcAXa1F2lLsuKBxvxr4oMuRVKpHPMZe0ZQS7g41dagQYnOx4eaaWtVNePjshG2kyV+Q7 4AY2oq3FmEmxh7OTe/vcyBbxxw3pUMLkhCUs2sq79YwdyrksghLWCDAmZOlKwwsLsyblmrsr+ep9 facgh1hHr0gLeqTGQrrSGdGs0mbV15PJ1Wrz32vmeiU7m7ISnRx751/o0Zg+0k5Tc1Kbx+wFPoQv YpSRwVURaXEyFih+2Fp8rjLK1GCQpNWXVkX4NoVeEU0WSu4KLchs7KEkpNnCbwYpS/K814Ni7DQ1 m93gJO9aD7wOE26N6+uBd8BSHxMcfMCiiOPJo9N98vV7rke6hhzH2gGUoo99lSErxgznxJpakt0m 56r+tSoaaaepOanNY/a1Kk4uZRmrgiWzZN9XBVxkShrujqwZG9LYJVg00fmxKuCi5NNgFR1t7Ngo pLlnoDY5V/WvVdFIO03NSW0es1+rgk1gDnfHZTyyhrsDWUmrJmWKGQiaH3vFG9zUMFYQsJYq2JHV /3NeJjeSHDEUvcuKtqAQ++KB7uOBfBDG/XkkIzOYkY2GoFuBxWRw/fyEqoX2TIlTu93fBn2g+3GX ktvNR0p2QDsl79A1JQXuAPQcjQJVTDk/U1Io6YivMDscpL5SMthzJyAX6GPt42kV8hjba3yc5s7K bfORlfv9nZXt6UNzx7RtvqPXrNTIRVQe7UtW4K+hzcN/4kvzHInK/6Edq0coxxiv8akAW59PnEU2 Szn88pp3BNumj3W/v7OyPX1o7pi2zXf0mhUhRwDQkRXuyNTa0/9eoCDlhNpe+WqcoNKhGvEFy72z ZuNhlb6er6w4zTuCbdPHut/fWdmePjR3TNvmO3rLinC6ck7Q4AWu1UevDBhdS+dUDM6KPM8JGvCj 9sogBK1HOTa9Vfq6pDMrTvOOYNv0se73d1a2pw/NHdPOyjt6yQpUzrE+zzEdF2yfPFa4gSCSmvle elsQJpA+OdXDrpN6Cw1qUstixd9Ivd1GUMPA1NndUm8BIl9Hl/R+L3V2f7we5HNWldyv9PGshlqc fV8sgTR+OMv6/zrLIN+fVu09rtN4XWZ///vPTzfZ+A83WeocGGW4K4tqV7nIhPP42ysJh04Pxcid ODSNXtFJmeimlEhOpga3FCLwvbTKrlOiyVMQkaT0IDeZmKZFTRCR2GXrZD0Dp7klVEQJe5atEvuy cEsz3gSbRLFAuVUKVoy2pFJNfQ2yl9bcJPZx16OHfGGhml0KHLUSWeguFRdZ5pfEm2lnO09FKt5I M+WAJZ1LpFVOqaFSYgjRdIknB5OmNZkinWREPSC74bJLRkZRQsWpEpt60PmfEkS9W9P1liBnUTyd QteWVFFiqpQcXHGNTlxK8iaNHFe+0IhFOY0AQLDREM9bRZPBad1qLpEvq2N8Ru1LSuSaT5HmaHFl KPE0MOHVojcIUihhtY0w6I+x3mLXB/WGfiBfenjBPpLRZ7AxVtVjy5KvL4muxnWgARhzKMbK1Cgc iLTDHjQmZrfHJjLy17roAQuX72yTopVKXfxdXrLNDCJkcOzUQ8qrRKVSmFFYFvDO6p6AI5DCLBAd Dopua/CldeCSH/tO6ltMNoOACeUkSdM+pgwziVJYuCkyFkTSJNf+Gd1uUzBYG0pbq12aPJiVjEEg phns18lDVuWkMUX81emRLrb5FOnEH905sDL2yy0dUfdzETBPawnQkVpD5umTL7B2UjJdrtduC0xl uCq/X+MwCPPlmQNriYIaqDR/8go1hJN3ZuYg6/T6vceiABWkIzza+HMu0h0CVhJgg2Q9FGuR39Jc HpYqKaKoCko2Qk5GSlKzgNzXWWp7vSNLpQI99R58Vt+n4Hz7krGqK3kCm4VSeuihxjjcgQ3qPaxF a2LLcYdhMwiEGdBW7ANJsvvomDksTZWUCXhWpIHyqyxyBUYbWqK84DuyULLuTmhGX2BSAYgZtHRA 0FhjTw9SCOUFDMlMBhyFQpWkZL7V9Vahy/kl25s+v94qgAVEWvu83g0hlCkOpUycHyzJcFAhwLnp WWFUtBszkazlS9qvw4NGE78v2jub0U7ma2XbSV0D/fqLelGD3196rxii+T0pV1DSlPs9KYTGDt6H rrRWP3fqZtEPXZI+Zj8W9S9jA38EGABt4J5qDQplbmRzdHJlYW0NZW5kb2JqDTUgMCBvYmo8PC9U eXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEwMDZdL0ZvbnROYW1l L0FyaWFsTVQvRmxhZ3MgMzIvU3RlbVYgODgvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9Bc2Nl bnQgOTA1L0Rlc2NlbnQgLTIxMS9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoQXJpYWwpL0ZvbnRT dHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag02IDAgb2JqPDwvQ29udGVudHMg NyAwIFIvVHlwZS9QYWdlL1BhcmVudCA3NiAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUg ODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAg NTIxIDAgUi9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDIgNDkgMCBSL1RUMCA1MSAwIFIvVFQxIDUy NSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5IDAgUi9JbTAgNTMwIDAgUj4+L1By b2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA1MjMgMCBSPj4v UHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDM+Pg1lbmRvYmoNNyAw IG9iajw8L0xlbmd0aCAxMTQxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRW227cNhB9 11fMY1t0Kd4pAkGAeO0ELuLWjVX0wfWDspbtTXZXjqXUdb++h6RWe8leEHQNi7rMnDOcORwyf/PU Te+qSUevXuXly2NN+WV1P11U3bRZUH5y0vxD19Ixqch4ZoQgYwvmnfcFuULiDfeebvI3XVdNHupb us7L5hGOTdc1c8rf13cd5R+m9w8d3bx+fXI6piz/bUz5xZhTehpfcZq0xJk2RSExWvwcxgLPiqid LDJBU1i+g+V9mwntmC7ICsYRj5acHP6f6uwu+5IZi48xvP77yOjB4M+faJEIx1fE4x9djX/NOHOG nqmgC7z5RIJ+oesbTre0n+sq+x1u3kthESr3WoTQudNGpJDluqPwjEsSRR/mwbkmRy2jZ/BKvnLw lVoJFciM9jFtGJaelnOOGungHO5EwQqP37o/t9JpOArlpMEIf77BLfUW9zJuESJGpOKbqSZea/fz fsk4CYPojVOeRs4yp4Ml3mq8lUiVD86GJvMsP59zOm2QY0BRT2N9CE5oE1PqJEnXY59dQEjxkl89 VBAxxHwxPj8FeK+5yK4k49qCamQU07xnlwgVhVJinV0k9l2Yeh1TIqgwT4cZxVwFGqSUtFfreDLh mVTb8I3HJbQ9iS0us+TqxRrScFJmeVmCh8pYTc4Vbic0Gu6fg2nZEiqB8V88lU+4KM1AOUoD/Llj IibBS4YoUM1ynv1wvuiemtuvk9gAuubH8lN2wFWF9YGyJ9+ybruPaALBCTGKZYzSY9YpRNzqFCHy jnyN0rCOqb2AqJG6APmXlHacgtjrYJRl0hrro8fZMWsU30TpBWuqjpm7ghnHRQJfHLP2liF0V0Tr 2yPWVmisQgP1xFDeHjNXCAXhr6Z5VvayeX/S3L4MshGDbFhoMrHRcOXVuoBkX5xQF76zIpLLUO6C r6kD5TApykGPq0InBcqIGO6cP4QruACw0L10Hmoan9GsmVQdFDSF9tKbh6btqKs+1218E8kDuBAD z1Lz2zyQBSoBWWxM4aluH5tFO/04nU27F0i8x7TacRumxQRE2vec0TCRvVkaWJQw2Hq4SsKdNGEh zbaS1eMluL1IWiomHPc2Ir09a9mBYsvvLvY2r4OXKrz57lIv87IX8NsaH8/1MUjsMUL7Pjfzum3D eeV+Z57XNGJ2F2+AVdh9Cu1dKl770nb1nD7W3XNdD1KsFqm1JXA9NF3sxrvAFVesUM5u5TWAoaQ7 1/rKRfhwKBEq+dwdsZbIsy4UT0lpZrPmuT2U6jgBu1/UK2TFccJABWVEfvfh4pIOaFH9Xy0qhf0E x0uxR4u7p7OtS7Wqu9s9v4FmU6HjtGjpcVYtanqsJp/rrt0pLbnacve0uRWHDo1BiaJvDNUCwqK2 XnSDwFaqOipZ5XBQ8dZuJqhX515dLZ3i0c4bmbz+PmKM44qyVupoPK2oHF/+TH+c4tI80fnl0cUs uDigsSWNEdjgFNdph22bkPTdbXN3u9FcM+uxLW5kBP13UcdTzEbz/E+AAQDmUdG3DQplbmRzdHJl YW0NZW5kb2JqDTggMCBvYmo8PC9Bbm5vdHMgOSAwIFIvQ29udGVudHMgMTAgMCBSL1R5cGUvUGFn ZS9QYXJlbnQgNzYgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsy OSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDUyMSAwIFIvQ1MxIDUy MiAwIFI+Pi9Gb250PDwvVFQyIDQ5IDAgUi9UVDAgNTEgMCBSL1RUMSA1MjUgMCBSPj4vWE9iamVj dDw8L0ltMSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0wIDUzMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNTIzIDAgUj4+L1Byb3BlcnRpZXM8PC9N QzAgNTE5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyA1Pj4NZW5kb2JqDTkgMCBvYmpbNTQgMCBSXQ1l bmRvYmoNMTAgMCBvYmo8PC9MZW5ndGggMTA2Ny9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SImUVt9z2kYQftdfsY9JU06391M3k8lMwJ6OO3HSFk3zYPtBBgFKA3KQHJL89d27E6pMAbd4zIF0 +33ffrt7In27batFMWvh9es0//5QQvpbsaw2RVvVG0jH4/ob3AjLhATtmEYEbTLmrHMZ2EzQFe4c 3KVv27aYrco53KR5/UCBddvWa0jflYsW0j+q5aqFuzdvxhcTSNIPE0ivJxzit8mUw6wBzpTOMkGr oZelNaPvEqCZbRKEinb+QjuXTYLKMpWBQcZJjxIcLP1vy2SRfEm0oZtBXnd/pFW/4eNPsImEkynw 8AfTyfuEM6thBxlc05VPgPAr3NxxmMNprmnyO4U5J9CQVO4UeuncKo1RshgGomNcAGadzLO5xkAl QqSPirGijxVKovRkWrlgGy37SMM5pxopH+w/YcYyR69hPDfCKgpEaYWmleL5E26hDrj3utErJqX4 r1QjrzGneb8kHFCTem2lg5E1zCq/k64quirIKueDNczWSXq15nBRk8cEBR2NcV4cKh0stQKE7bAv r6mRwls6XRXUxNTM15OrCwLvei6wS8G4MkQ10pIp3rELkkqFkjhkx8h+DFMPMQWJ8nlayih45WnI UlBODvFExNOxtv4eDyN0mMQBl9lzdc3qbRjnSZrnxAN5qCbnkj7OYNR/3vmteQNUCVp/0Ld8S29S MaIcxYXiuWUYTHCCkQqqZr5OXlxt2m09f5yFA6CtX+afkjOh0s8HlT3G5mXT3tMh4INII+41CkdZ k0QetZHj5NQoLkM05ZDamUzzYKNJ5D65W5PRZKU2Yful332Zdza+G9fz772N2NvI/NCFwePSyaGh ohMbdR6QCi585hkfGHUrhI4K+9IMcyaJ1h3NtwNDjoSGqrNuVcLkEqqGmqH4XP0gFx+barOEIrhJ gpXlxlMxJDu7kYg1RzxtbkemjGbWimjVn5NXrw6URyAbcFhEPA2mfRvTs0AFtKZetLtiW0K7Klo4 WjMhDdM2M+6pg9vHTQPV5vkE3Zn8emjMNJOOd35+rDbzetccTVPs0yS+85hSCDqaEW3A/DBlcPvi TJ+JfZ8NTq3YXV1bjPbmPp+OpFlwSD32xOQhuZCZr0bciP7QpcM1nrmKySyeKgcK5ckDBc/2v5dF hUdDs8xVtOP25Rkr1P8ZuUM26x9ynLo1tAty8x8HrnPWeyyP29sjd9Pn1HD6ZsXzzeiRT1avhxeG jnj/mA7FKzfzo40oe71+9M4CSmmZdWgi4tdiW9WPDfxFXd5AvYB12TTFsmx+DvpH++buwOXxcZZc skxm7sDn3apuSngotsW6bMttE2y5L885E1hUbz5/jk8pR4SCHsXBn4dyVi0qOvK+VgXMq+JzvRzk oU8b7l1R9CNMPM3gvv5WHo7+8cb+B4CsZei4zQICG7b23wIMAO/tcd0NCmVuZHN0cmVhbQ1lbmRv YmoNMTEgMCBvYmo8PC9Db250ZW50cyAxMiAwIFIvVHlwZS9QYWdlL1BhcmVudCA3NiAwIFIvUm90 YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291 cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDAg NTEgMCBSL1RUMSA1MjUgMCBSPj4vWE9iamVjdDw8L0ltMSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0z IDEzIDAgUi9JbTAgNTMwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4 dEdTdGF0ZTw8L0dTMCA1MjMgMCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1 Y3RQYXJlbnRzIDY+Pg1lbmRvYmoNMTIgMCBvYmo8PC9MZW5ndGggNzA5L0ZpbHRlci9GbGF0ZURl Y29kZT4+c3RyZWFtDQpIiYRUXU/bMBR9z6+4j9ukOv64tmMJIdGAJqZ1X420B8ZDV1ooUhtoM7Ht 1+/YTlHHBmnVOHHOuef4frQ82Xar5Wze0dFR2fy6W1D5aXa92sy6Vbuhcjxuf9KF9kIbskFYpci6 SgQfQkW+0tiRIdBledJ1s/nN4oouyqa9A7HtunZN5fvFsqPyy+r6pqPL4+PxaU1F+bGmclJLyk/1 VNJ8R1KwrSqN1eHjsVZ4NkS7+aZQtALyLZDXu0KxF1yRU0LCD2tJHr/tolgW94V1eJns9e9Hlh8B X9/QJgvWU5LpS9P6QyGFt/RAFU2wc0uK3tHFpaQrel5rWnwGLQStHKzKwCpal56typb1IVEFITWp qrf54lkzkXViRlbm6keuZqNMFLMcUtqw7JlOSokacSTHO1WJKuBzyJdOewZRGa8tVvDlX9qan2jv favoGE7VP0fNus49r3tfSFIW7q03gUbeCc8RiV3GrkaqQiRbmq+L8nwt6bRFjhGKehkXojnFNqXU a9K+j302QSOlSzm9maGJ0cyT+vwUwfueS+pGC8kOUiNrBMteXcMqCmXUobrK6pGmoRuP4mE6pSNG QtaIgzmk6EyxuXzxnUxT8tTnE4tqb7Hvx3jScVOUTQMdalLBpDS4ndPo8f4hQpsdIdlYf+Op2eJi WEBylBfwpRcqnTNoARcoWLMuXp1vum179WOeZrxrXze3xQtUE0cAlc3cZrHrvmPOIwke1d6jDjh1 tohbzg6RWuRrlJfDmBwU+hapiyG/ae3qbOJZgjVOaGddSIyzITTqa1N3RTTthuBoRuWVqxK8HUKj tMwuYZcDWCcZkb3L6G4IrazwLlid0A9DaIyN88HkQ86G0KkvK84J3A6h0fPWhr5fFhF91vy3ffXh hDlp06gwjVhWwoaQeslah7+LEByGLU8Z9zNj8sykwH8EGAASXWOpDQplbmRzdHJlYW0NZW5kb2Jq DTEzIDAgb2JqPDwvTGVuZ3RoIDc2MzY3L0ZpbHRlci9EQ1REZWNvZGUvV2lkdGggMTAyNC9IZWln aHQgNzY4L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDUyMSAwIFIvVHlwZS9YT2JqZWN0 L1N1YnR5cGUvSW1hZ2U+PnN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAASDg4OEA4VEBAV HhMREx4jGhUVGiMiGBgaGBgiJx4iISEiHicnLjAzMC4nPj5CQj4+REREREREREREREREREREARQT ExYZFhsXFxsaFhoWGiEaHR0aITEhISQhITE+LScnJyctPjg7MzMzOzhERD4+RERERERERERERERE RERERET/wAARCAMABAADASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoL AQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVB UWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOE w9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQF BgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1 wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eX p7fH/9oADAMBAAIRAxEAPwDHqvO3cVbbe/aHNcDIBIEabvH/AF5+UmwcCsdPZnMZbZeHN2MaW7Hn dwG89tfilk212YputxHsteXWNyGtAbNthcQ46bo4B1VrN8QnHNwAARhMxlYuwDSMfIY5YzI6ynEG OtcJQnKtHdMcu3xVzpNDXdXqqubIa94c1waPcwOiQ0lvI7EhWMOzqOTcb7r4rryKBdjuJJYXWtaw MG3aNdNCONVfGccMZcI1xxyG9Pm2HVz/AGalKNn0zlDT+q5X2u3xS+12+K3cmuyzHyWWW/am35vp 1Rud9li07gS8e32+2Bp4TKtPwaH5uXeHQ3KrfRVEfz0PbYG+bfS/FN+9RAsx/lp/H8F33c3QLzH2 u3xS+12+K6D7QKXYzsm5gwjgV7sdzgXWPh/0KpmeNY8lzdVl9XuqsfU8iC6tzmGOYlsKXHk4+Koj T7PyWTxiNWTqk+12+KX2u3xXQi2531sNTrHmpjpZWXO9Np+zdmzHcrO6Xm1b7m25VwsvaxlGbb7r GbTuIIL7NrXE66/cmDMSLGMH0RnprpL6LjhiP0v0jH7Pq5/2u3xS+12+K2un/bKPrD9muuLve91j WHZU9zqi4OLGw2Yjssjp1t12fh2XWPtebKvdY5zzG8H84nxTxksn0xoQE7B734eC04wBub4uGqYf a7fFL7Xb4roPtAF76ci5l1zs9v2ZgcLbKWC/XdBO0bdI7LFsoOT1i2nX9JlWNMcgG1w/AIY8wkTc RGo8V7pnh4et60h+12+KX2u3xWz9Ym2MyKMunfS4h9Ujcwt9JxbIOh9wOniE2RfkO6j0us3WGt1O I97N7tr3mw+5wnU6d0BmuMJCA9Yl124d+ijhAMgZH0107uP9rt8Uvtdviteotyeviiy6++puRc41 2kilrqy/aGN9R0gccDT4qXTL8jJofbmS6xmVjOr3T7H23Br2N3cADt2QOehZgPljI/4RodE+yLoS 6kfZr3cb7Xb4pfa7fFbuTXZZj5LLLftTb8306o3O+yxadwJePb7fbA08JlWn4ND83LvDoblVvoqi P56HtsDfNvpfim/eogWY/wAtP4/gn7uboF5j7Xb4pfa7fFAhKFbodgwJ/tdvil9rt8UCEoS4R2Ck /wBrt8UvtdvigQlCXCOwUn+12+KX2u3xQIShLhHYKT/a7fFL7Xb4oEJQlwjsFJ/tdvil9rt8UCEo S4R2Ck/2u3xS+12+KBCUJcI7BSf7Xb4pfa7fFAhKEuEdgpP9rt8UvtdvigQlCXCOwUn+12+KX2u3 xQIShLhHYKT/AGu3xS+12+KBCUJcI7BSf7Xb4pfa7fFAhKEuHwCk/wBrt8UvtdvigQUoKXD4BSf7 Xb4pfa7fFAgpQUuHwCk/2u3xS+12+KBBSgpcPgFJ/tdvil9rt8UCClBS4fAKT/a7fFL7Xb4oEFKC lw+AUn+12+KX2u3xQIKUFLh8ApP9rt8UvtdvigQUoKXD4BSf7Xb4pfa7fFAgpQUuHwCk/wBrt8Uv tdvigQUoKXD4BSf7Xb4pfa7fFAgpQUuHwCk/2u3xS+12+KBBSgpcPgFJ/tdvil9rt8UCClBS4fAK T/a7fFL7Xb4oEFKClw+AUn+12+KX2u3xQIKUFLh8ApP9rt8UvtdvigQUoKXD4BSf7Xb4pfa7fFAg pQUuHwCk/wBrt8UvtdvigQUoKXD4BSf7Xb4pfa7fFAgpQUuHwCk/2u3xS+12+KBBSgpcPgFJ/tdv il9rt8UCClBS4fAKT/a7f3kvtdv7yBBSgpcPgFJ/tdv7yX2u395AgpQUuHwCk/2u395L7Xb+8gQU oKXD4BSf7Xb+8l9rt/eQIKUFLh8ApP8Aa7f3kvtdv7yBBSgpcPgFJ/tdv7yX2u395AgpQUuHwCk/ 2u395L7Xb+8gQUoKXD4BSf7Xb+8l9rt/eQIKUFLh8ApP9rt/eS+12/vIEFKClw+AUn+12/vJfa7f 3kCClBS4fAKT/a7f3kvtdv7yBBSgpcPgFJ/tdv7yX2u395AgpQUuHwCk/wBrt/eS+12/vIEFKClw +AUn+12/vJfa7f3kCClBS4fAKT/a7f3kvtdv7yBBSgpcPgFJ/tdv7yX2u395AgpQUuHwCk/2u395 L7Xb+8gQUoKXD4BSf7Xb+8tTp4bZj+tbD3Oc5ga6Q0emGH8wtOu9YkFauI7bg1jxtt/6ilR5R6QB pZ6L8YHFrro2n21N/wAFV99v/pVCbey26ugVMb6rm172Gzc0vO0H3PcPwTXYeWGlzqbA0CSS10AD 5Kvh6Z2MP+Gr/wCrCiocEiJE0O7Ka4gDEa+DexG1nFZa8Cx9jS/37gAA9zIGxzf3UUV2OburxA9p 4c1t7h+FiBhbXDAqdq17QHDyORYFaOZW/Htrx2vxTW0Oa8XWua2bGtPtH9ZRyMuIgWfV30Auu66I jwiwPl7NB9oe59JqbU9rbHbm+oHNdSxzyHB7nfuwruPj1+jX7Bda9jHndvmbGB8AMc3iVnvsbZ1D Iewy17cpzT4tdTaQrtVtrHU+kSLBVRtjmTSxV+eyTxwjwmUeIi6OuxbHJYoZMkrjGVRNWNNwsfRJ DW0VucTAANxJJ/64s7qLKnYuQW1il9LN5LC/3AvbWWuD3O/fXT2sLPUuorZ+0tgL6wd2zd9JzW/v f66z7uWynOfh5pcS5xpBJOpJN9KpYeYzDPjickzxTAqzVN6eDAcOSUcUI8Ed6F3/AARYXVMyjGrp r9PYx29u5ri6fiHhTdn59lDqTc3a9grcYdu0JcXfT5dMHxC6K3ovQ6KzZdW2qpsS99j2tE6CSXoL cL6tuaHMNdjXODAWWvslznMZHtefzrG/CRKtzycjKRlLFMmRJOvU7/pNAHmgKjkiANtB0+jgeo82 G4ui1zzZuZLYc52726kiPijv6lmuPuu0L22EBlbZfWQ5pdtaCYIHK6L9g9K/0H/Ts/8AJJfsHpP+ g/6dn/klMOd5aox9uREBUbANAfVg+75rMuMXI2a01LzVWdlUmwstO65/qWEtY7c/dv3QW7efAJ2d QzWFpF5lj7LGktYf0l873Rtj84+S3f2Z9X/tH2b9H9o/0PrO9Tjd9HfPGqP+wek/6D/p2f8AkkTz vLdcUu3yj+Kvu+b/ADnjuXlLLLLSw2vL/TrbUyQ0ba652j2geKj7V1v7B6T/AKD/AKdn/klCro/R LqxbTW22t30Xsse5pgwYIenD4hgAoQmB5D+K08pkJsyBecGbkjLdmeqftLjPqQzT2enxt2/R8kq8 3Jr3bHtaHBoIFVLW+wy32isNkHyXTfsHpP8AoP8Ap2f+SS/YPSf9B/07P/JJv37lv83LavlG32rv u+X98b28xXlZFeQcptp+0Ekm0w50uG0/SBHHkhUuNDq3VmHVEFh51ZwV1TeidHcXBtQJYdrwLHna 6A6D7vAgpj0fog3TW0bXBjv0j9Hvja0+/k7hA8wnDn8A2hPbh2G3bdB5XIf0xvfXd5hltjbvX3zd vNu8gfzhdvmIjnyRW52W24XCxotDi/eKqGuLnAgkltYnldL+wek/6D/p2f8Akkv2D0n/AEH/AE7P /JIHnuXNXjloK2G3bdI5bKL9Y1N/V5d2Rc6ltDrCamuNm2G62O5cTE90jk3G6u42TZQ1jKjDfY2o y0ca6nvKP1LDx6M2yqpm1jdsCXHloPcoZ6ZkggHGtBcYaC1+piYHyCsRzYuEHhoH1DbqxHHOyOIn ofoibbY243h59YvNhs0B3uduJ0AHJRX52U97Xus/m7PWaAytgFo/PIa0SfjKg/Ceyxtb6XtsdG1h Dg4yYEApvsZAeTW6KjFhh3sJMQ7w1R9zEauN1tsjgmL9R13SVZ2VSbCy07rn+pYS1jtz92/dBbt5 8AnZ1DNYWkXmWPssaS1h/SXzvdG2Pzj5Kv6Nfh+JS9Gvw/EocWH9wdtgmsn757sQGgAcxon9qf0a /D8Sl6Nfh+JUnvR7FZ7R7re1L2p/Rr8PxKXo1+H4lL349ir2j3W9qXtUnY7WmHNIMAwZGjhIP3La 6P0rAycZz7qt7g8tB3PGm1p7OHimZOahCPERKvBdHAZGgXD9qXtXUP6T0FlTrntY2ppLXWOtcGNc HbCC4vj6Wnx0QTi/VYMDzbRscS0O+0HaXNgkA+p2kfeoP9JYv3cn2D+LJ9zn+9F532pe1dVZ0fol W31a21+o4MZuse3c93DRL9SfBJvR+iPsfUytrrKo9RgseXM3CW7hv0lL/SWH93J9g/ir7nP96Lyv tS9q639g9J/0H/Ts/wDJJfsHpP8AoP8Ap2f+SS/0lh/dyfYP4q+5z/ei8l7Uvaut/YPSf9B/07P/ ACSX7B6T/oP+nZ/5JL/SWH93J9g/ir7nP96LyXtS9q639g9J/wBB/wBOz/ySi/onR2Mc99QaxoLn OdY8Na0akklyX+ksP7uT7B/FX3Of70XlPal7V1v7B6T/AKD/AKdn/klF/ROjsY576g1jQXOc6x4a 1o1JJLkv9JYf3cn2D+Kvuc/3ovKe1L2rqKOk9ByGF+O1lzAdpdXa57d3MS158VM9E6OHhhqG9wLg 31H7i1sAkDd2kfel/pLD+7k+wfxV9zn+9F5T2pe1db+wek/6D/p2f+SS/YPSf9B/07P/ACSX+ksP 7uT7B/FX3Of70Xkval7V1D+k9DYCXVj2vZW6H2O22Wloa0w7Sd4++eFN/ROjsY576gxjQXOc6x4a 1o1JJLkv9JYf3cn2D+Kvuc/3ovKQ1KGrqB0noJNQDWE3gupHqv8A0jQNxLPf7tNdEX9g9J/0H/Ts /wDJJf6Sxfu5PsH8Vfc5/vReShqUNXW/sHpP+g/6dn/kkv2D0n/Qf9Oz/wAkl/pLF+7k+wfxV9zn +9F5KGpQ1db+wek/6D/p2f8Akkv2D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReShqUNXW/sHpP8A oP8Ap2f+SUW9E6O8SyoOAJbIsefc07XD6XYiEv8ASWL93J9g/ir7nP8Aei8pDUoaut/YPSf9B/07 P/JKrdhfVulz2WmttlTS99fqvNga1u8nYH7vo68Jf6Sxfu5PsH8Vfc5/vRechqUNXW/sHpP+g/6d n/kkv2D0n/Qf9Oz/AMkl/pLF+7k+wfxV9zn+9F5KGpQ1dVb0folNZturbVW36T32Pa0SYEkvUaOk 9ByGF+O1lzAdpdXa97d3MS158Uv9JYv3cn2D+Kvuc/3ovLw1KGrq39E6OxjnvqDWNBc5zrHhrWjU kkuUv2D0n/Qf9Oz/AMkl/pLF+7k+wfxV9zn+9F5KGpQ1dNX0z6v22uoq9Oy6ud9bbnOe3aYMtD5E FH/YPSf9B/07P/JJf6Sxfu5PsH8Vfc5/vReShqUNXW/sHpP+g/6dn/kkv2D0n/Qf9Oz/AMkl/pLF +7k+wfxV9zn+9F5KGpQ1db+wek/6D/p2f+SS/YPSf9B/07P/ACSX+ksX7uT7B/FX3Of70XkoalDV 1v7B6T/oP+nZ/wCSS/YPSf8AQf8ATs/8kl/pLF+7k+wfxV9zn+9F5KGpQ1db+wek/wCg/wCnZ/5J L9g9J/0H/Ts/8kl/pLF+7k+wfxV9zn+9F5KGpQ1db+wek/6D/p2f+SS/YPSf9B/07P8AySX+ksX7 uT7B/FX3Of70XkoalDV1v7B6T/oP+nZ/5JL9g9J/0H/Ts/8AJJf6Sxfu5PsH8Vfc5/vReShqUNXW /sHpP+g/6dn/AJJL9g9J/wBB/wBOz/ySX+ksX7uT7B/FX3Of70XkoalDV1v7B6T/AKD/AKdn/kkv 2D0n/Qf9Oz/ySX+ksX7uT7B/FX3Of70XkoalDV1v7B6T/oP+nZ/5JL9g9J/0H/Ts/wDJJf6Sxfu5 PsH8Vfc5/vReShqUNXW/sHpP+g/6dn/kkv2D0n/Qf9Oz/wAkl/pLF+7k+wfxV9zn+9F5KGpQ1db+ wek/6D/p2f8Akkv2D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/ 0H/Ts/8AJJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/wDJJf6Sxfu5PsH8 Vfc5/vReRgJQF137B6T/AKD/AKdn/kkv2D0n/Qf9Oz/ySX+ksX7uT7B/FX3Of70XkYCUBdd+wek/ 6D/p2f8Akkv2D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/T s/8AJJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/wDJJf6Sxfu5PsH8Vfc5 /vReRgJQF137B6T/AKD/AKdn/kkv2D0n/Qf9Oz/ySX+ksX7uT7B/FX3Of70XkYCUBdd+wek/6D/p 2f8Akkv2D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/8A JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/wDJJf6Sxfu5PsH8Vfc5/vRe RgJQF137B6T/AKD/AKdn/kkv2D0n/Qf9Oz/ySX+ksX7uT7B/FX3Of70XkYCUBdd+wek/6D/p2f8A kkv2D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/8AJJf6 Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/wDJJf6Sxfu5PsH8Vfc5/vReRgJQ F137B6T/AKD/AKdn/kkv2D0n/Qf9Oz/ySX+ksX7uT7B/FX3Of70XkYCUBdd+wek/6D/p2f8Akkv2 D0n/AEH/AE7P/JJf6Sxfu5PsH8Vfc5/vReRgJQF137B6T/oP+nZ/5JL9g9J/0H/Ts/8AJJf6Sxfu 5PsH8Vfc5/vReRgK5VNmMyutzBZXY9xa97a5bY1g0LyBpsXRfsHpP+g/6dn/AJJL9g9J/wBB/wBO z/ySbL4hiI+XIK8B/FdHlZg3cS5lnUOsWMdW+2oteC1w9XF1B0P5yo01W1ZVN9rq2102NscRbVY6 GODoDWPcSTC6H9g9J/0H/Ts/8kl+wek/6D/p2f8AklGOcwgECMoiW/DAD9q84JkgkgkbWS4DDY+v HdQ9gdS0scHWMpcHeo+wOG9zf3uyJZb1KxhZZc17Ty12TSQfkbVt/sHpP+g/6dn/AJJL9g9J/wBB /wBOz/ySJ53Fd1Le9Yg/tUME6qxtW5ecrrfTY6651YaK7GgNsrtc51tbqwAK3O/eVuq+wPryMays FtdbfdZXW5rq621mW2OHgtj9gdJ/0H/Ts/8AJJv2B0n/AEH/AE7P/JKHmM+DNECfugg2DEAbfVlw DLhkTH2zxRMSJWd3IbZlMsFzbKxYDO/16Jn/ALcVLNeW42W+97HWZDNrQx7LSXG1lhJ9Nzo+iuk/ YHSP9B/07P8AySR+r/SCIOPof5dn/klXxw5WE4zvOeA8QB4atsz5nPOEoGOIcQ4SRd0m6pVZbiBl e4ON1B3MAc5obfWS4Agj2jXUR4qlnY+W27GYLLslm5rnucGwC3KxCJFTGN0aHHUTG7stE9QwQYN7 QRyPd/cl+0MD/Ts/H+5RMbndHbnC2cmyxzjX+sMdXaxgvlvD7bHNP53800M/6C2lW/aGB/p2fj/c l+0MD/Ts/H+5JTTbh5F2Xlb3BmMcmq3bsPqPdTVQ5pbZujbuZB9p4InwpOpzm4OD6l14D6t2S5zc i631y2vY0txn12CBu/kz9KXmVs/tDA/07Px/uS/aGB/p2fj/AHJKaeS3qo6e5oeH221MqaAw1XMu t21utc+t9jfaSXHa3TsdJVR1eZQy6g1/ZqfUrtrrxhfbW5j2Oa6hrqK2Pr99e8uaNN2oMw7X/aGB /p2fj/cl+0MD/Ts/H+5JTlP/AGj6jvRZacj0D6bHOtDMV4o9rS9/6HImw8n3AnWQPa59TcfS+1fs 7cz1d32n7RO27ft3/p43el9HTntvWp+0MD/Ts/H+5L9oYH+nZ+P9ySnKu+0EWMHrsxza01WluXY8 Mbj0hrNlL2W+4lxJJgOadw3FDxWZYYbbW3tzch+HY+Ba1hr/AFVl25rf0YdLXbho7bP5q2f2hgf6 dn4/3JftDA/07Px/uSU4wbmvrqYPtIscKh1CTc39Mb6N3pOMAN2+pPpe2PLatfCbZW7IqdvNVdoF BsLnuNZqrcfe+XO95dyT4doUv2hgf6dn4/3JftDA/wBOz8f7klPOdY/5Su/s/wDUNRzkUP6ldtrq AJvizc4CzcywDc51m2HE9o8kXL6bkZ+TZk4pbZS4gB0xq1rQeUH/AJv9S/db/nBaEZ4+CIMqIhTV MZ8RIH6VteoCrqNDniutvqVuIY8PraA4T7tz/DuUWvKruqsrscKvUY31nxq6z1am7omXQxu7xkv8 VP8A5v8AUv3W/wCcEv8Am/1L91v+cE4zxneQ6fgjhn+6zufQyl1obU2/Y4Bs0Xfn0x7a2hkwXdp5 +Sx24hu93puZb6frNLqqwwOY0vcN7SdXOdozaWx8Ih/zf6l+63/OCX/N/qX7rf8AOCHFjquNNTv5 WVDcc1kvFRxGspLiNnrB3qVC0mP0vd38NITW20ta94ZU24VnbrTdM2VxpXWK5jd4u5nSFI9F6uax UTNTTLWF/sB8QOO6h/zf6l+63/OCXHjvWY3Vwz/dZg4XqvIFbnMfbXQAa2AsY6vZJeHMPtLvc4Gf GYUfUxvUqYG1NZbcW3j2Phm2oH37RtEl2rYHO3QBN/zf6l+63/OCX/N/qX7rf84JcWP99VT/AHWr m2eoKXAsLBWxrduzfLK2Ndvj3cjTd8tFtfV/+hv/AOMP/UtWf/zf6l+63/OC1+l4eVh47qrayXF5 cC0tIggDuR4KPPOBx8MTeoXY4yE7IponfZh2YjW3MvGZ6m4VPADDnh+9r3sLDDTu76a8AqeXVdTl 47n5OU5orvBvrqZc8FzqIYRXQ5oB2k/RnzWz+l/0TvvZ/wCSS/S/6J33s/8AJKlr2bDkW4T7cPpm NZWathaLBXr6Dm4trQ5rjvjY+NrpOsayq78bKofeXNcX5FdBycisXP22b8h7tgpLLXhp2sABlrC2 faFv/pf9E772f+SS/S/6J33s/wDJJaqedqZ1CzHyLnnIN1GOTiR69QdYy3J2fonO9xLWs0fuJEbp nWeU/qf2x5xfUZc/1WCrZc6sBtNnpP8AUsccf3Oaw6NBE7SfpTv/AKX/AETvvZ/5JM51jWlzqnBr RJMs4H9pLXsp5y11rr7a8OzJZjgUOu9UZdljWu+0yWsc5l2rms+gfjoHIrac4wXvyH7W47GOHq0g 125NjLfYHu1FJGriXtEOJa5aVGR0jHYWY76aWE7i2tuxu7iYa0eCL+0MD/Ts/H+5JTi2t6mXhvqX VtZvZjRXdc5z2X2tbuLLK2/QFet0tdzP05nk4uY/EsFfrPvyrMyp7Hve5npObkel7Xu2MEtZBEdt YOuv+0MD/Ts/H+5L9oYH+nZ+P9ySmeJ6f2dvpeps1j1vU9Tk/S9b3/f8tELqjHv6ZlsY0ue6i1rW tEuc4sIAACl+0MD/AE7Px/uS/aGB/p2fj/ckppZFltz35ONXYGNpdTYXMtpe42PZDgz2WO9Ju92k H3bWHcTFPCrvdlVWZBvfTS+yumwMyanTYMZ7dzXudYWbmvkvJbprA2hbP7QwP9Oz8f7kv2hgf6dn 4/3JKcC67Ma9zrDfXVaWHIra3KHpPdlUN9NlrnuDva54/RbQ7w+jFq37QaSxvrsxTaTTa5uXZcGN rYNjmVPZf7nl5l5gbRpBYtN2b054h91bgCHQQT7mnc08diJUv2hgf6dn4/3JKcOvHvtoccll/wBq yX4dj49VjNg+yix3shjHhzHeDwBP0Vfvqv8A2d1THAse1rbGYwduse5r8djoDnS53vc7ufDtCu/t DA/07Px/uS/aGB/p2fj/AHJKc27Avxsim+phyPRtf9mqBgV0/Z73bJIhk2O2eG1tY5Cr41eXZkMo dZkPxPUY5zw3LxTrVk7huusdZEtr/O2zGkkztftDA/07Px/uS/aGB/p2fj/ckpxcx/UW48M9ZllH r/Z3BmRc60stsbW1wqcBo1rPdaHB+6dfdL5T8ttzRU68dQfbkNYCbRjuZ6OQ6gDd+g4DD4z9LXct n9oYH+nZ+P8AchNyOkNvdkNfSL3ja+0NixzdNC7bPYJKc2ijKsfVWbch+M64byG5OMRFNxPuutdb G7Z3DJiJJcoEdTNFYLrmMsrx7cpxbdY4WWNu9UNbU5tg94r9rCNvgG7p2v2hgf6dn4/3JftDA/07 Px/uSU5Ho5xpyLS/IfbRih+KR6tQdaH5Bb+i3u3HaGaP3OIjeJJC0OmVCo5DHCxtpuse8O9Q17bL bH1mvd7NWnXZ/a1R/wBoYH+nZ+P9yX7QwP8ATs/H+5JTZWDnNs9HLx8IXvbYzI9Wh1Tm1N9Suxxd U91bS5zrSNA52jjAjjV/aGB/p2fj/cl+0MD/AE7Px/uSU5dgzLepbN11LbnWVWtY2+GU+k8Msbc5 xpBJDXDa0OBME/SlXjqdlHrWOdUXWNrubW25wbXS14c9tdbm2++46FrtWbCdNy1P2hgf6dn4/wBy X7QwP9Oz8f7klK6eLRiVi5znv1hz2mtxZuOyWuc930Y+kd373ulZD6sxvT+m17rKKmY4FwbXe94u DKwxpbjPrsGm7vt8RO1a/wC0MD/Ts/H+5L9oYH+nZ+P9ySnGyac+4W0H1cm6zGcw7vUxmVPOPGu0 nHt3vPYy0nlzW+3cxPT+zt9L1Nmset6nqcn6Xre/7/looftDA/07Px/uS/aGB/p2fj/ckpzqQ+ys Yza7G315ll291b62Mr+1Psc4WOaAd9Z2+0md2vt3EVKaupOri2291jzSMprWX1bXm+r1NtjrSPo7 /wCZAZEkwNi3P2hgf6dn4/3JftDA/wBOz8f7klOUW57B7fXLHm0XSbHu9GjKrrZtmSHHH3Rt9z/p e50FaPTt+y3+c9D1P1f1t/qensZO71f0n85u+l8vbCJ+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0M D/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ +P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/ AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2f j/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts /H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8A ckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7P x/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ck pspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5 L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8Ackps pKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS /aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspK t+0MD/Ts/H+5L9oYH+nZ+P8AckpspKt+0MD/AE7Px/uS/aGB/p2fj/ckpspKt+0MD/Ts/H+5L9oY H+nZ+P8AckpspKt+0MD/AE7Px/uU68zEteK67mue7QNG6fyJKR9O/ojf6z//AD45WlV6d/RG/wBZ /wD58crSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmeN/hf6//AHxqOgY3+F/r/wDfGo6eNkI7 jcKyaGtfbpta9xraddZcGvI08lRxuqh2HRk5NfpOyWiyqqn1Mp5rc1rtxayoOEboOkDTXVaSzWdN uppxBj3Nbdh0/Zw+ys2MewivcdjXsIM1iPdprzyCpM3qmC+30mWFxlrfUDHmjdY1r2D1tvp+4PEe 7WQOSg3dWo2A47tzzZS0b2Pa19d19dTn1OcGh4Af9JpI1b4ia+L0i+p1mP6gbgstofW0t3X2DFqo DHeoHho99UEbOxiJBE29GftoY+8FmGK2YwDNrhVVbTbFh3nc4+g0SA0cnbwAlNtvVMFwcRYQGjcC WPaLGkhoNMt/SSXADZunc2PpCXx+o4mTZ6VTneqN0sfXZU4emKy6RY1p4tb9+iou6PY2hjTb6n2O sMwmsYGuip9VrRbush5JoYNPTH0uJBaJvTsvJpcMysbsrK9SyIrNVH2cUPljbLB72tLNHmN+/QiA lOm/Or+z020D1TlwMZurA8vYbBJI9o2guOkwNAXQ0tVnj1RjZLRTlEgCtpNrHB7bHtLX7W9qncga tPbaXFycf12sLXbLqXepS+Nwa/aWat0kFriCPA6EGCM9mDl22uuuIZnUva6vI2h2M9jW21sa2oWb 9G2uJ3EHe7RzmABJTbd1TBadbCQC4PIY9za/Te6tzrC1pDG7mO9zoGhMwCnr6jhW2elXZuf6jqNG uj1mB5cyYiQKyfhB/ObOcfq81x32uputfvFr7MdtkCy6279AHvcGGbT9LeDDdNNbV2DY3p9mPUfU tfcbWP0b6Trcn1hZBMO9Iu3R+dtjukpvVXV3NL6zuaHPYTBHuqca3DXwc0oiHTTXRTXRUNtVTQxj ZJhrBAEnXhESUpJJJJSkLJ/o9v8AUd+RFQsn+j2/1HfkSU1Ma/16g+IlGVLpn9FarqYlSSSSClJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSk3n5FRT7mtBLiAIOp0CKkN2bj0WVV3WtrfkO2VNdAL3RMD/XmByQo3Oc czDE6b36f9bcqOZ0joudeb8pottIDZNrxDR2ADwB8lZmv7VhMrduDC4fSL3aVnlxJJ+aSmXTv6I3 +s//AM+OVpVenf0Rv9Z//nxytIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKZ43+F/r/wDfGo6B jf4X+v8A98ajp42QjuurprNtp2sbHYkkkwAANSSdABqToEBuaBW+3LqdhVVxL8h1Iadxjmux4Gvj HOiJl4/2mg1h2xwcyxjo3APpe2xkjSRuaJEjTuOVUvr6pkU7XsrqLXA7K8i1vqthwLTa2pj64MOl szG0wCUVNk9QwGvrrOTUH3hrqWmxm6xr9GlgnWe0cqGX1LGx6skteyzIxan3Pxw9os2sbu1GpE6a x3WNT0zqLftWHsYGZVGyy51ljxWL78t/sc6ubXNbaJkt7a6yi9Q6Pn5b3jc1wPr7bX3WxF1FtTGf Z9prbt9QDcDJAJ5cQkp0Mnq+JXh2ZdD2ZTWCyPTsYWl9VTrtsz4N7AnvESVJvVsH7Q/HssbVYxpf 731gOax9rHFsOP0fSJd+6OYMgZ+f0nPzvUtf6VNr2GoVh77GbRRlVtdvNbTq7I1G3QCZMwrOL026 i+02Cu6nK9RtzXE+1hvyLmQ0tIfuF8OBiI/OSU6YewvNYcC9oDnNn3BrpAJHntP3KqzqNT3t/Rvb j2ENqyjt9CxztGhsO3e4/RJaGu02k7m7h9Jx314wutL3XXBpm3W5tTG7amPnXdt1eOPUc8jlVjRk Utxen2MnBqdUK8isPstP2dzHVMsY1kM1aNz5LYafobmwlOocnGDBYbWBjmG1rtzdpqbBLwZ+iNw1 41UWZuG9rHsvrcy3+bcHtIfDhX7TOvucG/EgLGd0fOsqox3+m2rCpFNT22WNfca7cexpdtY01bhR y1zi2dJhWcPpTqsuvKsYwFouJHqW5L22WihjXC273O9lRE+2AdsHUlKdNl1L9myxrvVbvrgg72CP c3xHuGvmERZvTcT0322kODGufTjMfoa6GvcTtEe0Od9GNDW2rwWkkpSSSSSlIWT/AEe3+o78iKhZ P9Ht/qO/Ikpzemf0Vquql0z+itV1MSpJJJBSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpM6qq0bbWNsaNQHAOEg eadSbyfgfyIqQfZcP/uPV/mBBdVTXm4npVMrlz5LWhpMVu7q2q1v9Nw/6z//AD2UlLdO/ojf6z// AD45WlV6d/RG/wBZ/wD58crSClJJJJKUkkkkpSSSSSlJKFgBABEgvYCD/XCkGMaZa1rT4gAfkRU5 eJm5mQG2ssosgs9fDa0tvo9QwWvebTDq9Zlg3bSIB4PV1Fgp33zvNtzGsqY+15ZRc6vdsYHO4Ak8 SfMIRxc+11Db20l2O5pGYHH1yGOaXxX6TQ31Q2HAPgA/ncGD+m2ljA6unKa2zIcce4kVH7RcbWP+ g/3Mbp9H846+KU6FOXj3uLanbnNaHuEEFoc5zRMgQdzHAjkEagITupYjdAX2GXAiuu21zfTe6s7h WxxHuaQJ5gxMKpV03Jqx2NodXj31uuDCz3sbVlne5oaWgfo3kEae7YB7Q8gK/pb22tfitmttNdDa /tF+LsbQX7fdUHb53/ncR3lJTr4b2Pa97HBzHODmuaZa5pYwgghWVT6bSKMf0BEVbWDbIb7K2DTc XH7yfiricNkKQMPMx83HZk4z/UpsnY+C2dpLTo4A8hC6rTfkdPuxqI33gVEkSG12uDLHxubO1hJG vZZtmB1AXWnIYzNx3215FtTGNrFx9F9Dq9l1rmnaWVv9xHcjUAIqdkZFRNgaS41PbVYA1zi17wxw 4Hg8Engd+CirBPTnC2x1eGK3W24trLAKmmqih2MHUEh0+30i6Gy3wM6IA6TkPrqqdihpaKWZznen tzbG5FD3WmHEvhrLD+kh3u4klJT0N11dFNl9p21VNL3ugmGsEkwNeEAdRwnOxWCz3ZzS/GG136Rr WiwnjT2nvCp2YFren9UxaKwxlwsbh1N2tZtfjsbDRw2bN3hrJ7yo39LuqvbkYQa603PsbvkMrBoy NodrJBvuc4xr744aISnZUQ8F5ZrLQCTB2w6Ro7g8cdu/IXNY3R7DksZZiu+wCxj3VZDcQN3CnJY5 3p43s5dXrG75N0hdg21ZVH2nF+0UOu2VUfonhzK/2i9jQ2xwaAyt7CAYgaDUQkp6pCx8hmRWbGAg NfZWZ53U2Oqdx5t0WDZg59eJl1sx3WnMx30VVsdUPs49TIdWx+97QA1lzW+zcBtIGkSPO6b1B9D2 tpc6xrsl+K6r7MX123X22Nc99+rQQWFprIcPdOoakp6Oq6u5pfWdzQ57CYI91TjW4a+DmlEXO3dK sNVlYxyCcp92Q+oY5dl1WuufW2Lpa70zY2RYABHskgLX6dQ7Hwq6nbgW7oa8tc5rXOLmtPptawQD ENG1v0WkgSkptpJJJKUhZP8AR7f6jvyIqFk/0e3+o78iSnN6Z/RWq6qHTK6zjNljD/Zb/crvpVf6 Nn+a3+5MSySUfSq/0bP81v8Acl6VX+jZ/mt/uSUySUfSq/0bP81v9yXpVf6Nn+a3+5JTJJR9Kr/R s/zW/wByXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/3JelV/o2f5rf7klMklH0qv9Gz/Nb/AHJelV/o2f5r f7klMklH0qv9Gz/Nb/cl6VX+jZ/mt/uSUySUfSq/0bP81v8Acl6VX+jZ/mt/uSUySUfSq/0bP81v 9yXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/wByXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/3JelV/o2f5rf7klMk lH0qv9Gz/Nb/AHJelV/o2f5rf7klMklH0qv9Gz/Nb/cl6VX+jZ/mt/uSUySUfSq/0bP81v8Acl6V X+jZ/mt/uSUySUfSq/0bP81v9yXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/wByXpVf6Nn+a3+5JTJJR9Kr /Rs/zW/3JelV/o2f5rf7klMklH0qv9Gz/Nb/AHJelV/o2f5rf7klMklH0qv9Gz/Nb/cl6VX+jZ/m t/uSUySUfSq/0bP81v8Acl6VX+jZ/mt/uSUySUfSq/0bP81v9yXpVf6Nn+a3+5JTJJR9Kr/Rs/zW /wByXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/3JelV/o2f5rf7klMklH0qv9Gz/Nb/AHJelV/o2f5rf7kl MklH0qv9Gz/Nb/cl6VX+jZ/mt/uSUySUfSq/0bP81v8Acl6VX+jZ/mt/uSUySUfSq/0bP81v9yXp Vf6Nn+a3+5JTJJR9Kr/Rs/zW/wByXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/3JelV/o2f5rf7klMklH0q v9Gz/Nb/AHJelV/o2f5rf7klMklH0qv9Gz/Nb/cl6VX+jZ/mt/uSUySUfSq/0bP81v8Acl6VX+jZ /mt/uSUySUfSq/0bP81v9yXpVf6Nn+a3+5JTJJR9Kr/Rs/zW/wByXpVf6Nn+a3+5JTJJR9Kr/Rs/ zW/3JelV/o2f5rf7klMkkNzKxtIY0HezUNAP0x4BESUpJJJBSkkkklKSSSSUpJJJJSkkkklKSSSS UpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/1n/8Ansqyq1v9Nw/6z/8Az2Ug pbp39Eb/AFn/APnxytKr07+iN/rP/wDPjlaQUpJJJJSkkkklKSSSSUxf+b/XZ/1YUlF/5v8AXZ/1 YUkVKSSSQUpJJJJTSzs63Bxn21BrnOuDSHAkQawexHgsv/nLnf6Or7nf+TVrrn9BP/hhv/npc2tD l8cJYwSAS1ss5CVAu1/zlzv9HV9zv/Jqbuv9UY5zX0Ma5gl4LHgtBjU+7TkLKwvS+01uuIFTCXvB AO4VjftgkD3RHzV8XVOZvqtFl9lTqibwwF72Wss3P3ue36Bgbv3dOyfLHAGuALRKRHzJHfWPqDTD qqgYBgteNHCQfp+Ck76wdTYxr3U1Na4kNlrtYDXcb/BwVV9zCw2EVPDcettIIYXeoz0WukfSJEGN 3bxbKMHU+lS0Gn0A5pyAfS3Bhpo3ls+6dHfR1nzQ4IaegJ4pfvFk36x9Qc4NbVU5zjAAa8kk9h70 3/OXO/0dX3O/8mh432eu4ZLjWKmsojVu8WMfT6h2fSnR3bX5pUupDXeuyp9u8+tD6WMFW1u3bDHf yv5v3fOEuDH+4FcUv3kw+sPUnMc9tNZYyN7g15Dd2gk7tJSf9YepM276a27gHNlrxLTwRLuFQxL6 6se1thllllYsYI3Or22hxAPdsgjwdCtNuZca7XbHWCrb6JNTGtBtsOhvD2jaNoDeYOmgRMIAn0Ck CUj+kWf/ADlzv9HV9zv/ACad31j6g1xa6qprmmCC14II7H3oN7sUWehX6XobLzIDC7e11xr/AEn0 uzY11+aJlNpEkCkYzm3EEelvL/UtFZbHviQ3jSPKUOHHp6Bqm5/vM2fWLqNhLWV1EgOdw7hgLj+f 4BM36x9QcYbVUTBMBrzo0ST9PwQwMdjsm0OqDbXWGiHM3em6m+BtBlvLdDGsBTa7GrY0tNe9s11W F1J9QPpsaC5jWggF22fUmJ1PKRjj/cCrl+8r/nLnf6Or7nf+TS/5y53+jq+53/k0DdjjFcHMrc+H +q4PqbF2523a1rC8j6MbDs+W5ZicMeM36BotM5D9J2/+cfUNod6VW0kgHa+CREj6fmjv6lZ+zhnO qqfdZdsIc0loaGdtZ/N8Vm1ZlFfSn4rmCy2y0uE8Vja0bp8fD8dNCWz/AMT9f/hg/wDUuTJY4XH0 V+srzFLxKWvqv02r9uXf9x8f/MP/AJJL9uXf9x8f/MP/AJJZSPi2MrvDnHbo4B37j3NIa7TX2uIO mvhqpDhx18gWe5P94ut9v6nuDf2fXuIJA9F8kCJPPmhftfMAeTh0xUYsPpO9hJiHe7TVCbXi0Y7z Zq99Za+tt1by7bZSQWljXROuhnQKRyKmttJcHUWupbsBBsNDK7K9W/vtgHw3QRpCZwQ/cBXcUv3i nb1HqL/oYFbpAdpS8+13B54MILet5DnBrcWhznGABWSST2HuSuyqLcNpu9zjs/R1vDCyH5GgkP8A a0EaeEKpXf6t2Q95DLcgO2u+i1r3vDjqeARLfnrpJRGOGtwGiDOWnqLfs6nnVNLrcKmsAgHdW5p9 +6NC6fzShfty7/uPj/5h/wDJIVFba63V3PYCbangB9dgdtbdpMuaJMAzoJk6KyRjepIFVZcxpss3 Y9wrIc+f0cBjpaG/QAI8yTuHBjH6ESnin+8Uf7cu/wC4+P8A5h/8kl+3Lv8AuPj/AOYf/JKvken9 kq27GO9v6MenY53t9zzY33t1/Nd8uIFJPGLGf0AtM5j9Iur+3Lv+4+P/AJh/8kl+3Lv+4+P/AJh/ 8kspJH2cf7oR7k+5df8Aa97rPRfj0sJOx0MLXtkweXaEKz1Lqb8XNsorx6Cxm2C5kn3NDuxHiqfU cyjL6iyylga1rmt9Th1kHkj8nfx8BDrn/Kl/9j/qGqKOOBmLgBcLrxtkM5CJqV+qrSfty7/uPj/5 h/8AJIjOq5z63WMwqnVtnc8VOLRAkyQVjK7W0vxKiyxlbqrbHEl4Y5oLaocBO4/RP0QSnnFjH6MV gnPuWx+3Lv8AuPj/AOYf/JJfty7/ALj4/wDmH/ySi9+M8PfW2tuO4WlzSGC0WkvNQaPpx9D6Pt5n 85Bz/T/R7Njef0TPTfsbpE21fTn+VqO/MkDHjJrgCTKdfM3Leq51MethVV7vo76nNmPCSh/ty7/u Pj/5h/8AJJ7MnFOZkNawOre+2xxscHse9jLdm3aGwCXeJPEFBa6p1G53pbCyw3aMbZ6537No+nH0 Po+3/pIDHCtYBPFLpJM7reQ1xa7Foa5pgg1kEEdj7km9byHODW4tDnOMACskknsPcputpfk5FjhV Y57g6n3UVj0XOeSXeo1zd30fpDf+KHXZTXbTZV6Tcdlodd9F1gi4kbd49UjZt4H4ylwQ/cCuKX7x X/beRtDvstG0kgH0zBIiR9LzTfty7/uPj/5h/wDJKLdnpnf6P2uX7P5n05imJj9HG3dE6TP5ynvx g+muKttlobknawwCykPh0e1u4vgtgfupcGP9wK4pfvFnV1XOun0cKqzb9LZU50T4wUP9uXf9x8f/ ADD/AOSVWh9DcS5twLpsrLWtcGO0bZrq12mvgjm2u5jrX+kG2NtdePb6n2hxeWbZ/SR9DjTx/ORO OAJ9ApHHKvmKa3q+XS8ssxaGuBI1YfzSWmDu11Ch+3Lv+4+P/mH/AMkiZLqXW2OxzS69znGX+kWl huv3H9J7Z+h5xxpKpWGoYzbNgFtzQyIEAVH3WN7+6Gie59RKMMZ3gFGUv3i2f25d/wBx8f8AzD/5 JL9uXf8AcfH/AMw/+SWUkn+zj/dC33J9y6v7cu/7j4/+Yf8AySX7cu/7j4/+Yf8AySykkvZx/uhX uT7l1f25d/3Hx/8AMP8A5JL9uXf9x8f/ADD/AOSWUkl7OP8AdCvcn3Lq/ty7/uPj/wCYf/JJfty7 /uPj/wCYf/JLKSS9nH+6Fe5PuXV/bl3/AHHx/wDMP/kkv25d/wBx8f8AzD/5JZSSXs4/3Qr3J9y6 v7cu/wC4+P8A5h/8kl+3Lv8AuPj/AOYf/JLKSS9nH+6Fe5PuXV/bl3/cfH/zD/5JL9uXf9x8f/MP /kllJJezj/dCvcn3Lq/ty7/uPj/5h/8AJLQ6fm/a6rn21VVml1RDq27T7n68k+C5pa/Sv6Bn/Cv8 rlFnxQGOREQCvxzkZgEvRtcHCRqCnQMP+js+COs5tKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpJJJBSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/wBZ/wD5 7Ksqtb/TcP8ArP8A/PZSClunf0Rv9Z//AJ8crSq9O/ojf6z/APz45WkFKSSSSUpJJJJSkkkklMX/ AJv9dn/VhSUX/m/12f8AVhSRUpJJJBSkkkklNXKwPt9D6fU9PbaH7o3cVgRyPFUf+a//AHZ/8D/8 zW3jf4X+v/3xqOp4ZZxjUTQ8lkoRJsh53/mv/wB2f/A//M0v+a//AHZ/8D/8zWt1XItx+n3WUAnI cBXRG2fXucKq/p+36bhMrBaBjmvD22dMxsTIbdW97qXehj5GPezV7nXN91wePdP0gB2h/v5f3vwC 32odmx/zX/7s/wDgf/maiPq0wvNYywXtAc5uz3BrpAJG/vtP3KVD8hj241OWa7bs69ttRbW51FT/ ALVc0tbtDhvDQ5pdI4IBbLTVGW6rJzLWZIpyWsf9nxgKmjKsrzM0Mr2Fm50kAHZDju53GUvfy/vf gFe1Ds2v+a//AHZ/8D/8zS/5r/8Adn/wP/zNQ6ln224dmCLA/Mtfm1PxhtN5oFWUaf0Y92oayDGu nM6yy+oZbH1txM2uyr0w+m6x9Y+1Wl9gdWG1UP8AV27WjbXsdrEkuEL38v734BXtQ7L/APNf/uz/ AOB/+Zpf81/+7P8A4H/5mtDqXo+tT9t2/s7bZ63qR6PrSz0vUnSI3xu9u7b+dsVXHzG4uQC+1tPS X+r9me8tZVAGPsDHu7bvV2CYLfo+wNS9/L+9+AV7UOyH/mv/AN2f/A//ADNOfqy4gA5RIaIaCzgT MD3+JQcLqfUrrcXfdW0vbj/oXODX3stqrfbY2ltLnu1c73Ne1g2+4Q1026MzqNXTcPOsf9rdfW31 KoZSPVyGM9GDB/PAYe02F3ta0NA9/L+9+AV7UO34of8Amv8A92f/AAP/AMzS/wCa/wD3Z/8AA/8A zNb1LbGU1stf6trWgPsgM3uA1dtGgk9kRH38v734BXtQ7PO/81/+7P8A4H/5ml/zX/7s/wDgf/ma 6JJL38v734BXtQ7PO/8ANf8A7s/+B/8AmasDo2/BOD60elbv9TbzLONu7+V4raQqvp3f1x/1DE05 shqzsbGgSMcRem7hf81/+7P/AIH/AOZpf81/+7P/AIH/AOZrolm9cr9Xp/pw077sZsPb6jPdk1D3 Nkbh4idU738v734BHtQ7Of8A81/+7P8A4H/5ml/zX/7s/wDgf/maBm4WNjZOLVku6fQwsyHA2YzW Yxduxx/NuuHv0+lu40haHVMenJr6bTjuays3B2NYwBzGGvGufS9oEAhpAIHB44S9/L+9+AV7UOzW /wCa/wD3Z/8AA/8AzNRf9WmVsdZZlhjGAuc5zIa1o1JJL1AG/FzrbLrPsj8xuO/Nv9n6uHfayxu5 4dX7djKtxEO5+k6VDqGdbb07KZk5X2ev7Pb9nd+iZ9t999Y1e07pYxjv0e36cjQthe/l/e/AK9qH ZM/6tMrY6yzLDGMBc5zmQ1rRqSSXqX/Nf/uz/wCB/wDmar52bnWM6hVZbWGenlsdi7ptZVWywV2e k2nczdtadzrC0h2g9zQNjqXo+tT9t2/s7bZ63qR6PrSz0vUnSI3xu9u7b+dsS9/L+9+AV7UOzmj6 tMLzWMsF7QHObs9wa6QCRv77T9yl/wA1/wDuz/4H/wCZprMjGx7bz099dVD6cZtd1Tq6sar9Lluc 5z9lrGglpb9E+4gaEyFjdVybn4nqZDXB7iwV4z6bLrSzIfV6j22MG6rayS6vaR7jt2/QXv5f3vwC vah2X/5r/wDdn/wP/wAzS/5r/wDdn/wP/wAzV3o2Xbk+t6t32h7du59TqrMPc7cS2h9bWu07h/uG mpnc7VS9/L+9+AV7UOzzh+rnog3faN3p+/bsidusfTVnO6D9ryn5Hr7N8e3Zuja0N53DwWrk/wBH t/qO/IipvvZL4r1qtgn241VPO/8ANf8A7s/+B/8AmaX/ADX/AO7P/gf/AJmuiWHl/sv9sXfb/T9T 7PR9n3R6+71MifQj37uI2e6YjWE738v734BHtQ7If+a//dn/AMD/APM0v+a//dn/AMD/APM1KrNz 2uqryb9uc12PWcOKv07LG1evdtDd52l9mrCGDZxo6bfRsu3J9b1bvtD27dz6nVWYe524ltD62tdp 3D/cNNTO5y9/L+9+AV7UOzS/5r/92f8AwP8A8zS/5r/92f8AwP8A8zVF9mRZTkZAxbWnrFGS31P0 bvWd6brMMBjLHOG2hrm6NEnmTqtKq+uvPfkty35TDitNQZ6L3ZrqX5LnsZsY3c6uRoyO25L38v73 4BXtQ7I/+a//AHZ/8D/8zUW/Vpji4Nyw4sO14DJLXQHQffpoQVCjquS5zqbM2s0B1Rtza7Kb/Rba 2862ejXW33VMHuYfpcyW7beDe5udeTbuxH3MjIG13rWvxccMD3NAa0OmQWiHOgS3Rti9/L+9+AV7 UOyH/mv/AN2f/A//ADNRZ9WmPEsyw4AlpIZI3MO1w0f2Igp+p32/brcxuPZazpXp7bmmoCqYty/a 6xpduoc0DQ68RygHNzqXOrotroYLMh9Qsds9e12ZkA1hvo2usja321lrvdz7mwvfy/vfgFe1Ds2P +a//AHZ/8D/8zS/5r/8Adn/wP/zNK5+RYynJycs01V517fVa2tjceqr7VS0udY1zfcYbJ0+iAN0u dZ6pj+v1LEZ9mpy4pyD6eQdrB78f3D9Hbr8vml7+X978Ar2odmt/zX/7s/8Agf8A5mmb9XBbWx7c z1Ky0GtwZubsd7htO/gzKK3Iysa1mK/KL8ih+PRXQ4M3ZVLm1C3ILXB1pjc8y120bNZh00el5bmY 1NVmSMHG2VzkgVMPqNw8MsrL7WOadwe46+726Ha2EPfy/vfgFe1Dt+La/wCa/wD3Z/8AA/8AzNL/ AJr/APdn/wAD/wDM1oVXZrs44jj7aXPusshv6Si2fRZt7e4uE8/opP0wtJH38v734BXtQ7PO/wDN f/uz/wCB/wDmaX/Nf/uz/wCB/wDma6JJL38v734BXtQ7PO/81/8Auz/4H/5ml/zX/wC7P/gf/ma6 JJL38v734BXtQ7PO/wDNf/uz/wCB/wDmaX/Nf/uz/wCB/wDma6JJL38v734BXtQ7PO/81/8Auz/4 H/5ml/zX/wC7P/gf/ma6JJL38v734BXtQ7PO/wDNf/uz/wCB/wDmaX/Nf/uz/wCB/wDma6JJL38v 734BXtQ7PO/81/8Auz/4H/5ml/zX/wC7P/gf/ma6JJL38v734BXtQ7PO/wDNf/uz/wCB/wDmaL+y /wBn4GX+l9X1Qz83bG0/E+K3VT6p/QLvgPyhNlmnKJBNg+CRjiDYCLD/AKOz4I6Bh/0dnwR1XZFJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmL/wA3+uz/ AKsKSi/83+uz/qwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS k3k/A/kUVJvJ+B/Iipiq1v8ATcP+s/8A89lWVWt/puH/AFn/APnspBS3Tv6I3+s//wA+OVpVenf0 Rv8AWf8A+fHK0gpSSSSSlJJJJKUkkkkpi/8AN/rs/wCrCkov/N/rs/6sKSKlJJJIKUkkkkpVNtTD aHva075gkD8xqL9px/8ASs/zghKo/p+O9xcW6lOBU6H2nH/0rP8AOCX2nH/0rP8AOCzf2Zi/uqNf TMY1sO3ljf8AqQlaqdT7Tj/6Vn+cEvtOP/pWf5wWb+zMX91RPScMvFhb7mgtBns6Cf8AqQlxKp1P tOP/AKVn+cEvtOP/AKVn+cFm/szF/dS/ZmL+6lxKp0vtOP8A6Vn+cELH+w47DXTY1rCZDTZua3tt YHOO1ojRogDsFS/ZmL+6l+zMX91LiVTpfacf/Ss/zgoWPw7HVvfYwupcX1ncPa4tdXPP7riqH7Mx f3Uv2Zi/upcSqdL7Tj/6Vn+cEvtOP/pWf5wWb+zMX91L9mYv7qXEqnS+04/+lZ/nBL7Tj/6Vn+cF m/szF/dS/ZmL+6lxKp0vtOP/AKVn+cE1Dmuda5pDml+hGo+g1Z37Mxf3Vcwam1MsrZo1r9Pm1pRB U20klU6j6wwrH0bjbVttaxk7rPRcLDUI1/SBu3vzweEUNtJYJz+ob/1RhtOY+62uQ21rMfG9Khuw PuoBbZ/OAh353Dp3IlPU82wHIIqGO23HpNLQbHzlsoMi9r9h2uu7M1A51lJTtJLnDnZhvws1xrP2 rHPoVhjh6P2u/EYN53n1Nu8cBkx2nS5Vn57+oDBPpE1mz17dr2gtrbjWAsZudEi/bq7+V/IKU66S z7mnJz3Ytr3spZU22sVvfQ6x7nvbZ7q3NcdgDdAYG/3T7Yoi+/Hvy8fCBsyDeC1rm+u401YuM1zi bLqeC5upeSZ4OpCU7ySxauq5tvo2ikMZkVB+LSQXnJsdR6+wXhwbXB097NYkE/m3unZFt9VnrODr qn7LGip1Brdta7YQ59k/S+k1xae08pKbiSSSSkWT/R7f6jvyIqFk/wBHt/qO/IipKUkkhOG+0scS Ghoc2CWyZIOo8NPv+CSkqSrMY43P5LGOAB3v0hjT9Hgp3aZDnuI2VsDjIkid8lvhxr4pKbCSo3XW mt9djYMHX6Ojq7Owc793/YjeradW7fe5zGAg6OZu1Jn+T4JWpsJKs7IsIBrb9IhrQR7t20udpuA0 455lSqtte/aQAGgF3czuc3sSPzflwkpOkgOteHOIjYx7WERqd+3WZ/leCi5734T3vgF1ZMDzakps pKsMh4cXObFQLhu0/MnX6Un6PG38iTb7QSLGxt2lxiPY+ROjncEa68SkpspKq6+8cM4bvcDA9ri6 Adzm7dBryi2Os9RrGECQ5xLgXfRLR2I8UlL1011usewQ65wfYZPucGtrn/NaERVm5D3tFgADJY0t 5P6QNM7vLd4IeNZYWNrZAO0GSC7RrK+0j95K1N1JCbY82enGoJLj22fmx9/4ORUlKSSSSUpJJJJS kkkklKSSSSUpJJJJSlT6p/QLvgPyhXFT6p/QLvgPyhJSDEZ+rs97+P5H/kEfZ/Lf/wBD/wAghYf9 HZ8EdMSx2fy3/wDQ/wDIJbP5b/8Aof8AkFJJJTHZ/Lf/AND/AMgls/lv/wCh/wCQUkklMdn8t/8A 0P8AyCWz+W//AKH/AJBSSSUx2fy3/wDQ/wDIJbP5b/8Aof8AkFJJJTHZ/Lf/AND/AMgls/lv/wCh /wCQUkklMdn8t/8A0P8AyCWz+W//AKH/AJBSSSUx2fy3/wDQ/wDIJbP5b/8Aof8AkFJJJTHZ/Lf/ AND/AMgls/lv/wCh/wCQUkklMdn8t/8A0P8AyCTJ9wJJh0AmJja09gPFSUWfn/1/++MSUySSSQUp JJJJSkkkklMX/m/12f8AVhSUX/m/12f9WFJFSkkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKUm8n4H8iipN5PwP5EVMVWt/puH/Wf/AOeyrKrW/wBNw/6z/wDz2Ugpbp39 Eb/Wf/58crSq9O/ojf6z/wDz45WkFKSSSSUpJJJJSkkkklMX/m/12f8AVhSUX/m/12f9WFJFSkkk kFKSSSSUpJJJJSlGr+ar/qN/6kKSjV/NV/1G/wDUhFTJJJVLrsh+QcbGLK31sbZZZY02N22F7Wta 1r2fuGTOmmhn2hTbSVQ5noMDcsH1ZIAqY+31Gtj9I1lYe8N1Ez9E6SdHOT+pYTBWS8k3BxrY1j32 O9Mhr2hjWl25pOrYkayNDBU20lnu6viMvsY922muuqz7QQ70nDIcWN9+3bHGsxqf3XIrupYjDDi8 aAvd6duyvcN36V2yK4Bk7ogamAkptpKvj3vtuymOAAotFbI7tNNdmvzeVWwuqsv6UzOsaQ8MBsqa Pf6pAhrGk/nyNgmSHN8UlOiks+jqlZxMa24ON19Ndr2U12XbfUbOora8tBMxPMHwKPZ1DEr2l1kt e0P3sDrGNrdw97mAta0/vOgaHXQpKbKSruzcZl/oOcd8hpO1xra930WusA2NcZEAmTI8Qm+34vq+ ludO7Zv2Wejvnbt9Xbsnd7Yn6Xt50SU2VPG/wv8AX/741UXdSwmWem55BLxU12x/putc7Zsa/btc 6eQDIgz9EwzsrBdca3CXF2z1DW/0t87dvq7dkz7Y3fS9vOiQU6yS5nqNIptrHrsxa7A4m+6fSDmb Yr+nX7nbiRrw06eDjENFbjmPdIfsrdWHuN0tDpZU0vdpqI1+iXcJ1od6zCw7aWUW0V2U1xsqcxrm N2jaNrSIEBTNNJ3TW073Ne7Qe57Nu1x8xtEHyHgudcMBtbbHXvaHv9INcLG2ertLwwsI3BxA0ESd ImRMnV4ba2WerY4WTtaxtllnsMOmtjS4bTo6R7ToYKVqdsdPwGvssGNUH3hzbnCtm6xr9XB5jWe8 8olWNjUhgpqZWKw5rAxrWhrXkOcGwNJIkrmKPs76fXsyIrAyXy3c8OpxbdnqBzSR9GPjOnCsNrwX Vvsbe4trifpy4PMMLBEvDzo0tkOOjZStTv5GNjZLBXk1MvYDuDbGte0O4mHA+KG/p+A+r0X41Tqg Q4VmthZuY302naRGjRA8tFjY9GJkveyq55srDTYxwfW9m/dt3NeARO37oPBCq14eXZVbk/aK2VV2 XN2vD2+zHsez3W+pAkN526eBStT0ben4DS4txqml7PSeRWwF1UBuw6atgARwi0000ViqittVTZ2s YAxokyYA05XOlmM1lZebw+xjbPSFdtltbX8eo2pr9vca9wY4KgDifaLavUfsrqrtFo3uZYLi4NDC Gw6dNsE7iYGoKVqepSXNtrw3Vvs9Wxorjc17bK7PeYbFb2hx3HRsD3HQSVOrFx7mg12WGXbCC2xr mODd0Pa4As0/ejkeIlWp3Mn+j2/1HfkRVhv6c1jHP3uO0ExJ7LcSBtSlF7GPEPaHDmCJUlXsdb6x a3ftDWmGenyS7nf8EVJPRpkO9Nu4RBgSI4U4EzGp0J+CBSbHPcXF+0OcB9DYdri0DT3JB7hZa4/R Z7W+48lrTG0DxPPPZJSQU0gECtoB5gDwj+KkGMDi8NAedC6NT81WdkOeWgAsO4Bw1H59fiAeHeSn 9pO0OLYa5u9pn8wESTp2DvNBSYsYWlpaC06kEacynDWt4AGgGngOAgPySDDWbpLgPpahkB30WuPJ jhTqtNjnDYWtbGp5ktDoj5/69ipmWMLg8tBeNA6NR80+1u3bA2xG3tHggWZWxzht3NAMETq5rS4i dsdvEpzc8O9MsHqGIAd7dQ487f5J7JKShjA4vDQHnQujU/NM2qpoIaxrQ7RwAAn4oTLXNo3uG528 tgHxs2wCU/2h3qbNhMEBxG4w5wB/diNe5HwSUlcxjiC5ocW6tJEx8FF9Ndjg57Q7aCACAR7o8fgh DIdtcS2fT3Os14Ac4e326/R8kvtDhvO2W1y5xJ1gOeNAG/yUlJyxhcHloLxoHRqPmmNVRbtLGlvM QI0EfkTPe8PaxjQ4uBOp2/RjyPioNyNwDmt/Ry0Ek+6bA0jT+0O6SkoYA5zuS6JnyHCkqlF73Maw De+AZcYEBjCdQCeXf7UYXS8Mj3S4OE8NbrP4j7/JJSVJJJJSkkkklKSSSSUpJJJJSkkkklKVPqn9 Au+A/KFcVLqpDenXuMwGzoCTyOwSUjw/6Oz4I6zcfqOGylgLyQGgusYx9lTA4bpfYxpY3QzqRprw rJ6hiDIdjmz9KxwY8Q6GOeA5gc6Nrd24bZPuOgk6JiWyks/K6pTWWsrM2G6qmXNf6bi+1tb2tsgN c5oJ0BJEGRoVoJKUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSiz8/+v8A98YpKLPz/wCv /wB8YipkkkkgpSSSSSlJJJJKYv8Azf67P+rCkov/ADf67P8AqwpIqUkkkgpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUVJvJ+B/Iipiq1v9Nw/wCs/wD89lWVWt/p uH/Wf/57KQUt07+iN/rP/wDPjlaVXp39Eb/Wf/58crSClJJJJKUkkkkpSSSSSmL/AM3+uz/qwpKL /wA3+uz/AKsKSKlJJJIKUkkkkpSSSSSlKNX81X/Ub/1IUlGr+ar/AKjf+pCKmSqXU5DMg5OMGWPs Y2uyuxxrbtrL3Nc1zWP/AHzIjXTUR7raSCnPdRni2vKHp23tbYw0uca62NuNboa8Mc47fT7j3ST7 RDUsXBtqupteW+1uSbACdH5dzLobpqGwROk6GPDQSRU49fSshlNDNzCWVYddmp0dg3Cw7dNdwJ8I gePtLk4WW8ZlNQrNOfO+xznNfVvqbQYYGODoDJ+k2eNOVppJKa+PQ+q7Ke4gi+0WMjs0U116/NhV LF6U+n7KHuGyqqsXsafY/Ix2BlbojXkkk6yyuPorVSSU4jek5NbKC2LHsxqcd4bkX4jQ6jd7gaWn fO/uBEeehrenXtZSzG2MNVTaha19tLq/T0a7YC8WtEyGPOmvuO4xqpJWpz7cTJOaLqttbS5rnWNs saYbAc11GtdhcBt3mCARA9gmrb0q11pcKMeywXeuzLe4jI9lvrNrP6J0DT053GG6x+atpJJTg3uf W8dPZZQ8/a2XbA/dlObZlNyHD0YG3aHTul3tbMCfaZvSrW36gOq9c37zff3t9ePswivQ6fS/lEH6 K2EklNfI+2B7H42x4AcH1WONbTu2kP3tY8+2CIjXdzos93S7jQ0Nayssv9dmNVZZTUxvpGksZbW1 rmySX6N5JEaly2EklOZR061hpeQ1jm5Bvsb6lt5g476B+kt9zjqOzQBp2kpmFl0PZdUK7LGOyRsc 51bdmXeLgdwY/UbQIjvzprppJKcV3Sst2O+tz6zY+nNrLhua3fm2ixhj3QNNdTHnyrObiPdZfkF7 GM2Y7gXna3dh3PvO8x7WmQJ1jUxpropJKcrptz8nOycguqex1VLA6h3q1Ncx1xLPU03O9wJ0EBwE dySjo+CGvOTjUW2vttsL3Vte4ttte9slzZ0aQFopJKcd3Tcgir16qOoGuptUZLjo6ou/Stmu33Wg jd4bRq7lR/ZF/wBnFO5p2049UhzqyTgWmxh3NEt9QHUjVh43raSStTlVdOtFV5dWwW2hgDXXX5M+ i4vH6WyHM1d7drfYfd7uBaw6sqmsNsIdueTtNj7fSr28Cyxu6yXCfdEbo4aJtpJKYXfzNn9U/kV1 Urv5mz+qfyK6jFRUm2jcXfnEAE+QmPyp1Xtte20saYAaD9B9nJd+6dOE5CRtLGu3CQZJjc7bLufb MKRrYQ4EfTMn4gAT+CFVZY95BI2guEbHDRri36cwkLiLHtcDtDw0O0gbmtgczyUlMhj1AzBJmZJc TMtPc/yQpMqYwy0eQ1JgeAnj5IbMup+7b+aC7lurR89PnCTMmt5aGgkuniDG2Jkgx+d/qdElMzTW WtbBAYIbBLSB4SDKk1jWTtETyB5AD8gVdmRa70jsJ3sJLRt1Ps9wl3Gqn9rpL2tBndEHT8/UaE7u /gkpk7HqcSSDrOku2+4EHSY7qTqmOJJGpjUEg+2Ygj4lCflNBc1ol7SBtlpkbw08O057wiPs2hvt Jc8wGiJmC7uY7JKXFTAwMA9oO7Uk6zumfikamF28jXnkwSO5HCgchkTBIaJfx7ACQZ18jxKizIMu a6XOkhrQBJ97xySBw1JTMY7I92p1LoJaHbiXEEA6jXgyn9GuHCNHgh2p1BJP/fil6zeCCHS0bdJ9 3z/1goiSkb6Q97XEkbQRAJb9KO7SPBL0a5BAiI0BIbpx7eNERJJSIY9QEAER3BcDoA3kGeAFNrIe 55Ml0AeTR2++VJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpUuq7v2dftALtugJgTI76q6qfVP6Bd8 B+UJKcavCzX4mRQ30nV5zf0lpc5jqy6ltDtte1+6Nu4e8eHmrdmDa77RBb+myqL26n6FHobgdOf0 Rj5Kzh/0dnwR0xLlOws7b9nZ6XoDJGR6hc71HN+0/aXM2bYbHE7jMcDd7dVJJJSkkkkFKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKUWfn/ANf/AL4xSUWfn/1/++MRUySSSQUpJJJJSkkkklMX/m/1 2f8AVhSUX/m/12f9WFJFSkkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKUm8n4H8iipN5PwP5EVMVWt/puH/Wf/AOeyrKrW/wBNw/6z/wDz2Ugpbp39Eb/Wf/58crSq9O/o jf6z/wDz45WkFKSSSSUpJJJJSkkkklMX/m/12f8AVhSUX/m/12f9WFJFSkkkkFKSSSSUpJJJJSlG r+ar/qN/6kKSjV/NV/1G/wDUhFTJJJJBSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSkkkklKSSSSUpJJJJTC7+Zs/qn8iuqld/M2f1T+RXU6KipRDAHl/dwAP9mf71JDc927Yw BzgJMnaADx2PgnIUyosdIe7aSTs9se4z4T38UjU07tT7nNefizbH/UqHrPDjuYA1rmscQ6TueG8D b/KUHZe1lh2e5hIa2fpNbu1mNPon7kFJRQ0N27nFojYNPZtMiNNYjvP5UmUhj9+4ucZkmPzto7Af upm3OLhLQGuc5jSDJlm7kQP3VL1q95ZJkEAmDtk8DdEd0VMfs8bdr3N2AhsbdGmPbq0+HxTtoa0j YS1uksB0O0ADXnt4pDIqLQ5pLg7iA5xPyA/14SbkMJeOzIhwBIcCGkQQP5XCSmP2ZunudDRDBp7d QRGnbaOZUrK3O9OHEFhku03fRLfCO6f164mT/VDXF2n8mJUbL2tY/aZc0OIkHaXNExPBSUo47IiS A4Q/j3gkkzp5niEvs7AS4Eh0yDpoZce4/llF3DcG/nEEgeQifyqAvqMQZ3RBgx7uJPASUoV/pA86 7WgA9ye5P8PiURCGRUWhzSXB3EBzifkB/rwl69Y5PcgwCQA0lsuMacd0lJUkNt1bnbQTMkaggEt5 AJEFSdY1rg0yCeDB26/yuElMkkP164mTHb2u90/u6e75JvXZrM6GAAHF3Adq2J7pKSpITcipxABO saw7b7gCNYjuk3IqdEE+7iQ4c8cjv28UlJUkL7RVBMmNI0drJj26a89kvtDC9rQCd09jII28iNPp d0lJUkkklKSSSSUpJJJJSlT6p/QLvgPyhXFT6p/QLvgPyhIqRYf9HZ8EdAw/6Oz4I6jSpJJJJSkk kklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUWfn/1/wDvjFJRZ+f/AF/++MRUySSSQUpJJJJS kkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpJJJBSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/wBZ/wD57Ksqtb/TcP8ArP8A/PZSClunf0Rv 9Z//AJ8crSq9O/ojf6z/APz45WkFKSSSSUpJJJJSkkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpJJ JBSkkkklKSSSSUpRq/mq/wCo3/qQpKNX81X/AFG/9SEVMlUuuyH5BxsYsrfWxtllljTY3bYXta1r WvZ+4ZM6aaGfbbVS6nIZkHJxgyx9jG12V2ONbdtZe5rmuax/75kRrpqI9yUo5noMDcsH1ZIAqY+3 1Gtj9I1lYe8N1Ez9E6SdHOT+pYTBWS8k3BxrY1j32O9Mhr2hjWl25pOrYkayNDAnUZ4tryh6dt7W 2MNLnGutjbjW6GvDHOO30+490k+0Q1LFwbarqbXlvtbkmwAnR+Xcy6G6ahsETpOhjwSlO6viMvsY 922muuqz7QQ70nDIcWN9+3bHGsxqf3XIrupYjDDi8aAvd6duyvcN36V2yK4Bk7ogamAqVfSshlND NzCWVYddmp0dg3Cw7dNdwJ8IgePtLk4WW8ZlNQrNOfO+xznNfVvqbQYYGODoDJ+k2eNOUlNvHvfb dlMcABRaK2R3aaa7Nfm8qthdVZf0pmdY0h4YDZU0e/1SBDWNJ/PkbBMkOb4qzj0PquynuIIvtFjI 7NFNdevzYVSxelPp+yh7hsqqrF7Gn2PyMdgZW6I15JJOssrj6KSktHVKziY1twcbr6a7Xsprsu2+ o2dRW15aCZieYPgUezqGJXtLrJa9ofvYHWMbW7h73MBa1p/edA0OuhWa3pOTWygtix7ManHeG5F+ I0Oo3e4Glp3zv7gRHnoa3p17WUsxtjDVU2oWtfbS6v09Gu2AvFrRMhjzpr7juMJTddm4zL/Qc475 DSdrjW17votdYBsa4yIBMmR4hN9vxfV9Lc6d2zfss9HfO3b6u3ZO72xP0vbzogW4mSc0XVba2lzX OsbZY0w2A5rqNa7C4DbvMEAiB7BNW3pVrrS4UY9lgu9dmW9xGR7LfWbWf0ToGnpzuMN1j81JTfd1 LCZZ6bnkEvFTXbH+m61ztmxr9u1zp5AMiDP0TEvt+L6vpbnTu2b9lno7527fV27J3e2J+l7edFlX ufW8dPZZQ8/a2XbA/dlObZlNyHD0YG3aHTul3tbMCfaZvSrW36gOq9c37zff3t9ePswivQ6fS/lE H6KSm11DMfjvqYLasZlgcTkXjdUHM2xX9Ov3O3Ej3cNOh7Tbk2UVuObG4P2Vuqa4+tLQ6WVNNj9N RGv0S7jieR9sD2PxtjwA4Pqsca2ndtIfvax59sERGu7nRZ7ul3Ghoa1lZZf67MaqyympjfSNJYy2 trXNkkv0bySI1LklN13UsJtbbHPLQ9/pBrmPbZ6u0vDCwt3BxA0ESdImRMnZ+K2tlm5zhZO1rGWW Weww6a2NLhtOjpHtOhgqrR061hpeQ1jm5Bvsb6lt5g476B+kt9zjqOzQBp2kpmFl0PZdUK7LGOyR sc51bdmXeLgdwY/UbQIjvzpqlMsfqlT6fXstYKgMl/sa526nFu2eoHAkfRif3p04VhvUMR1b7G2S 2uJ0dLg8wwsES8POjS2Q46NlZzulZbsd9bn1mx9ObWXDc1u/NtFjDHugaa6mPPlWc3Ee6y/IL2MZ sx3AvO1u7Dufed5j2tMgTrGpjTVKbOPm42S97KnE2VhpsY5rq3s37tu5rwCJ2/dB4IQcHOfkWW1W tDHsfb6ZH0bKqrn0zr+c3b7uRq0/nQAdNufk52TkF1T2OqpYHUO9WprmOuJZ6mm53uBOggOAjuTs wX/ZjUXBtrb7L6rG+7a59z7W/unVrtrgIkFzZ1lJSsXqVT8FmRe4Me3Grybw0O2sZY0ukc/uu01O inZ1PBrtfVZaGOqIFpIIZXuaHN3vja3cHaSdToNQQs93Ss5uCcep1W+3CrxLHOLtrHUteJaAPdu9 SO23mHfRVuzBtd9ogt/TZVF7dT9Cj0NwOnP6Ix8klNqrKpuaDXuMu2EFj2uY4N3Q9rmgs0/ejkeI kyrUU21X5D/a5uRcH8kFrBQyvjbqdzPu1nsrKSmF38zZ/VP5FdVK7+Zs/qn8iuoxUVIVlW8kiJIA cHDe0gGRpI4RUN1kO2taXuAkhsaA8fSI8E5COvEawAgj1GxtfGo2sDI+Gn+vKkccGtzZ9zg8B3gL TuOilZa1lbnyDtBgTyWgkj8E4tqLS8PaWDQukQPmkpaullZLgBvcXEuiD7nboUPSebHyQKy9rgI9 x2hvefEeCIbahAL2iRuGo1b4qL8itjgCRBMFxIgaO/i2ElLClzW17HAOrbskiQRp2kfuphj7WljX e32kSJO6vbHhp7f9qKbKxtlwG/6Oo93wUTaBb6ccwAR+8Q50fc38UlMBS8O9QPHqGZJb7dQ0cbv5 I7pn4xc0s3Qw7i3TUOsDgZM6/SKIb6mkh7gzaY9xAnQO0+9SdZW07XOAdEwSAYHdJTG2oWtDT4/h wR8wSFA47Tb6nt1IcSWgvlsDR3bjwU7LmVlocQNxgkmNujiD/wBFSNlY2y4Df9HUe74JKRHHJrrY HAbBt3wd/AHtIOn4pjjGHAO0skP0/Nc5ztNdPpeaL6tWo3t9ujtRpzz9yiMiv1DWSGnTbJHuO5zY H3JKUKY26/Re5/H7+7T/AKSjZj77A+Ry10lu5w2kaNdOg0/Kih7C4sDgXjUtnUfJQFzfUewkAViX SfdwDMeGvKSmH2Y7SJbqQQNp2NidWt3aHXkFMaX1nfWS9/GoDtC1oMy5v7n+xHFlZAIcCHcGRrrH 5VF1pDyxrHPIAJjb3n94jwQUjrxy2oMLtZY4x/wYZp/0U7ceGgbuBW3j/RO3fipstL3QGO2gkb/b HtMeM9vBSL2BwYXAPOobOp+SKkDMRrQANojbBDQHENcHe49+PJE9Ei02B2pOoIn2kNBHP8n/AGKe 9kTuEEbgZ/NHdRN1IAcbGhruDIgx4JKSJKDbWOe6sH3s5HfgGfxTmysAkuADeTI01j8qSmSSh6tQ IBe2XQWiRrPEJ/UrBLS4bmiXCRIHiUlMkkMXVmz09w3RI1GupBj4bURJSlT6p/QLvgPyhXFT6p/Q LvgPyhIqRYf9HZ8EdAw/6Oz4I6jSpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUW fn/1/wDvjFJRZ+f/AF/++MRUySSSQUpJJJJSkkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpJJJBSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh /wBZ/wD57Ksqtb/TcP8ArP8A/PZSClunf0Rv9Z//AJ8crSq9O/ojf6z/APz45WkFKSSSSUpJJJJS kkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpJJJBSkkkklKSSSSUpRq/mq/wCo3/qQpKNX81X/AFG/ 9SEVMkkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkk klMLv5mz+qfyK6qdjS6tzRy4ED5hK3LtrbuNQd5NcZ/6lOBU3EG6t1mga3jSwn3MJ7tEfxCoftd/ /cZ/3/7Ev2u//uM/7/8AYjYQ27KLXNNY27Ze4OJM/pA/SI/leKk6q1xNhAD9A0BxG3bu907f5XEQ qX7Xf/3Gf9/+xL9rv/7jP+//AGJaKbppt2WMkO9UavPtO7YGfRAPgk+l4ta+sNhu0BpO36IeOwP7 ypftd/8A3Gf9/wDsS/a7/wDuM/7/APYloptHFcZmDvBDhuc0CXOd+b9L6Xl+KmGPJNgHu9QuDXac N9Ln8eP71S/a7/8AuM/7/wDYl+13/wDcZ/3/AOxLRTeZU8W+q6Bu3SAZidgGsD9xDbjWbPTkMaWb XkEu3HZs+iRpHkf9lX9rv/7jP+//AGJftd//AHGf9/8AsS0U3DXebRbtZIiG7j2Dxzt/lJ202NcH AhpJl7gTwXF+3aRB550P5FS/a7/+4z/v/wBiX7Xf/wBxn/f/ALEtFN1tL4qY4NLaSIMzu2tLQYjT so+hb+kaNu20FpMmW7nPMxGujlU/a7/+4z/v/wBiX7Xf/wBxn/f/ALEtFN1lBbZuOoDnOB3O/Pn8 z6I5/wBZUnVOIsgiXPa9v9gN0P8Amqh+13/9xn/f/sS/a7/+4z/v/wBiWim8yl3req8CfcYGu0kM boYHZqk6hj7S97WvG1oEiYgunn4rP/a7/wDuM/7/APYl+13/APcZ/wB/+xLRTeqqcx5OxnuLibAf fDnFw/N/imdQTaXctc4O+k4Rtj8waH6P+sKl+13/APcZ/wB/+xL9rv8A+4z/AL/9iWim6cYlrhPc emJIhrXb4041007AeCeqlzXh5gaOkbnPMu2Rq7n6Ko/td/8A3Gf9/wDsS/a7/wDuM/7/APYlopvY 9T6htMEENkg/nNa1sRHl/sTHHOwARuFjn6Es3bt35zdeD/BUv2u//uM/7/8AYl+13/8AcZ/3/wCx LRTa9GyX1gANewBziXabnPJiQd3Pknsx7HMNYjbL3NdJkmwO0IjT6Sqftd//AHGf9/8AsS/a7/8A uM/7/wDYlop0Qwts3NA2FoaRxt2TED5oiyv2u/8A7jP+/wD2Jftd/wD3Gf8Af/sSsKdVU+qf0C74 D8oVb9rv/wC4z/v/ANiDldQsyMd9Ix3NLxEzPdK1NrD/AKOz4I6DitLaGg6EBGTEqSSSSUpJJJJS kkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlFn5/9f/vjFJRZ+f8A1/8AvjEVMkkkkFKSSSSUpJJJ JTF/5v8AXZ/1YUlF/wCb/XZ/1YUkVKSSSQUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSk kkklKSSSSUpSbyfgfyKKk3k/A/kRUxVa3+m4f9Z//nsqyq1v9Nw/6z//AD2Ugpbp39Eb/Wf/AOfH K0qvTv6I3+s//wA+OVpBSkkkklKSSSSUpJJJJTF/5v8AXZ/1YUlF/wCb/XZ/1YUkVKSSSQUpJJJJ SkkkklKUfSq/0bP81v8AcpJIqY+lV/o2f5rf7kvSq/0bP81v9ykkkpj6VX+jZ/mt/uS9Kr/Rs/zW /wBykkkpj6VX+jZ/mt/uS9Kr/Rs/zW/3KSSSmPpVf6Nn+a3+5L0qv9Gz/Nb/AHKSSSmPpVf6Nn+a 3+5L0qv9Gz/Nb/cpJJKY+lV/o2f5rf7kvSq/0bP81v8AcpJJKY+lV/o2f5rf7kvSq/0bP81v9ykk kpj6VX+jZ/mt/uS9Kr/Rs/zW/wBykkkpj6VX+jZ/mt/uS9Kr/Rs/zW/3KSSSmPpVf6Nn+a3+5L0q v9Gz/Nb/AHKSSSmPpVf6Nn+a3+5L0qv9Gz/Nb/cpJJKY+lV/o2f5rf7kvSq/0bP81v8AcpJJKY+l V/o2f5rf7kvSq/0bP81v9ykkkpj6VX+jZ/mt/uS9Kr/Rs/zW/wBykkkph6NP+jZ/mt/uS9Gn/Rs/ zW/3KaSSmHo0/wCjZ/mt/uS9Gn/Rs/zW/wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3KaSSmHo0/wCj Z/mt/uS9Gn/Rs/zW/wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3KaSSmHo0/wCjZ/mt/uS9Gn/Rs/zW /wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3KaSSmHo0/wCjZ/mt/uS9Gn/Rs/zW/wBymkkph6NP+jZ/ mt/uS9Gn/Rs/zW/3KaSSmHo0/wCjZ/mt/uS9Gn/Rs/zW/wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3 KaSSmHo0/wCjZ/mt/uS9Gn/Rs/zW/wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3KaSSmHo0/wCjZ/mt /uS9Gn/Rs/zW/wBymkkph6NP+jZ/mt/uS9Gn/Rs/zW/3KaSSmPpVf6Nn+a3+5L0qv9Gz/Nb/AHKS SSmPpVf6Nn+a3+5L0qv9Gz/Nb/cpJJKY+lV/o2f5rf7kvSq/0bP81v8AcpJJKY+lV/o2f5rf7kvS q/0bP81v9ykkkpj6VX+jZ/mt/uS9Kr/Rs/zW/wBykkkpj6VX+jZ/mt/uS9Kr/Rs/zW/3KSSSmPpV f6Nn+a3+5L0qv9Gz/Nb/AHKSSSmPpVf6Nn+a3+5L0qv9Gz/Nb/cpJJKY+lV/o2f5rf7kvSq/0bP8 1v8AcpJJKY+lV/o2f5rf7lIBrRDQGjmAAPyJJJKUkkkgpSSSSSlJJJJKYv8Azf67P+rCkov/ADf6 7P8AqwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUV JvJ+B/Iipiq1v9Nw/wCs/wD89lWVWt/puH/Wf/57KQUt07+iN/rP/wDPjlaVXp39Eb/Wf/58crSC lJJJJKUkkkkpSSSSSmL/AM3+uz/qwpKL/wA3+uz/AKsKSKlJJJIKUkkkkpSSSSSlJKFgBABEgvYC D/XCkGMaZa1rT4gAfkRU0Kb8+6pmZV6bse1osZjbSLjW4SP0pft3RrG2J9u6Pej/AG/F9X0tzp3b N+yz0d87dvq7dk7vbE/S9vOiBTRn01Mw6vTbj1NFbMncTcK2iB+iLNu6NJ3RPu2x7FD7Flx9miv7 P9o+0etud6n9I+1bfT2Rz7Z3/wAr+SkpsN6lhPe5jHlzmF7XBrHn31TvrEN1f7Sdo9xHuAjVCxer 4l9VT3u9Ky2lt7q3Bw2VkOlxc5o9o2n3ccfvNlV4Nrfs8lv6HKvvdqfoX+vtA05/Sifmg1dKtGNd jPe0Nsw68Nr2y4/ovWbvLTHLXgxPMie5Sk1/VKxiZNtIcLqKbLWMursp3em2dBY1hcAYmOJHiFPq Gd9jOM4ia7bhXaY+gw1vdv5EBu2XHs2VXycPOzGXG1tVLzjXY9Ya91rXOydnucTWzbt2eBmfLW5l 4v2h+PIa6uqxzrWu1DmOptqiIM/T+5JSPJzvSzsTEYNzshzvUMSGMbW9zZ10LnN08QHeCJVn4t1g rY50u+g5zLGV2QJ/R2OaGv01G0mRqNFVp6bbW+ix9nqWVXFz7HkueaWU2UVCSOfcHO7bi8jlCwOl W478drwCzFEMsN99u6GGqRS+GVyD4uj6I/eCU36+oYlm4tshrGl+94dWx1beXsc8Brmj95sjUa6h JufiurfZuc0Vxua9lldnvMNit7Q47jo2B7joJKq4+Bks9VjvTZS6t1Yr3WX0vJ0a70bIFbWifY1x BDon2hRbgZbsa6t7g0PNZbQ623JY703bntdba3dttHsLYIA1g7iElNxufiurfZuc0Vxua9lldnvM Nit7Q47jo2B7joJKizqWE8WEPINIabGOY9ljfUJaxpY5oducRo2JOkDUTn/s19TbrhVjYbCKXllb oqDsK31wXO9Nkb5IJj2gA+6YEGss6nZluD6nBzMXY6ixzqt+PdZaa/XbB3cSQAWhw0MS5KdjHyqc jcK9wcyNzHsfU8B3B22Na6DB140PgVQGbmW2XNoso9WkvP2FzT9ocypxa2X+q3b6mhBLIAcPpck/ T8Syh9ttjQx9ga2PWuynba9xEvuj97gN85M6CysXPyK347202NLnGrJc4ttpLydj2ViojdWHQDvB MTIlJTatz8Wmw1vc6W/Tc1lj665E/pLGtLWaancRA1OiR6hiDIdjmz9KxwY8Q6GOeA5gc6Nrd24b ZPuOgk6KhldKttvyCAH1ZRBeXX30tZ+jbUQaavbZo2dXNmdukSrFmDa77RBb+myqL26n6FHobgdO f0Rj5JKVldUprLWVmbDdVTLmv9Nxfa2t7W2QGuc0E6AkiDI0Kl1DMfjvqYLasZlgcTkXjdUHM2xX 9Ov3O3Ej3cNOh7AdhZ237Oz0vQGSMj1C53qOb9p+0uZs2w2OJ3GY4G723cj7YHsfjbHgBwfVY41t O7aQ/e1jz7YIiNd3OiSmuc2/Hsooymb333GpltbXbHN9P1N+0ept93tgu7F/0QYK3qWI8w0vOhLH enbss2jd+idsiyQJG2ZGokKvR0+2sVOArq9PI9ZuPWT6NbHVGhzGO2t/eL/oiXGO+5Ax+lW1XY9h oxxZjOl+U1x9fJljqnOs/RaF2/efc73CJ13BKbWL1Sm/HbkPPptdTVaai1+9puLmgAkDfuc2GgNk 9p3NUn9UoD8djGvd9otNJ9ljXVuDC/3tLJb20dHtO76IVenpl9dLq3em/bj0UMkuG44j7CHS2Cwu DgQRJY7UbtoktWFlBtDnuG6i/wBVtZe+7bW6t1Lm+s8b3fTL9R/I0GqSkjeo44qpc5zrnW1tsmmq 18teNHljA9zA7tu8+YKuMex7GvY4OY4BzXNMtc06gghZeNh52Gyk1NqueManHsDnuqa12Nv9zSK3 7t2/wER56abWksDbdr3QN52w0u7kNJd+UpKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+ a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/ 3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3 +5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3J KZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5 L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZ JKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0 qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJK PpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv 9Gz/ADW/3JKZJKPpVf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPp Vf6Nn+a3+5L0qv8ARs/zW/3JKZJKPpVf6Nn+a3+5L0qv9Gz/ADW/3JKZJKPpVf6Nn+a3+5NWAN4A AG/gCB9BngkpmkkkgpSSSSSlJJJJKYv/ADf67P8AqwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKTeT8D+RRUm8n4H8iKmKrW/wBNw/6z/wDz2VZV a3+m4f8AWf8A+eykFLdO/ojf6z//AD45WlV6d/RG/wBZ/wD58crSClJJJJKUkkkkpSSSSSmL/wA3 +uz/AKsKSi/83+uz/qwpIqUkkkgpSSSSSlJJJJKYv/N/rs/6sKSi/wDN/rs/6sKSKlJJINeXiW2u oqursurnfW17XPbtMGWgyIKCkySqM6p0x72sZl0Oe4hrWttYXOcdAAAVYtuqprNtz21Vt+k95DWi TAklFTNJQququrFtL221u+i9hDmmDBghTQUpJJJJSkkwewvLA4b2gOLZ9wa6QCR5wfuSa9jxLHBw BLZBn3NO1w+REJKXSTNex4ljg4Alsgz7mna4fIiE6SlJJJJKUkkkkpSShbdVTWbbntqrb9J7yGtE mBJKjRk4+Qwvx7WXMB2l1bg9u7mJbPikpKkkkkpSSgbqmtscXtDav50kiGQ0O93h7TPwVX9r9J/7 m4//AG7X/wCSRU3UkGzLxKrW0W3V13WRsrc9rXu3GBDSZMlQt6j0+mw1XZVNVjfpMfYxrhIkSCUl NlJQtuqprNtz21Vt+k95DWiTAklQx8vEyd32a6u/ZG703tftnidpPggpMkkmc9jBL3BoJDZJj3OO 1o+ZMJKXSSSSUpJV787Bx3hmRkVUvI3Btj2sdt4mHEeCLVdVdWLaXttrd9F7CHNMGDBCKmaSSSCl JJJJKUkkkkpSSSSSlJJJJKUkkovc4bQ2JcYk6xoT/BJTJJRrcXNk8gkH+yYUklKSSSSUpJJJJSkk kklKSSSSUpJJZleR1Cyu3J9XHZTVZc3Y+t7fZj2PZ7rfVhshurtmngUVOmkqX7UxQ1peLKyWtc8O rsIp3tDouc1pawgGTuIganTVEtz8Wmw1vc6W/Tc1lj665E/pLGtLWaancRA1OiSmykqmLmC1oFhA tfbexjWg6sx7Xs3HmNGiTxJA7gJN6liPMNLzoSx3p27LNo3fonbIskCRtmRqJCSm2ks9vUXWdNx8 2tm03uoBY8O9ovtZW7nbMbjB4Oh4Vu/IqoYH2E6na1rWuse53MNYwFx0E6DiTwElJUlUd1LCbW2x zy0Pf6Qa5j22ertLwwsLdwcQNBEnSJkTJ2fitrZZuc4WTtaxlllnsMOmtjS4bTo6R7ToYKSmyksn K63S2txxf004+RdXaGvdVuxTtiQIIJnXd4fvNV6rNxrgTU4v2lo0a7UWGGvbpqw9nj26EzAKSmwk qJychmcyh7qnC0u/QsB9aqoBxbc927VpLdv0QAXAbjHuF0jNtzam3Pyce3dW11lNLSH1PsEw8+q/ jUcBJTppJJIKUkkkkpSSSSSlJJJJKUos/P8A6/8A3xikos/P/r/98YipkkkkgpSSSSSlJJJJKYv/ ADf67P8AqwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlKTeT8D+RRUm8n4H8iKmKrW/wBNw/6z/wDz2VZVa3+m4f8AWf8A+eykFLdO/ojf6z//AD45 WlV6d/RG/wBZ/wD58crSClJJJJKUkkkkpSSSSSmL/wA3+uz/AKsKSi/83+uz/qwpIqUkkkgpSSSS SlJJJJKYv/N/rs/6sKSi/wDN/rs/6sKSKmt1H1f2flehu9b0bPT2Tv37Dt2xrM8JO+xeljxt9Pcz 7L6fjHt9P0+22ZjTZM+2VZQa8TEqtdfVTXXdZO+xrGte7cZMuAkyUlNDozM4YGE59tRo9Cv2Cpzb NvpjaN/qkf8AR18lYv8A+UsXd9D07ts/R9b9Htj+Vs3x327u0qTOl9MY9r2YlDXtIc1zamBzXDUE EBWLaarqzVcxttbvpMeA5pgyJBSU0cmxgyW04zzVbkWtryLGCS3bTZa2N4czfDADoTtifzCgOvzf VbiNvIIy/QNzmsdY6o4hyDIAa3cCdDEaCQ7WdL7JifZ/s3o1/Z/9Dsb6fO76MRzqnrxsetjGV1MY yol1bWtDWscZBLQOPpH7ykpwci/KBOULnC3HxeoNbpXDji2tra5w2cmATECRoAJB0g3LsynYzsp9 fo1V2F9Tahvfe+0ERYyyGt2Db3/eLjqrjsbHezY6pjmS520tBbus3B5j+VuM+MnxTZGJiZO37TTX fsnb6jGv2zzG4HwSU0OmXvyMg5DwA+7CxLHBv0dzze4xM+KrYt+RitvawGw5V+QcXdLmMyPtL6y1 0RDIh8DWBa7st0MYHl4aN7gGl0e4tbJAJ8pP3qIpqG2GNG1xe3QaPfO5w8zuMnzKSnAxn5NFNGFQ 6+z35jnWVml2Q70MnYC52R7Nd+veY7SrXr9QsopALxYTcHtpdjHKPo2bGk+oTVx/ObeHkAQJC0rc TEtr9K2muyvcX7HMa5u9xJLoI5MnXzSsxMS2ptFtNdlNcbK3Ma5jdogQ0iBASU5uRmXlleRXcfs7 aGXuspbXtAducbLqrnep6ZA9oYd2jxMwodQyepNdl34rx6WCPcxxaxpcyptxBaabHOkO7PZ4aRuO tbjY9z2PtqZY+o7q3OaHOY7Qy0njhNZiYltrb7aa7Lq42WOY1z27TIhxEiCkpy+oZWUynqORXk/Z /sUsrYW1urcTSywF24btxdZAh0fR9p1Dmy8vqAuy3UC3biGGbTjNxjFLLf0xucH8u920j28ayVay +lMyCGsFFdXpGifR3XsqcHNc2qzeAz2uge0gefCt2YmJba2+2muy6uNljmNc9u0yIcRIgpKRZrA5 2PtsFV4tJxy5psYbPSsBDmtLfzN3cax8DSyMm+n1yax9uAxqzZUZ9Sm651TCxtsNa+S8wZA0lzgt W2mq6s1XMbbW76THgOaYMiQVCvExKqnUVU1102TvraxrWO3CDLQIMhJTlHJ6jXXazc9jw/FFbsgY 77f1i/0n7mYzgNkDTgzu100L6+V6n2P1nT9q9D7RFfrbPsv2qfobJ3e36P0fP3LQqxMSqv0qqa66 9wfsaxrW72kEOgDkQNfJPZjY9jHssqY9lpDrGuaHNe4QAXA8/RH3BJTT6UT6mcDaLi3J2mwACdlF Lfdt03CIdEazoOASr/lbJ/8AC+P/AOfMhWqqaqm7amNrbpo0Bo9rQ0ceDQB8ApBjA8vDRvcA0uj3 FrZIBPlJ+9JTQw/S+y5P2jbHrZH2j1I+h6jtvqbu3pbYn8yO0Kvhvy23ZYxKmWVeqyDfbbVb/RqN HB1T3cfvGZ5WlZiYltrb7aa7Lq42WOY1z27TIhxEiCitYxpcWtALzueQI3OgNk/IAJKcvMofjdMr qYRY9l+OWg/o2bjlVuDWxu2sEw0a7WwNYUsg5bWOzcltdH2OuyxvpOde5/sMtdubT7dJ2z7nBp3N 266TmMeIe0OAIdBE+5p3NPyIlOkpwnZXVcL1vtDm2xi3317nNt9+Psgfo6MfQ79efKO5eoMux6Wh 2Q/KJtoc2l4pba7Zk0/zZYKh3gz3LdW99CnBwaDNGPVUZ3SxjWe4AtnQeDiPmUqsHBpBFOPVWHFr nBjGtl1Z3NJgfmnUeCSnPtzMs0U7S/7Rfea7aqhV6uPFT7PTZ63sMbB7nTuBLm6FsCBy7b8MXWWM NOY5oDvQNrm/ZX2fpfSDmg8gRHsM8w5bFuNj3BwtqZYLAGvD2h25rDuaDPMEyEmY2OyptLKmNqaQ 5tbWgMa4O3gho0+lr8dUlNF7ct3Vr/s1ldcY9G71K3Wz+kyIjbZXH4ot2U/Dta/LsBx31Hc5rYay 6hrrHkNG53vZJ59uyNS5GvwcHIeH5GPVc8DaHWMa923mJcD4qbMbHZU2llTG1NIc2trQGNcHbwQ0 afS1+OqSnJdf1N1wpcLw9tTbnjH+y7mOyLLf0bzfodgYGgt5gk8hRszc81W5Hqtr+z4NWU6tgY9j 7nC5xbv93sOzsZ42uGs6+RiYmTt+00137J2+oxr9s8xuB8FN1NT9+9jXeo3ZZIB3s19rvEe46eZS U44+013Z3pWvcbMtrdo9EXbfs1b4p9RoYXcTun2NP52p0sN7raWWGxzi3ex4LWtJex+079s+5u0g 7TtJkgRtgluNj3BwtqZYLAGvD2h25rDuaDPMEyFJtNTNmxjW+m3ZXAA2M09rfAe0aeQSUzSSSQUp JJJJSkkkklKUXtcdpbEtMwdJ0I/ipJJKY1tLWweSST/aMqSSSSlJJJJKUkkkkpSSSSSlJJJJKUs/ F6ViVl1t1FL8g3W2i3Y1z/fa6xnuLZkAhaCSKnHz+lPyn5AdTRcMgbWZFp/TYzSwVxW303TtILx7 m6k8cmw2rqFVlrqmUn7S5tj3Oe/9E/02VEBor/SAbJ+kyePbytBJJTnYvT7MWx91bgbbrbDc0uc5 jqX3PsZtn6LmB86CCS4HkPaDA6Vbjvx2vALMUQyw3327oYapFL4ZXIPi6Poj94bCSSnOOFkN6XTi M2OtxjRtLnFrHtxbGOBJDXFu5rPAwTGvKjlY2dlsYba663UWCxja77W+pLH1kGxlbHMjfOgM8GFp pJKcyjp1rDS8hrHNyDfY31LbzBx30D9Jb7nHUdmgDTtJFZW/A9PJfZQ0tfkti6z0Ky3Lu9dvv2u9 wDOI8ddNdhJJTg1YORlYBc1zC+1mdVuMsY5uZaXstb9P2naI/kumTGur6Nrcy3Ibtc2yumsAktP6 N9pefon82zTxOmnKspJKaTqcu3Kqdb6Ypx7HWse0u3v3VvrDSwthsCzncZjgT7Wx8bIGRXZa2qtm PU+mttJO17bDWZ2Fo9OPT0bLuedNbySSlJJJIKUkkkkpSSSSSlJJJJKUos/P/r/98YpKLPz/AOv/ AN8YipkkkkgpSSSSSlJJJJKYv/N/rs/6sKSi/wDN/rs/6sKSKlJJJIKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUpN5PwP5FFSbyfgfyIqYqtb/TcP+s//wA9lWVWt/puH/Wf /wCeykFLdO/ojf6z/wDz45WlV6d/RG/1n/8AnxytIKUkkkkpSSSSSlJJJJKYv/N/rs/6sKSi/wDN /rs/6sKSKlJJJIKUkkkkpSSSSSmL/wA3+uz/AKsKSi/83+uz/qwpIqUkkkgpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKLPz/6/wD3xikos/P/AK//AHxiKmSSSSCl JJJJKUkkkkpi/wDN/rs/6sKSi/8AN/rs/wCrCkipSSSSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlKTeT8D+RRUm8n4H8iKmKrW/03D/AKz/APz2VZVa3+m4f9Z//nspBS3T v6I3+s//AM+OVpVenf0Rv9Z//nxytIKUkkkkpSSSSSlJJJJKYv8Azf67P+rCkov/ADf67P8AqwpI qUkkkgpSSSSSlJJJJKYv/N/rs/6sKSi/83+uz/qwpIqWe9jGOe9waxoLnOcYa1o1JJKqszpe0WUW 0VvIbXdYGBjnO+iIDy9u7tva3X2/SICnnUPyMHIx2EB91T62l30dz2lomJ8VBmd6j21102iyR6gs Y+plbfzj6hbsdHbYXSf5MuCUwxuo2ZDKrGYd4quDXNscaNux+ocQLi7g+E+SsZGS2na0Mdba+dlT Nu9wb9I+4taAJ5JA4HJAOR0j7LTRiNc3MbkNrYxzXtzfSbZtDXAtcPTAB+QWhlbqsunLLXPqrrtq eGNdY8G11Tmu2NBcR+jjSTqNIkhKT4+S27c0sdVayN9T9u9od9E+0uaQY5BI5HIIBllZdn2ltT30 PdgstBta+t7n2M9Owa4+3cWiwsiRM+6A0BxrtxG2uqY2lzcI5hfXVsdU1tP2RzXTXDS1rrZkEAOn UEO1SnaNtYtbST+ke1z2t11bWWhxn+2FNc1k4LzQ9/2cue2jqFFRDNz27rD9nY2BIb6YcG9oO0fS AN2/GwqsojKxjfjCpgoBpfl7bd9jrne1thDnbmkuOrvEwUlOm29jsh+OAd9bGWE/m7bS9oj/ADCm xsqrJa91Rn07H1PGktfU4tMwT4SPIhUum1ZNdoOSHep9jxWWPd7ptYbt43ayROvxVWrFy6w9tIdW M669lxG5rq/1ixwubA0JqkBxmXel2SU6+LlVZdPr0ndWXPa12hDvTe6skEE6Hbp5Iy5yzEeyqlhp aMWuzLHpPx35dYLsiaSKKyCPZu2u4A0/OCLZjRhYwuabGtNsNsxX5FAa9+5g+zMeXs2t0Z+62Wu2 kgJKd5JYWZS8+g92O513osDaXtflbbGydleSx00vkw613PtcD7ShdUwzdfku22tyojCdXSLWn9G3 YfWdVZ6X6SeHsj6WhO4pT0SS5zqjaXY/ULbsex91lbn4tvpvDmUfZ2yPUIHpgOD9zCQTqNp3QX6h jXWZeTuaPUsI+y2fZbMm5jfSY0Gq9r2sqizcRuIg+46GUqU7mTktoaz2OsfY7ZXWzbue7aXkAvLW /RaTqRx4wFHHyvWe+t1T6Law1zq7NhdsfuDXTW57dS095044UOoBnps9Sp9lYf7n1F/q1e10PZ6X v59vt7OM+2Vn2/arsTIroNtmO00ljr63+ptFs31ljhW+xgrA5lz5c3c48JTtpLnWYjnY9ra2EVWW 4o2U49mAwbMgOse1jnl+7aRLwBoBB9pg9mMKy+t1BOBXlguobWX1mg4o+jU0Hc31jOgPul3YlJTq tyWvN4YxznY7tjmjaC93pttAbJA4eOY1VUdStNrqRg5HqMa17mzj6NsLg0z6/wDIKbpNYZ9r2VPp qfeHUseC39H6NQBaDw3TQfm/RhsQDVseOp5Dy07HUUNDo9pc195IB8pH3pKU/Oh7hXRbfWwltl1Y YWNc36QgvD3be+xrtfb9IEKA6lve9uPjW5LKy0G2t1Ppu3sbaNpfa0n2vHZQou+xtfj2VWvsNttl fp1vsY9t9r7G+8DY36UHeWwdfow4joxct+Rl2Ovtxd9rDsrFTq3fq9ILmutpJOoInTjiZSU3Lc6p mKMlgda1zmsa1gAeX2WCoNiwtghxggxGspVZhfYK7qbMZz/5v1fTIsIEkNNT3iQNYMEiSJgwDPxY wW0Y4c2LqCCz3vH6xW51nuDpPLiXT3Lu6V2Fc2i14tsy8htb/s7bSysNsc0j2mltUE8bpkCYIkyl OghX3soYHvBIL2V6fvXPbW38XLn68Q1G4dO9cerjXV60DD/WCGmk+ymjwd7jo3iQXa2LqcV1UdNx XUWepQXP9Cyiv25FTgX1kV74gnT6IDvc3dqlO6oPtrrdWx5h1rtlY11cGufH+a0rFyqLxjMpeze5 lwfl2Oqdk15DXVvaLDUwgv8Adt9n+DgabGtJajBH6ta6oPrqyy9gFBobVW6k1/o6Xl72t9WHHj3e +NvuSU6d2a5mQcevHtve1jbHGs1BrW2F7W/zljP3CjUXsuYXNBa5p22Vu0fW8alrgJ8fgRBBIIKp 2Y19nU7nsutx2ehS3dW2ste4PvJE21v+jI48deyp5GNYKrMa4WWU/aBZbf6YutsqfUSHuYGOY8i0 bNuw7WBp2iGuSU7T7a63VseYda7ZWNdXBrnx/mtKmudxsJgspPpPspoyxZS6yn03MpsoNftYK2bf 04kgNEaWO09yXS8a5l+MXtDMisfrTm4tlL3u9NzXC3Je/bb7yD7Z3Oh3GoSnokliYFLK32tfQXVe k4XvdQ+u10R7btXNyXuE+5oOsx/OLbSUpJJJBSkkkklKSSSSUpQs1LGyQHOgwY/NJ5HwU1Fzd0ak EGQR27d0lLVElmusFw+TXEBTTNaGiB8Z8zqU6SlJJJJKUkkkkpSSSSSlJJJJKUs5vUrz+kdjhuML zjl/qTYX+t9na5rA2Nu6JlwI10MDdorMxemuAcbrLA05Ftxx5a6tx+0OtqfwXD80wHAeI1dJUw/b lX2n0pp2+t6Gz1h9q3+p6M+jt43a/S+j7vJXcPKsyRa41emyux9TXFwcXmqx1ZdAGg9vxmdIALot wdlm5l9raS82fZwWCve53qO92z1NXGY3R2+jojUUMoYWMJIL32a/vXPdY78XJKaNPV2vqvvexorx 63WvbXY2y6sNE7LqyG7H6caiQ4EiBMKuuVH1fUNL/SpfefstwyfZTG4OltcE7ht8deIVkdNqdvF1 lmQ11b6WtsI9lNsb2BzQ1xnaNXFztOeZkMHcyxmRfbkstY6stsLGN2P0dpSyvnxOo7RJlKYPy8yl hdkY7BJYys12mxhste2toeXVsLdXjUB2k94DoWdSvpbY27HBvrNH6Oqze1zMq30Ww57a/dIOhEce 7XQh6eXtc27JuuOhYXGtvpuY4Pa4NrYxpIc0H3B3EcFwKHTmEONttl1jnVONjtgdGNZ6tbYYxrY3 T2nXniEph+0LY9L0W/a/W9DZvPo7/S+0T6mzdGz+R9LTj3KXTrb7LMz1gWOZeGhhdva39BSfaf3S SSOOdQDIU7On1vc97XvrtfaL22N27q7BUKPaHNc3VgjUHk+UTxcRmN6u177HXP8AUsdYdzi/Y1h4 Aj6PHA7QIASmwkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUos/P/AK//AHxikos/P/r/APfGIqZJ JJIKUkkkkpSSSSSmL/zf67P+rCkov/N/rs/6sKSKlJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUpN5PwP5FFSbyfgfyIqYqtb/TcP+s//AM9lWVWt/puH/Wf/AOeykFLd O/ojf6z/APz45WlV6d/RG/1n/wDnxytIKUkkkkpSSSSSlJJJJKYv/N/rs/6sKSi/83+uz/qwpIqU kkkgpSSSSSlJJJJKYv8Azf67P+rCkov/ADf67P8AqwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpr34VGQ8Ot3u02lgssbU5vg6trgx095BkaHRWEkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUWfn/wBf /vjFJRZ+f/X/AO+MRUySSSQUpJJJJSkkkklMX/m/12f9WFJRf+b/AF2f9WFJFSkkkkFKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUm8n4H8iipN5PwP5EVMVWt/puH/Wf/wCe yrKrW/03D/rP/wDPZSClunf0Rv8AWf8A+fHK0qvTv6I3+s//AM+OVpBSkkkklKSSSSUpJJJJTF/5 v9dn/VhSUX/m/wBdn/VhSRUpJJJBSkkkklKSSSSUxfMAgEw5pIAJMBwJ0CW/+S//ADH/ANykkipj v/kv/wAx/wDclv8A5L/8x/8AcpJJKY7/AOS//Mf/AHJb/wCS/wDzH/3KSSSmO/8Akv8A8x/9yW/+ S/8AzH/3KSSSmO/+S/8AzH/3Jb/5L/8AMf8A3KSSSmO/+S//ADH/ANyW/wDkv/zH/wBykkkpjv8A 5L/8x/8Aclv/AJL/APMf/cpJJKY7/wCS/wDzH/3Jb/5L/wDMf/cpJJKY7/5L/wDMf/clv/kv/wAx /wDcpJJKY7/5L/8AMf8A3Jb/AOS//Mf/AHKSSSmO/wDkv/zH/wByW/8Akv8A8x/9ykkkpjv/AJL/ APMf/clv/kv/AMx/9ykkkpjv/kv/AMx/9yW/+S//ADH/ANykkkpjv/kv/wAx/wDclv8A5L/8x/8A cpJJKY7/AOS//Mf/AHJb/wCS/wDzH/3KSSSmO/8Akv8A8x/9yW/+S/8AzH/3KSSSmO/+S/8AzH/3 Jb/5L/8AMf8A3KSSSmO/+S//ADH/ANyW/wDkv/zH/wBykkkpjv8A5L/8x/8Aclv/AJL/APMf/cpJ JKY7/wCS/wDzH/3Jb/5L/wDMf/cpJJKY7/5L/wDMf/clv/kv/wAx/wDcpJJKY7/5L/8AMf8A3Jb/ AOS//Mf/AHKSSSmO/wDkv/zH/wByW/8Akv8A8x/9ykkkpjv/AJL/APMf/clv/kv/AMx/9ykkkpjv /kv/AMx/9yW/+S//ADH/ANykkkpjv/kv/wAx/wDclv8A5L/8x/8AcpJJKY7/AOS//Mf/AHJb/wCS /wDzH/3KSSSmO/8Akv8A8x/9yW/+S/8AzH/3KSSSmO/+S/8AzH/3Jb/5L/8AMf8A3KSSSmO/+S// ADH/ANyW/wDkv/zH/wBykkkpjv8A5L/8x/8Aclv/AJL/APMf/cpJJKY7/wCS/wDzH/3Jb/5L/wDM f/cpJJKY7/5L/wDMf/clv/kv/wAx/wDcpJJKY7/5L/8AMf8A3Jb/AOS//Mf/AHKSSSmO/wDkv/zH /wByW/8Akv8A8x/9ykkkpjv/AJL/APMf/clv/kv/AMx/9ykkkpjv/kv/AMx/9yW/+S//ADH/ANyk kkpjv/kv/wAx/wDclv8A5L/8x/8AcpJJKY7/AOS//Mf/AHJb/wCS/wDzH/3KSSSmO/8Akv8A8x/9 yVcw8kEAvkSC381o7qSSSlJJJIKUkkkkpSSSSSmL/wA3+uz/AKsKSi/83+uz/qwpIqUkkkgpSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUVJvJ+B/Iipiq1v8ATcP+ s/8A89lWVWt/puH/AFn/APnspBS3Tv6I3+s//wA+OVpVenf0Rv8AWf8A+fHK0gpSSSSSlJJJJKUk kkkpi/8AN/rs/wCrCkov/N/rs/6sKSKlJJJIKUkkkkpSSSSSlJJJJKUkq2TdaLa8aja261r3h7wX sayosDva1zSSS8dx3M6QYjJsx2H7bBIIDLKmuPq7pO1tQL37mxqNdPdPIaVNtJVHdSwm1tsc8tD3 +kGuY9tnq7S8MLC3cHEDQRJ0iZEis6vistY07vSdTbe63ZZDBjkBzXe3QjWQdWkbSJcElOgkqjup YgDS0vs3jcPSrtu9kkB36Njva6DtPDuWyFKnK9XLsqYWupbTTbW9uu71nWjmYIhghJTZSVHC6iy9 mQbYqOLbax5d7G+lW9zW2an6MNgnjc13goYvVWWYjL72vY+19obS2t77gyq1zPdWwPcIAG7sCfMJ KdFJVnZ+K2tlm5zhZO1rGWWWeww6a2NLhtOjpHtOhgpWdQxK9pdZLXtD97A6xja3cPe5gLWtP7zo Gh10KSmykq1ufi02Gt7nS36bmssfXXIn9JY1pazTU7iIGp0UcjqWFjF4ueWisTY/Y91bNN21z2tL Q4iIaTJkQNRKU20lWtz8Wmw1vc6W/Tc1lj665E/pLGtLWaancRA1Oijm3ZDHY9eOWNffaay6xpsa 1oqss+i17P3PFJTbSVKvJtqtdTlvrdtrNxuY01MrY0xFgc9+2eWmdYdoNupK8/Fs3e51Wxpe71mW Y/sb9Jw9VrZDe5HGk8pKbKSqV9SxH2spl7LbSRWyyu2lz9rS87fUY2YA18NPEKwLaza6kH9IxrXu bro2wuDTP9gpKZpLKxM3MyA21llFkFnr4bWlt9HqGC17zaYdXrMsG7aRAPBaOr49tPqubY0myytt YrtfYRS8sLtgZujidIaTtJlJToJLOv6tQx7WNJDX0XXesa7HMr9CAQ9oA413CQQRtOrgrLs3GZf6 DnHfIaTtca2vd9FrrANjXGRAJkyPEJKbCSz8XqlOQN5Potb6+5tjXsO3Gsaw2bnhoAAOojkxPtcr FGbRe8sZva8DdtsrspcWjQlota2YkTHEieQkpsJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmL/zf67P+rCkov/N/rs/6 sKSKlJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUpN5PwP5FFSbyfg fyIqYqtb/TcP+s//AM9lWVWt/puH/Wf/AOeykFLdO/ojf6z/APz45WlV6d/RG/1n/wDnxytIKUkk kkpSSSSSlJJJJKYv/N/rs/6sKSi/83+uz/qwpIqUkkkgpSSSSSlJJJJKUhtZW42FzGuO+JIB/Mb4 oiiz8/8Ar/8AfGIqa+RRb6teRjhptqa+sVvJZW6u0sJ9zWuLSCwRoe4jWQGyjPsNWQ70/Wps3sxw 4+lHp2VH9Ls3SfUmdsaBscuOgkkpzq8LINzMizY15yTkWMa4va1v2Y4wa1xa3d2PA7jtqC7pWQ+i xjXM32Mza9SQ0NzrDax0weIAIjuTOkHYSSU0rasuvLfk4zK7fVrZW5tj3VbfSdY4EFtdkz6nlEd5 0bBwX4jwC4PY3GoxweHF2P6kuI7TvHdXkklOUOlPO0OcAHW3HIDTpZj2XPyGNOnu1hpB02usHeVC zpd/6N7Ye+t+SdgutxZZlXesD6lQLtAANsRrzoJ2EklOU7p1rcalldbC9hsLgLr6Xj1neoYyG7nu 1+lI95h3tgNUsjCzH+kWPa68VtY/JDn47xY3/CGuuWWiTIY6ANRMOMaaSSnHz+lPyn5AdTRcMgbW ZFp/TYzSwVxW303TtILx7m6k8cmv1N9tNObRvx23Z9Zf6RsJu3upbT6dVW1ps3GuGukan6JiD0CS SnHyulW235BAD6sogvLr76Ws/RtqINNXts0bOrmzO3SJV3NwmZbscWMZZVVabLGWDc1zfSsYNCCD 7nAq2kkpzL+kVFr68RteNXfTbRc1jQwH1WjZZDY3FkQAY0cdRwRN6Vbay9toFRtosoa/1781w9eJ I9bYGxt8Pd4iNdhJJTRspzsqp9d4qx9AanVude4XMcH1v9zKh7HNmNd3kBqbEofUx7rSDdc82Wlv 0dxhrWjj6LGtbMCYkiSVYSSU5hxc+11Db20l2O5pGYHH1yGOaXxX6TQ31Q2HAPgA/ncGFnTbSADX TlVssvcKbiW1u+02esHn2WQ5nuaNDIMyJ2rWSSU4h6RkfZXUsFTJqyqWsaSGNbmkWiIZ+Y8bYjVv u0PsVu3EyTmi6rbW0ua51jbLGmGwHNdRrXYXAbd5ggEQPYJ0EklOS/pVrxbWXtbW+vMrDxJd+vWM tB26fR9w51gHvAvUnNe4/aa6q64jax7ri4nxLmVgAeEGZ7RrYSSUx9Kr/Rs/zW/3JelV/o2f5rf7 lJJJTH0qv9Gz/Nb/AHJelV/o2f5rf7lJJJTH0qv9Gz/Nb/cl6VX+jZ/mt/uUkklMfSq/0bP81v8A cl6VX+jZ/mt/uUkklMfSq/0bP81v9yXpVf6Nn+a3+5SSSUx9Kr/Rs/zW/wByXpVf6Nn+a3+5SSSU x9Kr/Rs/zW/3JelV/o2f5rf7lJJJTH0qv9Gz/Nb/AHJelV/o2f5rf7lJJJTH0qv9Gz/Nb/cl6VX+ jZ/mt/uUkklMfSq/0bP81v8Acl6VX+jZ/mt/uUkklMfSq/0bP81v9yXpVf6Nn+a3+5SSSUx9Kr/R s/zW/wByXpVf6Nn+a3+5SSSUx9Kr/Rs/zW/3JelV/o2f5rf7lJJJTH0qv9Gz/Nb/AHJelV/o2f5r f7lJJJTH0qv9Gz/Nb/cl6VX+jZ/mt/uUkklMfSq/0bP81v8Acl6VX+jZ/mt/uUkklMfSq/0bP81v 9yXpVf6Nn+a3+5SSSUx9Kr/Rs/zW/wByXpVf6Nn+a3+5SSSUx9Kr/Rs/zW/3JelV/o2f5rf7lJJJ TH0qv9Gz/Nb/AHJelV/o2f5rf7lJJJTH0qv9Gz/Nb/cl6VX+jZ/mt/uUkklMfSq/0bP81v8Acl6V X+jZ/mt/uUkklMfSq/0bP81v9yXpVf6Nn+a3+5SSSUx9Kr/Rs/zW/wByXpVf6Nn+a3+5SSSUx9Kr /Rs/zW/3JelV/o2f5rf7lJJJTH0qv9Gz/Nb/AHJelV/o2f5rf7lJJJTH0qv9Gz/Nb/couZWNpDGg 72ahoB+mPAIii/8AN/rs/wCrCSmSSSSClJJJJKUkkkkpi/8AN/rs/wCrCkov/N/rs/6sKSKlJJJI KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUpN5PwP5FFSbyfgfyIqYqtb/ AE3D/rP/APPZVlVrf6bh/wBZ/wD57KQUt07+iN/rP/8APjlaVXp39Eb/AFn/APnxytIKUkkkkpSS SSSlJJJJKYv/ADf67P8AqwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSiz8/+v/3xikos/P8A6/8A 3xiKmSSFk3sx8e3IeCWUsdY4N+ltYNxiY8EFn7Ra9rrfSsrcQHVVtc19e7v6j3w/b39rZGo19pSm 2ksXp3UrctuOTnYZsta178ZjD6olu5zB+sHUf1fktHJutFteNRtbda17w94L2NZUWB3ta5pJJeO4 7mdIKU2UlUGTZjsP22CQQGWVNcfV3SdragXv3NjUa6e6eQ1O6lhNrbY55aHv9INcx7bPV2l4YWFu 4OIGgiTpEyJSm2ks+zq+Ky1jTu9J1Nt7rdlkMGOQHNd7dCNZB1aRtIlwRXdSxAGlpfZvG4elXbd7 JIDv0bHe10HaeHctkJKbaSrU5Xq5dlTC11Laaba3t13es60czBEMEIWF1Fl7Mg2xUcW21jy72N9K t7mts1P0YbBPG5rvBJTeSWdi9VZZiMvva9j7X2htLa3vuDKrXM91bA9wgAbuwJ8wrDs/FbWyzc5w sna1jLLLPYYdNbGlw2nR0j2nQwUlNlJVrOoYle0uslr2h+9gdYxtbuHvcwFrWn950DQ66FK3Pxab DW9zpb9NzWWPrrkT+ksa0tZpqdxEDU6JKbKSqZHUsLGLxc8tFYmx+x7q2abtrntaWhxEQ0mTIgai ZW5+LTYa3udLfpuayx9dcif0ljWlrNNTuIganRJTZSVTNuyGOx68csa++01l1jTY1rRVZZ9Fr2fu eKjXk21Wupy31u21m43MaamVsaYiwOe/bPLTOsO0G3VKbqSrV5+LZu9zqtjS93rMsx/Y36Th6rWy G9yONJ5Ua+pYj7WUy9ltpIrZZXbS5+1pedvqMbMAa+GniElNtJCdaHPsorcBexgf7gXNb6m4MJ+j OrDpP3Ki1/VnZdmN6+OPTrrs3ehZr6rrGxH2jt6f4pKdNJUW3Z2RutxjUypj31iuxri+x1Lyx3va 8BkuaQPa7T3d9ohXd1HIuvFT6sdlL2sFdlTrbPdTXadzmXtby+NPvKSnRSWfZnWu6ezIpDWWWWV1 tLgbK/0lzaS9sFm5pnc06bhB0UvtGRjWsZmWVWMsDjvrYafSbU3c57w+x/s7F0jaS0a7tEpvJKtX n4tm73Oq2NL3esyzH9jfpOHqtbIb3I40nlAt6pXsHohwsNlTdt1dlJLLbmVOLRY1kxv7cGJ5SU6C SrvzcZjHPLiQ15r9rXPc6xvLWNaCXRrO2Yh0/RMBf1SgPx2Ma932i00n2WNdW4ML/e0slvbR0e07 vohJTeSWVmdQfTnOxzlY2IxtTLAchu5z3WOsadv6WvjYPHlXca8PArday60MbY59bSyt1dpdsc2X P52n84+PdJTYSVR3UsRugL7DLgRXXba5vpvdWdwrY4j3NIE8wYmEn9Twa3hjrQS5jbRtBe30XzFh c0EBnt1dwNJIkJKbaSos6pQX5DHte37PaKR7LHOscWB/saGS7vo2faN30SrNWRVaGmslweCQdrhG w7XNdI9rgdNpg86aFJSVJJJBSkkkklKSSSSUpRc7bGhJJgAd+/dSULNCx0EhrpMCfzSOB8UlMmuD hI+EeY0KdQqBDNdJLj8nOJCmkpSSSSSlJJJJKUkkkkpSFRey9hewEAPfXr+9S91bvxairMwMllQd j2V3NsORfH6G4sizIsc07wzbBBBmYRU6aSwsGhrX4QZQ6vMr/p9xqdWX/oXtfuuLQLJtLTo50n3a xKWHjub69bKrAXUva+5lbsXJ9TQDfY93p3WnU+oNGkEzD0lO6qLepOfuczEvdUx72Otb6Rb+ieWP IaLN51aeGyewQukMDPVDKm11+2HMpswmOd7pHoWE6jT3/nSB+YoY2BkWUXNdlZGO2y7I/RsFTIa+ +yC1zqi8SDIM95CSnVY9j2NexwcxwDmuaZa5p1BBCiLaza6kH9IxrXubro2wuDTP9grAux2Xig5t L6WsoY1rKcf7QxtzS5trAx9V4Y1sN2kAbh+c8ARD7HkeibDUftNmNisusdWbHPdj3RlB8QXy2NJ/ St+juSpT0qSwaMb9WytrS2lwqiunFfi17mOc55NFj9z5BAfAG9ntbLtBd6axjaWh1IYBafQLan0s /m9XtpfuNP5zdYkyfz9Up0UkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUX/m/12f8AVhSU X/m/12f9WEVMkkkkFKSSSSUpJJJJTF/5v9dn/VhSUX/m/wBdn/VhSRUpJJJBSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/1n/8Ansqyq1v9 Nw/6z/8Az2Ugpbp39Eb/AFn/APnxytKr07+iN/rP/wDPjlaQUpJJJJSkkkklKSSSSUxf+b/XZ/1Y UlF/5v8AXZ/1YUkVKSSSQUpJJJJSkkkklKUWfn/1/wDvjFJRZ+f/AF/++MRUwyaGZGPbjvJDLmOr cW/S2vG0xM+KCz9oue1tvpV1tILra3Oc+zb29N7IZu7+50DQa+4W0klOdg19Tx8fHxn00FlLGVus bc/dtYA0uDTQPDifmrGTTaba8mja66pr2BjyWMcy0sLvc1riCCwdj3EayLKSSnPsoz7DVkO9P1qb N7McOPpR6dlR/S7N0n1JnbGgbHLi1eFkG5mRZsa85JyLGNcXta37McYNa4tbu7Hgdx210UklOPd0 rIfRYxrmb7GZtepIaG51htY6YPEAER3JnSDbtqy68t+TjMrt9Wtlbm2PdVt9J1jgQW12TPqeUR3n S6kkpo4OC/EeAXB7G41GODw4ux/UlxHad47oA6U87Q5wAdbccgNOlmPZc/IY06e7WGkHTa6wd5Wq kkpx7Ol3/o3th7635J2C63FlmVd6wPqVAu0AA2xGvOgmbunWtxqWV1sL2GwuAuvpePWd6hjIbue7 X6Uj3mHe2A1aqSSnMyMLMf6RY9rrxW1j8kOfjvFjf8Ia65ZaJMhjoA1Ew4wLP6U/KfkB1NFwyBtZ kWn9NjNLBXFbfTdO0gvHubqTxydhJJTz/U32005tG/Hbdn1l/pGwm7e6ltPp1VbWmzca4a6Rqfom INjK6VbbfkEAPqyiC8uvvpaz9G2og01e2zRs6ubM7dIlbCSVqambhMy3Y4sYyyqq02WMsG5rm+lY waEEH3OBVe/pFRa+vEbXjV3020XNY0MB9Vo2WQ2NxZEAGNHHUcHTSSU47elW2svbaBUbaLKGv9e/ NcPXiSPW2BsbfD3eIjW1ZTnZVT67xVj6A1Orc69wuY4Prf7mVD2ObMa7vIDW8kkpr4lD6mPdaQbr nmy0t+juMNa0cfRY1rZgTEkSSkyh7c63IJGyyqqsD87dU61xn/PCsJJKaLac7H3VYwqfU977BZY5 wfW655e72NYQ+HOJHubp7e24wr6Riuuvty6asp9r2llljGPs2Nprr93tAHuaTppqtFJJTWz8X7Xj +gQ1zTZU57X6tcyu1ljgRB5a1RPT8dmPfVhsZhvvYW+pSwMc1xBDXezb9GdFbSSU4n7He82bcfGw hbRbjvNB3S28D3n9FVO0sGnfcdREOtZGPn5lPpXtqpZvqdFdlj3u9O5ljofsrLYa0xEySNWxropJ Kcq/ptxpqoqIdVivD8dvqWUP2em+r0nWVguG0O0cJLh7XDlxlR062sVWQ1tjMj13M9S2+Qajjmbb ZcSGmR7QNA3+UtNJJTRtqzmZ1mRj11WstqrrIssdU5rqnWu/NqsmfUSvx8y5ldzHMx8xgewlpNzB XboYLmtmCGv+jqW7ZAJKvJJKcm/pb22tfitmttNdDa/tF+LsbQX7fdUHb53/AJ3Ed5Tv6XZ9nyaK ywC3CrxK/pBofWLhJneQ39IO7j/HVSSU51+Dc517mBlnq2tuaC+yl4cKhS4Nsr9zNGg7hMguYQB7 lZxWZFVVddpD4Dtztxc5vuljASJftaY3GCYkiSYsJJKUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlKL/AM3+uz/qwpKL/wA3+uz/AKsIqZJJJIKUkkkkpSSSSSmL/wA3+uz/AKsKSi/83+uz/qwp IqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUVJvJ+B/I ipiq1v8ATcP+s/8A89lWVWt/puH/AFn/APnspBS3Tv6I3+s//wA+OVpVenf0Rv8AWf8A+fHK0gpS SSSSlJJJJKUkkkkpi/8AN/rs/wCrCkov/N/rs/6sKSKlJJJIKUkkkkpSSSSSlKLPz/6//fGKSiz8 /wDr/wDfGIqZJIWTezHx7ch4JZSx1jg36W1g3GJjwQWftFr2ut9KytxAdVW1zX17u/qPfD9vf2tk ajX2lKbaSxendSty245Odhmy1rXvxmMPqiW7nMH6wdR/V+S0cm60W141G1t1rXvD3gvY1lRYHe1r mkkl47juZ0gpTZSVQZNmOw/bYJBAZZU1x9XdJ2tqBe/c2NRrp7p5DU7qWE2ttjnloe/0g1zHts9X aXhhYW7g4gaCJOkTIlKbaSz7Or4rLWNO70nU23ut2WQwY5Ac13t0I1kHVpG0iXBFd1LEAaWl9m8b h6Vdt3skgO/Rsd7XQdp4dy2QkptpKtTlerl2VMLXUtpptre3Xd6zrRzMEQwQhYXUWXsyDbFRxbbW PLvY30q3ua2zU/RhsE8bmu8ElN5JZ2L1VlmIy+9r2PtfaG0tre+4Mqtcz3VsD3CABu7AnzCsOz8V tbLNznCydrWMsss9hh01saXDadHSPadDBSU2UlWs6hiV7S6yWvaH72B1jG1u4e9zAWtaf3nQNDro Urc/FpsNb3Olv03NZY+uuRP6SxrS1mmp3EQNTokpspKpkdSwsYvFzy0VibH7HurZpu2ue1paHERD SZMiBqJlbn4tNhre50t+m5rLH11yJ/SWNaWs01O4iBqdElNlJVM27IY7Hrxyxr77TWXWNNjWtFVl n0WvZ+54qNeTbVa6nLfW7bWbjcxpqZWxpiLA579s8tM6w7QbdUpupKtXn4tm73Oq2NL3esyzH9jf pOHqtbIb3I40nlRr6liPtZTL2W2kitlldtLn7Wl52+oxswBr4aeISU20kJ1oc+yitwF7GB/uBc1v qbgwn6M6sOk/cqLX9Wdl2Y3r449Ouuzd6FmvqusbEfaO3p/ikp00lRbdnZG63GNTKmPfWK7GuL7H UvLHe9rwGS5pA9rtPd32iFd3Uci68VPqx2UvawV2VOts91Ndp3OZe1vL40+8pKdFJZ9mda7p7Mik NZZZZXW0uBsr/SXNpL2wWbmmdzTpuEHRS+0ZGNaxmZZVYywOO+thp9JtTdznvD7H+zsXSNpLRru0 Sm8kq1efi2bvc6rY0vd6zLMf2N+k4eq1shvcjjSeUC3qleweiHCw2VN23V2UkstuZU4tFjWTG/tw YnlJToJKu/NxmMc8uJDXmv2tc9zrG8tY1oJdGs7ZiHT9EwF/VKA/HYxr3faLTSfZY11bgwv97SyW 9tHR7Tu+iElN5JUbbc5+dZj49lVTKqq7CbK3Wuc611rfzba4j009ee1tTnZH0q7DTNbXPFz2iSam t3OPfcNdpa4Sdu5JTdSVF/VKA/HYxr3faLTSfZY11bgwv97SyW9tHR7Tu+iEWrPxbrBWxzpd9Bzm WMrsgT+jsc0NfpqNpMjUaJKbKSrV5+Lbu2Oc7a0vHss/SMby6r2/pBxqyeR4hWUFKSSSSUpJJJJS kkkklKSSUXucNobEuMSdY0J/gkpkko1uLmyeQSD/AGTCkkpSSSSSlJJJJKUkkkkpSSSqN6lhPs9N rySHmpztj/Tba12zY5+3a108AmTIj6QlKbaSrfb8X1fS3Onds37LPR3zt2+rt2Tu9sT9L286KdGX j5DrG0u3mpxZZAMNe1xaWyRyI48IPBElSZJVq+oYlm4tshrGl+94dWx1beXsc8Brmj95sjUa6hKv PxbN3udVsaXu9ZlmP7G/ScPVa2Q3uRxpPKSmykqjepYhDiS+vaJ22V21PdqG+xtjGl+pA9s6kDkh L9pYQqfa95qZWWh/qsfS5vqO2NcW2NadpP53HOuhSU20lW+34vperudG7Zs2Wetvjdt9Lbvnb7oj 6Pu41UcLMGW7ILSDXTaK2EAtd/NVvIcHahwc4gjSIgiUlNtJJJBSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSlF/wCb/XZ/1YUlF/5v9dn/AFYRUySSSQUpJJJJSkkkklMX/m/12f8AVhSUX/m/12f9 WFJFSkkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUm8n4H8iipN5Pw P5EVMVWt/puH/Wf/AOeyrKrW/wBNw/6z/wDz2Ugpbp39Eb/Wf/58crSq9O/ojf6z/wDz45WkFKSS SSUpJJJJSkkkklMX/m/12f8AVhSUX/m/12f9WFJFSkkkkFKSSSSUpJJJJSlFn5/9f/vjFJRZ+f8A 1/8AvjEVMMmhmRj247yQy5jq3Fv0trxtMTPigs/aLntbb6VdbSC62tznPs29vTeyGbu/udA0GvuF tJJTnYNfU8fHx8Z9NBZSxlbrG3P3bWANLg00Dw4n5qxk02m2vJo2uuqa9gY8ljHMtLC73Na4ggsH Y9xGsiykkpz7KM+w1ZDvT9amzezHDj6UenZUf0uzdJ9SZ2xoGxy4tXhZBuZkWbGvOScixjXF7Wt+ zHGDWuLW7ux4HcdtdFJJTj3dKyH0WMa5m+xmbXqSGhudYbWOmDxABEdyZ0g27asuvLfk4zK7fVrZ W5tj3VbfSdY4EFtdkz6nlEd50upJKaODgvxHgFwexuNRjg8OLsf1JcR2neO6AOlPO0OcAHW3HIDT pZj2XPyGNOnu1hpB02usHeVqpJKcezpd/wCje2HvrfknYLrcWWZV3rA+pUC7QADbEa86CZu6da3G pZXWwvYbC4C6+l49Z3qGMhu57tfpSPeYd7YDVqpJKczIwsx/pFj2uvFbWPyQ5+O8WN/whrrlloky GOgDUTDjAs/pT8p+QHU0XDIG1mRaf02M0sFcVt9N07SC8e5upPHJ2EklPP8AU32005tG/Hbdn1l/ pGwm7e6ltPp1VbWmzca4a6RqfomINjK6VbbfkEAPqyiC8uvvpaz9G2og01e2zRs6ubM7dIlbCSVq ambhMy3Y4sYyyqq02WMsG5rm+lYwaEEH3OBVe/pFRa+vEbXjV3020XNY0MB9Vo2WQ2NxZEAGNHHU cHTSSU47elW2svbaBUbaLKGv9e/NcPXiSPW2BsbfD3eIjW1ZTnZVT67xVj6A1Orc69wuY4Prf7mV D2ObMa7vIDW8kkpr4lD6mPdaQbrnmy0t+juMNa0cfRY1rZgTEkSSkyh7c63IJGyyqqsD87dU61xn /PCsJJKaLac7H3VYwqfU977BZY5wfW655e72NYQ+HOJHubp7e24wr6Riuuvty6asp9r2llljGPs2 Nprr93tAHuaTppqtFJJTWz8X7Xj+gQ1zTZU57X6tcyu1ljgRB5a1RPT8dmPfVhsZhvvYW+pSwMc1 xBDXezb9GdFbSSU4n7He82bcfGwhbRbjvNB3S28D3n9FVO0sGnfcdREOtZGPn5lPpXtqpZvqdFdl j3u9O5ljofsrLYa0xEySNWxropJKcq/ptxpqoqIdVivD8dvqWUP2em+r0nWVguG0O0cJLh7XDlxl R062sVWQ1tjMj13M9S2+QajjmbbZcSGmR7QNA3+UtNJJTRt6bj351mRk01XsNVddYsaLHNcx1rnf SGk7wgW9MeGuqqZU/GFotZiv9lJb6fpuqLQ1wDQ79INDLuw+ktVJJTk43TbaXte2umhrcgZApqJ9 Nu6k4z2j2N/N98xqZbp9IxwOlW478drwCzFEMsN99u6GGqRS+GVyD4uj6I/eGwkkpzsTEy8d7yAx rAwtZU2211Vj9NhDXh3oNEEbWbhDu+0TopJJKUkkkgpSSSSSlJJJJKUova47S2JaZg6ToR/FSSSU xraWtg8kkn+0ZUkkklKSSSSUpJJJJSkkkklKWLi05d9Lqv0f2f7Zbb6kuFjfRzHWbdm0h0lnO5sT wY920kipx29KtbfqA6r1zfvN9/e314+zCK9Dp9L+UQforQw6H0UuY8gk23Wafu3XPsb+DlYSSU5L emZLqsjHc5tNN1L6QGPsuYS8bWvbXZpUGiYY0kaxPtCi3pVtrL22gVG2iyhr/XvzXD14kj1tgbG3 w93iI12EklOfdV1DJrLbWU1bHV2Ma177d76bGWgFxrZtHsj6LuZ7Q6D8LLve+60V12PdjDY1zrG7 MS83E7ixmp3ERHbnXTTSSU51mFkC5+RXsc8ZIyK2OcWNc37MMYtc4Ndt7ng9h30NhUZFTsizILN+ RaLAK52tb6Vde33cxs578wJgW0klKSSSQUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpRf+b/XZ /wBWFJRf+b/XZ/1YRUySSSQUpJJJJSkkkklMX/m/12f9WFJRf+b/AF2f9WFJFSkkkkFKSSSSUpJJ JJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUm8n4H8iipN5PwP5EVMVWt/puH/Wf/wCe yrKrW/03D/rP/wDPZSClunf0Rv8AWf8A+fHK0qvTv6I3+s//AM+OVpBSkkkklKSSSSUpJJJJTF/5 v9dn/VhSUX/m/wBdn/VhSRUpJJJBSkkkklKSSSSUpRZ+f/X/AO+MUlAHaXgtdq6QQ1zhG1o5A8kV M0lHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7kt/8 l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJ f/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7 kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd /wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf /mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A 5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSU ySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5L f/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8A Jf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP /uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySUd/8AJf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/ AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJf/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUySU d/8AJf8A5j/7kt/8l/8AmP8A7klMklHf/Jf/AJj/AO5Lf/Jf/mP/ALklMklHf/Jf/mP/ALkt/wDJ f/mP/uSUySUd/wDJf/mP/uS3/wAl/wDmP/uSUyUX/m/12f8AVhLf/Jf/AJj/AO5MSXFoDXzvYdWO HDge4SUzSSSQUpJJJJSkkkklMX/m/wBdn/VhSUX/AJv9dn/VhSRUpJJJBSkkkklKSSSSUpJJJJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/1n/+eyrKrW/03D/r P/8APZSClunf0Rv9Z/8A58crSq9O/ojf6z//AD45WkFKSSSSUpJJJJSkkkklMX/m/wBdn/VhSUX/ AJv9dn/VhSRUpJJJBSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKS SSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJ JSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklK SSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJTF/5v9dn/VhSUX/m/wBdn/VhSRUpJJJB SkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6 bh/1n/8Ansqyq1v9Nw/6z/8Az2Ugpbp39Eb/AFn/APnxytKr07+iN/rP/wDPjlaQUpJJJJSkkkkl KSSSSUxf+b/XZ/1YUlF/5v8AXZ/1YUkVKSSSQUpJJJJSkkkklKSUXuLRoJJIAB0+kYTjfPuDY8iT +VoRU16uo9PusFVOVTbY76LGWMc4wJMAFWVztb87/m/TvqqbjMxq3utba43tqrY15fWw1ACwAS33 QHQZ0R8vL6gLst1At24hhm04zcYxSy39MbnB/LvdtI9vGslKlO097GMc97g1jQXOc4w1rRqSSUmv Y4uDXAlh2vAM7XQHQfkQVh9Vsusw+qOOR6NeO11IrIZ6dgfQx/uJG7cTZAhwH0dDqCe3Iy35Rort 9MHM9Hdta4tq+xesQJ77tQTOvMj2pKdZJYjcvqD7fVAt9P7SaYJxm4nptv8AQ7uF27aPm/gbdFYr ORex+Qcx1A9aykM21ekAy51DY3M3bjGnuI39iPakp0g9heWBw3tAcWz7g10gEjzg/cnXO4OTk04F NTbCR9mwAxxDdzPtdrqnFvtj2tjbM8CZ1m1kX5uObcdl5se04hZba1jnD7VkGlzS2sVgthvkdT7u IVKdhVquo9PusFVOVTbY76LGWMc4wJMAFRwrLS7Ipsebfs9orbY4ND3NdVXb7tga3l8aAaR31Wfg VZ2T0jFx311V0PoqHrNsc+5rQxpa5rPSaA/TQ7vadfdEFKdtJYjsnqQt+1MeDi/aRRsJa32+v9md +j9Eu57+rr9KAPYrVD77Zyn5RraL31eiW1+iW13OoaPoh+50fv8A0jxHtSU6DHsexr2ODmOAc1zT LXNOoIITrn8HOyKukCwj0nY2CH49LwCLhXU0+qS08btNoIIGrvpNiOa/OOHmU2uvbW7EvfN5xPU3 VhujBRPtIcQ6RppBBSpTu35OPjsD8i1lLCdodY4Mbu5iXR4JUZOPkML8e1lzAdpdW4Pbu5iWz4qn n+ux3TxVF1rbyB6jvT3/AKtdJc5jDHyb9yrZOTl49t+TdXXXczDtfS2t7rWP9AtcfWJZWdC4bI4l +uqSnaSWI7L6hisve8WkMxrrm/ajjbvUp27djcVwJb7jun+TBE62Mg5GFtudmOurrmy6q1tQeaGe 172mtjNGb9x0cTAaInVKdNV252C+/wCzsyKnXglvpB7TZub9IbZnSE2NbZdbfZP6u13pVN01dUSL Hzz9L2wf3JGjlQqHpYWKHFmT04nHFDgH03MbvYKHOEkP920u+hEH2mdqSnYTPexjHPe4NY0FznOM Na0akklYGP8Abm1Nxca9xtsuzLC5xrrO2nI2H3ejYNS+Y2ak6OaBtIrcjN2jLdaWZGPiZ4huxzC/ GtZWHGaxMwCdAJAhrRIKpT0qYvYHhhcN7gXBs+4tbAJA8pH3rNuyMhmaSbHNx22V1jYKn0j1Ng2X An1Q9zn6bfaAWE6blQpycnCx7S2w27GdRviwN1sx8hobOxrfEk/E9ohKeiSVWmu2m3Y/KdeXtJFd ora/2ke5pqYzT3e7Q8jjvY/S+DP853/kElMklH9L4M/znf8AkEv0vgz/ADnf+QSUySUf0vgz/Od/ 5BL9L4M/znf+QSUySUf0vgz/ADnf+QS/S+DP853/AJBJTJJR/S+DP853/kEv0vgz/Od/5BJTJJR/ S+DP853/AJBL9L4M/wA53/kElMklH9L4M/znf+QS/S+DP853/kElMklH9L4M/wA53/kEv0vgz/Od /wCQSUySUf0vgz/Od/5BL9L4M/znf+QSUySUf0vgz/Od/wCQS/S+DP8AOd/5BJTJJR/S+DP853/k Ev0vgz/Od/5BJTJJR/S+DP8AOd/5BL9L4M/znf8AkElMklH9L4M/znf+QS/S+DP853/kElMklH9L 4M/znf8AkEv0vgz/ADnf+QSUySUf0vgz/Od/5BL9L4M/znf+QSUySUf0vgz/ADnf+QS/S+DP853/ AJBJTJJR/S+DP853/kEv0vgz/Od/5BJTJJR/S+DP853/AJBL9L4M/wA53/kElMklH9L4M/znf+QS /S+DP853/kElMklH9L4M/wA53/kEv0vgz/Od/wCQSUySUf0vgz/Od/5BL9L4M/znf+QSUySUf0vg z/Od/wCQS/S+DP8AOd/5BJTJJR/S+DP853/kEv0vgz/Od/5BJTJJR/S+DP8AOd/5BL9L4M/znf8A kElMklH9L4M/znf+QS/S+DP853/kElMklH9L4M/znf8AkEv0vgz/ADnf+QSUySUf0vgz/Od/5BJh J3SAC07dDI4B7geKSmSSSSClJJJJKUkkkkpi/wDN/rs/6sKSi/8AN/rs/wCrCkipSSSSClJJJJKU kkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKTeT8D+RRUm8n4H8iKmKrW/03D/AKz/ APz2VZVa3+m4f9Z//nspBS3Tv6I3+s//AM+OVpVenf0Rv9Z//nxytIKUkkkkpSSSSSlJJJJKYv8A zf67P+rCkov/ADf67P8AqwpIqUkkkgpSSSSSlJJJJKYv/N/rs/6sKSi/83+uz/qwpIqWYxjGNYxo axoDWtaIa1o0AACAcHBL63nHqL6Q1tTixu6trNWhpjSO0KwkgpDbiYltnq2012WbSze5jXO2OBBb JHBk6ean6NW7fsbu3b90Cd+3090+O3SfDRTSSUh+yYn2j7T6Nf2j/TbG+pxt+lE8aJfZMT7R9p9G v7R/ptjfU42/SieNEZJFSL7Njw8ekyLQW2DaPe1xc4h3jJeT8z4pqsTEqr9KqmuuvcH7Gsa1u9pB DoA5EDXyRkkFLNYxpcWtALzueQI3OgNk/IAJMYxjGsY0NY0BrWtENa0aAABOkkprvwcF9rrn49Tr XAtdY5jS9zS3YQXET9HT4aKX2TE+0fafRr+0f6bY31ONv0onjRGSRUwFNTW1tDGhtX80ABDIaW+3 w9pj4KGPiYmNu+zU10b43emxrN0cTtA8UZJBTAU1NbW0MaG1fzQAEMhpb7fD2mPgpOYxxaXNBLDu YSJ2ugtkfIkJ0klIcfExMbd9mpro3xu9NjWbo4naB4pY+JiY277NTXRvjd6bGs3RxO0DxRkkVLMY xjGsY0NY0BrWtENa0aAABAbg4LL/ALQzHqbeSXeqGNFm530juidZVhJBSG3ExLmlt1NdrXO3uD2N cC8N2hxkc7dJ8EvsmJs9P0a9n7uxu36HpcR+57f6unCMkipE7Gx3XtyHVMN7BtZaWg2NbroHc9yp CmoWG0MaLDMvAG47g0HX+w37h4KaSCkOPiYmNu+zU10b43emxrN0cTtA8UZJJJSkkkklKSSSSUpJ JJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkk lKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKUWfn/1/++MUlFn5/wDX/wC+ MRUySSSQUpJJJJSkkkklMX/m/wBdn/VhSUX/AJv9dn/VhSRUpJJJBSkkkklKSSSSUpJJJJSkkkkl KSSSSUpJJJJSkkkklKSSSSUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/1n/+eyrKrW/03D/rP/8A PZSClunf0Rv9Z/8A58crSq9O/ojf6z//AD45WkFKSSSSUpJJJJSkkkklMX/m/wBdn/VhSUX/AJv9 dn/VhSRUpJJJBSkkkklKSSSSUxf+b/XZ/wBWFJRf+b/XZ/1YUkVKVe/Owcd4ZkZFVLyNwbY9rHbe JhxHgrCzHuy29Wv+zV12Tj0bvUsdVH6TIiNtdk/gkp0mPY9jXscHMcA5rmmWuadQQQnWF9oyqmOq Y1zci3Mcy1mOa3bN1ByB6Bv2t1ABduGri8gSQi15Ga4Mx3vfU6zJNPqO9B2S2sY5yPcK99YduEfR +hGk+5JTq+tVu2b27t2zbInft9TbHjt1jw1U1iYl1rMt7BcLfUzzVY8BvvazBBh0abg5g3RGoOgG ihVldRfj4INlttmVQcix2O3HY9u0UgNAv9m33y7vu4hvtCpTvJnPYwS9waCQ2SY9zjtaPmTCyqb8 zIOPjvtdQ57chz3s9F9v6taypgdpZXJD/fA+lxHCrl99OddY3KNxjDqJDa9u1+XZS4Ha36QAIP8A KLtB7Q1Kd5JZPr5Xp/bPWdH2r0Ps8V+js+1fZZ+hvnb7vpfS8valj5GX6tT7Ld7L8rIxxVta1ra6 TeWmR7i79EBMxt/N3e5JTevzsHHeGZGRVS8jcG2Pax23iYcR4I7Hsexr2ODmOAc1zTLXNOoIIWa9 2W3q1/2auuycejd6ljqo/SZERtrsn8EK2vOrezHx7BXfkm3Ie1pDK2bfTaWse+q3u+T7Pe4ufLPo lKdhMHsLywOG9oDi2fcGukAkecH7lkY+Rm5PoY77TTYRk+pZVsc8uxLm0ATZWW6h0n2DXjaNEJ2R dVnWgWb2Gmll+aAyKGMtyWlzmz9LsTG1plzgGjakp3UliZeX1AXZbqBbtxDDNpxm4xillv6Y3OD+ Xe7aR7eNZKt9PY5uX1EmxzwchsB22G/oKjptaPGPgB3klKT1dR6fdYKqcqm2x30WMsY5xgSYAKsr na353/N+nfVU3GZjVvda21xvbVWxry+thqAFgAlvugOgzoj5eX1AXZbqBbtxDDNpxm4xillv6Y3O D+Xe7aR7eNZKVKdtJZzn323Zb/tRxq8R4aBtrNJaKa7i63e3dy/WHN0HY6qNWXkP9LD3frjLC3If A/m8fa91kRt/StczQfR9T+QUlNq3qPT6bDVdlU1WN+kx9jGuEiRIJRKMnHyGF+Pay5gO0urcHt3c xLZ8VX6n/Rmf+GMb/wBuaksp1z8unFrtdQ19dtrnsDC+anVNDf0jXtj9Ie06DXmUpuqFt1VNZtue 2qtv0nvIa0SYEkrMY/Iuzn4gzobXSx4NbavVe4W3VuPuD26bQHw36URs1aVkZFuR0bFydrTdc7Ds 2yWM3vuqdE+4gT8fmkp0MfLxMnd9murv2Ru9N7X7Z4naT4IyzMg5bWOzcltdH2OuyxvpOde5/sMt dubT7dJ2z7nBp3N261XZXVcL1vtDm2xi3317nNt9+Psgfo6MfQ79efKO6U7jnsYJe4NBIbJMe5x2 tHzJhOsfqDLselodkPyibaHNpeKW2u2ZNP8ANlgqHeDPct1b3VuZlminaX/aL7zXbVUKvVx4qfZ6 bPW9hjYPc6dwJc3QthKdhV787Bx3hmRkVUvI3Btj2sdt4mHEeCygcu2/DF1ljDTmOaA70Da5v2V9 n6X0g5oPIER7DPMOVp7ct3Vr/s1ldcY9G71K3Wz+kyIjbZXH4pKdCq6q6sW0vbbW76L2EOaYMGCF NUbsp+Ha1+XYDjvqO5zWw1l1DXWPIaNzveyTz7dkalypOv6m64UuF4e2ptzxj/ZdzHZFlv6N5v0O wMDQW8wSeQkp20lhWZuearcj1W1/Z8GrKdWwMex9zhc4t3+72HZ2M8bXDWZD7TXdnela9xsy2t2j 0Rdt+zVvin1GhhdxO6fY0/nalKdtJVsN7raWWGxzi3ex4LWtJex+079s+5u0g7TtJkgRtiygpSSS SSlJJJJKUkkkkpSSSSSlJmua4S0hw8QZUbv5mz+qfyJD+ed/Vb+VySmaSSSSlJJJJKUkkkkpSZ72 MY573BrGguc5xhrWjUkkp1S6v/yTm/8Ahe3/AM9uRU3UlWz7bKseaztc+yqrdoS0XWsqLhOkgO0m RPIKpvty6XZGO282uYyh7LLPSbZ+nsfW5jIaxm6GezcPpn3GElOqme9jGOe9waxoLnOcYa1o1JJK yvtGWcb02WWG5t3p2NcKG5gHp+rsbr6Dnah3h6c/nhPlWm3oOW5zi9wovY4uAY/dWHsIcGy3cCIJ b7SdW6Qkpu0Z2DkPLMfIqueBuLa3te7bxMNJ8VYWVlPzj6Dsmqqqpl9UvqtdZcHPeK2hm6qsCXOA dr9AuHdBdk9SFv2pjwcX7SKNhLW+31/szv0fol3Pf1dfpQB7ElO2kudoszKmsxqn32+pbm2OdUMf 1h6OTs/wwazad5J0meIborXr9QsopALxYTcHtpdjHKPo2bGk+oTVx/ObeHkAQJCVKdhJBxn+rVXe LPUbbWxwIbsYZG7e1p9w3TwSY085MgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSiz8/8Ar/8A fGKSiz8/+v8A98YipkkkkgpSSSSSlJJJJKYv/N/rs/6sKSi/83+uz/qwpIqUkkkgpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUVJvJ+B/Iipiq1v9Nw/6z/8Az2VZ Va3+m4f9Z/8A57KQUt07+iN/rP8A/PjlaVXp39Eb/Wf/AOfHK0gpSSSSSlJJJJKUkkkkpi/83+uz /qwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpi/wDN/rs/6sKSi/8AN/rs/wCrCkipSYMYHl4aN7gG l0e4tbJAJ8pP3p0kFIrcbHuDhbUywWANeHtDtzWHc0GeYJkJvsmJ9n+zejX9n/0Oxvp87voxHOqM kipEzGx2bQypjdpDm7WgbXBnpgiP5Ht+GnCazExLam0W012U1xsrcxrmN2iBDSIEBGSQUhsxMS2p tFtNdlNcbK3Ma5jdogQ0iBAT/ZseGD0mRUA2sbR7GtLXAN8ILAfkPBFSSUh+yYn2j7T6Nf2j/TbG +pxt+lE8aKYpqG2GNG1xe3QaPfO5w8zuMnzKmkkpYMYHl4aN7gGl0e4tbJAJ8pP3od+Nj5DAzIqZ cwHcG2ND27uJh0+KKkkpruwcF9fpPx6nVAh2wsaWbmt2NMRGjRHw0RWU1Vx6bGshrWDaA32Mna3T sJMBTSSU1zg4JfW849RfSGtqcWN3VtZq0NMaR2hHDGB5eGje4BpdHuLWyQCfKT96dJJSzGMYxrGN DWNAa1rRDWtGgAAQDg4JfW849RfSGtqcWN3VtZq0NMaR2hWEklIbMTEttbfbTXZdXGyxzGue3aZE OIkQUUMYHl4aN7gGl0e4tbJAJ8pP3p0klLOYx4h7Q4Ah0ET7mnc0/IiUO/Gx8hgZkVMuYDuDbGh7 d3Ew6fFFSSU0ndMxH2udbVXZSa6q2UOY1zGegbIIB04sjjRXHMY8Q9ocAQ6CJ9zTuafkRKdJFSlX pwcGgzRj1VGd0sY1nuALZ0Hg4j5lWEkFNerBwaQRTj1Vhxa5wYxrZdWdzSYH5p1Hgp242PcHC2pl gsAa8PaHbmsO5oM8wTIRUkVImY2OyptLKmNqaQ5tbWgMa4O3gho0+lr8dVC/Bwch4fkY9VzwNodY xr3beYlwPirCSSkTMbHZU2llTG1NIc2trQGNcHbwQ0afS1+OqbIxMTJ2/aaa79k7fUY1+2eY3A+C Mkkpg6mp+/exrvUbsskA72a+13iPcdPMqNuNj3BwtqZYLAGvD2h25rDuaDPMEyEVJBTBtNTNmxjW +m3ZXAA2M09rfAe0aeQU0kklKSSSSUpJJJJSkkkklKSSSSUpM1rWiGgNHgBCdJJSkkkklKSSSSUp JJJJSkz2MexzHtDmOBa5rhLXNOhBBTpJKa1fTun1bvSxaa/UaWP21sbuY7lpgag+CnXiYlVTqKqa 66bJ31tY1rHbhBloEGQjJIqQ/ZMT7P8AZvRr+z/6HY30+d30YjnVT9Gr0vQ2N9Hbs9OBs2RG3bxE dlNJBSz2MexzHtDmOBa5rhLXNOhBBQH4OC+11z8ep1rgWuscxpe5pbsILiJ+jp8NFYSSUhtxMS5p bdTXa1zt7g9jXAvDdocZHO3SfBKzExLam0W012U1xsrcxrmN2iBDSIEBGSRUsGMDy8NG9wDS6PcW tkgE+Un706SSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlKLPz/wCv/wB8YpKLPz/6/wD3xiKm SSSSClJJJJKUkkkkpi/83+uz/qwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlKTeT8D+RRUm8n4H8iKmKrW/03D/rP/wDPZVlVrf6bh/1n/wDnspBS 3Tv6I3+s/wD8+OVpVenf0Rv9Z/8A58crSClJJJJKUkkkkpSSSSSmL/zf67P+rCkov/N/rs/6sKSK lJJJIKUkkkkpSSSSSmL/AM3+uz/qwpKL/wA3+uz/AKsKSKlJJKpdmuZkHHrx7b3tY2xxrNQa1the 1v8AOWM/cKCm2khUXsuYXNBa5p22Vu0fW8alrgJ8fgRBBIIKKkpSSCzJbZZZWxjiarPSsPtgE1tt 3c8e4DxntGqMkpSSSEb2eo6poL7WBjnMHZlri0Ol0D80+enHEpSVJJJJSklUuzXMyDj149t72sbY 41moNa2wva3+csZ+4Uai9lzC5oLXNO2yt2j63jUtcBPj8CIIJBBRUlSSQm3sdkPxwDvrYywn83ba XtEf5hQUlSSUGW12OsYwy6p2ywa6OLWvj/NcElM0ln09UFlTMh2NdTjWND/Xf6WxrHiQ5wZY5wHi Y05dABK0EVKSSSQUpJUsrPfjO1xbrGbmMFjDTtc61zWNADrWu+k6OPw1Vii19rC59L6CDGywsLj5 /o3vH4oqSpJIOVktxqfVLHWe5jAxm3c51r21tA3Fo5d4oKTJKtVmF9grupsxnP8A5v1fTIsIEkNN T3iQNYMEiSJgxZSUpJCvvZQwPeCQXsr0/eue2tv4uRUlKSUH211urY8w612ysa6uDXPj/NaVXuzX MyDj149t72sbY41moNa2wva3+csZ+4UVNtJCovZcwuaC1zTtsrdo+t41LXAT4/AiCCQQVJ9tdbq2 PMOtdsrGurg1z4/zWlBTNJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJQfYGkiCYEuI/NHj+Cmkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkhVXstfcxoINDxW+e7ixlmnyeEVJSk kkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSlFn5/8AX/74xSUWfn/1/wDvjEVMkkkkFKSSSSUpJJJJ TF/5v9dn/VhSUX/m/wBdn/VhSRUpJJJBSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSS SUpJJJJSlJvJ+B/IoqTeT8D+RFTFVrf6bh/1n/8Ansqyq1v9Nw/6z/8Az2Ugpbp39Eb/AFn/APnx ytKr07+iN/rP/wDPjlaQUpJJJJSkkkklKSSSSUxf+b/XZ/1YUlF/5v8AXZ/1YUkVKSSSQUpJJJJS kkkklMX/AJv9dn/VhSUX/m/12f8AVhSRUpZ1mNfZ1O57LrcdnoUt3VtrLXuD7yRNtb/oyOPHXstF JJTg5ONkNrdS4G2tmSLbbLajk+vTZS6HWV1bfU22+0NH0A1hjaAUq8fbjM9Ss2Yf2kvspbjvqr9H 0CwBuMS9+31YdEfSl8R7lvJJWpwsShwyGuqosqo+3F7Gva4bavsJYHQfot3aAabdGw0jaK4wXV4P Tg6oekKJyGW0WZv6w5tW3dU0h24BrgCdGj26SAulSStThNx2trxftlTsjEa2+azQ57Wvssa6mMdv quaGs3Bs/Rb7TtJ2qD8Ktt5uoxXVtt+yemdh37aczdZPJYNmwhpiGgCBsIb0CSVqcL0G+pHoO/aP 2rf9o9J0/Z/tO/8ApG3bHoaRu49kT7VPGxHVW0XNrc21+Zk+s+HbvQcchzQSeGF20gfR3Q7kytpJ JTnWY19nU7nsutx2ehS3dW2ste4PvJE21v8AoyOPHXsq3UMGr9Cy0WPoO991raxlWPyDsDS6s12N 1bu12e2A1pa07TtJJKefppaK8duZTZfiVfaG7H0ut1fYx+OfSazSKpGjQGas9p9qn9ltfkvdRU5u F6NW7Ge0sN7G2ZB9NrnOhoAcDsPbax2xshbqSVqeczaLb8jIfth1204ljsS2+9jTUwD07t7G0kP3 EB23a73GJWrhYzKMvOcKhWbrW2BwbG9hqYPpD+WH6c6z+dJvJJKcKnp+YejVN9e51jcdhGG8Utrc 9jARS/8ARtdtJG1wLtRIJQc2i2/IyH7YddtOJY7EtvvY01MA9O7extJD9xAdt2u9xiV0aSVqce6r G+15By8Z99r3tOK9tTrHtr9JgAZc0RV+kDuXNg+7SZU6se/fXgOYRi4r/UbZ+a+quHY9Y7+13mT+ j92li1UklNTqLHvx2BjS4i/HdAE+1uRW5x+QEoPUa6nZFDsqk34jWWBzPTdkN9Zxr9Nxra1x+iH+ 6NOJ110UklPP7MD7c/18Sx+OMer063VvvaybcjbNI3lsj6Pt9jfb7J2m3dRlO6PjU2F/2kHEFrhF ljXstqL3SdwO2CZMjuVpCqsWuuA/SPa1jna6trLi0R/bKmkpz7sK5tFrxbZl5Da3/Z22llYbY5pH tNLaoJ43TIEwRJnKrxDUbh071x6uNdXrQMP9YIaaT7KaPB3uOjeJBdr0qSSnCupxXVR03FdRZ6lB c/0LKK/bkVOBfWRXviCdPogO9zd2qyqLxjMpeze5lwfl2Oqdk15DXVvaLDUwgv8Adt9n+DgabGtJ 3UkrU4NGCP1a11QfXVll7AKDQ2qt1Jr/AEdLy97W+rDjx7vfG33K7ZjX2dTuey63HZ6FLd1bay17 g+8kTbW/6Mjjx17LRSSU4WRjWCqzGuFllP2gWW3+mLrbKn1Eh7mBjmPItGzbsO1gadohrkLGwmCy k+k+ymjLFlLrKfTcymyg1+1grZt/TiSA0RpY7T3LokkrU870vGuZfjF7QzIrH605uLZS97vTc1wt yXv22+8g+2dzodxqD4FLK32tfQXVek4XvdQ+u10R7btXNyXuE+5oOsx/OLbSStSkkkkFKSSSSUpJ JJJSkkkklKSSSSUgtBmwQTvYGtgTr7vu5R0kklKSSSSUpJJJJSkkkklKSSSSU87RVU4n06H/AG37 a9zb9jnfoW5jjZtu1axuwOBbLZ19p3e5Nxrjmy9oGR9pL/UGLY670fW3tH2veGbfS0js32QTot+q quppZWNrS5zyNT7rHF7jr4uJU0bU0emY4qrueWFttt95cXTuLPXsLIn82DIjTUnuVm0497asqvGq cL3Y9jRd6bsW714hnq2F2y55Mn1G6NIJmHroEklPO0412zJOG0VPONaxopxbOnNdc+PTJNr/AHOE HaQPbJkiRJ7KsJ1Lxg4j6hNZv20vx2PpF1brGurc1nqSwO0DXabm/nQ7bSStTgvxmWNubiUPpxHv wwGMrfi/pGZO654ZDHD2bZeB259uk7MYVl9bqCcCvLBdQ2svrNBxR9GpoO5vrGdAfdLuxK20krU5 3Sawz7XsqfTU+8OpY8Fv6P0agC0Hhumg/N+jDYgaKSSSlJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSS SSlKLPz/AOv/AN8YpKLPz/6//fGIqZJJJIKUkkkkpSSSSSmL/wA3+uz/AKsKSi/83+uz/qwpIqUk kkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSk3k/A/kUVJvJ+B/Iipiq 1v8ATcP+s/8A89lWVWt/puH/AFn/APnspBS3Tv6I3+s//wA+OVpVenf0Rv8AWf8A+fHK0gpSSSSS lJJJJKUkkkkpi/8AN/rs/wCrCkov/N/rs/6sKSKlJJJIKUkkkkpSSSSSmL/zf67P+rCkmc0OEEka ggiJlpkcym2fy3/9D/yCKmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZJKO z+W//of+QS2fy3/9D/yCSmSSjs/lv/6H/kEtn8t//Q/8gkpkko7P5b/+h/5BLZ/Lf/0P/IJKZKLP z/6//fGJbP5b/wDof+QTtaGggEkkySY8AOwHgkpdJJJBSkkkklKSSSSUxf8Am/12f9WFJRf+b/XZ /wBWFJFSkkkkFKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKT7mtBLiAIOp 0CZMaqrRttY17RrDgHCfmipj61P+kb94QHvY/NxNrg6HPmDP+DKsfYsP/QV/5jf7v9fySrxcat4e yljHA6Oa1rSPuH+v5FSmr07+iN/rP/8APjlaVXp39Eb/AFn/APnxytIKUkkkkpSSSSSlJJJJKYv/ ADf67P8AqwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSmL/AM3+uz/qwpKL/wA3 +uz/AKsKSKlJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUpM5UVJnK Kmf+v+v+v+xDkfH/AF/1/wBQv9f9f9f9iHI+P+v+v+oKGh07+iN/rP8A/PjlaVXp39Eb/Wf/AOfH K0mpUkkkkpSSSSSlJJJJKYv/ADf67P8AqwpKL/zf67P+rCkipSSSSClJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSmL/AM3+uz/qwpKL/wA3+uz/AKsKSKlJJJIKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUpM5UVJnKKmf+v+v+v+xDkfH/AF/1/wBQv9f9f9f9iHI+P+v+v+oKGh07+iN/ rP8A/PjlaVXp39Eb/Wf/AOfHK0mpUkkkkpSSSSSlJJJJKYv/ADf67P8AqwpKL/zf67P+rCkipSSS SClJJJJKUkkkkpSSSSSkORi15G31HWN2zHp22U8+PpObPzWXhtZT0zEy3uuttvbjB+6+4guvfUC6 HPI5M8aj28EraVYYNQxKcQF3p0elsMjcfszmubOn8jVFTVHU8hzhtxZbZdbjVH1BLraXWe4iNGba ySfpA6BjtCY29ZZWyqRVXbYbWn17fRpDsZ/pWAWbHE+4+32iRJMcK43Bqb6UF36G6y9uo+nf6m4H Tj9KY+SGenMAaarbKbGutcLG7C6Mmz1bGw9jmxujtOnPMpSq+o1P6c/PImuttjnhhDwfQLmu2O03 A7fadJEcKtnZ+fRjZDXVV1ZAx7bqXMsNrQKdoeXbqm6jeCBBB4MLQ+zVuxnY1pdayxrm2F5O54sn dJERM9oA4ECFXd0xtrLG5F9t5sqfQHu9NrmV3Rv2+nWwa7RyDxp3lKbdLXNqY1whzWgEbnWagfvu 9zvidSs/Eofk4lOd61jMq+tls73mlrntDtvo7gzbrHG6Nd2/3LTVL9nM/m/Vs+y/9xPZ6O39z6G/ b/J3bY9sbPakph+0LZ9X0W/ZPW9DfvPrb/V+zz6ezbG/+X9HXn2qA6nkOcNuLLbLrcao+oJdbS6z 3ERozbWST9IHQMdoSb9nM3/ztnoep632f2en6m/1d07PU/nPd9Ly+joiNwam+lBd+husvbqPp3+p uB04/SmPkkprjqV9jqq6ccPttF27dZsrY/EsbU+XbSS0kmCGzxLRJ2id1GLWZLw5tdWPmOuqadwL 8W2pjts7Z4dtJjQ9pU39NcMqk1WWVMY3JcbWlu5tmTdXbG1wLXA+7lpj+tBRv2ZjFoY/c9vp3VPB MeoMtzX2udtjUub2gCTA4hKc+7rdjsbKbQ7HdkV49l1bqLxkNaKoDi/9GIPulogh0EGFaOfayx1b aN978gUFvqksDzii/cC5ujRwYHi6C47TYGDuZYzIvtyWWsdWW2FjG7H6O0pZXz4nUdokymdPrbY2 0ve+wWi8udt91go+za7WgfR107+WiSkTeoW2CtlFLXZD/V3Ne8srb9lsFNkPDHE+4+32iRqYOinX kZGZgW2UN+z5B9ausPIdssqe+ppdG4ctk8/NDyMP0WNfji82tfaQ6k0+oG5LzdYP1iGbdwH8rQea nh4Qb092Le07LTdvY5xc/wBPIse/a58kl210Eyde55SUgxmsZk1gfacWwkzVkWPvZcza72tcbbaw 6fdod8NOm0ymw+uVZV1LAaS3Jn0m13Cy9vsNn6WraNvtbr7nQ6BryrdeE4WssuyLcj0iXVtsFTWt eWlm79FWw/RcRrprxMJY+D9nLA2+11NQ21UEsFbGgbWj2sa50DT3Od4n3AFJTVp6wTjjIyKDVW/G dlsDXCx5rqDC8EQ0D6Y26mR9LadELLy8uq1xyatja8PJtLKrnFlmw0x79rHNcNdduk6HmLo6Zjel VS7c+urHdihpP0qrAwO3Fsa/oxxHdQf0plu8333XOspsxy5xYIrv2zDWMa2fbzHxmBCUp3UbG5Fr DR+gpurofbvEl14r2bWR2dYN0kQNRuOgZ3Urx+kbjh2Mbxjh/qRYH+t9nc5zC2Nu6YhxJ00EnbYd g1O9WS79NdXe7UfTo9PaBpx+iE/NUL8K514qqbeKRey8EupGKHC1t9h9p9Yz7tHS3ceAACEpk261 3VQA93pmxzWvk+g6uuqHUtHBtFvumPohzd3tc0Cc/Gdm5gyHZZLLWtYKDmGtrPQqdH6v7eST4q3b 0mqzc022ClznvFMVFjbLdxc4F1ZdqXEkF0GS0gsJardVDKn3PaSTe8WPns4MZXp8mBJTmftc042P 6rqvVvFjg7IsGM0MqcG7bCGui0bhuaBG4P4iEevqb8hlP2Wtlltwtd7rNtO3GeKnltjWPLpc4bfa JGpjhEd05gduptsoeHWOa5mxxaL3B9jR6jHiHPG7XUHQEN0Un4O4Vlt9rLqg5ovBY6xzbSHPB9Rj m6loOjREQ2G6JKauR1c0WNosbRRcGB725F4pZ7nOYPTcGP3fQJ1DdC2RJIEmdUrfbXY2t3pXV4zi 9zj7G5ZtFf6PUTvDWmP3tdGox6eQ4PrybqrS0NssBre6wNc5w3eqx4EF7vogDWOAACHAx3eqH7nt vpbj2Nc4ma2b/wA76Un1DJlJSKzNBza6AwlrbRX6geWxa6i25zS386GBvl7vFqBT1gnHGRkUGqt+ M7LYGuFjzXUGF4IhoH0xt1Mj6W06K4zBqY2gAuJosdcCSJfZa2wPc7Tv6hOka8aaIY6ZjelVS7c+ urHdihpP0qrAwO3Fsa/oxxHdJSzcvM+0DGtx2NtfVZbW5tpfU70yxoaSa2uGr9fboIjdqBeWTjY2 W/L9e05FZbTZV6l5oL5tdW5prZRur9uwyXNkyPpAaaySlJJJIKUkkkkpSSSSSlJJJJKY2ktqe4aE NJHyCiwbbHNBJADTqS7Ul3j8FNwDmlp1BEH5pms2kkkuJ0kxwPhCSmSSSSSlJJJJKUkkkkpSSSSS lJJJJKUq2dl/ZKhZDfc4N3WO9KlmhM2WQ7aNIGn0iB3VlCvpNrAG2PpcDLX1kbh24cHNOh7g+PIB RU0b+rNproLvRY/Ia57Tbc2ugtrLQS20Nfu3bwW6CW6nadFKvqb8hlP2Wtlltwtd7rNtO3GeKnlt jWPLpc4bfaJGpjhE/ZzA2v0rbKra9/6Zuwvd67vUtkPY5nueJ0aI7QNFJ+DuFZbfay6oOaLwWOsc 20hzwfUY5upaDo0RENhuiSmH2vMdZ6FWOz1mMa+5tlpYwb3PY3Y5lb90+mTqG6RpMgAd1g7DbVQX UMxq8yx7nBjm02byWhoDpfDNBwdZc3SbB6eQ4PrybqrS0NssBre6wNc5w3eqx4EF7vogDWOAAEem Y3pW0t3Mrtx24paD9GqsPDdpdOv6Q8z2SU1up5uSMXPGPX7cat7H2izZa2w0iwOY3bBDQ8GdwPMA wJ1lRyel15HrNN1tdWSD61dZa1r3bBXuktLho0aA7TGoMum8kpSSSSClJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpi/83+uz/qwpKL/AM3+uz/qwpIqUkkkgpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSkzlRUmcoqZ/wCv+v8Ar/sQ5Hx/ 1/1/1C/1/wBf9f8AYhyPj/r/AK/6goaHTv6I3+s//wA+OVpVenf0Rv8AWf8A+fHK0mpUkkkkpSSS SSlJJJJKYv8Azf67P+rCkov/ADf67P8AqwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJ JJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpi/83+u z/qwpKL/AM3+uz/qwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkk pSkzlRUmcoqZ/wCv+v8Ar/sQ5Hx/1/1/1C/1/wBf9f8AYhyPj/r/AK/6goaHTv6I3+s//wA+OVpV enf0Rv8AWf8A+fHK0mpUkkkkpSSSSSlJJJJKYv8Azf67P+rCkov/ADf67P8AqwpIqUkkkgpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUk kkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSS SlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKUkkkkpi/83+uz/qwpKL/AM3+uz/qwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSS lJJJJKUkkkkpSSSSSlJJJJKUkkkkpSkzlRUmcoqZ/wCv+v8Ar/sQ5Hx/1/1/1C/1/wBf9f8AYhyP j/r/AK/6goaHTv6I3+s//wA+OVpVenf0Rv8AWf8A+fHK0mpUkkkkpSSSSSlJJJJKYv8Azf67P+rC kov/ADf67P8AqwpIqUkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpi/83+uz/qwpKL/AM3+uz/qwpIq UkkkgpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSkzlRUmcoqZ/wCv+v8A r/sQ5Hx/1/1/1DSPEfihvvay6moCTc4ifDa0u/gipq9O/ojf6z//AD45WlW6c0nEadPpWf8Anxyt 7T4j7wgpiko1vbabA3/BO2OJ090A6feibT4j7wkpikpbT4j7wltPiPvCSmKSltPiPvCW0+I+8JKR v/N/rs/6sKSTmExqNHNPP7rgVLafEfeElMUlLafEfeEtp8R94SUxSUtp8R94S2nxH3hJTFJS2nxH 3hLafEfeElMUlLafEfeEtp8R94SUxSUtp8R94S2nxH3hJTFJS2nxH3hLafEfeElMUlLafEfeEtp8 R94SUxSUtp8R94S2nxH3hJTFJS2nxH3hLafEfeElMUlLafEfeEtp8R94SUxSUtp8R94S2nxH3hJT FJS2nxH3hLafEfeElMUlLafEfeEtp8R94SUxSUtp8R94S2nxH3hJTFJS2nxH3hLafEfeElKaSGmN OEt7vEp40Ika+YTbT4j7wlqpW93iUt7vEpbT4j7wltPiPvCWqlb3eJS3u8ShZND7se2plnpPsY5r bGn3Mc4QHCCOFUxOmVVubd9now7mOOmMWxYwtLdr3enWSJMx4hpS1U6G93iUt7vEqrUzqIsDrn0O rd9Ktgc11ekiHlx3xx9Fs86fRLUN6oGE5H2dzyzRlbntaLW9tzg6Wu5+iC3j38paqbe93iUt7vEq hVi5326u/IspeyuqxgdWHVuLrXVGNjnP49Pnd340k39p8R94S1Ure7xKW93iUtp8R94S2nxH3hLV TV6i9/2G7U/RI+9WELLx33Y1lTC0OeIBJ0R9p8R94SUxUmkhpjThLafEfeE8aESNfMJKW3u8Slvd 4lV83GfkYzqmFsktO1x9j2scHOrdz7XgbTodDweFSd0p4xbDhtpwMuyp9cUn9DueRtcSxtbi5oHt Me3cdD3WqnV3u8Slvd4lVHV9UmWWY8NA9pa/9K4D3Hdv/RydOHxzrwlYzqhtea3Y4qaQaw7e59jd olriCAz3T7ofoR7dPctVNve7xKW93iVU6hiPyK2NaK7Qx+59Fpiq5u1zdr9H8Fwd9E6tHxEacE41 bnYjKqLLGsBpaR9mY8E7nhrWt3H3eW7a0e3lLVTd3u8Slvd4lVNnVG1PG7HttBaWH30sLd3va4Ta R7eHSdT9HTV9nUfS276PW3R6sO2bImfS3TM+2N/8qfzUtVNre7xKW93iVn42HlstfZd6DnWZHquI kwwY4pDmT9Fxc3iTDSRuKLQ3qgYTkfZ3PLNGVue1otb23ODpa7n6ILePfylqpt73eJVXqL3/AGG7 U/RI+9KlnUW2xe+iynaSXsDq375btGxzniAJ13ayNBGs8vHfdjWVMLQ54gEnRLVSVJS2nxH3hLaf EfeElL7iGtgx/vTb3eJTkaASNPMJtp8R94S1Ure7xKW93iUtp8R94VfNxn5GM6phbJLTtcfY9rHB zq3c+14G06HQ8HhLVTY3u8Slvd4lZTulPGLYcNtOBl2VPrik/odzyNriWNrcXNA9pj27joe9p1fV JllmPDQPaWv/AErgPcd2/wDRydOHxzrwlqpt73eJS3u8SqljOqG15rdjippBrDt7n2N2iWuIIDPd Puh+hHt09xsiu91D20Pay1whjyQdk6b41nbzHfiRylqpLvd4lLe7xKz/ANn3DDbiNczbTdU6kz/2 npuZa1p05a1u0czAJOpixh4z6KXMeWkm26zQ/m3XPsb+DktVNje7xKW93iUtp8R94S2nxH3hLVTU yXOOVigkxueY/wCtuVlCtx3vvosBbFRcXSdfc0t0R9p8R94SUxSUtp8R94S2nxH3hJTFJS2nxH3h LafEfeElMUlLafEfeEtp8R94SUxSUtp8R94S2nxH3hJTFJS2nxH3hLafEfeElMUlLafEfeEtp8R9 4SUxSUtp8R94S2nxH3hJTFJS2nxH3hLafEfeElMUlLafEfeEzoa0uJEASdewSUwf+b/XZ/1YUlFn 6aquxujXbLBPO2Q5E2FJTFJS2FLYUlMUlLYUthSUxSUthS2FJTFJS2FLYUlMUlLYUthSUxSUthS2 FJTFJS2FLYUlMUlLYUthSUxSUthS2FJTFJS2FLYUlMVJvJ+B/IltPiPvCBddYywU0hrrnNLvcSGh oIadWg66pKczqd/1gqyqmYFVF2Pcdu54fuqdEk2EPHt0mQPKJjdeeHjKwg8hz5duLRtaXemZIBJj 7ylPUf3af85//kUq6sx+VRZcKw2ok+wuJ9zS3u1JSsJxb09rg0vINpDGxudD3aDcQPvKp9A6jk9Q oybslnpOZkOrbVEGtrGs9hmDMkzPfw4VnHOZTQ2oYr3QXHduY36bi4aEzwptflNLi3CILzueQ6sb nQGydfAAJKXwv+1X/Hn/AKhqsqlR9tqFv6q4m2w2fSr0G0D97yRPVzf+4bv8+v8AvSU2UlW9XN/7 hu/z6/70vVzf+4bv8+v+9KlNlJVvVzf+4bv8+v8AvS9XN/7hu/z6/wC9KlNlJVvVzf8AuG7/AD6/ 70vVzf8AuG7/AD6/70qU2UlW9XN/7hu/z6/70vVzf+4bv8+v+9KlNlJVvVzf+4bv8+v+9L1c3/uG 7/Pr/vSpTZSVb1c3/uG7/Pr/AL0vVzf+4bv8+v8AvSpTZSVb1c3/ALhu/wA+v+9L1c3/ALhu/wA+ v+9KlNlJVvVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c3/uG7/Pr/vS9XN/7hu/z6/70qU2UlW9X N/7hu/z6/wC9L1c3/uG7/Pr/AL0qU2UlW9XN/wC4bv8APr/vS9XN/wC4bv8APr/vSpTZSVb1c3/u G7/Pr/vS9XN/7hu/z6/70qU2UlW9XN/7hu/z6/70vVzf+4bv8+v+9KlNlJVvVzf+4bv8+v8AvS9X N/7hu/z6/wC9KlNlJVvVzf8AuG7/AD6/70vVzf8AuG7/AD6/70qU2UlW9XN/7hu/z6/70vVzf+4b v8+v+9KlNlJVvVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c3/uG7/Pr/AL0vVzf+4bv8+v8AvSpT ZSVb1c3/ALhu/wA+v+9L1c3/ALhu/wA+v+9KlNlJVvVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c 3/uG7/Pr/vS9XN/7hu/z6/70qU2UlW9XN/7hu/z6/wC9L1c3/uG7/Pr/AL0qU2UlW9XN/wC4bv8A Pr/vS9XN/wC4bv8APr/vSpTZSVb1c3/uG7/Pr/vS9XN/7hu/z6/70qU2UlW9XN/7hu/z6/70vVzf +4bv8+v+9KlNlJVvVzf+4bv8+v8AvS9XN/7hu/z6/wC9KlNlJVvVzf8AuG7/AD6/70vVzf8AuG7/ AD6/70qU2UlW9XN/7hu/z6/70vVzf+4bv8+v+9KlNlJVvVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSV b1c3/uG7/Pr/AL0vVzf+4bv8+v8AvSpTZSVb1c3/ALhu/wA+v+9L1c3/ALhu/wA+v+9KlNlJVvVz f+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c3/uG7/Pr/vS9XN/7hu/z6/70qU2UlW9XN/7hu/z6/wC9 L1c3/uG7/Pr/AL0qU2UlW9XN/wC4bv8APr/vS9XN/wC4bv8APr/vSpTZSVb1c3/uG7/Pr/vS9XN/ 7hu/z6/70qU2UlW9XN/7hu/z6/70vVzf+4bv8+v+9KlNlJVvVzf+4bv8+v8AvS9XN/7hu/z6/wC9 KlNlJVvVzf8AuG7/AD6/70vVzf8AuG7/AD6/70qU2UlW9XN/7hu/z6/70vVzf+4bv8+v+9KlNlJV vVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c3/uG7/Pr/AL0vVzf+4bv8+v8AvSpTZSVb1c3/ALhu /wA+v+9L1c3/ALhu/wA+v+9KlNlJVvVzf+4bv8+v+9L1c3/uG7/Pr/vSpTZSVb1c3/uG7/Pr/vS9 XN/7hu/z6/70qU2UlW9XN/7hu/z6/wC9L1c3/uG7/Pr/AL0qU2UlW9XN/wC4bv8APr/vS9XN/wC4 bv8APr/vSpTZSVb1c3/uG7/Pr/vS9XN/7hu/z6/70qU2VC7+Zs/qn8iD6ub/ANw3f59f96Z7817H N+yOG4ETvr7/ADSpTYwv6HR/xbP+pH+v+uh/9f8AX/X/AGCxa3141LHghzGNa4eBa0D/AF/1gsHw P+v+v+vYoV/r/r/r/sX+v+v+v+xQfA/6/wCv+vZQfA/6/wCv+vZKV/r/AK/6/wCxf6/6/wCv+xQf A/6/6/69lB8D/r/r/r2Slf6/6/6/7F/r/r/r/sUHwP8Ar/r/AK9lB8D/AK/6/wCvZKV/r/r/AK/7 F/r/AK/6/wCxQfA/6/6/69lB8D/r/r/r2Slf6/6/6/7F/r/r/r/sUHwP+v8Ar/r2UHwP+v8Ar/r2 Slf6/wCv+v8AsX+v+v8Ar/sUHwP+v+v+vZQfA/6/6/69kpX+v+v+v+xf6/6/6/7FB8D/AK/6/wCv ZQfA/wCv+v8Ar2Slf6/6/wCv+xf6/wCv+v8AsUHwP+v+v+vZQfA/6/6/69kpX+v+v+v+xf6/6/6/ 7FB8D/r/AK/69lB8D/r/AK/69kpX+v8Ar/r/ALGPB+H8U8HwP+v+v+vYV77mNAqpdcTzBa2P84hJ Lj39TyqvrBVgMqN2PdQHu2xuqdveDYSY9ugBnyjXR14/8ot/4l3/AFbUg/KDy8YR3uAaXbq9xa2S ATPaT96VVeU/MF1lBqaKyzUtdqXNP5pQU2lJn0h8UtjvAp2tcHDRJTS+xu/7k3f5zf8AyKX2N3/c m7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+ RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1 fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uT d/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8A yKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/ 3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v /kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkkl NX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7 k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/ AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3 f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/O b/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJ JTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv +5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN /wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2 N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/ zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVa SSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G 7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5 zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil 9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9yb v85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5F WkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+ xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDIpfY3f9ybv85v/kVaSSU1fsbv+5N3 +c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/cm7/Ob/5FWkklNX7G7/uTd/nN/wDI pfY3f9ybv85v/kVaSSU1fsbv+5N3+c3/AMil9jd/3Ju/zm/+RVpJJTV+xu/7k3f5zf8AyKX2N3/c m7/Ob/5FWkklNOzFe2tzhk3S0Ej3N7D+qpfY3f8Acm7/ADm/+RR7v5mz+qfyKaSmr9jd/wBybv8A Ob/5FL7G7/uTd/nN/wDIq0kkppnEf6rmfaboaAR7m9y7+T5KX2N3/cm7/Ob/AORVg/0iz4N/K5SS U1fsbv8AuTd/nN/8inGE4n+k3d/zm/8AkVZTt5+R/IkppMxXuaScm7lw+k381xH7ql9jd/3Ju/zm /wDkUer6B/rP/wCqKmkpq/Y3f9ybv85v/kU4wnEgfabtf5Tf/Iqynb9IfFJTz+Pl59tTXuySJE/Q Z/5FE+0Zn/cs/wCZX/5FZVdpGOwA8AfkU67Rul7oA/KVDKVXuWvjuc4w4q4juS6Jycv/ALlH/Mr/ APIpfasv/uUf8yv/AMiszKyRbksrodIENP8AFEymto9NoJL7JPwATPe1ESCJS6eS/NA45cInx6XY b/2vL/7lH/Mr/wDIpvteX/3KP+ZX/wCRVTGxL8it1oeyqtrg3fa7Y0uPYcq1jdMc7KsoyXisVM3m HCXNP5zZHA7qUcR+rGDM1V6+K/2vL/7lH/Mr/wDIpvtmX/3KP+Yz/wAiq+PhXXh7m2VtZW7Z6rnR W50wNpjWU7cDJdk2Yoj1am7nCTBEA6aeaFy7FFz/AK32pjm5n/ck/wCYz/yKY52Z/wByT/mM/wDI qdXS2llxuyKmuqb+a8Qx549TTQLL1IBQJI36olKcasnXxbx6jmj/ALUf9Fn/AJFCf1XOa4H7QS3v 7K//ACKpPBVW0kAowmRIHejsdlvHI9T9rrftjL/05/zK/wDyKIzqXULBLLXOA77K/wC5YfIB8dVo YziMePFx/IFvezjoEQhr/VC3jl+9L7W99v6l/pXf5tf9yb9o9Q/0rv8ANq/uVVgFlwa8u2BtjyGn aT6dbnxMHw/2ItWPXa9rTTe0vZ6rJsLtzJiYqx3nX4f99mjl5jDjySxnFEmNa0Oov9rcxctkyYxk GQgSs/YSP2JP2l1D/Su/za/7kv2l1D/Su/za/wC5VbGtZcWsLthZW8B53OHqMD+QAO/grLsC9tlt Zc39E0vLpOx20ElrTGp0P3HwVjF7OTHGfBCPFxaGI/RNNfLHJjmYcUpVWt9xa/7S6h/pXf5tf9yX 7S6h/pXf5tf9yCcfIl21jnBjthcGujdMRqPw5URTeQ4trcQwBziAfa0iQT8lN7WL92H+KGPjn3l9 rY/aXUP9K7/Nr/uS/aXUP9K7/Nr/ALlXFN5a14rcWvO1joMOd4A90RmLaWWue17TSBuaGkuBcC4b gYhump+GiBxYh+jD/FCuLJ3l9qT9pdQ/0rv82v8AuS/aXUP9K7/Nr/uQnYt7MkYzxte5wY0mQ0y7 aHDThM7HslvpH1w8kNNYcZcwAuEOaDoD4Je3h/dhrr8oVxZO8vtTftLqH+ld/m1f3JftLqH+ld/m 1f3Kqa7gSCxwILgRB5YJd93dOKb3BxDHEMAc4hp9rSJBPyR9nF+7D7Ajjn+9L7Wz+0uof6V3+bV/ cl+0uof6V3+bV/cg149jw4uPpMa3cXvDoiWjTa0/vhM7HvBcGtLwwBznNBLdjhua7jSRrqh7WL92 H+KE8WTvL7U/7S6h/pXf5tX9yX7S6h/pXf5tX9yB9nyNpe1jnMaAXPDXbRLQ7Ux4H/UJrqbqdpeC GvaHMdB2uDmh2h8p1R9rFtww+wK48neX2tj9pdQ/0rv82r+5L9pdQ/0rv82r+5U5KUlH2Mf7kP8A FCPcn+9L7W5+0uof6V3+bX/cgO69kNdtN7pHMMZp/wBFBJKynfz1v9b+CBw4xXohr/VCROR/Sl9r tft/I/07v+22f+RS/b+R/p3/APbbP/IrEc7a0nTykwFZZRZ6Xqvqea3AljmDd7a/puIB0iRzp+UQ ZZYMQ9UY9NBAdWfFjy5D6ZEb6mWmjpft/I/07/8Attn/AJFL9v5H+nf/ANts/wDIrH0mJ7kAwRMR xMeKM3FtdV6vtayCRuexjnBvdrXODncdhzpypIxwyiJAYyDseEMcvciTEmYI31dL9v5H+nf/ANts /wDIpft/I/07/wDttn/kVRf0/KZY2otaXueKoa9j4sJgNdtcdp+Md/ApM6dmWOtYyuXUvbXYNzfa 97tjRz+8lwYe2P7Ai595/a3v2/kf6d//AG2z/wAil+38j/Tv/wC22f8AkVmXY9tMb9pDphzHNsaS ORuYSJHh8EY9NygWD9GfUBLYtqMtaHFztH8DadeEuDF+7j/xQq595/a3f2/kf6d//bbP/Ipft/I/ 07/+22f+RVD7DeXFoNegBLvVq9Mbpgb9+2dOJlL7Df6Trpr9NhIcfVq5E6RvnXaY8e0pcGL93H/i hVz7z+1v/t/I/wBO/wD7bZ/5FL9v5H+nf/22z/yKzqsO+2v1GAFpJa0F7Guc5oBLWtJDnH3DgIVl b63BrxBIa4D+S9oc3jyKPt4tuHH/AIoVc/3p/a637fyP9O//ALbZ/wCRS/b+R/p3/wDbbP8AyKon p+UMo4jmhuQI9jnsbq6IAJdBJngJDAyCC6aw0Et3G6kNLgA4wS+DAcOEODF+7j+wKufef2t79v5H +nf/ANts/wDIpft/I/07/wDttn/kVmtxb3VeqGjbBIG5oeWt5c1k7iBB1AjQ+BT2YeRXWLHAbYa4 gPY5zWvALXOa0lwBkcjuPFH28X7uP/FCrn3n9ro/t/I/07/+22f+RS/b+R/p3/8AbbP/ACKou6fm NutodXFmOw2Wt3N9rAAZmYOh7KqkMeI7Rxn/AAQq5/vT+12P2/kf6Z//AG2z/wAipt61lOAIyDB/ kM/8isRSZ9H5n8qcMOMn5If4oRxS/el9rt/tjL/05/zGf+RS/bGX/pz/AJjP/IrH1S1TvYxfuR/x Qjin+9L7XY/bGX/pz/mM/wDIpftjL/05/wAxn/kVj6papexi/cj/AIoVxT/el9rsftjL/wBOf8xn /kUv2xl/6c/5jP8AyKx9UtUvYxfuR/xQrin+9L7XY/bGX/pz/mM/8il+2Mv/AE5/zGf+RWPqlql7 GL9yP+KFcU/3pfa7H7Yy/wDTn/MZ/wCRS/bGX/pz/mM/8isfVLVL2MX7kf8AFCuKf70vtdj9sZf+ nP8AmM/8il+2Mv8A05/zGf8AkVj6papexi/cj/ihXFP96X2ux+2Mv/Tn/MZ/5FL9sZf+nP8AmM/8 isfVLVL2MX7kf8UK4p/vS+12P2xl/wCnP+Yz/wAil+2Mv/Tn/MZ/5FY+qWqXsYv3I/4oVxT/AHpf a7H7Yy/9Of8AMZ/5FL9sZf8Apz/mM/8AIrH1S1S9jF+5H/FCuKf70vtdj9sZf+nP+Yz/AMil+2Mv /Tn/ADGf+RWPqlql7GL9yP8AihXFP96X2ux+2Mv/AE5/zGf+RS/bGX/pz/mM/wDIrH1S1S9jF+5H /FCuKf70vtdj9sZf+nP+Yz/yKX7Yy/8ATn/MZ/5FY+qWqXsYv3I/4oVxT/el9rsftjL/ANOf8xn/ AJFL9sZf+nP+Yz/yKx9UtUvYxfuR/wAUK4p/vS+12P2xl/6c/wCYz/yKX7Yy/wDTn/MZ/wCRWPql ql7GL9yP+KFcU/3pfa7H7Yy/9Of8xn/kUv2xl/6c/wCYz/yKx9UtUvYxfuR/xQrin+9L7XY/bGX/ AKc/5jP/ACKX7Yy/9Of8xn/kVj6papexi/cj/ihXFP8Ael9rsftjL/05/wAxn/kUv2xl/wCnP+Yz /wAisfVLVL2MX7kf8UK4p/vS+12P2xl/6c/5jP8AyKX7Yy/9Of8AMZ/5FY+qWqXsYv3I/wCKFcU/ 3pfa7H7Yy/8ATn/MZ/5FL9sZf+nP+Yz/AMisfVLVL2MX7kf8UK4p/vS+12P2xl/6c/5jP/IpftjL /wBOf8xn/kVj6papexi/cj/ihXFP96X2ux+2Mv8A05/zGf8AkUv2xl/6c/5jP/IrH1S1S9jF+5H/ ABQrin+9L7XY/bGX/pz/AJjP/IpftjL/ANOf8xn/AJFY+qWqXsYv3I/4oVxT/el9rsftjL/05/zG f+RS/bGX/pz/AJjP/IrH1S1S9jF+5H/FCuKf70vtdj9sZf8Apz/mM/8AIpftjL/05/zGf+RWPqlq l7GL9yP+KFcU/wB6X2ux+2Mv/Tn/ADGf+RS/bGX/AKc/5jP/ACKx9UtUvYxfuR/xQrin+9L7XY/b GX/pz/mM/wDIpftjL/05/wAxn/kVj6papexi/cj/AIoVxT/el9rsftjL/wBOf8xn/kUv2xl/6c/5 jP8AyKzKKHXEhoEjUkkNaB5ucQAp2YzqgC4DaSWhzXNeCWhpOrSf3gmHHhBrgjf90J4p78UvtdD9 sZf+nP8AmM/8ik3q2Y+2usZB95IPtr7Nc793yWXRS++9lLTtL+XfutHJW43pWNtc2mprjW0ufY8g xA7udxP+uibkhiia4I35BBlOjUp2RpSP9oZv/ch3+bV/5BL9o5n/AHId/m1f+QVJoEkN8JhEowMq /fv/AEbgGueSfZW14lvCjynFjoe1GUpXQER062x4hlmJSOaUYRrXUm5bCg2P2lmf9yHf5tX/AJFL 9pZn/ch3+bV/5FZIeWvIbLmN0c76Q+R7rQx6Q+qx5rfZtAhzPot8S6e0JQlglEy4IiiB8oo3oCD2 X5sPMY5RickvUP3tQQLMZDof4pv2lmf9yHf5tX/kUv2lmf8Ach3+bV/5FZ+RfUX1U0Ai5p/TBw0N fj92vx08kn749kT4FPjHGYmXtDQnThFmmL9bxRicxjx9ZSIA83QPUcwiDkOI7gsq/wDIJ/2pm/8A ch3+ZV/5BZlZvsafSrNrxMsaIcITsfNttVoNbqQS8RLhAd2O391Mjk5UkRAjxEcVcHSr7M0+W5yI lIyNQlwn9YN74flJvfw8dnS/amb/ANyHf5lX/kEv2pm/9yHf5lX/AJBZT8wOrIxidzZcd1bDuB2t 8XRCnU576mus+mZnQN7nsE+IxSlQhHz4QxzjnhDilkl5W6X7TzJJ+0Ok8nZV/wCQS/amb/3Id/mV f+QVB7RXdbWPoM2FsmSBZVXbEnUwXwJ1jkk6qNjbGtqs1aHW+mWkc/o7HHnzaPxRAw8MZcEfXVek dWOUswmYe5Kxf6XYW6P7Uzf+5Dv8yr/yCX7Uzf8AuQ7/ADKv/ILPR3Y1jbTUS32ta9zwZY1rgHSS Pj25OgnRPOLEP0Yf4oWjJlO05/a2R1PMAgZBH9ir/wAgl+1M3/uQ7/Mp/wDIKpXQ+y0VsIIc8Vh+ uzc8w3t3Um4vqXV01WssdYYBG5ob8d7W/gh7eIfox7/KkTzH9Ofb5mx+1c3/ALkO/wAyn/yCX7Vz f+5Dv8yn/wAgs5JH2cf7kf8AFCPdyf5yf2rVn9E0eQRqb8emwG0wAZiJVKu0BoHgiesxYWPJLHk4 wATqNfFtWQbq27gUjKyLLnTBPtI0ISzGM+2kNJIraGySXanU8qiH1j6LiyedphEZbWwQFDk45555 iT6to1syzzROIQjGpdZOxhECg1m3H9N1k20ZMbSyG+5h8VKo4Rt6hXTayuu2sVUOscQyIIcGk9p4 /BY5urdzqn9aqI0hPEiABWy2OUiIFbOxgt6c3EpL/s3qOcRd9ohzg2YGxp8vkOUz8uvf1PIa8B9g FVJDhvd+YXM140BWT61J5AT+vV5aI8RoCtl3umgOHZv0MoHScigWMZY5zXbXnaXtrh0N8TIVWBCC b6yZKX2hvimmzWmzHImQHgyeFSv4KO+4Qq5PqPA7DU/AJ0ISlIRG8jSAKUBAA8AB+Ct0/wAyP6x/ gqfqs8URmUxrdvOsrpBQAHZbRb1EeuAS1u6u5oLiGtl1TgJLtOVczLjmVg3UUHJDdnrfaawABP5g fHjzPfkc4xyqjyJ+5L7TT+6PwWdzHJSyZJzE4gTrQjsAG/g5uOOEImBJhet9yS3byPXIBDttdLSW kOG5tTWu1BI5H+1WX5266w6+k43Fo/O/TNcGg6xoXfKXeKyRlVDgR8IT/bK/BWsGEY8UYSPEY8Wo /rG2tmyGeSU4ggHh3/qinYfl478lmQd4NVm4NDQdzDa63U7hB93GvxQ6cljdjrS4vqsNwj3eo523 RxJEfQ515WX9sr8EvtlfgpOCNUxXLs6oyqQGbgX2bTW6zaGFrDWa4ADofE8mDpE+Ebcio44oZuIa WbXEBshptcZAJj+c81mfbK/BL7ZX4I8MVXLs6ZyKvtzcobtpsFr2wJB3bi0a6/HT4Jm5W7ey4wx7 dv6NrRt9zXzsbtBnbH+5Zv2yvwS+2V+CXDH7Nvor1Osc5oENaCWFoZuGhYGsY/dr+d6Y08C4aqYz 6xxLRW6ajsre4ta1jGyXzsMMGonXtosb7XX/AKwl9rr/ANYQ9uCbm6v2yHPIkzTXUwODXtBZsnR0 iPaUqsts1vtLi+mz1WhoEO0Z7eRtA2dgfhosr7XX/rCX2uv/AFhHgj/L7EXJ1vtlW/GdDooe1zuN Q1lTdNf+DKr32Ms2PEh21rXNI0HptDBBnWY8BHmqP2uv/WEvtdf+sJCMRVdNFHiO7cPo+6N30W7Z j+c9u6fLmPkov2T7JiBO7ndA3cefCq/a6/8AWEvtdf8ArCdp3RR7NhZbv563+t/BXPtdf+sKm4j1 HOmQ4zp2Ql0TEEW6XRKWXZoa9rXDaTD2726ETp4wrjMfqLL3PqtpYwAmprva1rLLILS3+Vt7xr9E 8rCba5h3Mc+t37zHbHfe1wTm6w822mYGtjuGncPzux1WdzPKTy5OOJiNBu3uX5mOOHCRI69rTZNF lRc60MFrrrQ8VzG4bHH85w5fx27+AtNsw7WusuLA70RWGO9X1G2U1bGFhZ7CHEAnd5jzObukklzn EkuO5xd7nxuOruTCW4eH5P71PgwnHj4ZHWzrHxYc2UTnxAaUN3aOfiPzjY2Ka25Tb3OAe4XMa/Rx 3bi1zQ4nSAZPBABhg9SYH1i92xtYrExO5zL6ST7RpFdQH9nxKyNw8Pyf3pbh4fk/vUvtxqtWLiKe 7I9VrWNY2qthLgxm4jc+A50vc467R3jRW8fJpbZikvDfTotrc5zS5rX2G7buG10j3jsVm7h4fiP7 0tw8PxH96cYgiv5aoBN26LX7bXkZWOA4NJBqcaiRIEV+htBHjt786lCstxzTksqBY197H1MMyKmi 0anXjcO6p7h4fiP70tw8PxH96HCPy/BVlvVZjKcWoMY119dr7GudvmuW17XNghp1b3njhHbbiNy6 Mt1oeKmVn0mh7X+pRSIBJZtgvZGhPKytw8Pyf3pbh4fk/vS4Brvrf4psumzJw/WwLGh1Qx7Ntgcf UiptgtDpaxvd7vuQWZhqw66mbC8WWOcH1sthrm1hseo137p4VLcPD8n96W4eH5P70uAefn/LxVZd Fl9Hr05peA6gVTRDt7nY7WtG10bYdtGpII10MDc92Xj2VurYAxzqaWG4byX+lWzdW4EkD3NEEDtr oSRm7h4fk/vS3Dw/J/elwC710VZde3qTH5Fzd36FxyS18fSbYy30hESPdY7/ADteAslNuHh+T+9L cPD8n96MYgbIJJXRKx7fmfyoW4eH4j+9EZYwNgnxP3lPjugpIShR9Vnil6rPFPsd0asoShR9Vnil 6rPFKx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPFKx3VqyhKFH1WeKXq s8UrHdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPFKx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqz xSsd1asoShR9Vnil6rPFKx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPF Kx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPFKx3VqyhKFH1WeKXqs8Ur HdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPFKx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqzxSsd 1asoShR9Vnil6rPFKx3VqyhKFH1WeKXqs8UrHdWrKEoUfVZ4peqzxSsd1asoShR9Vnil6rPFKx3V q28dzDTZQ9wr3ua8PMloNYcIO0E67vP8ZBzkCjHbTU6u1wse5xNYeIc2uI9Vnkf9YWb6rPFP6zPF Qyx2bsd6SCa2TY1vo5DbPEFh/tQf4LXZ1Cp2PZi5MtrdL2WVj3B7dQHDTcD5/wC1uD6rPFGourdc xj4LCTuJnQBpPj4ozjE6nXY6b2xyBHqB2iQQdiGzjSS+0/Ra0tHm542x+MqpldX9Ro9/pB9ba7gD o4s7K87IpMDe3a3gCAAhOsx3clp+MKrzXLHOYSB4DC/sPRm5Dno8tKROI5Aa4T2kOtfVzasl1jGs YRzsLW67vNv8ZOnPHG/jdQuxsexmw2MIDQxoJdqXHt4zqqItpaIBAHgE/rVfvBPGAkS4yDxcNcI0 HD2Hj4LeY5vjlH28ZgImZJNcUjPufp1s+Lf24uTbstcKa6QwUbXNZvc4EluvifzuBCzmkvG7T5eW nZO62lxlxDj4nVIW1AQCAAm8ty0sU5SM7jIbePf6I5jmo5cMMYxcMoEeryFH/G3LpdHuZRSRa8es HbnEBlYsaYaNXn83n6Q/8jDLNWRmBjHy1zTW61wAB3bhPtDdADA+HyVD1qv3gl61X7wRjykRkMxI 0eKhvrLez1WHmskoiJgNCLI00j2A2bf2LFwbHODi8FsB7XaDxJ/BVhZLXMaNgOscTJnd96ibaTyQ UjbUYJIJHHzSHLEZIz4vlqxXzefl0Zjz14Z4jjl6walfy6dNOv6Xgyuy8WaW3jflAhtcks3s121k /RcJ/eBgfR1IBH6luRjt6hfdS3HrZPpVmWCxzWucS7/Se5w2keTS4ky5socCHEEOEEHWR4KDW4bS 1zWMa5ghpAALQZ4+9CXLTu8eTgHFxVw39GuM0TrkxGU+Hh4r6JIKv/aq2XOdU+xjX1MqNgAbY017 NQA/WdniOfLWh61X7wS9ar94K0QDuwRMhsG0+9jrC8GwHdWRB2bvTaQ555h5OveJPKIMqr16HvfZ aKX73WvA9Qj2kMgvOg2+Pc6eNH1q/EJvWr8QhwD8K/YkSn263+1d20OO2S2dCRBj4aqJS9WvxCb1 a/Efenoo9n//2QoNCmVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBvYmo8PC9Db250ZW50cyAxNSAwIFIv VHlwZS9QYWdlL1BhcmVudCA3NiAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9D cm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgNTIxIDAg Ui9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDIgNDkgMCBSL1RUMCA1MSAwIFIvVFQxIDUyNSAwIFI+ Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5IDAgUi9JbTAgNTMwIDAgUj4+L1Byb2NTZXRb L1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA1MjMgMCBSPj4vUHJvcGVy dGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDc+Pg1lbmRvYmoNMTUgMCBvYmo8 PC9MZW5ndGggODY4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiYRV2W7bRhR951fcx7ao hrMPBwgCRLJSuLC7iUAfXD+wFG0xiUhHoqEkX98zM5SqqpYswxpuZ7nn3qHyd5uhfajqgd68ycuv Tw3lv1WPbVcNbd9RPp32X+hOOiYVGc+MEGRswbzzviBXSFzh3tN9/m4YqnrVLOkuL/snAPth6NeU 3zQPA+V/tI+rge7fvp1ezSjLf51RfjvjlM5mC071ljjTpigkVouPw1rgXBFt6y4T1OLJn/Dk4zYT 2jFdkBWMw4+WnBz+N032kH3OjMXNaG+8PzH68MCfP1CXBGcL4vGPFrNfMs6coR0VdIsrH0jQz3R3 z2lJ57UW2e+AeS+FhVXutQjWudNGJMvyGCg845JEMdq8WGsCahmRAZWw8oCVWgkVxIz2MTYse6Tl nKNHOoDDkShY4fE5xnMrnQZQKCcNVuD5f7SlPtHe+xbBMZyK/5WadK09r/s54yQM3BunPE2cZU6H J3FV46pEVD6ADdXrLL9ec7rqkTGoaJSxPpgT2sRInSTpRu75LQYpfuWLVYUhxjDfzq6vQD7OXFRX knFtITUximk+qktYRaOUOFYXSf0lTnnMKWEq1OlQUcwqyCBS0l4d88nEZ1XsbbjH4xY6LeJES+21 xmENMUzLLC9L6FAZu8m5wmFNk8PxLjxabgmdwPoNZ+UGX0ozSE7SAjx3TMQQvGRwgW6W6+y7627Y 9MvnOr4Ahv778kN2AarC/kDbE7ZstsPfeAkEEDyKvUfpUTUs8uQNiSOpSVqO2bQXGGeEFsj+ktK+ T/JnAUYpVgiLcQ6IeXh6Xo5J3kz75ddDkuKQJAv7Lu49rrw6zlSOfpPVU1HPQ/EFP8oKFk1yeOjO v2WnfshIFo7sy8UnWrxGMRl4r6YcVw29n1O7xWRUn9pviPR523aPVHUxW3jXDoQ87GKEO26Qc+Qg ZkoXVkXyalk9DWC8abvnL5Fusvd3rkNSamZcYX0s3zqf8v7YbLrm00kAgUtw8QqPsGHXWZ8s/Ui7 VVuvqH6tvsukShlmpTFpfh76za7aLE/spVpDzqktQr5mVRvDVIHflcj6VNUfm2GLTiwvWU0y+kKk psCPauFNilT7ZLru1+vnrq2roXnRuBCHeTKv8EoXLukxjV07rGjAXM3mjI73yT8CDABnCcKnDQpl bmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqPDwvQ29udGVudHMgMTcgMCBSL1R5cGUvUGFnZS9QYXJl bnQgNzYgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1 NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDUyMSAwIFIvQ1MxIDUyMiAwIFI+ Pi9Gb250PDwvVFQyIDQ5IDAgUi9UVDAgNTEgMCBSL1RUMSA1MjUgMCBSPj4vWE9iamVjdDw8L0lt MSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0wIDUzMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNTIzIDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNTE5 IDAgUj4+Pj4vU3RydWN0UGFyZW50cyA4Pj4NZW5kb2JqDTE3IDAgb2JqPDwvTGVuZ3RoIDg3MC9G aWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImEVV1v2zYUfdevuI/bAFP8pggUBWqnGDI0+7KA PWR5UGUlUQdbqcW06379DknF0Tw7kWGRknjuOffcS6l8tw/9bdMGevOmrL89dFT+2tz1uyb0w47K 5XL4m66lY1KR8cwIQcZWzDvvK3KVxB3uPd2U70Jo2vtuQ9dlPTwAOIQwbKn80N0GKn/v7+4D3bx9 u7xYUVH+sqLyasUpX63WnNqRONOmqiRGi8NhrHCtiMZ2VwjqsfJHrLwbC6Ed0xVZwTj0aMnJ4b/v itvic2EsHiZ50/OF0YcFf/xAu0y4WhNPP1qvfi44c4a+UkVXuPOJBP1E1zecNnSea138Bpj3UlhI 5V6LKJ07bUSWLOdA4RmXJKpJ5ou5ZqCWCRlRGSsPWKmVUJHMaJ9sw/CEtJxz1EhHcJyJilUexxzP rXQaQKGcNBiB5//hlvqI+0m3iIqhVPwv1cxr7XnezwUnYaDeOOVp4SxzOq7EXY27Elb5CDbUbovy csvpYoDHCEUTjfVRnNAmWeokSTfFfn+FRkqncn3foInRzFerywsEn3ousSvJuLagWhjFNJ/YJaSi UErM2UVmPxVTzmNKiIp5OmSUvIo0sJS0V/N4MsezKtU2PuNpCx0nccSlnrimZo02LOuirGvwUJ2q ybnCtKXFYf41Lq1HQiUw/oOreo+T0gyUizwAzx0TyQQvGVSgmvW2+O5yF/bD5rFNL4AwfF9/Kl6A qrg/UPaMrbsxfMRLIIKgUcw0iqSRZ3GwHFYt8jAPp71AP8O1GO1PKW2mP7veCMeM8WjnCFi/tloZ plATn1Zvm3342Icxgt7Xk/0flsPm28F+cbCfxc2aNixXXs0LIackc3rH3J5Hxyo+MxhpmSz0UNJn rxZzs+LUnHYsxxVcILDQk/v3HY3zrM7BFI/tL41KsH6kxxFFC0OqG1LUjtsojgmJ91qWmIXpF4qY Y2ttmVKoXIp91+26fRO6o3zPgQ2MQgtgO0bwl2bfD49jUpXp7ZMtSPykCCk1M66yPluuuEuRooSR hlt6aNq/ujBSs9u8lOzpDJ+DK6eYFVplA7ddMz7uj3OcGxZnzr8S1HCJD6uenAso5kH2q3WR5+si TYWvd+XNkSVd2/Vfus1J1fZkMz9HkthSxiuR9+lkKptvpH8FGABFxtWTDQplbmRzdHJlYW0NZW5k b2JqDTE4IDAgb2JqPDwvQ29udGVudHMgMTkgMCBSL1R5cGUvUGFnZS9QYXJlbnQgNzYgMCBSL1Jv dGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNv dXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDUyMSAwIFIvQ1MxIDUyMiAwIFI+Pi9Gb250PDwvVFQy IDQ5IDAgUi9UVDAgNTEgMCBSL1RUMSA1MjUgMCBSPj4vWE9iamVjdDw8L0ltMSA1MiAwIFIvSW0y IDUyOSAwIFIvSW0wIDUzMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9F eHRHU3RhdGU8PC9HUzAgNTIzIDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNTE5IDAgUj4+Pj4vU3Ry dWN0UGFyZW50cyA5Pj4NZW5kb2JqDTE5IDAgb2JqPDwvTGVuZ3RoIDk0MC9GaWx0ZXIvRmxhdGVE ZWNvZGU+PnN0cmVhbQ0KSImkVk1v20YQvfNXzLEtoOXOfi8QBIhkI0gRNW5EoAfXB4WmLCaWqFAM EvXXd3aXUmhVH4fKsFak3ps3M292qfxN29WLednBq1d5sdtUkN/Nn+r1vKubNeTjcfMD7oVlQoL2 TCOCNo55670D6wTd4d7DQ/6m6+blsnqE+7xoNkRsuq5ZQf6+WnSQf6yflh08vH49vplAln+YQD6d cEhXkxmHcgucKe2coNXQy9Lq6FoCbMt1hlAT8i0hn7YZKsuUA4OMUz5KcLD031bZIvuaaUNfxvT6 70daHQB//QbrJDiZAY9/MJv8kXFmNXwHB1O68xkQfof7Bw6PcF5rlv1JNO8FGkqVe4UhdW6VxpSy GBLRMy4AXZ/mxVoTUYnIDKzEFQeuUBJlENPKx7bRsmcazjl5pAI5fELHnKfXkM+NsIqIKK3QtBKf v9AW6kh7nzeGjClT/E+pSdeY87pfMw6oKXttpYeRNcyqgKS7iu4KapUPZA3lKsvfrTjcNNRjCgW9 jPEhOVQ6ttQKELaPfTulQYpv+Ww5pyGmYZ5O3t1Q8H7moroUjCtDUiMtmeK9uqBUySiJQ3VM6qdi ymFMQUmFOi1VFHsVZKiloLwcxhMpnpHR2/Adj1vouIgjLbXX6oc1tGFcZHlRkA4U0U3OFRRlcIQj ffoecMUWyAZa/6GroqU3qRjpjdJCZG4Zxg44ar7lZGWxyn65/bGp2npVrbvtr8Xn7AJNeMeMU1JF Hp0VRbXtPtEBEHiUH+7zE54qDvml1Kjb1KVRWoYBldeEpYaFeKO7JH8WraWkjPZpf7uG1sg8Gkzo 9hrahNiWNnRAb66hHTKDVvjUiGtoHzYGGhnR2ytog5J2OzcmoquAvi36QXk/bh53h0HBw6CwcKzE o4VLL4cjI3pLkhvHop4Hi19Mw99C6JThYfiGzqbJO2VqioUcKRiqFGyyrMov0C0rqFeb5yrMWHrI RAVmlOUm6DCkiel3fJxpvDA9SYjO+3AS62TYopqf6WtCa+mYNvQe0fWn+rnudkdlDrbVmShGGCpO mjSvzQLefpzeXTBI/F+DhFBMW2d88khye92jUaxD4v58CJwTbfwZOlkmfYo9+da2ZNPzDjra3PVi F+275NeV8FQvUyj71m+7dt5VT3W1PdH9sJ8uxgrPOI+hg9H0pqUTdnbS958coxWzjotU3vwa2iLT 9IBPCuEHzpe++POd1I5+KjmvX5q0aZuuKuO0b5rnutzBcFL+FWAAmsMTOg0KZW5kc3RyZWFtDWVu ZG9iag0yMCAwIG9iajw8L0NvbnRlbnRzIDIxIDAgUi9UeXBlL1BhZ2UvUGFyZW50IDc2IDAgUi9S b3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVz b3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NTMSA1MjIgMCBSPj4vRm9udDw8L1RU MiA1MSAwIFIvVFQwIDUyNiAwIFIvVFQxIDU2IDAgUi9UVDMgNTI1IDAgUj4+L1hPYmplY3Q8PC9J bTEgNTIgMCBSL0ltMiA1MjkgMCBSL0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h Z2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDUx OSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMTA+Pg1lbmRvYmoNMjEgMCBvYmo8PC9MZW5ndGggMzEz NC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSInsV9tuW8cVfedXzGMSQIdzvwBBgFi2CxdR m1oE+uD4gaaOJBoUqZC03fTru/bMnJk5vEgO8tCgqA2b4tK+z56910x/3O6Xt/PFnn3//XT222PP pj/P75br+X65WbPpixebf7F30nVSMRM6IwQz1nfBheCZ8xIID4G9n/64388X9/0NezedbR6huNnv Nw9s+lN/u2fTt8u7+z17/8MPL15essn075dsenXJWfp2ec3ZYsd4p433Ep8Wfxw+Pb4rxnaL9USw JST/Asm73URo12nPrOg44tGSM4d/235yO/l1Yix+GcPLv78wugj88zu2Tg4vrxmPf9n15d8mvHOG fWGeXQH5yAT7K3v3nrMbdt7X9eQfUAtBCotQedCCQudOG5FClq2iCB2XTPgc5pO5JkUtoyZpJV1Z dKVWQpEzo0MsGz4GTcs5xxlpUqafhO98wJ9Wn1vpNBSFctLgE/p85FvqA99D3IIiRqTiKNXk19rz fn+dcCYMojdOBXbhbOc0SQLVQCVKFUjZsMXDZPrmgbOXG9QYplh2YwMFJ7SJJXWSSZdtv7pCI8X/ ptf3czQxmvnq8s1LGM89F70r2XFt4erCqE7z7F0iVByUEq13kbyTmoRfSsUh6FgOsoSqMR1UqyKT ipShs5IpVMCiQDCrELQPuUQx3t/Vgs8bvD6Zuxhyz16ohC9mk+lshgTYLHYCp0rOFvj17AvJzHYM x4fPfxO0pVQ9u8A/lAFnh1ulkLp2HC03e5h8M9vO17uH5X7fb6dv+0W//Nxvv519nLyanQxJ1pCQ nmKyiw2IzOmnfOOC6wwS5AJVx//sYWK4xgCK3VTQVYM6HKxzglugWb2F7s8USA3RHFUFCceioCMD 5R8/UAJhO2URBOah4zgLKsHrV5Rw1JK5lqVmwikKRgXRWWoUkr+M8hex+C4cKEiB6nqOsLVQcBqC Sk4en6iqHvLQCiMal8x3XKXKabRJMLFyBV01qEVv0wQPhEbtFjlXOHOycCklGTPqhLYh9VTJDSOP rrmwBn2ci/H6FYvVO5YKkLJOpfSvNjf96oykNCiuNVpHyV++mX/YfNqz/X3Pbvrb5XoZF9nmln2e b5ebTzv20+sXu9OWjLGdVt5GQ/P1DbuZ7+eP8/19Eq/XpCpiIHgRghln9eV+ubhni8163S/2O/bw abVfPq766PqXb584SVtP0uctJgXuu6NZjNMUdE0GVOR7oPFzOs0oKwbM6wgYc0rMFxQm4xwhNLiM Nu5lJwy5TyhNXUClkwBlPy4cSIlOh2NzQzbUXdTjEiC3nXG5Yblq4ikGSFDG+2cCAbftXpCeZ0Yi dMih5SkpDN3cvLvqRP0KhdOd756bqRejoVoaRXHZKY0u8Z1RuUuuiS99WqWB2ahVE+NekyqWWmJC SPCOaONtf7Pcosmox5fr2013tlUVnRQqjVHraPkFmSb45Wa9325W7GF3R7rIROQ5eEpXEfkr3rsn WtkPlVIS7eKo77SgUZ/PGfXWZoyuIupigxNqVUV9glRpslaQA1UZrUaHHh0HUNF4Q1p1gtC5rZ9G yp40N0SOZk6cAA1EDa4oR82bcGroUY6bDjeSHzezG2azwTwWdeEbQx0UW/l5mdPdG34HIzjThQoL WMnIMcGhUJJMBK52dx06EDzgcdvvnyQBopCyUdpuqCq2qxfUIxVTHuTMUFUp9UQsFd4jqabSK8q+ Aot4bsKNxejoNFZFAyk5PBaqh4oNkZC5gimdZ1U2prE0pErGBp8VW0xycBVaTWoOFW3yLx6Oa7KY 3H43OUoXlfIWE/2wKmCIh9UrWLXYYNVzsddEeJjI4g8l8gcOFzVAD12hdT6y/zfOV9b7/k/UN2fe K88+WNJMUuLkfsOGdZE4KFAxrobB9Ia24vTnzWq5+K0S7+MFjUNBDcBGFIpneMg0kCjgh/muf2qe lVeNDDKmigD8UOEEGXp6Ch7HPUFgqwTh9ZO+O5WmOYRdhhJBaaQUeHkcvCNbA1qdtuqEmrzeqp+I 0uyu0RwKjtKg9SbxrqLlaG0XRNrhjUEcbnHuXT6IKhsNFBwMKD5twsiG0aJJKzqrgrQkPa48x5V/ 4u1I5IhYHQ5zCFJjXacKVXTVoI6Hgmb1Fjr3BBJnHo+H7zkwJzwOMAVcqE+e69X8c8/io+bruJ90 kgiYdqB/GAGGa1u37n7DPvRs169vijHVGFPHxkCmVfCOWXoIlBX+tl/0y8/9DVHBp5id0Cf2NzoA NfF0xanomCagTQOwGgDML57eJxaXLA6PE1Cj5kQenw1mVe6Y9knb7oSG6f+3w6L20Ubn2+iUyQOV YvFEaiu0GiBrwel46nq6QlaegkaKbiCaI9RKukTOuHKvUKU/UTRUHOy9gSODEacF8TARtFvSDAGf 1nkutWjl01IMZPgcWi1IDJQ8Lou3VlYFU46uscChldEmhpNoa4F68n84PTq+ZlNLjTmMmY2Zwjn1 18MAWd5M9gHCByiDZVLHaYQ4LMdPkjSlBqFovoNsoOXwsqnQaoBM8OirDEW9MWKp68YRRKjGGZcT brkgOZdViRvx2OytapIyQZco8BjTpnOgH7YTIu/8iEhyIPIRIEmNvITK04KYXKroSYwjg4RlxQaI 9RsAiaVJ30J+iObvxTUqF5EaXsxW2RiyqjQl+VHC1RYzPCqqstmRawh5GI5YZEElDcbCIoCKAZUm tx1Qih/Q0F0S55Um0ljQZyo5NuqPCGtrgVCrRq4Ico33FNOh4GFWVCZwyE6mA8H+NaJmSxlgniGq qK5zB1cxKlazHRUom8lcGX6jiBJEsoR2XYg+tn3Dcb5W4ww5Mc8xaX6SQhvwQIMLHjh6ofCLu37d b+f7zfYpTmAHj0oX+qd5LvFDg0qpyrVoUZEPSdH1TNUEG3PpgYQLlfZtxdJTDRe5QqsK1enX6rao Go52FM+A1thjI0iNO2UziwCMKTPSo9+DmA1hjM8eexRzROjYL5EWd3hcCA9Yp1N/VuTMMbvnj7ke rrOdEpGz4Cc+sNFX68X8cfdpNd/38XxPakiPZvQu88TNLStEU1aeKQ+7CRwelxIkXTjdeQwSF9W3 /c1y2y/2y82aLelx9lRb+dJW9MJA7CEeNrvABBM+nhTOAhVScnjyCF8OCmMx07SgMp1r5ELIM/X2 tO9wmuG3z8eDjFVk6QgqxJ1hMq2u+R4Q9PHdo1jx/hTC08uGVJ8h4pKX6mDgp2lhsQJ5uXQmL5SK pgtBbyqSVeWdQ2iiA4TazO4qauhFFhd2a4FQkOFiIXmLaGNXmVOyaWQe2s1U4CCGIQtFlVmN0m0g Igj4jj5L34lntIaqSMn6RN3ihcfuS3glE209DW5mjTryhJZ13E5oaIOJCBxqfugqF71XaBWhRNcI LWGCPqcOJbRE2siaTpgBiyYNcSni2Nlr+z3N0qpEWNqgrflWsoZymEUsDXZcPlBcLzwikRpWYU6t hlukwDOJQJhYFwWCxdNaM7bw4YqObACVhykDazNUUiXS2QJpwzdKhB2bbySb6g8Gm2PKPsfIcQ0r WnNLaKosrdaQeUyySYh3Fcm750DusF5pI8n/MF81PQ3DMPTOr+gZqShfTlquCBCHSRP/YJoKQ2xM 2sb/5zlO0nZquyuntpHj2LH73nO5m3y/hygaUvB9lsVQyjUHd6aQyYC7fFSFrgmJ6phbgxLSmnTS zDKSGcCnEfCzCBP4Jw9VYbSQDmcAD5gbIwa+vq/WjxE44cSKEyEcH73gjTONSGyaB/iu5TFwaLQB m6vEXy/P1ea03X1dAMq/p24EsOs+FX8L/uvyPmIBcixXW5CV5xFLK+fjsU/Hn8vpuK/ewHkpHb0g xno3AcrDuVYU2SIf6IkSknHxFhxUIU98TAzENJO+9vKFG8p6nCyljp1Z7XcyPjRcz+GaBtm3bQDt U2nDj/s7raBtNWvb/xHSbkZV4Qe6oarqYRNPFEwHZrrcbuvN9ru7nJfqZvOJZG2KnpWszF01Kxye +lzS/ASlqa6MDkiHrzVt9jqleYjJCxJbJJ9pmWyTfRTbWWRw03/CbP42NBg2k/xZdefz5rNbzJ/6 /IFTSE9bibyiAP4uRcQvzwuZTvrUCAoTMKCyoY/ddW0bNPfA2GVakzNHm4EiEweZSPyDeMZmvSeu h+d5jQKDz6gSBD2dQ4CNlbCiWSnCnwADAN0Lp4sNCmVuZHN0cmVhbQ1lbmRvYmoNMjIgMCBvYmo8 PC9Db250ZW50cyAyMyAwIFIvVHlwZS9QYWdlL1BhcmVudCA3NyAwIFIvUm90YXRlIDkwL01lZGlh Qm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9y U3BhY2U8PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDIgNDkgMCBSL1RUMCA1 MSAwIFIvVFQxIDUyNSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5IDAgUi9JbTAg NTMwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dT MCA1MjMgMCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDEx Pj4NZW5kb2JqDTIzIDAgb2JqPDwvTGVuZ3RoIDEyMTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJrFfbbttGEH3nVwz61BbVcu8XIAgQK26RIu7NBPqQ+oGWaFupRToiAyf9+h5yKYZSJMpJ a8OiRHHOnDlzZnedvtg0q5t80dCzZ2n28aGg9Lf8dlXmzaoqKT07qz7QG+mYVGQCM0KQsZ4FF4In 5yXu8BDoKn3RNPnirljSmzSrHhBYNU21pvR1cdNQ+sfq9q6hq+fPz17OKUl/nVN6MecUP80vOS1q 4kwb7yWuFj8OV4/PiqhelImgFZ78CU/e1onQjmlPVjAOPlpycvjbFMlN8i4xFl929PrvZ0YPD/z5 PZUx4fySePdLl/NfEs6coUfydIE7b0nQz/TmitOSjue6TH5HWAhSWFDlQYuWOnfaiEhZjgNFYFyS 8D3NyVpjoJZdZBsVY+UQK7USqk1mdOhkw2UbaTnn6JFug9t3wjMf8DOO51Y6jUChnDS4Ip7v5JZ6 L/eWt2gZg6n4rNSY19rjed8lnIQBe+NUoJmzzOn2SdzVuCshVWiDDS3WSfpqzellBY0BRX0aG1py QptOUidJuh77/AJG6l7Sy7scJoaZL+avXgK891yXXUnGtUWqmVFM8z67BFU0SolxdhGzH8LUY0wJ Um2dDhV1WrVpICnpoMZ4MuJZ1fW2/Y53I7RfxF4us83Vm7WV4SxL0ixDHsq6bnKuKVtQ985Q9tg+ l9WENuD6Dz5lG7wozZBvFi8I5o6JTgEP8R1HK7N18u35h4dis1oXZVN/l71NJsJk8Mx6rXQXh7Ui K+rmGgvArA0EQREJzkYMIznoDZ1m8TKGNMIwOKSnclk0zaq8bdHOs16c12fV8uMgjhjEYe0odePE VVBjmWQvU8y/nzrwtqwdBf6S0sTSB8H3i3FhCk1wATihI1x2V1AHx6x23LagTEisFhF6kpfANAkd gu2Q6nW+aa5X28YM7HpOWwtgMg6qHCEVV0z64GPXbouy2ORNUVNeLqkuymU9RfZ0K2MSCwWwRMmo wKJar2GPiBuZHgiVUjPjvA273VjmTU4P+eLvYrLuE5ASW5bwwfgOs631iVVuuz2JrnDLgnFs06ZY rjbFots+J9ifomydZxrLh+lAm6pjvFPyfqjx2KRR5K6AP57XbGKE5H8dIRkE88pZ839N0SfALxsk QErsSycgdyZqfv5Vo/QJTnIDo3Phv3qauiE5auAhkcHYGid6NzzUxftldYi7OCWAFYqJILTuR7Ns NtX9yFtmsP1h1yuJinH629s2eo8TfNoajiYcp77YcZGHjDxkzwMbeNw0hLBP9d3YdqPN8jg0zgvO dc8B+gXKm/ZgbIF6CmvJMd44dfVrBlyzvz60BGXfzaMoOJJ7tCOiVDenBmSwx1FAD1o82Amf7Y4I 8kwXqpxmWM/EruG2flnkJV0XJ1j3pjyRyKoWInA/TnRfLA/RDydkcBr/2GjfN/6HYe/CUX+7NBzx Ds6AWF7QkM6W1ovYmseC3tcFRUGpJzfsiObzveYYrLKGGe5xhG1hBx1XZd0U+ZKmLbC77k4nMphv ZX2/ZWKs1KbI7785pKY+rOYAZXHo99wr9dmaMzL5eLndBdJYZD0O62pP023tN9WGcGjFZZ2XiwLq rh/yzaquyt116F8BBgDUVUtUDQplbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2JqPDwvQ29udGVudHMg MjUgMCBSL1R5cGUvUGFnZS9QYXJlbnQgNzcgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1 IDg0Ml0vQ3JvcEJveFsyOSA2MiA1NjYgNzgwXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1Mw IDUyMSAwIFIvQ1MxIDUyMiAwIFI+Pi9Gb250PDwvVFQyIDQ5IDAgUi9UVDAgNTEgMCBSL1RUMSA1 MjUgMCBSPj4vWE9iamVjdDw8L0ltMSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0wIDUzMCAwIFI+Pi9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgNTIzIDAgUj4+ L1Byb3BlcnRpZXM8PC9NQzAgNTE5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAxMj4+DWVuZG9iag0y NSAwIG9iajw8L0xlbmd0aCAxMTA4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaxW227b OBB911fMY7tYU+TwJgJFgdpxFl00e7OAPiR5UGQ5Ube2UkndNPv1OyRlx3bteIHGQURdOGfOnOGh lL5r+3pRlD28eZPmj/cVpH8Ut/Wq6OtmBel43HyDS7QMJWjHtBCgTcacdS4DmyHd4c7Bdfqu74vy rprDZZo39xTY9H2zhPRDtegh/au+vevh+u3b8dkEkvT3CaQXEw7xajLjUHbAmdJZhjQa+lkaM7qW AF25SgTUNPMXmnnbJUJZpjIwgnHio5CDpf+2ShbJl0QbehjoDc9HWm0mfPwJVjHhZAY8/MFs8lvC mdXwABlc0J1PIOBXuLzmMIfjuWbJnxTmHApDVLlTwlPnVmkRKeN2oHCMI4hsoPlsrTFQYYj0UTEW N7GopJA+mVYuyEbDOtJwzqlHygf7M5GxzNFvO54btIoChbSoaaR4vpMb1V7uNW/hGRNT8V2pMa8x x/N+STgITey1lQ5G1jCr/Ey6q+guklTOB2sol0n6fsnhrCGNCQqGNMZ5ckLpIKlFQDtgTy9oIYVD OrsraBHTYr6YvD8j8GHNhewSGVeGUo20ZIoP2ZGoUqOk2M4uYvZDmHIbE4mUr9NSRUErn4YkBeXk Nh5GPCNDb/0zHiy0X8ReLrXONSxWL8M4T9I8pzyQh25yriAvfUe4oLMHPy/vgNpA4790lbd0kIpR vlEcKJhbJoICVjGiQK3Ml8mr6bf7qq2X1arvXuefkmfC0CEzmZIqxNFekVddf0MbgI8jfiLyGwWC uCbITSRImtPNURy2YVXmGDqSzaNeIZpI4+h8LTSTzuksBMxOzZaS0RqUYXLV9/XqFq5elc2qZ1ev few0H9rwYdzMHzdtEJs2MG/aYFwundxuCA4NCaUertJxr2LGtwSnEnUkvenvvnhm012q4BlcekzA QkXgj3fVCvq7KvSD6CpLQNy7HmmvipkCPrqTjNFbzuGAfD7dI/w/ezxgZWR8iS5itVVZ1f9UHdwX 5d9V38GipbfGCdpbqjyXyWh6bTnkcWlM9lkHFNpHAswRBPIpSikxIPwcOI12HRcQDnBAVEzbzLjY bhkXtC/sfApdtZp3cEMln+zOmqE/1ScySelYRgccpL3//LjW9WDH9AbZnUDWUtM7X7pYRVGWTTv3 3umbfU02a+EQns5IzoxQ9jXpae+AebUsVnMGz/gQX8SHtPhIJ2t2ebyEE5+QoxmVejkvPmFHO2r1 I27cQguG1O4H/HictETNFH0tiii18WwoTbcs2v6mPrIu3UZmeQIUhWLCKZcNBh38ddJU8slU9kQK SR83gj51IvFF0z4ULZm3aemlPa9JryNF4MGNhXSm1hmzs/IG0ecb0clWvpI9lY5BabKVzLiOYERs Mj24U9nDLpf+Re603KPU3VNpxIr2kB2/B2LDq7Pri/4rabHYyodPu4A6mE+hYVJrbb7bBcrPRdfV i7pq4cP5eHcj+E+AAQD3kdPjDQplbmRzdHJlYW0NZW5kb2JqDTI2IDAgb2JqPDwvQW5ub3RzIDI3 IDAgUi9Db250ZW50cyAyOCAwIFIvVHlwZS9QYWdlL1BhcmVudCA3NyAwIFIvUm90YXRlIDkwL01l ZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0Nv bG9yU3BhY2U8PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDIgNDkgMCBSL1RU MCA1MSAwIFIvVFQxIDUyNSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5IDAgUi9J bTAgNTMwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8 L0dTMCA1MjMgMCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRz IDE3Pj4NZW5kb2JqDTI3IDAgb2JqWzU4IDAgUiA1OSAwIFIgNjIgMCBSIDYzIDAgUl0NZW5kb2Jq DTI4IDAgb2JqPDwvTGVuZ3RoIDE2NjIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFdZ b9tGEH7Xr5jHpIhXex9AECBWnCJF3CMm0IckD7RE20wl0RWZOu6v7+wuRVIKD7mxYdGSdma+ub6Z nb/eVflNuqzg5ct58nifwfz39DbfplVebGF+fl58g4/cEC5AOaIYA6UtccY5C8Zy/IQ6B5/nr6sq Xd5lK/g4T4p7FCyqqtjA/H12U8H8Q357V8HnV6/O3yxgNv9tAfPLBYX4bnFFYVkCJVJZy/Gp8cfg 0+J7AVAutzMGOZ78GU/eljMmDZEWNCMU8UhOweDfLpvdzP6eKY1fBnj192dKNgf+/Am20eDiCmj4 havFrzNKjIIHsHCJn3wBBr/Ax88UVjBs62r2B4o5x5lGqNRJ5qFTIxWLkHlXkDlCOTBbwxz1NQpK HiS9VJTljSyXgglvTEkXwoaPvaSmlGKOpBf2/zFLrMOfrjzV3EgUZMJwhU+Upwe2uTyyvcfNPGJE yr5zNdrVetju3zMKTCF6ZYSDM6OJkf4kfirxU46hcl5YwXIzm7/bUHhTYIxRFdRmtPPgmFQhpIYD N7Xui0sspPAyv7pLsYixmC8X796g8rrmgnXBCZUaTZ0pQSStrXOEiokSrGudRet9OjH2HaUcUXlH DboUguXtYExBOtFVyKNCFZPrv6Ohh469ODYm98bqcvWBOE9m8yRBQ5CEfFK0kix9TiiCSx78uaQE TAQ+/8V3yQ5fhCRo8Cw+UJgawkIMLIbfUExmspk9u/h2n+3yTbatyufJl9mIGHeWGM6cDHLIFklW VtfZyoshPBbhnQV8mK8aoIfqAWLUMVhn8dFVK50i3PljqPUT5zrCGDyvsFGEcyIKXEydFpZoxmw8 3fgK77zcRVLn4P15sXpsc9CkgPiWDW1LhRPdZPA6GcHNfg+t6os3eqgi5ia9A8EbVsgoQ41MRo2L YluhSyMO8Sc7xHk0zaNpzjgyZmhvpvucIVoaqr1LhHHkxmPHgl+iKQp0oI7ZoB3sXWNoXRbn2U2x y+Dr/bpIV/n2FlJYrtOyzG/ybAfv356/qMtgSJ3CgqAI2wV1r9drOMrBYVdR4ybwecY11qmIr7rL 4D5d/pVVJZS+vEaS0bBJjDvrxr3T0MeWhfPJ5yZmQFsZXbl+BG98JAlnjUNtpQ7qdpww7Xhs8XKT 7qrrfE8MbaxOxiqoIEb7+eH1pZjCXbbM8n9wb0DgjX4Cn555Gx3uD+o5OwW0xtwaa6mJoJe7LNse JCCON5+1cNT5QYejXPtWMpy40FOBkY9SJXtTddSkR7C0wllw2CXoc7FbHSDySwvz8yCe9P2AiEJl GeaHYx8cNTga2GjzRkgWTTpal82n5yMVqp9CF8fGHCNWNnVqGPoySXshoLqpKj5ADq3qSA4mZjzB +l9c+L5blbBEMtwVa9hkZZneZiVURWiQtxeQbleQb5FINkgfsWFOIiWBuw3H7YEfuYQq74qy8hZG 2i8Y6WeTVjEXuB8IXhN6pLkA+5DlyHesNdwfrXKFqHFb5XXm+zqNuob55JQ2jtoEk6Lbbd9XuOAY BR1Pc1/WseF4WAm17q1vc2J9DwIUoccNUj0WupoudPsDhS6kJMpSrmtCdvvOOnUkRhrhTfWpfr9a M77otd/cwwi7qbAmmoHYN81Mk1M9oVpQSQReaWJdv5iaKN2+mdKscTXm1tQ8uMqxUvxNsw9vuzMO MUCrVyKbOSSAGPNVWqXN/PVTpunuyRgYrEsbdqqQRSP1nrKbMXXKfOVqZL62RjjOV6FtncPFRV8Y Jlux0SbwHkalqSv94S5fZyelbmwXaLVLga1rtY0hXhabzVTa+EAJNyqVwKxJLexE1k7gZGeIMM7s u0/JemWpctztnpC9MUppbAjcNbjF+2q7FvXum62ExMVHKlpz7vXUaeb/Eyr60LNwNXURi61/7ero wz6RWttYy/vtaoAE3Z4EOzPhkHVHarE1iRuNpXpiKDiHPONJLxxnDNXu156RucDojwwGD9GCxvmA +a/be3QqsCfd/44uaTjsiOFPuPJ1psCArsPb3oes/Loeu+yxH77tSRVCNnDV+/8L3F7vwdXuHS5Q GbYt7ji4rN2lFTxkkG/u19kGL1LZ6hRGE/0NUdtTEkUVtdFeXAz9HbJ8LKts09dqY7NNWrzScMqb +LA43Px2OXkL64y4/obqaNeCON8ggSoft+kmX8LItJfN2OhfNlvNQjG/SKjIwsVN36LZra//BBgA EKrrgg0KZW5kc3RyZWFtDWVuZG9iag0yOSAwIG9iajw8L0NvbnRlbnRzIDMwIDAgUi9UeXBlL1Bh Z2UvUGFyZW50IDc3IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hb MjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NTMSA1 MjIgMCBSPj4vRm9udDw8L1RUMiA0OSAwIFIvVFQ0IDU2IDAgUi9UVDAgNTEgMCBSL1RUMSA1MjUg MCBSL1RUMyA1MjYgMCBSL1RUNSA2NiAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5 IDAgUi9JbTAgNTMwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdT dGF0ZTw8L0dTMCA1MjMgMCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQ YXJlbnRzIDE4Pj4NZW5kb2JqDTMwIDAgb2JqPDwvTGVuZ3RoIDE4OTkvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJrFdbb9tGFn7nr5jHdgFTcx8OUBSoFadIUe+6kYA+pHnQyrStwpZSib1k f/1+Zy7kkKacpKiDmNLxuXznfrj47tjt7jbbjn3zzWL98UPLFjeb+91+0+0Oe7a4vDz8xd5JV0vF jK+NEMzYpvbO+4a5RoLCvWfvF9913Wb70N6yd4v14QMED113eGKLH9u7ji3e7u4fOvb+228vXy1Z tfjPki2ul5zFb8sVZ9sT47U2TSPxtPhxeDb4rhg7bfeVYDtwfg/O+1MltKt1w6yoOfBoyZnD/2Nb 3VW/VcbijwFe+vuF0T3Dz/9i+2hwuWI8/GOr5b8rXjvD/mQNuwblVybYD+zde85u2Xlbq+oniHkv hQVU7rUg6NxpIyJkWQoKX3PJRJNgvuhrFNQySJJUlJW9rNRKKDJmtA9hwyNLWs45cqRJmD6Jpm48 fkp5bqXTEBTKSYMn5PnIttQT2xm3IMRAKp65Gu1ae97ubxVnwgC9ccqzC2drp4kTVA2qRKg8CRu2 faoWb544e3VAjKGKJTPWEzihTQipk0y6pPvqGoUUfi1WDxsUMYr5evnmFZSnmgvWlay5tjB1YVSt ebIuARWJUqK0LqL1OZ2y1CkBivx08CjEiswgpEx7VeqT5/Uhl0mhVSHzJMlDg01dnErqLJlqmaJ0 ua4W6zVgsHVINgeG9ZYSxmFp/SfxrU8MWcLzf/i2PuKX0jUMXsQHhLmrRQhQg9w4jkyvn6qvrv76 0B53T+2+O329/rV6QUz6pnZSeB3kMErW7an7b3tLYoAnIryLgE9nfNz5CBApQSgv4qNUq72ppSeP oPUXKW2EcZbfoIuU91ZF+J/iVk1tBao/cPe+sjdvSPBqPZ+EPgc1NXRoaq68KrMhUzaCo/Muek4h HEUb/pmIuE/uNHTog6ByXpvgAupE8md52HfwJmicg/oM50Sp8rK2vkFRfinKUIAD4Bn3B91jzD+3 bPuw2d+3rHtoWYRuteOWjNVCYuxGk0H5fPUMulWYMFI0QfeJ9tXvj7v9PTt1x03X3n+c+BGUKtGX 5yfBW65pNnkZI/PV3eGIvl+R2ui+7HXZWVVa2lqZJleC4i5oujkeunYbVvLN4XG3/fjL12y3DzF5 fRU+tcenEzvcFWE6Gw+NRe6Nw9oZ2diiPI6HR3Z3xN4mNcsrttluD8dbilB3YN+/vb75/OKJlmW0 LJPlBosCbMJ+Uf2IPgNSv6gX8905nqbD6+Xr1Tixfxu3Ear2lkv3xdCHhGv5KdUj9DfH3eG46z5e XG5OuKr+IT+waJUlUF/gx6QJlPWf0j1y5C1wzzhxZpj2q/D8kSY4rjQxvtKwCKgAcBjVAneLYE+Z pEByik6Zx0oaOB0G/Tx1EH/EeZePwV6TwJLzApeSxCFMdwhtFlw4WM/ZfgNVRoT1N2VZVT3wSjam bvQYbiSVwJQw6ZKdp56DmzSVcK0ew032S7gTllVFRyBcwtQwKmGMFItpJ1LsQMFQhQhRfQJDVIoG zhmuBlJjn3GRFxN1ROptDoIgSTVw2YhMFLoSjgmjHGl7qKSylBmJQ9Wa7BRpc6KAYdM9m9kezxxg /f0V17x63oHYNReCTiPKljcE0eOMFTT/006mofvUnk6b+/b0QmuYbEtxdL/KzubkFNQiokRVZpog omYHhxwRNd7sU15v5vQmahHeQkORhsJakbIC2YR36ltIG+6+UFI5bYXSInOKm9q4CPblzNn5zJU3 VZ862MLAxOmg8kxrb3fHtI/j3Bx4cXCSVwbvFZAwQsTT8zMS7DKkYlCk0UPOmnKqoXMbR809mmoD 20ArOdNkGNgSoeAphk7PVtAKzlX5ahYMGmLRePuJ744a40TTewbehsIrzDCiengj7vhG1gusZqPU nH3lUXOH8dB/LtwIWuGhuPYhK6t4ArbHF9Lis8FhyCjcGyKgRgwtYhgWvcYqbEDVFGpr8aoZPATV q5QAUBGSKckEpUS1Ps0zULXJVOWL8RiT3zPS9HIREykqxvJAdQOvNJkKpKPBOfgU+g3to0XIp9Sp veArWm2aNwLraxepounnxl3s8BCZATHpsGOnnKl9jInNM98heJGrL11n07QYBc/lQV3GfphCpU/D xBq8D5x6FCQiGZVr3ZRjdOJKCJOTz1w/GyZc297lkBoTXbib7yLjVGi+3EO6ljI20dA7BU/unMw2 3zqYK5/VO3K+dUwjERqu4+ZaHzf7evG23f5BvQMVerT8BmGsO4lK0sxKRQEV8easX2g5sOSeQ4bj 6IFlSPNcQ5lqdRrzQy0QrUGKTKIiwwZNyoMwkVAUKgsPjC6HtVDZ03rjI3lF70+iMAOCmKIZMU19 iUWEEydUpsE2tio5SPpShql4wNNkBiobghGlLH1yQSqTnJAjf2PdEVVGZxsqFPquXPoeh9CIJW7S sa5MTUZLWSJZNain7+YZiIJr4kCMhUr7H/2IW5A+PfV4sVt7JI1KuRkYz+16IcfL3gzLXshnewJ3 mkb3G4ks5z3x03a65jnMa47lPmEcbZL/CzAARoT2Vw0KZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9i ajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTQ5OCAtMzA3IDExMjAgMTAyM10vRm9u dE5hbWUvVGltZXNOZXdSb21hblBTLUl0YWxpY01UL0ZsYWdzIDk4L1N0ZW1WIDcxLjc0MjAwNC9D YXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmds ZSAtMTUvRm9udEZhbWlseShUaW1lcyBOZXcgUm9tYW4pL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250 V2VpZ2h0IDQwMD4+DWVuZG9iag0zMiAwIG9iajw8L0NvbnRlbnRzIDMzIDAgUi9UeXBlL1BhZ2Uv UGFyZW50IDc3IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkg NjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NTMSA1MjIg MCBSPj4vRm9udDw8L1RUMiA0OSAwIFIvVFQwIDUxIDAgUi9UVDEgNTI1IDAgUj4+L1hPYmplY3Q8 PC9JbTEgNTIgMCBSL0ltMiA1MjkgMCBSL0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMw IDUxOSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMTk+Pg1lbmRvYmoNMzMgMCBvYmo8PC9MZW5ndGgg MTA3My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUVttu20YQfedXzGNTVMu9L7cIAsSy UaSI0zQi0AfXDwxNSUxNUiYpOO7Xd3aXkilWkmMZFiVyLmfOmZlV/L7ty2WW9/D2bZw+bQqIP2er ss76sqkhvrhovsMNN4QLUJYoxkDphFhjbQIm4XiHWgu38fu+z/J1cQc3cdps0LHp+6aC+GOx7CH+ Uq7WPdy+e3dxOYco/mMO8fWcQvg2X1DIO6BEqiTheNX4MnhN8LsA6PI6YlCi5W9oueoiJg2RCWhG KOKRnILB/7aIltFDpDQ+9PCG5zMl9wZ//Qx1SDhfAPV/sJh/iigxCh4hgWu88w0Y/A43txTu4HSu RfQnulnLmUao1ErmoFMjFQuQ+diRWUI5sGSAebbW4Ci593RewZfvfbkUTLhkSlpPG152nppSihpJ 5+w+sYQkFl9jf6q5kejIhOEKr+hPD3JzOcm9w80cYkTK/ldqyKv16bwPEQWmEL0ywsLMaGKks8S7 Eu9ypMo6ZwV5FcUfKgqXDXKMoWBIo60Dx6TylBoO3Ayxr66xkfxbvFhn2MTYzNfzD5cYfOg5n11w QqXGVDMliKRDdo5QUSjBxtlZyH4sphzH5AjK1WmwIs+VS4OUgrRiHI+HeFp4bd0z6kdoWsQkl9rl GprV0XCRRnGaYh5IvZqUSkhzpwhl+OnR2aUdoAx4/Re/pS2+CUkw3yxc0JkawjwDCZJvKEqZVtFP V983RVtWRd13b9Jv0Rk3bhOiEymk98NdkRZd/xUXgPNDfCzgm3mAygMM2JBupGkWLuOI0irCrbPF gLOQ/qSxYopgGwvura9fssYO06i89dZF35a5r+8qHVj/eNHcPe1ZZ3vWiZtRP6dUWDHmnw/8h8qm mS11fB1Q+zfnKsDcKzmlaa8jNfY4WSEuowwDMxkCXzaL4+UPxloR3Fky1J6dNXULnVsTTN1G/weW La7xfl1gj96VbZH7c2GDT4q+gyp78no7dg3VrjLCOO7CUJ+vCkf1pPicS6JMou0hVXlTr7CbJmzN 9swMzc7ZC0EZ9qiyVIcedUXkTVVt6zIPx1u+zuq6uD/TCfzVnXAUkUrwAE2senVHCPbcEi+EPmyK +bZtcYrvn2Db4VDiVC+btsrqvIDK9/+vXtSXxDs3uc+p8QxDnpkJo3vfdJ0PHCLs9J96W0YSYfSE kzbriwkndLrdTkZyR4NGHpKwk5a7PiUAZzQWr9LYA+ABAA8ABB5cmJzpH9V2Ii0iPhcXTy1j6LAX P48m7+tZ/SbT4vxP5hCME6YtYzsBeyhr3yCPWdmX9QoetsW2CLKOpXHo7cGAHwuvqSLYKCYs68d1 UQ/AEdYzQHk8AmqaSMrNhOBhR7gxxhNzU9SocoqAq6YtPPLdjnLV/DJq9h9ixXD8lUXdT5+DpD54 hydks+0g7JM9ihIBjLvsPwEGAIrgjvoNCmVuZHN0cmVhbQ1lbmRvYmoNMzQgMCBvYmo8PC9Db250 ZW50cyAzNSAwIFIvVHlwZS9QYWdlL1BhcmVudCA3NyAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAg MCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8 PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0ZvbnQ8PC9UVDIgNDkgMCBSL1RUMCA1MSAwIFIv VFQxIDUyNSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUyIDAgUi9JbTIgNTI5IDAgUi9JbTAgNTMwIDAg Uj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA1MjMg MCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDIwPj4NZW5k b2JqDTM1IDAgb2JqPDwvTGVuZ3RoIDIxMDQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ nFfbbhtHEn2fr6iXAPYCavb9EsQGItrZtWElikggD5YfaGpk0ZFIhxxE8X79VncP50J2D4crwxqx WZfTp6tO10x+3lar+8Wygp9+msy/fythcr34slovqtVmDZPLy80/8JEbwgUoRxRjoLQlzjhnwViO K9Q5+DT5uaoWy4fyDj5O5ptv6Lipqs0TTD6U9xVMblZfHir49Pr15ZspFJPfpjC5mlKIn6YzCssd UCKVtRyfGn8MPi1+FgC75bpgsELLf6Pll13BpCHSgmaEIh7JKRj8vy2L++KvQmn8MsCrv79QsjH4 41+wjgmnM6DhH8ymvxaUGAXPYOEKV74Cg/fw8ROFO8jnmhW/o5tznGmESp1kHjo1UrEImXcdmSOU A7M1zMG9RkfJg6f3ir688eVSMOGTKekCbfjYe2pKKZ6R9M7+L2aJdfjT9aeaG4mOTBiu8In+tJeb y4Pce9zMI0ak7GirMa/W+bx/FRSYQvTKCAcXRhMjvSWuSlzlSJXzzgqWT8Xk3ROFNxvkGENBnUY7 D45JFSg1HLipY7+9wkIKvyazhwUWMRbz1fTdGwxe11zILjihUmOqCyWIpHV2jlDxoATrZmcxu3fj mNdvxSDoQIePhKyBdKLrwqNLCoZUexwqHq41NcFHuzj01HvPulw9EZfzYjKfIwyYh/OkiGG+9GdC sTDmz95uvgM8CHz+Fz/Nt/hLSIJdcREf6EwNYYEDi/Qbioc5fypevP3nW7ldPZXravdy/rUYcOPO EsOZk8EP1WJe7qrP5d0JN+kU4ZZj1Xu3W861d8D9sLifi7Ah45odsbijbEDFJVG+AQ/ww7t3PvLb eU3sdUMq23Maiewl9unqxDImxrL0ieMDy8FwgnvGzbekXS+Wf5YV3CyqcpfJyZM5Qx7apKSCJXMK ygh2DXf9tLcvfohkZ82xxQmzKNTxjO6RtqvPu9uXGZAiDTLAq4H5NJEGVD/lO1yoUD9Y1j7HtkaE TeYVEe2Up0soi4rh6xRtlsEG98vjKSejaklEE/WVoj9kMMshzG1gp4kTTugaLmNpuJ46x/z10UO8 bRCn4uL2tCDc1caveBasGgfWs6CpFigcnKD+WDPErdT0PG6l1uO41WdyG+CO4LaH+BS3UqsOt3mw 5kxulez2UoZbpfR53CrNx3Frz+Q2wj3NbQ/xKW4VXtjIrYz19cpm0bozydWIwqPlQ+Rq7PGzyNX4 1yhyGT2T3T3eU+z2IDfsMs7S/GqcHTr8sgHE6UspXoZ18AOVx6tQ8HATUx0U2EUiN+tqu3nM5clc RPnoXjBxxqzvV5q+cVprVEJmXNwwEdnt5q6abGCvLR6GHAXDi4aHIU7hyF0f2ci+Dz2OuEN+Aodv MI9DB2uWhZG7GLKBfcFKrutWkC4bOaPhnSHrKAlOOIY5nND6hbUt71bbclmRXKqcAmfjh9KS1umh M22tQ2lJ6k6daU5as5FjbXHBR+GItWXqShzAkRPNbORYW0oP1lZr7WvLUjtcWjwnhdm4sbQcMydK i4+Yow+zSCmI5RQVN1NbEDcdfbV/3bqIj9o3qLBXV8v2vrcvog5raaj2b0mEcf86EN6VBqIIGrTc xH1+iImbl6whR4aF6BiNZZudpvnAzK/z7NTTZ3eoxr+zhzBSSNvQvtiFpFLVoWU29EhtbEOH+mX7 0DwPeqTctZFDTQopY4fqZGd0rPHaZWqv/iYLI62NgwWsUIEtalBz62o7uoCVUgdlP1y6vlCEjxQQ cbZ/OUxExYpUgpqIBacM2OK7KDyunlbVUV133uaOIwnhRx2q5Inazmh9vrYDccI5c1TbWQHlI4W8 DX1Y2/kKHKnNbeh+bQubiyxG6m0beUxtd6zH1bYYEufMxS+pwevHKX1Q22GiTLdc66EsMWpfgZtT 1gavLqrrKnscEv3og8M/t4JQVo/eZ2p+G8SF2qth/uek5jeOgnKiGGVuuC9EWvMj7SrNusVt0OM5 fhrneMhlygl/UnnwqkvlOK0/rNEfvPHSqtHG7qnQevP/iVATTjCcyhijpyjPXFMD12x7qmOlSIy9 sZrQo69ZkZnQ86EPrtns6CdGDuRt5L4UpQfQjnVPivIwMjLuD0gOtYQ9noPyBzRS0NvQ4YC41aeu CjlS0NvI/nyE1TUv2FPZ0GmRHggdDghfmeTJ0ENCxE+w7qwn3cbGu8EmvogygQeW1rC6adGj53q5 2JV3QcBiXhFnqroznxNxuPVxUGl6cW5fPK+qB7i5yYqATKthT3dTCUMxayr6+a63q812VX1vtp19 ncFpybuzxL5zSNNyFZGm9Urg5S+YM7yf5ZfpL7NekumMwnQGtc7Opr8WnOCo/QyMwhWm+Qoc3sPH TxTuoODSEWwrx4jf3NP+s1F+wcvvYzErGHjO3kMhGCU2NH3j0C51fQSWZmuCH7pfSmXwjasXpV3q Z66Re8CFf9HFV1Mcfhq3dqnrdrinI8fenmprIf1cwbApug7tahNWSpUwbFcbQyX3kLqG7WpjqPFx bNiuHhJxdEY5IpInh1YJ/O0qHh7G5+Hu7dq2q72z5KjGR3Hb1a6tYowI08/21FntQ598uNzcfW8b prnFUKQh/seWcyKOErGLeG/6QRXxI0V8YDsZ7htJh+ZRLEoK5+pgKEmrpP/LRe1Ih7XIjmEyhp0v Pj+WwH6ED5vdLs4/m3vYj3KL9R3c1C+Kq826o4yyyaWSufzYpozVrr+Lb4vln2W1g9UaqocSlqg7 Pt9mXcJ8eg2omw9l/GoPpU3Zbk+nU0rkWlin+im3Hfz79H8vtqty1xfn/wkwANf9NegNCmVuZHN0 cmVhbQ1lbmRvYmoNMzYgMCBvYmo8PC9Db250ZW50cyAzNyAwIFIvVHlwZS9QYWdlL1BhcmVudCA3 NyAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3 ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0Zv bnQ8PC9UVDIgNDkgMCBSL1RUMCA1MSAwIFIvVFQxIDUyNSAwIFI+Pi9YT2JqZWN0PDwvSW0xIDUy IDAgUi9JbTIgNTI5IDAgUi9JbTAgNTMwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQy9J bWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA1MjMgMCBSPj4vUHJvcGVydGllczw8L01DMCA1MTkgMCBS Pj4+Pi9TdHJ1Y3RQYXJlbnRzIDIxPj4NZW5kb2JqDTM3IDAgb2JqPDwvTGVuZ3RoIDkyNS9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcVl1T4zYUffevuI+7nYksyZIldXZ2hgS2Q2dpt8Qz fQAeTGISb4kNsSikv75HtglJ2ITSMFjY8bnn417LxEdLX97kE0+fPsXZ6q6g+Fs+K6vcl3VF8XBY P9GFNEwmpB3TQpBOLXPGOUvGSlzhztFVfOR9PpkXU7qIs/oOwNr7ekHx1+LGU3xezuaerj5/Hh6P KIp/H1F8NuLUnY3GnCYNcaa0tRJrio/BanGeEDWTKhJU4s5fcOesiYQyTFlKBePQoyQng99lEd1E 95FO8WUrr/9+oNX6hj9/oqojHI2Jtz80Hv0WcWY0PZKlM1z5ToJ+pYsrTlPazzWO/gDMOSlSSOVO iSCdG6VFJ1luAoVjXJKwvcyDXjugki0yoDqsXGOlSkQSyLRybWxYnpEp5xw9UgEc/hKWWYfPJp6n 0igARWKkxgo83+KWaof7WbcIiqFUvLLa8abpft77iJPQUK9N4mhgUmZUuBNXFa5KROUCWNNkEcWn C07HNTJGKeppUhfECaXbSI0kafraJ2cYpPYQj+c5hhjDfDY6PUbxfuZa9kQyrlJQDXTCFO/ZJaSi UYnYZBcde4BJ8AYrBqLbOEIlpEbKJZsQ2UF01z5r+ghf6dyRKJ4l9vMYnA6zKM4y8FDWNoyDJJuE 0Dk6nz2G+7KGkDTWf3CWLXFIFMPYD7oFYG6YaE1a5Gs4upUtog8nT3fFslwUlW8+Zt+jAzDpLDNS ONXisB1kReOvi+kbMOU0k1ZirAPsUso0AOBHdH4GrSHj1o5E52hvQS0V0+EJ29FPp6eh8knW5/p1 WE9X61zlOlcWHrT2YeOJSzYTln3CrZROBaYBTRt0Cw+jj70vDDK2vZcQ4Up3Max7tmswEWuD6o3S 1qG06P0dVfntqikbqm8oy69vCxI/H7CZ/E+bstMiOy0SYVuFzNV/Ndl6dAeLSWyrph1dFPsy+jJG CbwiHm7LakaNX+a+mK1okldV7eluWfwdeurnBZ6jMeXhhfLXAePqXcZ/JBOThvyx87/Xtli3Fvvn G6W3Qvi2LOtl6VeDYd7gXbmRQUsYasv11KRvlFYcj2fqtG1LV68S9DU19aKgzsv+1qfYy2wg3o6h ePKoxuhAC/R7WrBLa9Pwb4Qx705fPSfE94T/Unkr/HNk3Qd/+eGx9HM6rx+qKY7XZXX5cWsit8IM cgY7zfkxNd7LLDFud6Je5pnuH0pf0GNxe8s2g/1XgAEA24Mnnw0KZW5kc3RyZWFtDWVuZG9iag0z OCAwIG9iajw8L0NvbnRlbnRzIDM5IDAgUi9UeXBlL1BhZ2UvUGFyZW50IDc3IDAgUi9Sb3RhdGUg OTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BCb3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2Vz PDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NTMSA1MjIgMCBSPj4vRm9udDw8L1RUMiA0OSAw IFIvVFQwIDUxIDAgUi9UVDEgNTI1IDAgUj4+L1hPYmplY3Q8PC9JbTEgNTIgMCBSL0ltMiA1Mjkg MCBSL0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0 YXRlPDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVzPDwvTUMwIDUxOSAwIFI+Pj4+L1N0cnVjdFBh cmVudHMgMjI+Pg1lbmRvYmoNMzkgMCBvYmo8PC9MZW5ndGggMTY0OC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSImUV99v2zYQftdfcS8D2mGW+Zvi0BZo3GJI0XRZLWAPSR4UW0nUOVYqqXOz v35HUrYlRbQTB7Fsmnffd98dyeP0fdUUN9migTdvpunjQw7T8+y2WGdNUa5henJS/oQLpmPGQZpY UgpSJbHRxiSgE4YjxBi4mr5vmmxxly/hYpqWD2hYNk15D9PP+U0D06/F7V0DV+/enXyYQTT9cwbT sxkB/202J7CogcRCJgnDp8KXxmeC3zlAvVhHFAqc+QfOvK0jKnQsElA0JshHMAIa/6s8uom+R1Lh j45e+/tEit2Ev3+FtQeczYG4P5jPvkQk1hI2kMAZjnwDCp/g4orAEsJY8+gvNDOGUYVUiRHUUida SOops64hNTFhQJOW5sFYvaFgztJaeVu2s2WCU27BpDBONnxsLRUhBHMkrLH9RJM4Mfjq2hPFtEBD yjWT+ER70sNmYoC95U0tY2RKn4TqcZUK436PCFCJ7KXmBiZaxVrYmTgqcJShVMYaS1jcR9PTewIf StQYXUELo4wlR4V0kmoGTLe+P55hIbm36fwuwyLGYj6bnX5A523NOXTOYiIUQk0kjwVp0RlSxURx 2kWnHt2aMcS1oWgk7eSwnlA1EIZ3TZg3GaOBkC0P6ZOb6FbgJ1EMLfnWsi1XK8RJGk3TFGlA6vJJ kEO6sDkhWBjpxs5La8BE4PM//JZW+MZFjKti4h9oTHRMnQYJyq8JJjO9j159/PmQV8V9vm7q1+m3 6IAZM0msGTXC2eFukeZ1c50vj5gJI2OWMKx6a3bJmLIGGA/18UxcQNrsIqI+oqBDyUQs7QIc8IfT U+v5Y9oK+/mkXD7uhRU7YWO7EN1iJNzwrsSsldhx8TSwWjBtE/9AGhqrR4EWHQkxJulF2GVsGB6n w/DG/VqtNG1DS7PrVQ7sd/hc1jVUWZNDeQOzct1U5Wr6NV8WVb5w+7ZDb+tixDmjzG5AyvR5P2SL f/KmhmINzV0Oi6x2AOU6h3R2DpevNne5/2mLbXEmgwI04wExoWJKEzPQauHZwxb736wq8vrydS9z 57us0W3SfH56mtK9psJTwA3Flox/IAWDG7bAyukSOHfA8BUjqgOgbBS0H7Yr2BFMjh9wv2NmAHv5 Cst0gVWa3TolKTm7DofNxxl0ypJaTBdkgseztDsvl25d43ZjAStfkXhKTajLB25eKAaXmB9t47DJ 2NYN86tv1KsSMd95fcvILwHO4hDnnWNOcT3jqlMtXSyRUbpWR0Ptsd5jXO0Yj/nF8BSPMe1+8lsZ JCufRdapoIjigKvHkZWHtBVKvUxboVlX2zBd9UJtt3SPadtjfExboemztNUv1FbK7kIJaCsVe5m2 tm3taJsE6SYv1NbTPa5tj/ExbW0Xi9oKfUxc80JxFbKwbNkhcZUmY+IGtVXYzHW0pWG6lLxQ3S3f Y+r2KB9TV2n5PHXpgfOmPW6wt/PnHPPnHMdyaCuuV8eUB0EC50vYsxNFUeo9cy9KeLbNDtF42tvZ LEgjdMgMHWONJAK7/5aGSbyM2IwFXY+fBd3OIYzSl1GG+Yf28OGJLFl7f2XcH5Bm34m09RW0wBuv 1lz6iMtjs7F7o8xQ3yCvQrwDm7nVhh0psf4Rj5+D4oQ24aBre2RwKhPTuhZB1+MbZq8ne6KRoXjj tTD9HFRtDxuHsALb3QGtXB09XygW2qDG/T5bJXaoc5XjIu0KadCxVkVZFc3jZNflh1TGhf/E+gS7 +mWP5GxOYDaH9rYyn32JcFlL2NjN+gxpfsMG+BNcXBFYQoT3tlg4UsZdYeG+M6Sx2yLU3slW0Tyi YBvTTxBxZvC6YbO9s9kP9W1aZAsYCS6HUPuhrtkIpye2PUJ7Ay6sG4op7drsR7vOhaQjc/ej3blS 6JZed+5+dBjrmIahcEeVZWwskP3oKuK2ARK9ie3QuJZKyhEi+1FLpFvgge3X1qfYXczY9nLYX01C kbbUTdKp1dMG6rtyU+OdM2v8nbR3XYT77NEO3ea1/3m7fxTlGoarw7YDNACfaOxfjOZ9+BakKcsY TteIWTXF4scqq/a+99deZY645prH2KUI73tzl69hk8OPOoeH7YK+tmtz75w9uVwOnEvKY836pOum wqvs7eNvUDRQ1PBQ1nVxvcq9htlqZW+bXZ18lDUssjVc5zt0l6rd9XIILBSebITLPnabinzZ27// F2AA887aqA0KZW5kc3RyZWFtDWVuZG9iag00MCAwIG9iajw8L0NvbnRlbnRzIDQxIDAgUi9UeXBl L1BhZ2UvUGFyZW50IDc3IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BC b3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NT MSA1MjIgMCBSPj4vRm9udDw8L1RUMiA0OSAwIFIvVFQwIDUxIDAgUi9UVDEgNTI1IDAgUi9DMl8w IDY3IDAgUj4+L1hPYmplY3Q8PC9JbTEgNTIgMCBSL0ltMiA1MjkgMCBSL0ltMCA1MzAgMCBSPj4v UHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDUyMyAwIFI+ Pi9Qcm9wZXJ0aWVzPDwvTUMwIDUxOSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMjM+Pg1lbmRvYmoN NDEgMCBvYmo8PC9MZW5ndGggMTkxMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUV1tv 21YSfuevmJcF0sWaOvdLkQSo5WDhIG7TiIt9iIOCpmlLiUy5IlPH/fWdcxFFSqQkO4hpHZ2Z+eab Kye/rJvFXV408Pr1JHt+LGHyMb9fVHmzWFUwOT9f/YDPTKeMg7SppBSkMqnV1hrQhuEJsRa+TH5p mryYl7fweZKtHlFw1TSrB5h8KO8amHxa3M8b+PL27fnFFJLJb1OYXE0JhE/TGYGiBpIKaQzDp8If jU+DnzlAXVQJhQXe/C/evK8TKnQqDCiaEsQjGAGN/9dlcpf8mUiFX3p48fszKdoL//83VMHgdAbE /4PZ9NeEpFrCExi4wpOvQOE9fP5C4BbGbc2S31HMWkYVQiVWUAedaCFpgMy6gtSmhAE1EeZBX4Og YF7SSQVZ1soywSl3xqSwnjZ8bCQVIQRjJJyw+4ua1Fj86coTxbRAQco1k/hEedKzzcSO7Q1u6hAj UrrnarCr1LjdPxMCVCJ6qbmFM61SLdxNPBV4ypAq64QlFA/J5PKBwMUKOUZVEM0o68BRIT2lmgHT Ufe7K0wk/2sym+eYxJjMV9PLC1Qec85b5ywlQqGpM8lTQaJ1hlAxUJx2rdNg3YkxtOtc0Qja0+E0 IWsgLO+KsCAyBANNRhwyBNfoSPCeF7uSfCMZ09URcZ4lkyxDGJD5eBLEkBUuJgQTI3ty97IaMBD4 /Bs/ZWv8xUWKVXEWHihMdEo9Bwbp1wSDmT0kr979eCzXi4eyauqfsq/JATFmTaoZtcLLYbfIyrq5 KW+PiAkrU2YYZr0Tu2ZMOQH0hwZ/zrxD2rYe0eDRqELJRCpdAe7gh8tLp/ldFon9cL66fd4SK1pi U1eIvhgJt7xLMYsUeywBBmYLhu0sPBCGJQ4P9sQtheiTDCS0Edt1j228I/qQWmNRLY2eZfnNsgT+ M3xY1TWs86aE1R1MIa9u4RM85sW3sqlhUUEzL6HI6xIciGBPbO3ZQYPMkaiNsn1X0EA2/QjFPK+q cgl3qzUa3Jhyhv930f92a3Lrohq2KNEQN1b2Lbae9GL3sY0b3YQtRKjHqkuVmDQi2MSW4pImPNCm FbFTUSI6Rj96k/AJOR2zywbt9ouvJXfHLGc85dxiLffNXr/CXC0wVfN7H0tKrm7q659GEPBhBJ3c pM5m8BMnswKumLOGDcdZW4ecxDl1Rn0ArMbW78jg2rVz5wdeK/w19IaFEtzXiq2bt1rfSPKvEcDi EOBWK8dRgTFRLMKldBiuI1FqN1J6cNct3GG93j3sODbef8NG8cqT8HoWpMUZJmQ3ccfpFUq9gF6h 2Wn0qhfSG+Aep7cH9wR6haYdesfx6hfSK6U4iV6JaXM6vW59PYle80J6A9zj9PbgnkCvW2iRXhHm 5RszCti+kF8Vy40d4Ve9qDuoU7sDJS8kWJ3YHtRge6CMjlKsQoPYUEwPgD40fmQ0sNP8pYrAGPeL Fm7rzsx0VTXr1bIzMblH2OryHV35mRkexLde3J73dF2/8lM6UjIqYyj+JVgoqPmx25bi2ks197f9 hB8dTXR4OnYXgbgDsLADsGgNW1Lb+Dc5Q1I+Sv/YDBzW6zueMSakAkvFqN6xUTWs15U6J5qFylF6 VO3YRBlW6xKccx1p0CE+I1ddlRlBwlU1CmBkRnTCsqMfVaZWWsxc38+UjRl2KCjDjb2b03tFIYhK rXZm+on8qbxdrMuiSWFTt25BDtuVo3ugJgS+fVK+r+r6ld9NB7O8I2Mkci6kPVATndv47iIti4E/ UhMjA6SzqA7WxCYCdq8s2GgExlr/qGpXGZxYyo8Fl4116VHVPouFJoFRMVpz7FArFUdaaX+PnhXz 8vb7clHd771/7KnAl11pduTrxr1N3T9vk463bxLDLxIC5aVxRvqa7tarB/iwqL7/6CBR3RV9Rw++ DTk9ckfPt3Iz30bvc2zU0o9hvF8duy1sKpmOaV4uezGZzghMZxBfV2fTXxPMOwlPbkRfYVS+4svP e/j8hcAtJDiBcbq6GOCC4BL5oXOkFcczN1KXySyh4Dx+DwnnPMUR0QrEz/3b0aYzlQh0jvnR3Mps j7piA2j2ZHtQtgJcSvc1hrArsz3tKheSDtzdnnbvSqEjvO7d7emur0Psjbm7zyljfADZ9nSZcMNT 4Suze3d7Okyn8jzsYtmeOizdYh6ZdNv0j38NNTzX5vzKYVmnBC4bqOerpxqaed5AEbelx7z4VjY1 LCo8L8GvPXPfiOFpsVzGClbYf5RLZ6TICgpQF1WvsI8AUQZ3WWFN6PM3ZaeY9fDYNL7SmOr7kN/d 4TArb0N1+vJqkciWFm2H4bQ6qbGpIFYHpTfPsI5jcrGqdhnxQy8w8h8Ya73tWkBSIVyhY50TrHMf vSn7g/R28cxlarbeRyipwEbjS63j9WvMMfYWLe/kgWgdjv4eVkkZSQ0nPEy/hzKvXH/P4WI1G9yM tpLMctyRCHrmY3DkNsdVxDBtlb/dNEgnFMjfqgEM/OO6/KusMITw+H1dLp8B2a+/F/OQaOO5JAXF 1yCrdxKiLh9znDUYt7Qbm38EGADHuXrPDQplbmRzdHJlYW0NZW5kb2JqDTQyIDAgb2JqPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFswIC0xNDEgOTk2IDg1NV0vRm9udE5hbWUvU2ltU3Vu L0ZsYWdzIDQvU3RlbVYgMC9DYXBIZWlnaHQgMC9Bc2NlbnQgODU5L0Rlc2NlbnQgLTE0MC9JdGFs aWNBbmdsZSAwL0xhbmcvemgtQ04vRm9udEZhbWlseShTaW1TdW4pL0ZvbnRTdHJldGNoL05vcm1h bC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag00MyAwIG9iajw8L1dbMjc0WzEwMDBdXS9UeXBlL0Zv bnQvQmFzZUZvbnQvU2ltU3VuL1N1YnR5cGUvQ0lERm9udFR5cGUyL0NJRFN5c3RlbUluZm88PC9P cmRlcmluZyhHQjEpL1JlZ2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDQ+Pi9Gb250RGVzY3JpcHRv ciA0MiAwIFIvRFcgMTAwMD4+DWVuZG9iag00NCAwIG9iajw8L0NvbnRlbnRzIDQ1IDAgUi9UeXBl L1BhZ2UvUGFyZW50IDc3IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Nyb3BC b3hbMjkgNjIgNTY2IDc4MF0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCA1MjEgMCBSL0NT MSA1MjIgMCBSPj4vRm9udDw8L1RUMiA0OSAwIFIvVFQwIDUxIDAgUi9UVDEgNTI1IDAgUj4+L1hP YmplY3Q8PC9JbTEgNTIgMCBSL0ltMiA1MjkgMCBSL0ltMCA1MzAgMCBSPj4vUHJvY1NldFsvUERG L1RleHQvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MwIDUyMyAwIFI+Pi9Qcm9wZXJ0aWVz PDwvTUMwIDUxOSAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMjQ+Pg1lbmRvYmoNNDUgMCBvYmo8PC9M ZW5ndGggMTM3OS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImsV1tv00gUfs+vOI+7K+rM fTwSQqJpQaxaYEmk1Qp4cBMnNZvYwXZbur9+v/E4V5yEClI1Tpxz/75zzrj/sqyzaTKu6fnz/uhx mVL/fTLL8qTOipz65+fFN/oobCQkaRdpzkmbOHLWuZhsLHCHOUef+y/rOhnfphP62B8VSygWdV0s qH+VTmvqf8hmtzV9fvHi/GJAvf67AfWvB4zCt8GQ0bgiFikdxwJXg5fFNcZ3SVSN8x6nDJKvITmr elzZSMVkeMQQjxKMLP7LtDftfe1pgx+b8Nrfz7RaC/z9B+XB4WBIrPmj4eBtj0VW0wPFdI07X4jT n/TxM6MJHfY17P0FNecENwiVOcV96MwqzUPIYluRu4gJ4nEb5tFcg6ISjabXCrpirSuU5NI708o1 ZcNlpWkYY8BIeWX/icdR7PDa1mdGWAVFLq3QuEKf7fgWas/3Km7uI0ak/LtUg19jDvv92mPENaLX Vjo6syayykvirsJdgVI5r6xpvOj13ywYXRSoMUxR68Y4HxxXuimpFSRsa/vyGkRq3vrD2wQkBpmv B28uYLzlXONdiogpA1dnWkaKtd4FQgVQkm9758F7l81426ZAUD5Pi4yaWnk3KCkpJ7ftiWDPyAbb 2Lb1/S6JPV9u5aslqy/D+ajXH43gh0YNmowpGo09Iozj04OXG1UEGHD9D99GJd6kitATZ+ECZWYj 3lQgRvEtA5SjRe+3y2/LtMwWaV5Xv4++9I6oCRdHJlZSNXqYFaO0qm8wALwe4uOr+IRDxj6+EBqq jbzPwmXboHIasiiYt3c2CO4PSmtEJKXUJrg/Ja05GGoBs5fOT0k3RFMmhDI+JR0rTEclg+35KWkn IssEC+W+OyFtOPpN2pBkdUpYeJBMG3Z2SlpKPzlE/EMFNGhcK2LDNwW8HLWMvTovJo9rxvI1YyM/ 35oZx6ST29wVLTcCLfadOua5tkPLT0LoEOG6CzYUO2t6QKx6gJluogWznHHY5SrYHdyVJbhO6Yb2 VIPH2fSR6tuUpsV8Xjxk+axhdXAk+WE2C0CgbWzcbvh+v1ZHaiaeXjMR/IrWrxbgYDNuufnRuu2W DRM1ZHTQMqantaxt0Ncfrt9TVtE0TarsZu5LVVK2WM5TX8VweiimR3KWT865MzwbRzpmwmC1CA8s sz+YuF7zxbpTpnHiQeZGNqYXaVX5E9LsGV29Oqe75bxIJs3XT4LpIxmrX5KxZL7LmxXbDXVkFGL1 eUccs5d3Zt+S2OPOuoHf8rMD/NCf8u7mvieSummSV0U5uBy2A+SQEcVxsnDchWCXZVEX42JO8/Q+ nXsepdNpOq6z+0CkYGwVoewOEAtbWofhuFuIi2KIyOrueDY6WF/SYP41OskJacE5TrpSB3KN/yWf gI+3yCM6Arl+EuRdSWqLuQu8nsxvcxLgjekdfl8XZVrcp+UzynLgC2zGSZU+a6CuNuBXdZnU6SxL /e95QGznLMK620piXXLubLyX0Q2Qn6ffMEseqUrnKG46iehYcc0v6SeFFauMZ/fP9BPf9JM55Wan ncDWTu5tyccSTJXGHGHqlrQz2ECr/XagDTbigqsoZqtTQAJmA8y8qAlwJPdFNsGB7t3bq3/oxqOy TID5CYsGqFo8QIRz4Wp17g8d1V0kafAg5Lf0DhSDIq9LDIsl4kuxoZN8Qh/SSVaGDlzfrwuaZJgj zUpfexVHsMdxXGin1Z7D8S2KkM6r6Aj77M/ubBW7SOM5VTx5Z2+O+6K7tbdM75DtTe1H7bKowsqu bzHB94u7SB5pXOQznII2NbTfHa52HWqu/VOQ3p/FXShhqlTFIm2mym6F/xdgACrDu9ANCmVuZHN0 cmVhbQ1lbmRvYmoNNDYgMCBvYmo8PC9Db250ZW50cyA0NyAwIFIvVHlwZS9QYWdlL1BhcmVudCA3 OCAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUgODQyXS9Dcm9wQm94WzI5IDYyIDU2NiA3 ODBdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgNTIxIDAgUi9DUzEgNTIyIDAgUj4+L0Zv bnQ8PC9UVDAgNTEgMCBSPj4vWE9iamVjdDw8L0ltMSA1MiAwIFIvSW0yIDUyOSAwIFIvSW0wIDUz MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAg NTIzIDAgUj4+L1Byb3BlcnRpZXM8PC9NQzAgNTE5IDAgUj4+Pj4vU3RydWN0UGFyZW50cyAyNT4+ DWVuZG9iag00NyAwIG9iajw8L0xlbmd0aCAxNjMwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiXxXXU9cNxB9v7/Cj20kvPaMP6UoUthEVarSJmWlPiAeEIFAlIUkrJS2v75n/HXvDaQg2F2v xzNz5swZ383Lr4fb64vLg3r+fLP75/OV2ry9+HB7d3G4vb9Tm+Pj+7/VGUVNrHzW3lrlQ9I55pxU TIQVk7M637w8HC4ub67eq7PN7v4zDO8Ph/u92vx2dX1Qmz9vP9wc1PmLF8evtmra/LFVm5OtUfXT 9tSoywdltPMpEV4DfiJeEz6zUg+Xd5NVt9j5C3Z+eJisi9olFaw2iMeRURF/X6+m6+nL5AO+LOG1 74+8Gxv+eqbuqsPtqTLlV51uf5+Mjl59U0mdYOWjsupXdXZu1Hv1Y1+n0zuY5Uw2IFSTnZXQTXTe 1pBpaWizNqRsamH+b67V0FGxFKtqS8OWHFsWZ97lAhteumUwxqBGTozlnU06Zfws7U2g6GBoOZLH K+zNyje573z3uK1EjEjto1Sr3xB+7PfLZJT1iN5HzuooBh2d7MSqwyoBqizGXl3up82bvVGv7oEx jlLNTcgSnHW+QBpJUWxnvz4Bkcq/zenNBUgMMp9s37zC4Y1zxTuTNi7A1ZFn7UzzTggVhWK79G6r dzEj+JVUIoIucMhJQE25zEsTqiY1jLcjBNtDaHyTTI5302a3wzlqVwqCU/D2Uh2N999k6+5BAUy8 /otPu6/4x06D2Uf1xaiMyEoaKWiAgXrs9tNPu5sr9fru/c+7j9Pr3ZOwcI9piS4X2qXYSv8I3+/O oCfyYmPBKmk+zlEzqrSfKGWdECQpZ4A0y9mfJspBUHeEmkbJ+NPE1uvshTNOCBXrRgbUUWxJRyyx LEVqLc45abJtNXntw2ojSoxk5ETOTgdbT3TW6Si2QTtbXTtymgqQzjKK3cwtcqgBMdiam/k41DmH HuzeGVpY96I43CN1GvogG7Nv+XhAFLv5WAX7JPgoSmSNkyUkYgqWLsrZDTfsaOY+zGh6X0BCGqZv DGiTspFRUmrBU0JAJVEOYQ4eSTMQ8RFNu4KdfRqJMxoFrVvQnKF7XPJP0/UzIYUOOSGTRi+GnlVF 4OC0L5738Jw1U4kHveU6bPPetAjJIMka+yqj2IBntGNoGVGC+woTlMiP1TQKajR3OqGgXAnqWFs/ x2BQEUZYjQ+diuBp8i17iFErh1nEj1GZHTbaESYjIGECWoB4vYTSD76gaLU8KxZhBkVfmMAIkJtr RjK5Egnf9y7ADuLKj6RD32tN70GMRzvgCB0kme1ceUeBRNvg3zRrkoIVrV42F0VAHlGe/hnlr1AI tQaxnyh7IQijFtmWpMC+kMUV+IAaojedQT+OJgbPa9FAte5NihCooN4B6UsL8XCgDObyCsxMmlEb kNl34XkilBLjl4mkXsU5QXRqSBUggtzUxORegWvFQgZnK4eBVzsFQiixVv4umUrUYcPeHhI5SGVd RfqPuS7eZ4gjopvFQOAHhnPAkrRvDCKkP4QQsFQGsY1DYRw4WJuEox/iXJWpctAOZrhgSqJYxZDs TSF8rPosEzI5eSfewMegvHR83zgE1ou2WLsSUg88clcZdKbHSgJWfYBEyRKM0qkg5lFX5ZHS2CFV r6dbuWDUMMhSF2r03yDzwFvSH3hDvp1T3syYydwypRc8gre54O8bQT2Fdv0Z0u+FlLlQMYvGrhAh U8ge7WCDgJsqFR0qamtLyvgxTWVQ21ZnITpmBoOO3FUmY4woli9656PfRdohRbFrFmaur9wCLl3d G55FkEshwJ0+PB2NUUG4OYnWezcPH0Samy77IZbEQKWoL/nvOb3C+Ol6PNFBpSXf4WBsQ/+Gtnnf VoTjY0qKItZR5fJQA4JatWEDVbJtr1w7IPRspJydbaGlTlkedtoq7hBtoi7bBchCYpgXtAbAdaAI TF3uZZJUDRa96a6kzKFOeTKL+0gokwYPWEPCq24t22cePl5UP9rVkJzXRKkHDwmAyNFgihmlWiO6 KgrxmC141Cl8RacN0ZdHw1RO67cmcdCisjTPENxh2rMJx0Id36RLOphq64MWFQsPqkS/umyB0LMY sWl3Do9+8KG1k1yIXAlvzA6ZObaP5zEovOvMXvROufm5dacIs0s3yn1iXAMwnGq/L8WURHWLFMp9 Yu4NU8iFJ48+V0guFpWbYb69/gDxR5VBC5TL+H8CDACfmCx/DQplbmRzdHJlYW0NZW5kb2JqDTQ4 IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstNjI4IC0zNzYgMjAwMCAxMDEw XS9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRmxhZ3MgMzIvU3RlbVYgMTM4L0NhcEhlaWdodCA3MTgv WEhlaWdodCA1MTUvQXNjZW50IDkwNS9EZXNjZW50IC0yMTEvSXRhbGljQW5nbGUgMC9Gb250RmFt aWx5KEFyaWFsKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDA+Pg1lbmRvYmoNNDkg MCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250L1RhaG9t YS9GaXJzdENoYXIgMTQ5L0xhc3RDaGFyIDE0OS9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlw dG9yIDUwIDAgUi9XaWR0aHNbNDU1XT4+DWVuZG9iag01MCAwIG9iajw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udEJCb3hbLTYwMCAtMjA4IDEzMzggMTAzNF0vRm9udE5hbWUvVGFob21hL0ZsYWdz IDMyL1N0ZW1WIDkyL0NhcEhlaWdodCA3MzQvWEhlaWdodCA1NDYvQXNjZW50IDEwMDAvRGVzY2Vu dCAtMjA2L0l0YWxpY0FuZ2xlIDAvRm9udEZhbWlseShUYWhvbWEpL0ZvbnRTdHJldGNoL05vcm1h bC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag01MSAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9X aW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvQXJpYWwtQm9sZE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hh ciAxNTAvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA0OCAwIFIvV2lkdGhzWzI3OCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAg MCAwIDAgMCAwIDAgMCA3MjIgMCA2NjcgMCA3NzggMCAyNzggMCAwIDAgODMzIDAgMCA2NjcgMCA3 MjIgMCA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MTEgNTU2IDYxMSA1NTYgMCAwIDYx MSAyNzggMCAwIDAgODg5IDYxMSA2MTEgNjExIDAgMzg5IDU1NiAzMzMgNjExIDAgMCA1NTYgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1 Nl0+Pg1lbmRvYmoNNTIgMCBvYmo8PC9MZW5ndGggMjc0NS9GaWx0ZXIvRENURGVjb2RlL1dpZHRo IDE2MC9IZWlnaHQgODYvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNTIxIDAgUi9UeXBl L1hPYmplY3QvU3VidHlwZS9JbWFnZT4+c3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEABIO Dg4QDhUQEBUeExETHiMaFRUaIyIYGBoYGCInHiIhISIeJycuMDMwLic+PkJCPj5ERERERERERERE REREREQBFBMTFhkWGxcXGxoWGhYaIRodHRohMSEhJCEhMT4tJycnJy0+ODszMzM7OEREPj5ERERE RERERERERERERERERP/AABEIAFYAoAMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAAAAAAAAADAAEC BAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQAC EQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2 F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQAC AgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2 JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AMJ+Rkb3fpX8n853j8VH7Tkf6V/+c7+9Qf8ATd8T+VRW hQayX7Tkf6V/+c7+9L7Tkf6V/wDnO/vQkkqCkv2nI/0r/wDOd/etv6rXXP6u1r7HOHpv0LiR28Vh NZLXOOgaNPitr6p/8sN/4t/8FHMgxmB+juvEZAwJ/S1H5PfpJJKmzKSSSSUpJJJJSkkkklKSSSSU pJJJJSkkkklPkr/pu+J/KoqT/pu+J/KorQaylOtrXGHO2qCJVt3bnGNokfFNmSIki78F+IA5IggE XrxGh+xNsaA6sAu289hqeVsfVh1f7XY1gH82+XD4LEc9ppgae6PMha31T/5Yb/xb/wCCriBMZGRO l6ePdt5soBjGAjUojWto38o6/wAuj36SSShYlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnyV/03 fE/lUVN4JscAJJcQAPiux6P0LFwcf7d1MNFgG7bZ9CpvmP3lelMRGv0DXESS8d6Vu3fsds/e2nb9 60KeiZdvTrOoktrpYC5oeYdYB+7/AK6rXu6pm9a6g3C6e51OJ+eR7HGsfSc49h4BUvrF1Jt9wwcY 7cTF9gaPoue3T7hwE3ikSBVHc9aCaAs7uEt36p/8sN/4t/8ABYS3fqn/AMsN/wCLf/BOyfJLyRH5 h5vfpJnOa1pc4hrRqSdAAn51CothSSSSSlJJJJKUklwossZY0PrcHsPDmncD8wkpkkkkkpSSSSSl JJJJKeM+r+BRS23rGaQ2mou9Hd4g6v8A4DzVDqHUs3rmW3HoafSLv0VI/wCrf/rotzrHSeo5bsbB xGivBpYCXkw3fxqBqYVHLycPoVDsPp59TPsEXZB5Z5DwPl27qzE2eL5pHYfuhiIoVsOvi62NjY3R +j5NlLhZfW13q2jvaBo0eTSVwWvfU9123S6vt/1XfjVu/SkPaZP+E3bxPxXOV9A6q5xD6fRY36dl pDK2jxlHGQDPiOvF1RIE1Q6OWt36p/8ALDf+Lf8AwWVlMxmWCvHebWsEPtOjXv7lo7NWr9U/+WG/ 8W/+Ckn8kvJbH5h5vZ9X/wCS8v8A4l//AFJVP7dlssdBZ6FNtFJbB3uF7WSd09i7wWpeyl9L2Xx6 LmkWbjDdpGslQ+yYxBOwEPcx551dXGw/LaFTBFahnIcq3P6j6V7S9lWQyysBhYZbXZbsDgd0PBHf 4hK+/MZe+up1bLjdRXZbsJ3765+ju/1CvMwOmH16mMa4vgXN3FzhruA5luuo4Uz03CNTqjX7HbSd Xbpr+id0zIR4o9vwRRa32/IGnt3DLGPMH6BaDPPKq19Q6iMajc5r7cp7w1zay7Y2vcT7Q73HTy0W mOm4Qtbd6Q9Rpa4GXfSYNodExMd0x6VgFr2GobXu3kAuEP11br7eeyVx7KotfMtybeh3WPb6N5qd vaRxGh0nuED7Xl49Nr6/RbRgltdlQaWmw7WucWwfb9L2jVaoxccY/wBl2D0C0tLNfonnzQ7OnYVl wvfUHWCNZMHZ9HcJgx2lISHbqqiixL8y++0uLBj1WPq2wfUO2IMzCvoFDsQPsZQ9heXF9jWuDnbz ySJR0079khSSSSCVJJJtzS4skbgJLZ1g90lPnd31h6u9jqDeQ0S3c0BryP6w1WTzqeSvRW9H6DZd ZU3HrNtUGxuum/Ud046H0NzywY1Zc36Q1kT81ZGaA2iQxGEj1eCw+oZmE4uxbTWXfSAgtPxB0Usv qefmCMm91jf3Pos/zWwF3FfSOg2WvqZitLq9HHa/bI5AdwYQ6um/V+280MxP0jfpTXY0D5nTVH3Y 3fCb8kcB2t8/W79U/wDlhv8Axb/4LqGdG6C+2yluNWbKtu9uum8SO6n0/F6M29z8Kltd1cgmHNO0 ktMbuRIQllBiRR2SIEEGw2Orf8l5f/Ev/wCpKp/bcxljtpZ6FNtFJYWne4XtZJ3T2L/Ba1tVdtbq rBuY8Frmnu08hDOJjndLB7nNe7nV9UbD8toUAIqiyEOLgOzAfs9T6m3XPvtfc5hMiu3ZtjcJMnx0 CsY+fm5j666TXS5rN9pINgeRY6uGajT2zPwV6zp2FbWK31Ata5z2wSCHPMuggzrKVvTcG0Vh9LYp EVxLdrfD2xp5ImQPT8EUWkM/MJGTLPszr/s/owfV+n6W7dPM6xHCFVm9TtFUPqb9oZY5vscdnouj 97XdPyWn+z8P7R9p9IetO7dr9KI3RxPnypsxMZmzawD0g5rOfaLPpfelxR7Ko93Id1TOdU6+v02s rqosdW5pO43/AEhunSFo4V177Mim8te+h4Ae0bA5r2h40k8SiDBxAw1isbHNYwjXVtX0B8kVlVbH ve1sOsILz+8WjaPwQJHQJALzmC1wzsd9jGVVevkiu9ur7LC549N/EeI5mFco6j1K/fZVUHMeLRU0 t2tY+skMl+73bo10C0zh4xq9H0x6e/1Nuv092/d8ZQz0zANj7fRG+0EPOsHf9LSY1TjIHcIoud+0 8x1dNVbg6+z1N7vSO5hq2+w17+Zdrrwit6hl/asdr9obaWstoDTuqe+sv91kxMjjwVs9LwDSKDSP Ta4vGrt248ndO78U/wCzMEPbYKgHMLS2C4QaxDTAMcIXHt3VRaFed1J9FFm+ppzHCuv2mKyNxLj7 vdIboNNUPJtzcbJyLw+t1lGNU+32mLNr7NG+72yPitZ+DivxxjOrBpHDNdCDMg8hMOn4YrdWKxse wVOBJM1gkwZP8opcQ7KotDCZY3PNnqB1ry/7RTEemCZb7u8aD56KzjN6eOo5JpcDlkN9dvgO0aff HzXjqSR6+XRQ/a+wYhc7qGT6bSylulmu6t92kOb4GPpfJGo/p2V8KvyOXjKSB6+QSP2vrOEyxueb PUD7Xl/2imI9MEy33d40Hz0TdJAbkP2uL94dv3bh6cWvjZuAlp147heTpJx2PkEDo+4pLw5JRrn3 FJeHJJKfcUl4ckkp9xSXhySSn3FJeHJJKfcUl4ckkp9xSXhySSn/2QoNCmVuZHN0cmVhbQ1lbmRv YmoNNTMgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VGb250 L0FyaWFsTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMS9TdWJ0eXBlL1RydWVUeXBlL0ZvbnRE ZXNjcmlwdG9yIDUgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDAg MCAwIDAgNTU2IDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgNzIyIDAgNjY3 IDYxMSAwIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDIyMiA4MzMgNTU2 IDU1NiA1NTYgMCAzMzMgNTAwIDI3OCA1NTYgMCA3MjIgMCA1MDBdPj4NZW5kb2JqDTU0IDAgb2Jq PDwvSC9JL1R5cGUvQW5ub3QvUmVjdFsyNDIuNDA2NjQ3IDM5MS45MTIyMzEgMjA2LjczNzMyIDUx Ni4yNzExMThdL0JvcmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlw ZS9MaW5rL0EgNTUgMCBSL1N0cnVjdFBhcmVudCA0Pj4NZW5kb2JqDTU1IDAgb2JqPDwvRiguLi9w cm9ncmFtL0dSTVBfVGVzdF9QbGF0Zm9ybS5leGUpL1MvTGF1bmNoPj4NZW5kb2JqDTU2IDAgb2Jq PDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9UaW1lc05ld1Jv bWFuUFNNVC9GaXJzdENoYXIgNDYvTGFzdENoYXIgNDYvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVz Y3JpcHRvciA1NyAwIFIvV2lkdGhzWzI1MF0+Pg1lbmRvYmoNNTcgMCBvYmo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0ZvbnROYW1lL1RpbWVzTmV3 Um9tYW5QU01UL0ZsYWdzIDM0L1N0ZW1WIDgyL0NhcEhlaWdodCA2NTYvWEhlaWdodCAwL0FzY2Vu dCA4OTEvRGVzY2VudCAtMjE2L0l0YWxpY0FuZ2xlIDAvRm9udEZhbWlseShUaW1lcyBOZXcgUm9t YW4pL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag01OCAwIG9iajw8 L0gvSS9UeXBlL0Fubm90L1JlY3RbMjQzLjY4MDI2NyAxMTYuMjY4NDk0IDIxNS42NDg5MTEgNjg3 LjE3OTgxXS9Cb3JkZXJbMCAwIDBdL0JTPDwvVyAwL1R5cGUvQm9yZGVyL1MvUz4+L1N1YnR5cGUv TGluay9BIDY1IDAgUi9TdHJ1Y3RQYXJlbnQgMTM+Pg1lbmRvYmoNNTkgMCBvYmo8PC9IL0kvVHlw ZS9Bbm5vdC9SZWN0WzI3MC4wODAwMTcgMTE2LjI3MDUwOCAyNDIuMDQ4NjQ1IDE4Ny40OTExMTld L0JvcmRlclswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0Eg NjAgMCBSL1N0cnVjdFBhcmVudCAxND4+DWVuZG9iag02MCAwIG9iajw8L0YocmVjb3Jkcy90ZXN0 MS5leGUpL1MvTGF1bmNoPj4NZW5kb2JqDTYxIDAgb2JqPDwvRihyZWNvcmRzL3Rlc3QyLmV4ZSkv Uy9MYXVuY2g+Pg1lbmRvYmoNNjIgMCBvYmo8PC9IL0kvVHlwZS9Bbm5vdC9SZWN0WzI3MC4wODAw MTcgMTg3LjQ5MDQ5NCAyNDIuMDQ4NjQ1IDE5Ny40ODc0NTddL0JvcmRlclswIDAgMF0vQlM8PC9X IDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgNjQgMCBSL1N0cnVjdFBhcmVudCAx NT4+DWVuZG9iag02MyAwIG9iajw8L0gvSS9UeXBlL0Fubm90L1JlY3RbNDAxLjk1OTc3OCA0Njcu ODA2IDM3My45Mjg0MDYgNjE4LjUxMzEyM10vQm9yZGVyWzAgMCAwXS9CUzw8L1cgMC9UeXBlL0Jv cmRlci9TL1M+Pi9TdWJ0eXBlL0xpbmsvQSA2MSAwIFIvU3RydWN0UGFyZW50IDE2Pj4NZW5kb2Jq DTY0IDAgb2JqPDwvRihyZWNvcmRzL3Rlc3QxLmV4ZSkvUy9MYXVuY2g+Pg1lbmRvYmoNNjUgMCBv Ymo8PC9GKHJlY29yZHMvdGVzdDEuZXhlKS9TL0xhdW5jaD4+DWVuZG9iag02NiAwIG9iajw8L1R5 cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvVGltZXNOZXdSb21hblBT LUl0YWxpY01UL0ZpcnN0Q2hhciA4MS9MYXN0Q2hhciAxMTQvU3VidHlwZS9UcnVlVHlwZS9Gb250 RGVzY3JpcHRvciAzMSAwIFIvV2lkdGhzWzcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzODldPj4NZW5kb2JqDTY3IDAg b2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL0lkZW50aXR5LUgvQmFzZUZvbnQvU2ltU3VuL1N1YnR5 cGUvVHlwZTAvRGVzY2VuZGFudEZvbnRzWzQzIDAgUl0+Pg1lbmRvYmoNNjggMCBvYmo8PC9MZW5n dGggMjM4MC9GaWx0ZXIvRmxhdGVEZWNvZGUvVHlwZS9PYmpTdG0vRmlyc3QgODczL04gMTAwPj5z dHJlYW0NCnjazFrbbhs5Ev0V/sB2k8U7MAgQb2axs8lMjNiYfRD84NjaxBuPFSjOYvz3W0Uetm5p ybIEj4FYxSaLxcO6sdidZJRWiRS5rJJV3jBxyseoklfB81hQUfMT/wv8lFTWzJJVjtJURlunsmHq uY+Y8k+2yhjyKjumIajslbGZx4MyzvG8yFRkJGU8S+UhE6wIYYFRixR+iJHFyEMq8q0ibWTIcSOU FRm1Y5E6CHxeg3FS5HGjk6JMwpOV1SLDaG5Y5jGGG0mAkbJUhiw3GJUxTlkbeZbxyjojPYEbXnii sl7wcK8NJNNZcmDshlhykJ3xejZaZiaWHANPJ5acBA9PsMkJM0tOUZiDcloLT+QG69pQUk6kGsrc 8DxktXKUpGGUczLE0p33jNBa5QKbzbD2XRK18N5cdjIUlNcCzEY2J2/O2KQ8lVlZeSsCGYr3JFYw yocgDVI+abEPO0F2xVAqFGCOHYFIGkEFG1igi+Ia0kgqBGY07D0hsv8Y9piQWQGG14tamFl9kYTZ WxWtkyGnohPw3qsYxEyenSwKZh9VzOIFvP+kGa9ht0paNCbeZ8TD2PbJiuoCcUP2xcuwdoXHcUP0 HDw3ilsFduQozOLAYmU2TIpi3MCSo2gjsuTMijRs+6yFObIPk+yCTZ7ZzNxgL/dG3JPdOnjpYb9O 4j8cKzkbcdgkHkzClMWF2ZAmSYgQW+Cnn/rzh6/T/ux+/v3q/nw+nX6Yze77txPPPqrVB7YeVcrO WSjLLTSAevB5jDv0W/SzAxVqQHWlliOjUDZPoQy8UGMKJV/lEOaJWguFPAkLphf96eV8eleQS8Lg rqWe36Z/3r+dPigK/YfZ7fTXy6+qLvfqFW/8t+9/fJtohY0ZSS1lRUkuBYqkl4JZEow0vKQYaQRJ MtKIkmWkkRQUlSXPFIFaMk3FqrBbDolchXME5CqdN5KxJy85p+62ZJ3SjCXvlGYqmac0c8k9Ba8u 2acqq+Sf0qSSgUrTlhxUmjULVQWXPCQ6LNo4+3zJfvCPm0/f59P+nBV3Mvuzf3Pzv/6f7B/z25u7 L/07+fl9enU/m4Px1auJA2QPvB5gPZB6wPTA6AHQA52v0C4mDmp3TetQuoPOh3GoHs8y0aCjUXoJ lIFFII0AFsEQLahephdshbcTaiH5/uRfH/r3H/+ramT1p59Uqr7LTs/xV539rFplMThxAashYpoa 8egCFh/YDNB66HegzTCuhTjgtudKhQGiHUQPz00RFgMWScJ6ULtMmZEw88VTu0bdGsUGKfxoPm8U ac4ZDBgIMhAwjDfrIJwcwskhnBb9tPAhu+lDqflQRVSdyNZQW3KiNlrEuE0x+Qli/IYY+O5+YvKm GPtjMXlEzMSmduggwyPVIBMjDSOhWQTOgiI3I9G1Z4t8ZHESLBbx1XRcbKGjMaw/H4vqZcoLByBE nrHIQxZ5aBgPCGRCjiDkCAo4VwIOlYATBYc/BZwlEERYiLAQYSFCwqMIeRHycOgTigqKkBchDzsi 7JCQYQlFA+HspnZ0w64EuxJMRzAVwVQEUxHObMKRTTiwCcc14bAmOAjBQ6i5SHMFnHkWwWgRpBZB anHm2XYiD3pu/Ei1hNQ6UKRcqZMrxUSPhGlasdFKjVZotDKjFRmtxAByAnICcgJyGooKaKKVEw15 KyRaFYEykQzktfINeY2Q18g0fHaFkoF8g8NcLgq1PgJwC+CoJ+WSUClqIpw1BmePXBAqhSIc5LlW bUEeNGygYQMNG2jYeMhDXSu3gkohzzd8YZX6Vsu1Sg7BKJe1Wgy2AhYMBAAEANQKXQCgVkTGZSoC MREqN1A5+utJwLfAi/51uTKWVNnqZs6OteDj9OiWsqwy/esJN9737y4fZt/v+3/Pb+5v7j79Orue 9u/m5x9Lafj69ubTHd8ZLuf39feXu2suudktO/L9z3fXePY+dIF8zcummppXPt1YlQpG+yiMJ1yY Ttj/Oq1zZnfnJNNp9j+5skZTejl9eJ86J73mYrGZFazDtCXAnFg6vpexgP709vJq+gd39ie3s6sv OISwCbVQPuEaomqOEtBcITdtVtus7Am19WIv3nQu8laClLRdDFzuR7k5d5FKbwy20z5ETSNbWUxb 2kpMXXaWNzSyEy1XluIbtRgTjPVutaJ3t+Ibp+U9AE7Xk9n1wwYPCY/VW3ls4TFbeVzhoa08vvDY rTyh8LitPLHsy2/lQRgeEh1+LTpY3RIdZQ66/mZ1pxEutWoRQL805yOkDAvns4h8i8hHOY39tj1V aUNtNWwobJh92TVludWMM+rj6VDNmLyqmRy7PfTSUukhCMK6bTKH1D4QahY/SAnarGLg6mpPDObY LupSZ/ayRD28DoGQ17RgzZ5KsMdWAmdX/VgAawk96Y5rYi+vBffI58OsvdI5q57qYZ+pRfbwkmCR 0PWxDntn1w57F6Tj7CvDO5n+ZzafKt1xvcnHMZSVaKUA0KsFwPGQOBe7pwKxhwCx6yFsnd+lEzcK xR0ZSuhsfCoWfxCWms+XMpvLu9TiR6GE40LxeqdaxrHEg9w2r/kt3zl2qSWMQklHhuJ2qmUcSz7o KF733N0xFEeRGH1UKNZ1KT4Zy0Hp1oS1IsnZuMtEcdxEho6bXfyOlBu36MUeN6KD2QEljUNxx40i vmPuMlEeB+OP6rthd0TrcSzhuIrhenu7Wuw4lHjkMLLdDhNtUUt65igy41DyM0fRlmJOP7PjxvHC hY5b44ZdNW4Yj2cq7zTy5nuPFabDKq011UU2YgM27joUjrmmCcPtaHzNyfr70ZXbytp7CHyNgLjy /ymWXrmOvpeoL/u3CsY7W3zOMPVzRrlDBb85+fLj7XTpFWS0nSW+HsuneNfueXxH6yLHsUkqcsVt NCXnlu55I68V8WHD4MOGaf8pAR82UGy18qJqa3ihOOgUn1Vw7rdDt5147bBpiX5MCj7mIO+1pNMi vuXmFnU/ltLej6851slsfj2dn3++ufpyN/32bWI6vrey+9QffroAy99nt7P5hO/ZCn9t4Oz+4XY6 6c9mtzfX/ZvLb5+nAyl9F831hndabwZEdh9E0ngqoPqwE497YXj8C8NDLwxP2BePNA4AVB+2IErm r42xuIHIPSLqBcOjINTVtiyWnnOx/IyLef2ciz3Wi9rf/m69/Lvm1ct4/i/AAO3ZQQINCmVuZHN0 cmVhbQ1lbmRvYmoNNjkgMCBvYmo8PC9MZW5ndGggMTgzMy9GaWx0ZXIvRmxhdGVEZWNvZGUvVHlw ZS9PYmpTdG0vRmlyc3QgOTA0L04gMTAwL0V4dGVuZHMgNjggMCBSPj5zdHJlYW0NCnjazJrbbhs3 EIZfhS9QiZzh8AAUBuKmF0FcVIgN9MLwhWOriRHXChwVSN6+/6y4jrTS7lrerawLSRSXh48zw8Nw 1iVnrHGJjCOPXzYUM3698az/xUiK+A0mei0XTcqM32Sc9fhKKOwiamc8pSxIOOOYUCYj14sm8JGA VjJaDISCWi4KquegTWitaMhqjzkZclET2RA78FhrSNsh6wwJWiWLT2RNIDdFPLfesHWaEMNOUNAG w5Q1EQ171kQyLFFrZcNRW0YFToIc5wxnLezIeKct47GnqDmQhNeWnRgvoomABAQBTOOjIriEBGtO RkIJMUifKCDhkIAUidByDh4JNqIjJchbIEQkIGQdMqGCMKoSRSO+KpyMBIATZSNRUdlCIxAbZGOC 9ZpDJqhCiNkEUkGi9eCtlhETBODEwYSADgmUIQYtnExQVRJnE1WVBP3GSqLemciC6mg9CqRFnk1E fSS8iQnjhkJMzChIPphkFdXDNKyOHW0lHSX5bBKrWCC1xDAhgmKShyQII0kQIhKMBOyCxJskGByJ mBQEnYIgRaeF0XL0Wh0tRxUmHqcMPVCwJlv0TMGZ7KImyORK74FNZvAS4DKUgYSYHKAiCsFkNT+C UeakFhfUnq2yBhi0rVqCXTnL2gvsAIpSiailW1HeCKO2UfWoxmpTBBY+DpU1D3btnBotWnKYGJpC H86rcekMcxLVeK1OHwzy11+nby7x9ef07PrH4t/l9K/Hu+Xdw6c/Frfz6dnjxcfpxfz78s393aeH 6fny+nG5+n73cDt/WGKuTkimvz/clv8Sgmacf72+mZ/O/148zo2dYEblHE9OrqYznX2Y9h+m59PZ yQm6fX/pMHjkYO4m/b1q4JwuHm/njxef726+PMy/fbsktG/cBPoqiatS5LfF/eLx0uJJ+dQPzpc/ 7ueX07fX3z7Pb6fni/u7240/V4UMylmRXbyt0VJaoWGxOTY0zis0TJ590MrnRWRr3x1g3hUwOjYw LmD+2MCkgIW9wfTPALJVVhvamOuC71sXEm+sCyP27X2c7NP1++oooTkqk/rZWf1MqjVhCGDc5HN+ 4pChNUrOLwztFbhsa4B3FcHp6eL7pbgJtvucdQucYL8Q7NQOlbA3RjvxyeHIcvWTbr3zpwprBNFN BGud89PZPaT0D/Kmp/eLmy/FQvVggP0allltsivR6OFjRXb++frrfDr7ZFYreC2og9oPcU0z2yKh Q1pTFwgPAaGUN0lwpuyRibetKH5klDTh+FIWGcLCuTGdcPrrE4trRQnjoojtFUs7SxxktrlhtzgT 9omFWlHSyCi+VyztLHkIS7CuYbk86SHhVhJnR0XBEscvZ3HjqihSHwxLOwyNKpjQay4c2ll4VJb+ Gc3tC53zh1YS5XaYQcuuC40tAOeRSeqRTPukdmHc/Qh03SgdMymOuwcE14Pi21HSuCqCc+669wDq mEj5sCqi2H6gs4dVEXWcLcc95mKKhx4NtS+75KtNopbb2eni9sd2oWGnrYboVKkFzHXoy4Utp0F7 gStTPAy9wFQfuLRS3WNWPnHmlU88M6k+KZ3Pb5ZPI+5tmKg0yOW39v6rK9Ktytcf7+c//SyCkYbg 9GrQWV97WpzTxJPVm8HoVSCeIq25W7udqOIYVPee1e/qRFwfAeszT73Lr5Rd7yUXH55aKaW5lOYy rtUyUm/L9ZbY1gqVUqv5Xk+22tLrfaPezHa3Ul1Rb7vCzfuKpwuxfW/FNq7DdtyKFVWuXaVU9+l7 EO15tbN9P9fPQ0fGw8fFY+OR8YR9efa5gdsBtHEDt4uI4+vOMd6WUeonUoZnIax66+gsH7AzZw85 Mn/IzuSZVvSSi+Wtu+6mVfP/d6/cf2Bi1ww4ZV/OFvKqUZ1yNFkPBZAvu7g/OjSNmK+kFl8xfLIT rATpcj4uMH1/oFKmdccGVs6Oll814LSFdtiAQX6tgFOz6/dPTtvMFEdoLeCk738MDDg5bt5LV/dG uyNOtU/1yhEnV7lo4clFk7gVbQobMZ5Z9ZpG0/UNG+GXWfUGR1eZyoUOtrOMVO34zjL6fslArTXN ijIOAy06E9nUGSa5FFdOiisXymok/smlk9C0tdLOurwb/rQUj9HnTsdc7NDhE0a3Pqlcqnb65wqg eudnIII0NMCpI1K7E4HGNoIYJ/HZBK8zc3F28UFnL4c6VszObc1eP1asuHknJULdSz+HzSt6P1as eIvE0+SlIAeOFXOgVpRDx4q7WAbGil1zI5Q+sXArShgZJfSKpZ1lWKw4Nd9IkdwnFt+KksZFCbZX LO0sg0IWkqUxnV2fVKSVZFiseAvF255gWyfLoOXW+aZYLPfBSLuKhsWKt1eXKDg2dKF0yIXHndGR e1BCO4ofdxalnpc/WGI7i4xqurFvyZXUjhJGtVyfbU9AlH0HTDys5frcjpIObLk7zy3/CTAA8UIq cg0KZW5kc3RyZWFtDWVuZG9iag03MCAwIG9iajw8L0xlbmd0aCAxNzM3L0ZpbHRlci9GbGF0ZURl Y29kZS9UeXBlL09ialN0bS9GaXJzdCA5MDcvTiAxMDAvRXh0ZW5kcyA2OCAwIFI+PnN0cmVhbQ0K eNrMml9PGzkQwL+Kv8BtPP88tlQhles9VMfpUEG6h4gHCrkWlSMV5aT229/MrpODhN2QJiwgEU92 x56fxzP2rh3MEGLAjAHYSwqoxUoOjP5dgoh/TyGVbKWGTF7mUFStLAEA7EKJAVDsSoEAVJIJ1qSQ CxQgqZjAATK4IAGKsAl2Oxa/YjWR/Iq1RWoUxawKUKBoGEnQBHA2MAG90WiC307FPjgQRjVBAhG7 kAJxdsH+E9rlmE1I3o5VUKMjsCay9ZLAGs3GQ2BXi9khN1xaHXNEVNeRwO4igmSu8aqgJmQXcmAS F0pgd5uxmFBcgMCSXMDA6lBIgbMro7VcioObj8GcSpiC+EgQahBr2oRs7lfXKUGS81i3JTshQZDi GIQhRbNMRCFBIndASD5CRBISk9ey4RP2WhpScutmz8bEa5WQcjJl65tGd4DpKYj7D4Oa602goOQY zEHZYoRYgtV25RRUyZU1aE7gXg85+jhwCRnMf+6abKNrAlj0OI8NZ2bnEQpZLMjIvJ/VekkiIXuI kRHk4kNpUVWi84gFHTiPcZd2GM2zpe2gGS6S26G2wGS/QqFkCy1KFnUxso++hV1Ed15KJrkFSmoS +yiaDyAmDymLKIhqw0s28Ca5d9TCOmaPM0WXPBIsTE1Sa8V8A2bEa4hLHq523aTsd9WTxGNQzYYJ LnnikKUZmW0AsZh+82byu+XF5O3UpD8nR+c/5v/eTf66vbq7uvn0x/xyNjm6Pf04OZ19v3t7ffXp ZnJyd357132+v7mc3dxZZGmDMvnt5rJegEx+4eTr+cXscPb3/HYWYgPF/vTg4Gxy3I5JDB8mJ5Pj yfEnGzT/dnDQsmDchUWKPGRR2YSC/SiwCwrwCgqn2KRhGMudXhjcBcbmzIcwFjNNHERJ/Si0CwoV eIiCShtQtB+FR45cmyR6WWTcyLVJtBcl7TdyGZqsgzA4kEY6buTapN+LkseNXOR+lLHnXOyfW2jk ORf75xba85yrsIGF+5ciwr2ySIQN0dI/txDteSmChjYk9AAMj5vQ3D+3kIyb0Nw/t1AaOaG5f3Ih HTeheWBuySPP/v2rIpWRn1tiLwrH/QaL6gaU/lmOYa+xksoGkv5k5p3mW1rxiWTe+NAy4BXaK0sp Gx/9+7OZeZ8siagZTub+x21WV4iLpeHocH7545Gnia6BHZhXkKlbrbxGvfILxSZW3rjI+KP3S4KO 8Ljdbqk3l/fK8t5i+L3hw/n3TmNa67QbM15iaku3lRc1TmYXd0t1rupSy1RLrWWuZelKjF1zb9sd nzWW84/Xs7bpQ0OaokCTUvv6XnKDGiX69kxuLJGiZbWyjV7EzHz2v6+Pr21w/zE/TQ6v5xdfFqCp 9itBLbGWVMvakSSL/lYXONaHRStStaVqS+221G5L7bbkoVa4anF1DlfnSGWUyig42ErV5qrNtUdc Gbky8mCPqGpR7QnVnlBlpMrYvXD1tYJVG6s21h5RZaTKSIM9wqqFtSdYe4KVEStj9wj9eCvt1uR6 Bh7Oby9nt6efry6+3My+fZva02hAS7Tuw76dVZVf59fz26klWKj/ixsndz+uZ9PJyfz66nLy7vzb 59myaK+dLebVRdKdvlu+eOVtiFz4WaDuy0ae8rp4SnxlPPDKeHBbHhd2AOq+9BP5zvdL5hiUFaKp H3W061Wps90gmsM8iaUz22e1PSrZ6If9GYMxjeGYxp4aTov/7eP7/ufD8F7lGfkxfPnAuXSGbOGM n0ut9ZRfOiOvrxb0bJHwiDEe05iMaSyNaUxfMqHWePzQ8gVjWtdX1OeL6UeMpTGN6ZjG8pjGykvG tD7fIrF5f4Tj2iLxogmV1gZHny8SHjFWRjSW45jGYExj+JIJtcbjPzJ5wZiW9TB7vkXiEWM8pjEZ 01ga09iLPvjIsy0SGzeuhR4uEVOsO5vY7WxueCOePtg62CaxHtk4WMksXn1Z91+DdZut+trQsNv/ Na+lrdC23ARa3/7ZDKYVLL82sG6vFzW+MjCFCoZbg20zKzxCtjIt8PM9OwpuOJ1O8GBe2KdtxmYb 0+2RjkDDajop5Lg40QGKjQTV2HAGjHDvMOe+/WWF+4fz0AjkDNxz7BMDB2lPm3R58qWLJ4+Tz+df Z+0JHt47wYNWR9dO+e7rYKuTB3Wo1aFhHcVdTwtl5Qi6UPsy0XNcqLxyXDitXV10Z4Hcacvq+WGt f9+LK+eHWs9oUhk4N2x/57tjx6Gs/sKo0af3u/198Z4Jktl7KsBAMkij2F7URA2muF1C5EY5RoTe hEAzEYDbpMjL4cy0mhTdEd7BwX8CDABEOr97DQplbmRzdHJlYW0NZW5kb2JqDTcxIDAgb2JqPDwv TGVuZ3RoIDE3NTQvRmlsdGVyL0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDg4MS9OIDEw MC9FeHRlbmRzIDY4IDAgUj4+c3RyZWFtDQp42sxZ3W7dNgx+Fb3AfCRKJCWgCJAMuyiSYUFbYBdB L7LmoCvWJUOQAe3b76Nsn5xjze5J6iG7SKzYJMWfj6SoxBycdzGTU3tEF0rAMzmK9je7mDKe4pK3 9+pSVDyzSwXfcnEck4vFO4aICF4JBU9ywoJndJrtmVxm0IMnZ/surhDkFnXBs73ILoT6pbgQA8R7 70JKWvcNrPaGXBDskDy01ERYJCzqJ3Yhh4SFwIDEWEByyUaTHflg+hcsoEQK3lEwi0IwK8EVCIv6 KWJhW0AWJcLugbGQiIU44mILdSQRm0JLEsUWsJgUwhJBck4eC0guUrCAU7x5jaKL5tpEcBeZ8gR/ kAkkOChWLng2idHANebfRPAIM/ayYAhClaJFAQ5I0dwN1hSjOQJWRLPfuGK1xIjNSOljBlkmx37s eyz2Gb9sY3NSSmBg4zDlhCEsQbLCtcmkq303z2Y1DtBlE2gRKtAlJYOEGg0w4RHKxABFMPEcsFBw MAEuiAz2wcLUwDZc1YD3uaoB2DCbXaxYqNFkx0KmHSSrKSWQrBZcOIuzmSyQXOOOUHEBHJMkJ57s DQOTZo6IgRNy4BGh+iljIfapODFwwlwA19SAJVI9rwZlC5NGJ0L2BpLFIAHlRIv5BpKzeVQhOat9 guQCWCUtSCzzaPZOAz69erU5v0IQHSx34tRlB8gD7IA5vd+c1lz07s3msqajrd5u3v5+/dd2c/kR qLI3JyeQcnZ29+UqSOgC0hMOy74jRAvKc0pdQQIhYZRCh8QpnN5vftlcXH+9+/th8/bh+v7h9e3N 9vbhkWvz0+3N8C6Q77ioj2Fz+fn6w/ZPvNycfb778Efd+PwKCDQ1oKAVjzfvoWu/MlW3Hx4e9WNs r6WUffVC5E6pvlSJHYn34Qnaae4UxtGccnAl6kMyV1rtGFyJ4E5dKTtXnrtQaWSguTi7u/k6pbki h3JlZgP39VFG42P/YZYThvZkeZEMrvG9Y4Pv6csSPSADotSzzBNRlUSLRFbz7PvpFf7cReLX+08P n24//nx3s91c3L/7bfNu++Xh9POnj7d9kA5CxdwR74UpSqdcOYYXP0Tf+ZOT3rAR2BevR0j1zh9d Ofpq9MFo5mhJLyWNUnZmxCbepgGQuNsmDcjleeSe14b3nf6I1Pk9d7DkLtDxDqm9duWQ8JNCUrv8 2hoEOOUJCpTVFSjdUzxQ/NowKL6LxwdhoYaiRP9H5ROtqRbP4Idksr48LZ5pUjzteDWtMPs0VGl4 kcbOc9/p7lAayM+7206LkzI0mDGq2lPppMyMfPueOSwzA089sy6UGTvJrmyw+k7oaIMn+NL0jB69 Y3oSyHD6qSCjsUPbcXoKMpqCLLQgoynIyC/SxCqHF2ns+L92OwzztddmiykOw4DD3ppR4566wWOQ xokTPIYBjyEs4jHQ6glYZit+a3YdwFZWAH33aL+/4JHV0cxI0J9mMQJj+MW0iznX2byJSRNzaK45 FMeBwQbHaQ75/RMstqGeJRzLgom4bwfRH8eCMbkmdjmWXI4P94/w3PZ+kmi5y3oQcW8nrSHENCbL ZbNxImlUnKQNDWnTV4c6xffPNDz5W/MPCeYzjGIYbwlIJG8YwsjbYW4tmEg5U1d8mMfTI9ueiWRp VSCh/Cuihq1jhxHOrl8wBAraOazgpJ2v8LX5HDIoqs7s/Mi2X8dKgL4qFJd2pg7ztY9Aa0A6sPhw sDXBfkAwisxs/ch2EFfucIwWnxa2fuxlCseLzcAMPsUcUWruehb1NNfLRqbD5C1IsRy/eWBKu6SK ZQr5vjDv97LU9KkDmtrLoizS2E3PyuUyas2mmYIZtWlUaWhQvao9VZ42qIFv3zOTTOt56m3WUoOK aeUDeUzz/Wlq7cu1BzSHHmF59GPSBmHSICw16Nmnsfu9ldFTdL7ZJm66/aDgZb1PnEBmIN83dQKZ nqfeVx57CVXoGSHbMT0rZLyzg1MTsmaK4tCE7GBCYr96yMLSwMDUBI13VY7jNGhMjbGToPHQQVP5 PwYt1JDJ7qTDbR0PBzX6tF5PH0PdX9eiB5pVMAXNFW2fkQKMIdXjJcMqUnubSp5rjDu2/fvakDoc BjjojGF2qV69zvosrx9z1/A8h+O827t8d1qUprDtdbyr4PJwL1jhKc2F6kF7rCRpkUTWHzhovqMI N/1ThsbX69lTNcVQuHHPJK9kiLAsD3iy+oAX48K9ZmPwi4BsvGvIu7zWBmRN89QGWjI9nWlZIqkX DZqWSOx/Smvf/6Slcq4t/nTAnw4XDvqIQ21wqNx4cIJDHXCofhGHGtY2PMT5u+XW7vp/vbVdH5aO zvqimfCPAAMABtxI4Q0KZW5kc3RyZWFtDWVuZG9iag03MiAwIG9iajw8L0xlbmd0aCA4ODcvRmls dGVyL0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDI5Ni9OIDM1L0V4dGVuZHMgNjggMCBS Pj5zdHJlYW0NCnjarFbbaiNHEP2V+oH0VFVfCxaDveRhWYeY9UIehB8cW3hNHCkYBXb/Pqd7NPLM bEYrooDE1NRUd51Tt+5QhJhCUfzx8yQ+4hlIY32PpJbxTBSk6iGn+iwU2xKjJNAZU4p4N6FU7U2p NL2nkqs+kDH2sEgW4M4SWa7fM4lwFQqJeng0qwiMIjNJALjIQpJYIShJFnhmoCy+CoHEYoYAnJyr JpGKVU0m1RAgFAhW9zHSIJ6iMAQgjCJgCbpRFEJdjs+apH5CAFJIELBzKkzv3nUfV4B01122sDB9 6m5aoKp0291+uf9r3d08ka+Ki4tmr3gDBEqUqRCYYQOwAQ8wAPYIZuAENv22/pRtr662X1cSkvM+ +RoBL46LMPjF5F0xZmycJbscwSzfdb921/fftn/vutvd/evuw+ZxvdmNlnU/bx4HpQaHqJXsu5uX +4f1n1B2Vy/bhz/2jEIrl0+tYPC8A9heU7GuH3ZvCKO4kM1qptVp5poIZNZlbcoMqJoAdQHeYdEI XS4uB2aVBXAoLEotkiinfSRN55GUtwSRdJcrCAcEv70+7543T79sH9fd9evn37vP66+7y5fnp00P bgIRAdQ4ghdjcknjxcVdc+z3jm/mTrV9TvvP11fbx29zE99M8jGT2HjKKTxbPryZ8+gqdEi0fewp qrnCSEihHLyLKhyXCuawakTZCpJcLCyWSx+FNgD6skn7d14un49tzsx51UyAx2Bh8bjFah/hIYx9 Toa2uj446gvljCpA0nkUEa+Mvmsr9pqfPDseiiIOAD4cENj/jYCzK6dDmDUrMuRyEq5TadqtHFNm XSiOt2XTfkVpaFmoDuLTWb/H2vXrdICF6GTSgJKsanqidcyPGjAq/7e+/zfPxc884/BxJznWsxwX m2Q6y5DVepQt+vRn+VSv0zGnEkZcj/gN5xS1aKl9NEqu1MYa3Oqy23jWTOfg/MQvTv+qGRz7Zcfp LL4yr2Ybl1RYdptxENRrSj8O6zVndhBMzUs153KaeRsO6Crtx4CE0Lq83sSCDMMBN8N6MFhJS1eN w7IRvaCYGN5YwsLZse+jocaGpA85GILS7nz9Mx85U1b1ZtmbHY6eN/LTo6NeOXtT/YFpu4vOIzm3 CD+0iEct5hMa5zALtysz5nrsh3NTLA3nw4rZcC4WvX4f/n8EGABY+C25DQplbmRzdHJlYW0NZW5k b2JqDTczIDAgb2JqPDwvTnVtc1swIDc0IDAgUl0+Pg1lbmRvYmoNNzQgMCBvYmo8PC9TL0Q+Pg1l bmRvYmoNNzUgMCBvYmo8PC9Db3VudCAyMS9LaWRzWzc2IDAgUiA3NyAwIFIgNzggMCBSXS9UeXBl L1BhZ2VzPj4NZW5kb2JqDTc2IDAgb2JqPDwvQ291bnQgMTAvS2lkc1s1MjAgMCBSIDEgMCBSIDMg MCBSIDYgMCBSIDggMCBSIDExIDAgUiAxNCAwIFIgMTYgMCBSIDE4IDAgUiAyMCAwIFJdL1R5cGUv UGFnZXMvUGFyZW50IDc1IDAgUj4+DWVuZG9iag03NyAwIG9iajw8L0NvdW50IDEwL0tpZHNbMjIg MCBSIDI0IDAgUiAyNiAwIFIgMjkgMCBSIDMyIDAgUiAzNCAwIFIgMzYgMCBSIDM4IDAgUiA0MCAw IFIgNDQgMCBSXS9UeXBlL1BhZ2VzL1BhcmVudCA3NSAwIFI+Pg1lbmRvYmoNNzggMCBvYmo8PC9D b3VudCAxL0tpZHNbNDYgMCBSXS9UeXBlL1BhZ2VzL1BhcmVudCA3NSAwIFI+Pg1lbmRvYmoNNzkg MCBvYmo8PC9MZW5ndGggMzU2Mi9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1MPj5zdHJlYW0NCjw/ eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRv YmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+DQo8eDp4bXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5z Om1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3b3JrIDEuNic+DQo8 cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRh eC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPg0KPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MWU3YzgxOTAtZjUyYi00ZjY2LTkxODItMGYwNDlkOWUz MWQzJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpDb21wYW55 PSdFbnRlcnByaXNlIElHJyBwZGY6UHJvZHVjZXI9J0Fjcm9iYXQgRGlzdGlsbGVyIDYuMC4xIChX aW5kb3dzKSc+PC9yZGY6RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0n dXVpZDoxZTdjODE5MC1mNTJiLTRmNjYtOTE4Mi0wZjA0OWQ5ZTMxZDMnIHhtbG5zOnBkZng9J2h0 dHA6Ly9ucy5hZG9iZS5jb20vcGRmeC8xLjMvJyBwZGZ4OkNvbXBhbnk9J0VudGVycHJpc2UgSUcn Lz4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjFlN2M4MTkwLWY1MmItNGY2Ni05 MTgyLTBmMDQ5ZDllMzFkMycgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv JyB4YXA6Q3JlYXRvclRvb2w9J0Fjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBQb3dlclBvaW50JyB4 YXA6TW9kaWZ5RGF0ZT0nMjAwNC0wMy0wMlQxODoyNzowNCswODowMCcgeGFwOkNyZWF0ZURhdGU9 JzIwMDQtMDMtMDJUMTg6MjY6MTUrMDg6MDAnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDQtMDMtMDJU MTg6Mjc6MDQrMDg6MDAnPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9J3V1aWQ6MWU3YzgxOTAtZjUyYi00ZjY2LTkxODItMGYwNDlkOWUzMWQzJyB4bWxuczp4 YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0n dXVpZDo3ZTgxZTY1MS0zOGFlLTQwODktYmJkOS1jNDVlNmViNWEyYmQnLz4NCjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSd1dWlkOjFlN2M4MTkwLWY1MmItNGY2Ni05MTgyLTBmMDQ5ZDllMzFk MycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9 J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gt ZGVmYXVsdCc+UG93ZXJQb2ludCBQcmVzZW50YXRpb248L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0 aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPkVudGVycHJpc2UgSUc8L3JkZjpsaT48 L3JkZjpTZXE+PC9kYzpjcmVhdG9yPjwvcmRmOkRlc2NyaXB0aW9uPg0KPC9yZGY6UkRGPg0KPC94 OnhtcG1ldGE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4NCmVuZHN0cmVhbQ1lbmRvYmoNODAgMCBvYmo8PC9N b2REYXRlKEQ6MjAwNDAzMDIxODI3MDQrMDgnMDAnKS9DcmVhdGlvbkRhdGUoRDoyMDA0MDMwMjE4 MjYxNSswOCcwMCcpL1RpdGxlKFBvd2VyUG9pbnQgUHJlc2VudGF0aW9uKS9DcmVhdG9yKEFjcm9i YXQgUERGTWFrZXIgNi4wIGZvciBQb3dlclBvaW50KS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxl ciA2LjAuMSBcKFdpbmRvd3NcKSkvQXV0aG9yKEVudGVycHJpc2UgSUcpL0NvbXBhbnkoRW50ZXJw cmlzZSBJRyk+Pg1lbmRvYmoNeHJlZg0KMCA1MTYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAx OTM3OCAwMDAwMCBuDQowMDAwMDE5NzM2IDAwMDAwIG4NCjAwMDAwMzEzMjYgMDAwMDAgbg0KMDAw MDAzMTY4NCAwMDAwMCBuDQowMDAwMDM4ODA2IDAwMDAwIG4NCjAwMDAwMzkwMjYgMDAwMDAgbg0K MDAwMDAzOTM4NCAwMDAwMCBuDQowMDAwMDQwNTk0IDAwMDAwIG4NCjAwMDAwNDA5NjYgMDAwMDAg bg0KMDAwMDA0MDk4OSAwMDAwMCBuDQowMDAwMDQyMTI2IDAwMDAwIG4NCjAwMDAwNDI0ODYgMDAw MDAgbg0KMDAwMDA0MzI2NCAwMDAwMCBuDQowMDAwMTE5Nzg3IDAwMDAwIG4NCjAwMDAxMjAxNDcg MDAwMDAgbg0KMDAwMDEyMTA4NCAwMDAwMCBuDQowMDAwMTIxNDQ0IDAwMDAwIG4NCjAwMDAxMjIz ODMgMDAwMDAgbg0KMDAwMDEyMjc0MyAwMDAwMCBuDQowMDAwMTIzNzUyIDAwMDAwIG4NCjAwMDAx MjQxMjUgMDAwMDAgbg0KMDAwMDEyNzMyOSAwMDAwMCBuDQowMDAwMTI3NjkwIDAwMDAwIG4NCjAw MDAxMjg5NzEgMDAwMDAgbg0KMDAwMDEyOTMzMiAwMDAwMCBuDQowMDAwMTMwNTEwIDAwMDAwIG4N CjAwMDAxMzA4ODUgMDAwMDAgbg0KMDAwMDEzMDkzMCAwMDAwMCBuDQowMDAwMTMyNjYyIDAwMDAw IG4NCjAwMDAxMzMwNTcgMDAwMDAgbg0KMDAwMDEzNTAyNiAwMDAwMCBuDQowMDAwMTM1MjgxIDAw MDAwIG4NCjAwMDAxMzU2NDIgMDAwMDAgbg0KMDAwMDEzNjc4NSAwMDAwMCBuDQowMDAwMTM3MTQ2 IDAwMDAwIG4NCjAwMDAxMzkzMjAgMDAwMDAgbg0KMDAwMDEzOTY4MSAwMDAwMCBuDQowMDAwMTQw Njc1IDAwMDAwIG4NCjAwMDAxNDEwMzYgMDAwMDAgbg0KMDAwMDE0Mjc1NCAwMDAwMCBuDQowMDAw MTQzMTI3IDAwMDAwIG4NCjAwMDAxNDUxMDggMDAwMDAgbg0KMDAwMDE0NTMxOSAwMDAwMCBuDQow MDAwMTQ1NDkwIDAwMDAwIG4NCjAwMDAxNDU4NTEgMDAwMDAgbg0KMDAwMDE0NzMwMCAwMDAwMCBu DQowMDAwMTQ3NjM4IDAwMDAwIG4NCjAwMDAxNDkzMzggMDAwMDAgbg0KMDAwMDE0OTU2NSAwMDAw MCBuDQowMDAwMTQ5NzE0IDAwMDAwIG4NCjAwMDAxNDk5MzYgMDAwMDAgbg0KMDAwMDE1MDM3OCAw MDAwMCBuDQowMDAwMTUzMjc2IDAwMDAwIG4NCjAwMDAxNTM2NjQgMDAwMDAgbg0KMDAwMDE1Mzgy NiAwMDAwMCBuDQowMDAwMTUzODkyIDAwMDAwIG4NCjAwMDAxNTQwNTAgMDAwMDAgbg0KMDAwMDE1 NDI4OSAwMDAwMCBuDQowMDAwMTU0NDUyIDAwMDAwIG4NCjAwMDAxNTQ2MTYgMDAwMDAgbg0KMDAw MDE1NDY2NiAwMDAwMCBuDQowMDAwMTU0NzE2IDAwMDAwIG4NCjAwMDAxNTQ4ODAgMDAwMDAgbg0K MDAwMDE1NTA0MSAwMDAwMCBuDQowMDAwMTU1MDkxIDAwMDAwIG4NCjAwMDAxNTUxNDEgMDAwMDAg bg0KMDAwMDE1NTM3NyAwMDAwMCBuDQowMDAwMTU1NDgxIDAwMDAwIG4NCjAwMDAxNTc5NTkgMDAw MDAgbg0KMDAwMDE1OTkwNSAwMDAwMCBuDQowMDAwMTYxNzU1IDAwMDAwIG4NCjAwMDAxNjM2MjIg MDAwMDAgbg0KMDAwMDE2NDYyMCAwMDAwMCBuDQowMDAwMTY0NjU1IDAwMDAwIG4NCjAwMDAxNjQ2 NzkgMDAwMDAgbg0KMDAwMDE2NDc0NiAwMDAwMCBuDQowMDAwMTY0ODczIDAwMDAwIG4NCjAwMDAx NjUwMDMgMDAwMDAgbg0KMDAwMDE2NTA2OSAwMDAwMCBuDQowMDAwMTY4NzA4IDAwMDAwIG4NCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCnRyYWlsZXINCjw8L1NpemUgNTE2Pj4N CnN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K ---MOQ1078224931d5a268a3ea1176d35fba781154ebbb08-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 06:54:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04899 for ; Tue, 2 Mar 2004 06:54:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8Tp-0002kl-FN for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 06:54:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22BsXrm010579 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 06:54:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8Tp-0002kY-8Y for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 06:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04886 for ; Tue, 2 Mar 2004 06:54:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8Tl-0001cO-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:54:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8Sz-0001VI-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:53:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8SI-0001NS-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 06:52:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8SL-0002gA-Fm; Tue, 02 Mar 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8Rn-0002R7-E9 for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 06:52:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04762 for ; Tue, 2 Mar 2004 06:52:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8Rj-0001KK-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 06:52:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8Qn-0001D4-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 06:51:25 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay8Pq-00016X-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 06:50:26 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030203510882:59117 ; Tue, 2 Mar 2004 03:51:08 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1078228225.1050.6.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 03/02/2004 03:51:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 03:51:10 AM, Serialize complete at 03/02/2004 03:51:10 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] test Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 06:50:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am testing to see if this makes it. My email was misspely so i havent seen a single message posted to this list. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 07:29:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06280 for ; Tue, 2 Mar 2004 07:29:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay90s-00072Y-5R for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 07:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22CSgcg027056 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 07:28:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay90r-00072J-RI for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 07:28:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06262 for ; Tue, 2 Mar 2004 07:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay90r-0005wY-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:28:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8zy-0005oh-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:27:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8zE-0005gd-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8zE-0006zI-LH; Tue, 02 Mar 2004 07:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay8yf-0006xy-V8 for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 07:26:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06179 for ; Tue, 2 Mar 2004 07:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay8yf-0005ba-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:26:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay8xi-0005V5-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:25:26 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay8wo-0005PZ-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:24:31 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030204251247:59140 ; Tue, 2 Mar 2004 04:25:12 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1078230268.1051.29.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 03/02/2004 04:25:12 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 04:25:13 AM, Serialize complete at 03/02/2004 04:25:13 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] views on different channels vs same channel Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 07:24:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, since i have just scanned through tons of emails (halfway there), let me share my view on the the topic. 1) If you are using the same physical link at the lowest layer it doesnt matter how many sockets/channels you have. The DoS impact is going to be at the lowest layer i.e the physical link for which the only cure is to have separate links. The next level up is just before the packet is DMAed into RAM that the OS can get to it; there is some smart hardware you can program to have multiple channels and drop at the earliest level. Majority of the hardware you will find cant do this. Once the packet hits the OS, you can play with differentiation/QoS/rate metering of either the CPU time and/or bandwidth protection. Summary: having more than one virtual channel within one physical link is going to offer little protection against DOS. 2)On the sending: the value is going to be in having multiple queues just before the packet hits the OS. For this you need to recognize something in the packet. This does not imply the ForCES header needs some speacial signature; rather the packet can be administratively recognized and classified into a queue. Example could be recognizing a destination IP or MAC address. 3) The idea of having such unique names to "channels" is almost bell-head approach. Reminds me of my ISDN days. There doesnt have to be a clear cut explicit use for each channel (i.e thou shalt only transport data packets). I am in agreement of having more than one connection, but the approach is different. Like i shared earlier on our experiences: the way we had the two or more "channels" was to have different granularities of reliability. We typically sent on a cheaper but less reliable mass transport and on failure if the message needs to be reliably delivered then it goes retransmitted on a more reliable unicast channel. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 07:35:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06569 for ; Tue, 2 Mar 2004 07:35:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay96W-0007U3-Sj for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 07:34:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22CYWE8028761 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 07:34:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay96W-0007To-Mn for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 07:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06560 for ; Tue, 2 Mar 2004 07:34:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay96W-0006j5-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:34:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay95k-0006cj-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:33:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay952-0006Ue-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 07:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay952-0007KW-JU; Tue, 02 Mar 2004 07:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay94T-0007J8-U2 for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 07:32:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06443 for ; Tue, 2 Mar 2004 07:32:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay94T-0006Qa-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay93W-0006IG-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:31:27 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay92Z-0006AL-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 07:30:27 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030204310902:59148 ; Tue, 2 Mar 2004 04:31:09 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1078230625.1050.37.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 03/02/2004 04:31:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 04:31:10 AM, Serialize complete at 03/02/2004 04:31:10 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] on separation into two documents Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 07:30:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would have to agree with David. I am actually of the thought that there is not enough material to have the transport as a separate document to begin with. Again my thoughts on transport which may not have made it on the new list: - we should take advantage of transport mechanisms when available. (includes multicast, boradcast and others like TIPC). - The protocol MUST be able to live without them. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 08:12:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08447 for ; Tue, 2 Mar 2004 08:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay9gd-0003El-EP for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 08:11:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22DBpVx012437 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 08:11:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay9gd-0003EW-AE for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 08:11:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08414 for ; Tue, 2 Mar 2004 08:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay9gc-0004es-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay9ft-0004U9-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:11:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay9ev-0004Fd-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay9ev-00035Z-5v; Tue, 02 Mar 2004 08:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay9eV-00032o-Dt for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 08:09:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08077 for ; Tue, 2 Mar 2004 08:09:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay9eU-00048s-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay9dB-0003oF-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:08:18 -0500 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ay9bW-0003Ih-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:06:34 -0500 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: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i22D62N2012950 for ; Tue, 2 Mar 2004 13:06:03 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.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i22D7OXq001130 for ; Tue, 2 Mar 2004 13:07:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030205060132188 for ; Tue, 02 Mar 2004 05:06:01 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Mar 2004 05:06: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 Message-ID: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> Thread-Topic: Comments from chat with ADs Thread-Index: AcQAVxdbpPHWaZ5SSA2tld74bEVMgA== From: "Putzolu, David" To: X-OriginalArrivalTime: 02 Mar 2004 13:06:01.0388 (UTC) FILETIME=[1C8576C0:01C40057] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Comments from chat with ADs Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 05:06:01 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Patrick and I spent about 90 minutes last night chatting with Bill and Alex about ForCES, with maybe half of the time on the protocol. In the conversations with them, along with some follow-up chats I had with Allison Mankin, the following topics where covered: multiple=20 channels, multicast/unicast, and congestion=20 control. Below is what I recall from memory=20 (Patrick please correct me/elaborate as needed :) Multiple channels: =20 I discussed the interference issue that=20 was identified by the GRMP team. Bill & Alex agreed that many OS implementations can have an interference property (i.e. where two different connections will have queuing interference lower in the networking stack in the OS). So it is necessary to make sure when implementing a FE (or CE probably as well) that this is taken into account. Methods of doing that include: * Manually queuing packets (i.e. feed OS few enough packets that it cannot get into trouble - although you pay a performance price for that, in that fine grained scheduling takes cycles) * Indicating to the OS to treat flows differently -=20 some real-time OS will let you do this, that is they are implemented to internally retain QoS between flows. However, it was also mentioned that intra-FE=20 interference is only one kind of interference. Good FE implementation (e.g. by manually queuing above the OS) helps to fix intra-FE interference, but it does not solve inter-FE interference. That is, if all (C & D) packets are always on the same connection, that makes it impossible on the wire to differentiate them from one another. Imagine you have a bunch of FEs with some of them being subject to DOS attack for D packets, and you want to query one of the FEs for statistics. It would be good to have some way of ensuring the C packets (or any high priority packets - OSPF HELLO maybe) get through. Separate channels (as Jamal indicated, don't even have to be C & D) makes this possible. Putting everything on one channel makes it impossible to deal with inter-FE interference in a differentiated fashion.=20 Multicast & Unicast: =20 The discussion on this started out with a discussion of the IETF protocol design BKM that options can ruin compatibility. That is, if there are four ways to implement something, all optional, then you can have client 1 implement A & B, and client 2 implement C & D, and even though both clients are 100% compliant, they cannot talk to one another. Better to say all clients must implement A and make B, C, and D optional, so that way you know that all implementations will be able to=20 at least talk. Patrick & I pushed on this a bit, explaining that we actually had potentially (at least) two different environments - very close environments where multicast support could be present in the interconnect, and=20 not-as-close environments (and some close environments as well) where multicast was not available. Bill & Alex indicated that if there really are two quite different cases, then it is possible to have a "dual mandatory" approach. I.e.: If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. Congestion control: Several times over the whole conversation the topic of congestion control came up. Also, as part of some TIPC discussions, I ended up spending some time talking to Allison Mankin (transport AD) about congestion control as well. All the ADs I talked to where consistent on=20 the following: If you are running over IP, you MUST act in a RFC2914 compliant fashion (i.e. respond to congestion like TCP or SCTP or RMT does). Two reasons where put forth for this: 1) Any time you define an IP-based protocol you cannot guarantee that it will not go out over the Internet. As such, the IESG will NOT standardize IP protocols with "bad" (non-2914) behaviors. 2) Lots of implementation experience showing that other congestion control mechanisms don't work (congestion collapse etc). They where very firm on the above and my impression was that convincing them otherwise would be very difficult. That being said, a second alternative did arise: If you are not implementing on top of IP (e.g. running on Infiniband, ATM, Ethernet) then you could rely on mechanisms for congestion control built into what you are relying on, or even consider building your own congestion control mechanisms (ala TIPC). This makes it possible to define (for example) a multicast transport for forces without having to go all the way and implementing RMT - as long as it is clear that it isn't over IP. The ADs went as far as saying that the IETF could even accept standards- track drafts that say nothing about IP (e.g. define an Ethernet-only transport for ForCES), if it is necessary=20 for ForCES. GSMP and (some other group I forgot) was given as an example. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 08:35:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09173 for ; Tue, 2 Mar 2004 08:35:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyA2Z-0004rt-S7 for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 08:34:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22DYVnP018713 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 08:34:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyA2Z-0004rk-K3 for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 08:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09165 for ; Tue, 2 Mar 2004 08:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyA2Y-0007Ov-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:34:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyA1e-0007JN-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:33:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyA16-0007DE-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 08:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyA17-0004o1-05; Tue, 02 Mar 2004 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyA0i-0004me-IA for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 08:32:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09128 for ; Tue, 2 Mar 2004 08:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyA0h-0007Ch-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:32:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay9zo-00076I-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:31:41 -0500 Received: from ms-smtp-01-lbl.southeast.rr.com ([24.25.9.100] helo=ms-smtp-01-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay9zP-0006yx-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 08:31:15 -0500 Received: from creeksidenet.com (cpe-024-163-075-077.nc.rr.com [24.163.75.77]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i22DVDSm007609; Tue, 2 Mar 2004 08:31:13 -0500 (EST) Message-ID: <40448CA2.4080004@creeksidenet.com> From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] views on different channels vs same channel References: <1078230268.1051.29.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 08:31:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jamal, I pretty much agree with 1), but would like to be careful about the term physical link. In your example, if you have multiple DMA channels "listening" on a single physical backbone, you can provide reasonable DOS protection. So maybe think of a logical link as one where there is no overlap of underlying physical resource. The example above would be a reasonable approximation if the backbone is much faster than the DMA AND there was backpressure preventing backbone usage if one channel's DMA is not available. Jeff Jamal Hadi Salim wrote: >Hi, >since i have just scanned through tons of emails (halfway there), >let me share my view on the the topic. > >1) If you are using the same physical link at the lowest layer it doesnt >matter how many sockets/channels you have. The DoS impact is going >to be at the lowest layer i.e the physical link for which the only cure >is to have separate links. The next level up is just before the packet >is DMAed into RAM that the OS can get to it; there is some smart >hardware you can program to have multiple channels and drop at the >earliest level. Majority of the hardware you will find cant do this. >Once the packet hits the OS, you can play with differentiation/QoS/rate >metering of either the CPU time and/or bandwidth protection. >Summary: having more than one virtual channel within one physical link >is going to offer little protection against DOS. > >2)On the sending: the value is going to be in having multiple queues >just before the packet hits the OS. >For this you need to recognize something in the packet. This does >not imply the ForCES header needs some speacial signature; rather the >packet can be administratively recognized and classified into a queue. >Example could be recognizing a destination IP or MAC address. > >3) >The idea of having such unique names to "channels" is almost bell-head >approach. Reminds me of my ISDN days. There doesnt have to be a clear >cut explicit use for each channel (i.e thou shalt only transport data >packets). I am in agreement of having more than one connection, but the >approach is different. >Like i shared earlier on our experiences: the way we had the two or more >"channels" was to have different granularities of reliability. >We typically sent on a cheaper but less reliable mass transport and on >failure if the message needs to be reliably delivered then it goes >retransmitted on a more reliable unicast channel. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 13:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21670 for ; Tue, 2 Mar 2004 13:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEG6-00072i-8E for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 13:04:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22I4kUc027072 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 13:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEG5-00072Z-Aq for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 13:04:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21654 for ; Tue, 2 Mar 2004 13:04:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEG3-0003lz-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:04:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEFA-0003dy-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:03:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyEEO-0003VX-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEEP-0006qH-7r; Tue, 02 Mar 2004 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEEA-0006pW-OV for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 13:02:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21512 for ; Tue, 2 Mar 2004 13:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEE8-0003TF-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:02:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyED9-0003K2-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:01:44 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AyECF-00030O-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:00:48 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i22I0ADm024854; Tue, 2 Mar 2004 12:00:11 -0600 (CST) Message-ID: <4044CBA9.3090706@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: "Wang,Weiming" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia References: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> Content-Type: multipart/alternative; boundary="------------000304000405020201050600" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 12:00:09 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000304000405020201050600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Hormuzd, I am not sure I am in favor of a duplicate draft. What could be done is to recommend that separate C/D channels be used for enhanced reliability, and leave the rest to implementation. By that, I mean the strength of this pseudo-requirement is "SHOULD". That way, one document serves all. Are there issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: > Hi All > > > > I was thinking about the issue of transport(s) for the ForCES protocol > which is probably one of the most important and might be quite > contentious. > > One way to resolve this and make some progress is to separate this > from the ForCES base protocol, let us consider having 2 drafts...one > which > > defines the base protocol assuming a reliable transport and the second > which defines how the base protocol will work over different reliable > as well as > > unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. > The base protocol can concentrate on the basic protocol messages > needed for > > control, configuration, capability exchange, etc. as well as other > transactioning semantics (2-phase commit), etc. The 2nd draft, say on > 'encapsulation > > for the base protocol' can discuss the details of providing > reliability over unreliable transports using some encapsulation header > or TLV, etc. and how > > the base protocol will work over different transports. > > We will eventually need to mandate 1 or minimum set of transports for > the protocol, but that can be decided later. In the mean time we can > continue > > making progress on both drafts. How does that sound to you guys ? > > > > Let us know. > > > > > > Regards > > Hormuzd > > > --------------000304000405020201050600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,

I am not sure I am in favor of a duplicate draft. What could be done is to recommend
that separate C/D channels be used for enhanced reliability, and leave the rest to
implementation. By that, I mean the strength of this pseudo-requirement is "SHOULD".
That way, one document serves all.  Are there issues with this?

Regards,
Alex.


Khosravi, Hormuzd M wrote:

Hi All

 

I was thinking about the issue of transport(s) for the ForCES protocol which is probably one of the most important and might be quite contentious.

One way to resolve this and make some progress is to separate this from the ForCES base protocol, let us consider having 2 drafts…one which

defines the base protocol assuming a reliable transport and the second which defines how the base protocol will work over different reliable as well as

unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. The base protocol can concentrate on the basic protocol messages needed for

control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc. The 2nd draft, say on ‘encapsulation

for the base protocol’ can discuss the details of providing reliability over unreliable transports using some encapsulation header or TLV, etc. and how

the base protocol will work over different transports.

We will eventually need to mandate 1 or minimum set of transports for the protocol, but that can be decided later. In the mean time we can continue

making progress on both drafts. How does that sound to you guys ?

 

Let us know.

 

 

Regards

Hormuzd

 

--------------000304000405020201050600-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 13:13:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21917 for ; Tue, 2 Mar 2004 13:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyENs-0000SJ-Bn for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 13:12:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22ICmke001745 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 13:12:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyENs-0000S4-2L for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 13:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21895 for ; Tue, 2 Mar 2004 13:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyENq-0004o6-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEMt-0004fK-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:11:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyEM8-0004XW-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 13:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEM9-0007rR-BL; Tue, 02 Mar 2004 13:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyELp-0007nh-AO for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 13:10:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21846 for ; Tue, 2 Mar 2004 13:10:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyELn-0004Va-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:10:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEKo-0004Ny-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:09:39 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AyEJu-0004AT-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 13:08:42 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i22I8BDm026572; Tue, 2 Mar 2004 12:08:11 -0600 (CST) Message-ID: <4044CD8A.6010709@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: "Wang,Weiming" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia References: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0022EED99@orsmsx410.jf.intel.com> Content-Type: multipart/alternative; boundary="------------090408090707070902010109" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Mar 2004 12:08:10 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090408090707070902010109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Again, I am not sure if I replied too soon to your e-mail,..but on further reflection, I can see why you made the recommendation. Again, my answer is the same: no double drafts. The ForCEs protocol is transport independent by requirements specs. So, a well defined protocol should work transparently well with any transport. You can have different sections for each of the transports considered and add comments about any special thing that needs to be done or any special behavior to accommodate that transport mode. Regards, Alex. Khosravi, Hormuzd M wrote: > Hi All > > > > I was thinking about the issue of transport(s) for the ForCES protocol > which is probably one of the most important and might be quite > contentious. > > One way to resolve this and make some progress is to separate this > from the ForCES base protocol, let us consider having 2 drafts...one > which > > defines the base protocol assuming a reliable transport and the second > which defines how the base protocol will work over different reliable > as well as > > unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. > The base protocol can concentrate on the basic protocol messages > needed for > > control, configuration, capability exchange, etc. as well as other > transactioning semantics (2-phase commit), etc. The 2nd draft, say on > 'encapsulation > > for the base protocol' can discuss the details of providing > reliability over unreliable transports using some encapsulation header > or TLV, etc. and how > > the base protocol will work over different transports. > > We will eventually need to mandate 1 or minimum set of transports for > the protocol, but that can be decided later. In the mean time we can > continue > > making progress on both drafts. How does that sound to you guys ? > > > > Let us know. > > > > > > Regards > > Hormuzd > > > --------------090408090707070902010109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Again,

I am not sure if I replied too soon to your e-mail,..but on further reflection,  I can see
why you made the recommendation.  Again, my answer is the same: no double drafts.
The ForCEs protocol is transport independent by requirements specs.  So, a well defined
protocol should work transparently well with any  transport. 

You can have different sections for each of the transports considered and add comments
about any special thing that needs to be done or any special behavior to accommodate
that transport mode.

Regards,
Alex.
 

Khosravi, Hormuzd M wrote:

Hi All

 

I was thinking about the issue of transport(s) for the ForCES protocol which is probably one of the most important and might be quite contentious.

One way to resolve this and make some progress is to separate this from the ForCES base protocol, let us consider having 2 drafts…one which

defines the base protocol assuming a reliable transport and the second which defines how the base protocol will work over different reliable as well as

unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. The base protocol can concentrate on the basic protocol messages needed for

control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc. The 2nd draft, say on ‘encapsulation

for the base protocol’ can discuss the details of providing reliability over unreliable transports using some encapsulation header or TLV, etc. and how

the base protocol will work over different transports.

We will eventually need to mandate 1 or minimum set of transports for the protocol, but that can be decided later. In the mean time we can continue

making progress on both drafts. How does that sound to you guys ?

 

Let us know.

 

 

Regards

Hormuzd

 

--------------090408090707070902010109-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 16:29:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01914 for ; Tue, 2 Mar 2004 16:29:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHRf-0004nm-Cd for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 16:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22LStM3018452 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 16:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHRf-0004nX-5W for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 16:28:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01906 for ; Tue, 2 Mar 2004 16:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHRd-0001FC-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 16:28:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHQj-00016w-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 16:28:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyHPn-0000yN-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 16:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHPo-0004lT-SS; Tue, 02 Mar 2004 16:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyHPd-0004l3-0y for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 16:26:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01784 for ; Tue, 2 Mar 2004 16:26:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyHPb-0000wE-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 16:26:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyHOi-0000oQ-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 16:25:55 -0500 Received: from tomts35.bellnexxia.net ([209.226.175.109] helo=tomts35-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1AyHON-0000gx-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 16:25:31 -0500 Received: from develSPavel ([67.69.27.58]) by tomts35-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040302212525.LYKO20454.tomts35-srv.bellnexxia.net@develSPavel>; Tue, 2 Mar 2004 16:25:25 -0500 Reply-To: From: "Sandy Pavel" To: "'Wang,Weiming'" , Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Message-ID: <000001c4009d$a362c080$a401a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C40073.BA8CB880" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <005201c3fdbe$6ae6a5a0$845c21d2@Necom.hzic.edu.cn> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 16:30:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C40073.BA8CB880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Weiming1 Sorry for the delay in answering to your comments. Partial reason for this delay is that I could not see what is actually your argument against my opinion. In any case I believe Hormouzd has already summarized very well our arguments. Regards, Sandy -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: February 28, 2004 12:48 AM To: forces-protocol@ietf.org Subject: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Hi Sandy, Thank you for the comments. Pls see reply in the lines. ----- Original Message ----- From: Sandy Pavel To: forces-protocol@ietf.org Sent: Saturday, February 28, 2004 12:07 AM Subject: RE: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia See comments below: 4. To explicitly separate D and C channel also consumes more resources, because a resources for D channel have to be reserved. Instead, by separating D and C packets at the ForCES protocol layer and uniting them again at the transport layer, we may able to make a scheduling discipline by which the D and C packets can share the link resources effectively. We are trying to construct such a scheduling scheme, and it seems quite practical to so.To summarize, we propose that the 7&8 basic principles only mention the separation of D and C packets for DoS protection currently, leaving some space for further discussions. The discussions may be like: 1. Should such a separation be put at the ForCES message layer or at the transport layer? Which is better?2. Whether united scheduling for D and C packets are necessary?3. Should D packets be distinguished from C packets for its transport reliability in ForCES protocol so as to assign a different transport means? [[Sandy]] I am concerned about the separation of the D and C packets at the ForCES protocol layer. I wonder if it is not too late at both ends of the communication channel; by this I mean resources are allocated to distinguish between the two but DoS might have already occurred or C packets might have already been lost due to congestion on D. [WangRe] I can not find any reason it will be delayed more to schedule D and C packets at ForCES protocol layer than to schedule them at the transport layer. Actually the former happens ahead of the latter. I believe marking the two types and doing the separation at transport layer is safer and uses existing mechanisms that do not overload the protocol. [WangRe] Could you give more reasons why it is safer to schedue the D/C packets at the transport layer? My opinion is they are the same, except one is done by OS kernel scheduling (usually using round robin), the other is done by ForCES assigned scheduling whose scheduling decispline can be flexibly set by ForCES protocol, and D/C packets can be very easily and differentialtedly scheduled. Differentiated scheduling for D and C would be my preference. [WangRe] By saying to use united scheduling, I actually mean it may be able to exploit more from usual separate scheduling. If it is impossible (we are doing experiments to try it), there is no any limit for us to separately schedule D/C packets as usual. And yes, there should be a differentiation between C and D for transport reliability. [[Sandy]] [WangRe] Actually I agree to differentiate the D/C packets for its transport relaibility, if possible. Maybe I should have stated the question as " Is it worthy or not to define a separate transport layer channel for D packets in ForCES protocol specifications to only achieve a little lower reliability for the D packets transmision?" Taking the chance to reply your comments, pls allow me to point out more cons on this: 1. First of all, as I'v mentioned, such a D channel is only of use for assigning different transport reliability for D packets. It has no use for DoS protection. 2. Such a little difference for reliability requiements can be distinguished via ForCES protocol built in mechanisims by deciding to or not to use something like ACK, checksum, etc. 3. To define a separate channel for D packets is also very case specific. That is, in UDP/TCP based CE-FE interconnection case, we may think of using UDP for D packets and TCP for C packets. But what then if the CE-FE link is Ethernet based, ATM based, backplane bus based, and any future technology based? Are we going to define it one by one? And what then if the CE-FE link can only provide a channel? 4. On countrary, it surely consumes more resources and makes ForCES protocol management more complex. Best Regards, Weiming ------=_NextPart_000_0001_01C40073.BA8CB880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Weiming1

 

Sorry for the delay in answering to = your comments.

Partial reason for this delay is = that I could not see

what is actually your argument against my = opinion.

 

In any case I believe Hormouzd has = already summarized

very well  our = arguments.

 

Regards,

Sandy

 

-----Original Message-----
From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On Behalf Of Wang,Weiming
Sent: = February 28, = 2004 = 12:48 AM
To: = forces-protocol@ietf.org
Subject: = [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia

 

 

Hi Sandy,

 

Thank you for the comments. Pls see reply in the lines.

 

 

----- Original = Message -----

=

From: Sandy Pavel =

Sent: = Saturday, = February 28, 2004 = 12:07 = AM

Subject: RE: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team = Administrivia

 

See comments below:

 =

=
=
=

 4. To = explicitly separate D and C channel also consumes more resources, because a = resources for D channel have to be reserved. Instead, by separating D and C packets at = the ForCES protocol layer and uniting them again at the transport layer, we = may able to make a scheduling discipline by which the D and C packets can = share the link resources effectively. We are trying to construct such a scheduling scheme, and it seems quite practical to so.To summarize, we propose that = the 7&8 basic principles only mention the separation of D and C packets = for DoS protection currently, leaving some space for further discussions. The discussions may be like: 1. Should such a separation be put at the = ForCES message layer or at the transport layer? Which is better?2. Whether = united scheduling for D and C packets are necessary?3. Should D packets be distinguished from C packets for its transport reliability in ForCES = protocol so as to assign a different transport means?

 

[[Sandy]]

I am concerned about the separation of the D and C packets at = the ForCES protocol layer. I wonder if it is not too late at both ends of = the communication channel; by this I mean resources are allocated to = distinguish between the two but DoS might have already occurred or C packets might = have already been lost due to congestion on D. =

 

[WangRe]

I can not find any reason it will be delayed = more to schedule D and C packets at ForCES protocol layer than to schedule = them at the transport layer. Actually the former happens ahead of the = latter.  =

 

I believe marking the two types and doing the separation at = transport layer is safer and uses existing mechanisms that do not overload the protocol. 

 

[WangRe]

Could you give more reasons why it is safer = to schedue the D/C packets at the transport layer? My opinion is they are = the same, except one is done by OS kernel scheduling (usually = using round robin), the other is done by ForCES assigned scheduling whose = scheduling

decispline can be flexibly set by ForCES = protocol, and D/C packets can be very easily and differentialtedly = scheduled. =

 

= Differentiated scheduling for D and C would be my preference. =

 

= [WangRe]

=  By saying to use united scheduling, I actually mean it may be able to = exploit more from usual separate scheduling. If it is impossible (we are doing = experiments to try it), there is no any limit for us to separately schedule D/C = packets as usual. =

 

= And yes, there should be a differentiation between C and D for transport reliability.   =

[[Sandy]]

 

= [WangRe]

= Actually I agree to differentiate the D/C packets for its transport relaibility, = if possible. Maybe I should have stated the question as " Is it = worthy or not to define a separate transport layer channel for D packets = in ForCES protocol specifications  to only achieve a little lower = reliability for the D packets transmision?"  Taking the chance to reply = your comments, pls allow me to point out more cons on this: =

 

= 1.  First of all, as I'v mentioned, such a D channel is only of use for assigning different transport reliability for D packets. It has no use = for DoS protection.

 

= 2. Such a little difference for reliability requiements can = be distinguished via ForCES protocol built in mechanisims by deciding to or not to use something like ACK, checksum, = etc.

 

= 3. To define a separate channel for D packets is also very case = specific. That is, in UDP/TCP based CE-FE interconnection case, we may think = of using UDP for D packets and TCP for C packets. But what then if the =  = CE-FE link is Ethernet based, ATM based, backplane bus based, and = any future technology based?  Are we going to define it one by one? And what = then if the CE-FE link can only provide a channel? =

 

= 4. On countrary, it surely consumes more resources and makes ForCES protocol management more complex.

 

 

= Best Regards,

= Weiming

 =

------=_NextPart_000_0001_01C40073.BA8CB880-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 19:45:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14269 for ; Tue, 2 Mar 2004 19:45:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKVM-00039l-Lp for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 19:44:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230iuxg012129 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 19:44:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKVM-00039Y-DM for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:44:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14192 for ; Tue, 2 Mar 2004 19:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKVK-00072q-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 19:44:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKUO-0006sn-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 19:43:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyKTU-0006hp-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 19:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKTV-0002ul-Tl; Tue, 02 Mar 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKTT-0002uR-W3 for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 19:43:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14025 for ; Tue, 2 Mar 2004 19:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKTS-0006hP-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 19:42:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKSW-0006Uy-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 19:42:01 -0500 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1AyKRW-0006Bn-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 19:40:58 -0500 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: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i230eJ0h006361; Wed, 3 Mar 2004 00:40:21 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.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i230f4Xw012634; Wed, 3 Mar 2004 00:41:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030216400815560 ; Tue, 02 Mar 2004 16:40:08 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Mar 2004 16:40:08 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400B8.137A361D" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0023A097B@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcQAgWw/tMq0lG3LTLqhZyJZ1sMk4gANnkoA From: "Khosravi, Hormuzd M" To: Cc: "Wang,Weiming" , X-OriginalArrivalTime: 03 Mar 2004 00:40:08.0253 (UTC) FILETIME=[13FCBED0:01C400B8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 16:40:07 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C400B8.137A361D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, I am fine with that. It was just a suggestion to make progress on the common parts such as Protocol messages, that we agree on. =20 _____ =20 From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Tuesday, March 02, 2004 10:08 AM To: Khosravi, Hormuzd M Cc: Wang,Weiming; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia =20 Hi Again, I am not sure if I replied too soon to your e-mail,..but on further reflection, I can see why you made the recommendation. Again, my answer is the same: no double drafts. The ForCEs protocol is transport independent by requirements specs. So, a well defined protocol should work transparently well with any transport. =20 You can have different sections for each of the transports considered and add comments about any special thing that needs to be done or any special behavior to accommodate that transport mode. Regards, Alex. =20 Khosravi, Hormuzd M wrote: Hi All =20 I was thinking about the issue of transport(s) for the ForCES protocol which is probably one of the most important and might be quite contentious. One way to resolve this and make some progress is to separate this from the ForCES base protocol, let us consider having 2 drafts...one which=20 defines the base protocol assuming a reliable transport and the second which defines how the base protocol will work over different reliable as well as=20 unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. The base protocol can concentrate on the basic protocol messages needed for=20 control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase commit), etc. The 2nd draft, say on 'encapsulation for the base protocol' can discuss the details of providing reliability over unreliable transports using some encapsulation header or TLV, etc. and how the base protocol will work over different transports. We will eventually need to mandate 1 or minimum set of transports for the protocol, but that can be decided later. In the mean time we can continue=20 making progress on both drafts. How does that sound to you guys ? =20 Let us know. =20 =20 Regards Hormuzd =20 ------_=_NextPart_001_01C400B8.137A361D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, I am fine with that. It was = just a suggestion to make progress on the common parts such = as

Protocol messages, that we agree = on.

 

From: Alex Audu [mailto:alex.audu@alcatel.com]
Sent: Tuesday, March 02, = 2004 10:08 AM
To: Khosravi, Hormuzd = M
Cc: Wang,Weiming; forces-protocol@ietf.org
Subject: Re: = [Forces-protocol] Re: ForCES Protocol Analysis Design Team Administrivia

 

Hi Again,

I am not sure if I replied too soon to your e-mail,..but on further reflection,  I can see
why you made the recommendation.  Again, my answer is the same: no = double drafts.
The ForCEs protocol is transport independent by requirements = specs.  So, a well defined
protocol should work transparently well with any  transport.  =

You can have different sections for each of the transports considered = and add comments
about any special thing that needs to be done or any special behavior to accommodate
that transport mode.

Regards,
Alex.
 

Khosravi, Hormuzd M wrote:

Hi All

 

I was thinking about the issue of transport(s) for the ForCES protocol which is probably one of the most important and might be quite contentious.

One way to resolve this and make = some progress is to separate this from the ForCES base protocol, let us = consider having 2 drafts…one which

defines the base protocol assuming = a reliable transport and the second which defines how the base protocol = will work over different reliable as well as

unreliable transports e.g. TCP/IP, = UDP/IP, TIPC, Ethernet, PCI, etc. The base protocol can concentrate on the basic protocol messages needed for

control, configuration, capability exchange, etc. as well as other transactioning semantics (2-phase = commit), etc. The 2nd draft, say on ‘encapsulation

for the base protocol’ can = discuss the details of providing reliability over unreliable transports using = some encapsulation header or TLV, etc. and how

the base protocol will work over = different transports.

We will eventually need to mandate = 1 or minimum set of transports for the protocol, but that can be decided = later. In the mean time we can continue

making progress on both drafts. How = does that sound to you guys ?

 

Let us know.

 

 

Regards

Hormuzd

 

------_=_NextPart_001_01C400B8.137A361D-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 22:12:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24686 for ; Tue, 2 Mar 2004 22:12:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMnP-0008Bi-Uq for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 22:11:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233Bh64031457 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 22:11:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMnP-0008BI-Ol for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:11:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24492 for ; Tue, 2 Mar 2004 22:11:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMnM-0007hq-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:11:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMl2-000798-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:09:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyMk1-0006zr-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:08:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyMeD-0000iI-1B for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMe2-0006RY-1y; Tue, 02 Mar 2004 22:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMd6-0006Lx-Qg for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 22:01:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23914 for ; Tue, 2 Mar 2004 22:01:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMd3-0005q8-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:01:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMcC-0005ii-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:00:09 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AyMbg-0005bp-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 21:59:36 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030219001168:60025 ; Tue, 2 Mar 2004 19:00:11 -0800 Subject: Re: [Forces-protocol] views on different channels vs same channel From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: jeff pickering Cc: forces-protocol@ietf.org In-Reply-To: <40448CA2.4080004@creeksidenet.com> References: <1078230268.1051.29.camel@jzny.localdomain> <40448CA2.4080004@creeksidenet.com> Organization: ZNYX Networks Message-Id: <1078282766.1038.14.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 03/02/2004 07:00:12 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 07:00:20 PM, Serialize complete at 03/02/2004 07:00:20 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 21:59:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jeff, Agreed. I wasnt sure how commodity that feature was thats why i refered to it as some smart hardware. Our control hardware has two DMA channels on both tx and rx; typically we reserve the higher priority channel for control protocols and have strict priority scheduling (leading to possibly the best effort DMA channel to be starved). We can typically protect against most script kiddie type DOS attacks with this scheme. cheers, jamal On Tue, 2004-03-02 at 08:31, jeff pickering wrote: > Jamal, > > I pretty much agree with 1), but would like to be careful about the term > physical link. > In your example, if you have multiple DMA channels "listening" on a > single physical backbone, you can provide reasonable DOS protection. > So maybe think of a logical link as one where there is no overlap of > underlying physical resource. > The example above would be a reasonable approximation if the backbone is > much faster than the DMA AND there was backpressure preventing backbone > usage if one channel's DMA is not available. [..] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 2 22:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25804 for ; Tue, 2 Mar 2004 22:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN4A-00066l-O9 for forces-protocol-archive@odin.ietf.org; Tue, 02 Mar 2004 22:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233T2aW023478 for forces-protocol-archive@odin.ietf.org; Tue, 2 Mar 2004 22:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN4A-00066Z-2Z for forces-protocol-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25762 for ; Tue, 2 Mar 2004 22:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyN46-0002ck-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:28:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyN38-0002Th-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:27:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyN2A-0002Li-00 for forces-protocol-web-archive@ietf.org; Tue, 02 Mar 2004 22:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN2D-0005bI-5u; Tue, 02 Mar 2004 22:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN1I-00055c-5l for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 22:26:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25553 for ; Tue, 2 Mar 2004 22:26:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyN1E-0002D0-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyN0K-00025J-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:25:04 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AyMza-0001y0-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:24:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030219245985:60050 ; Tue, 2 Mar 2004 19:24:59 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1078284254.1036.45.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 03/02/2004 07:25:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 07:25:01 PM, Serialize complete at 03/02/2004 07:25:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] [Fwd: Your message to Forces-protocol awaits moderator approval] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 22:24:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I got the message underneath when responding to Hormuzds email. I also got a bounce on emails of: gyf@htrdc.com and alex.audu@alcatel.com The first email has bounced everytime i posted. Alexs email has bounced for the second time now for me. cheers, jamal -----Forwarded Message----- From: forces-protocol-admin@ietf.org To: hadi@znyx.com Subject: Your message to Forces-protocol awaits moderator approval Date: 02 Mar 2004 22:19:00 -0500 Your mail to 'Forces-protocol' with the subject RE: ForCES Protocol Analysis Design Team Administrivia Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message Either the message will get posted to the list, or you will receive notification of the moderator's decision. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 3 12:43:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13258 for ; Wed, 3 Mar 2004 12:43:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaOD-00012Y-MB for forces-protocol-archive@odin.ietf.org; Wed, 03 Mar 2004 12:42:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HgbwR003992 for forces-protocol-archive@odin.ietf.org; Wed, 3 Mar 2004 12:42:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaOD-00012J-Ba for forces-protocol-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:42:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13247 for ; Wed, 3 Mar 2004 12:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaOB-0004rH-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 12:42:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyaNK-0004jG-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 12:41:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyaMg-0004bF-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 12:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaMh-0000zw-7p; Wed, 03 Mar 2004 12:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaMM-0000wK-VG for forces-protocol@optimus.ietf.org; Wed, 03 Mar 2004 12:40:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13165 for ; Wed, 3 Mar 2004 12:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaML-0004aI-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 12:40:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyaLU-0004RN-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 12:39:49 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AyaKo-0004Du-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 12:39:06 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i23HcHDm029941; Wed, 3 Mar 2004 11:38:21 -0600 (CST) Message-ID: <40461807.7040605@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: donglg@mail.hzic.edu.cn CC: david.putzolu@intel.com, FORCES@PEACH.EASE.LSOFT.COM, forces-protocol@ietf.org, lidefeng@huawei.com Subject: Re: [Forces-protocol] (no subject) References: <1078224931.4044682cc3fb5@mail.hzic.edu.cn> In-Reply-To: <1078224931.4044682cc3fb5@mail.hzic.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 11:38:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Dong, Sorry I am just catching up. Have you tried this experiment with a real-time OS,..like LynxOS or VRTX? Looks like you are running into (or exposing ) limitations of Linux . I am not sure if Linux is really real-time multitasking. Particularly, how they handle queues in the kernel might be suspect. Regards, Alex. donglg@mail.hzic.edu.cn wrote: >hi, David, > >I am attaching the pdf file of my presentation in today's conference. Please >check it. >best regards >Dong, Ligang > > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > >------------------------------------------------- >This mail sent through HUCNIC Webmail system. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 3 19:12:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08826 for ; Wed, 3 Mar 2004 19:12:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygSe-00081S-7p for forces-protocol-archive@odin.ietf.org; Wed, 03 Mar 2004 19:11:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240BaWq030832 for forces-protocol-archive@odin.ietf.org; Wed, 3 Mar 2004 19:11:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygSa-00080r-Ic for forces-protocol-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:11:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08684 for ; Wed, 3 Mar 2004 19:11:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygSX-0000Sp-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 19:11:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygRQ-0000A5-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 19:10:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AygQ1-0007WX-03 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 19:08:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AygBi-0001M3-Kj for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 18:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygBd-00062T-Kc; Wed, 03 Mar 2004 18:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMtU-0001Jj-5U for forces-protocol@optimus.ietf.org; Tue, 02 Mar 2004 22:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25199 for ; Tue, 2 Mar 2004 22:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMtQ-000160-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:17:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMsR-0000xY-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:16:55 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AyMrS-0000mX-00 for forces-protocol@ietf.org; Tue, 02 Mar 2004 22:15:54 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030219163037:60039 ; Tue, 2 Mar 2004 19:16:30 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Putzolu, David" , gmwang@mail.hzic.edu.cn, donglg@mail.hzic.edu.cn, spyros.denazis@hitachi-eu.com, Steve Blake , Robert Haas , ram.gopal@nokia.com, alex.audu@alcatel.com, "Wang,Weiming" , Patrick Droz , jeff pickering , avri@acm.org, "Deleganes, Ellen M" , gyf@htrdc.com, zsolt.haraszti@ericsson.com, forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0023A099C@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B0023A099C@orsmsx410.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078283744.1037.32.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 03/02/2004 07:16:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/02/2004 07:16:38 PM, Serialize complete at 03/02/2004 07:16:38 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Mar 2004 22:15:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Tue, 2004-03-02 at 19:54, Khosravi, Hormuzd M wrote: > Hi Jamal, All > > I briefly chatted with David, Patrick regarding our deliverables by > March 20th and I got a feeling that they are looking for whether we can > merge the protocols and what are the high level design features that we > all agree on. > I think most of us already agree that we can achieve a merge if we work > towards it. I would suggest that we first try to get all the high level > features list out and agree on it, then proceed to the details. > > So in that spirit I would suggest to postpone getting into details such > as length of bits in the header, what the format is, etc for now and > quickly come up with a list of common ideas. Some of the items below > that we all seem to agree on may be a good start. > We could make the encoding discussion the last thing but it needs to be discussed as we are discussing the mechanisms. The main discussion points as i see it (to extend what David posted) are: 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability Its almost like 2-5 are very closely related. I am doing this off the top of my head so i probably missed something. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 3 21:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16255 for ; Wed, 3 Mar 2004 21:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiO9-0004H8-1y for forces-protocol-archive@odin.ietf.org; Wed, 03 Mar 2004 21:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242F4fj016427 for forces-protocol-archive@odin.ietf.org; Wed, 3 Mar 2004 21:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiO8-0004Gq-2a for forces-protocol-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:15:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16217 for ; Wed, 3 Mar 2004 21:15:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiO5-0007ie-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 21:15:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiN4-0007XU-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 21:13:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiM7-0007Me-00 for forces-protocol-web-archive@ietf.org; Wed, 03 Mar 2004 21:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiM9-0003pq-US; Wed, 03 Mar 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiLO-0003iC-Gs for forces-protocol@optimus.ietf.org; Wed, 03 Mar 2004 21:12:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16045 for ; Wed, 3 Mar 2004 21:12:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiLL-0007B1-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 21:12:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiKX-0006wn-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 21:11:21 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AyiJe-0006hH-00 for forces-protocol@ietf.org; Wed, 03 Mar 2004 21:10:26 -0500 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Thu, 4 Mar 2004 10:21:31 +0800 Message-ID: <002e01c4018d$92b99970$6f01a8c0@dlg> From: "Ligang Dong" To: , , References: <1078224931.4044682cc3fb5@mail.hzic.edu.cn> <40461807.7040605@alcatel.com> Subject: Re: [Forces-protocol] (no subject) 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 10:08:23 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksIEFsZXgsDQoNCkFjdHVhbGx5LCBpbiBvdXIgZXhwZXJpbWVudHMsIHdlIGFyZSBxdWl0ZSBz dXJlIHRoYXQgdGhlIGNvbmdlc3Rpb25zIG1haW5seSByZXN1bHQgZnJvbSB0aGUgcGh5c2ljYWwg bGluayByZXNvdXJjZSBsaW1pdGF0aW9uLiBJdCdzIHRydWUgdGhhdCB0aGUgcXVldWluZyBzdHJh dGVnaWVzIGluIHRoZSBPUyBrZXJuZWwgaXMgaGFyZCB0byBiZSBjb250cm9sbGVkIGZyb20gdGhl IGFwcGxpY2F0aW9uIGxheWVyLCB0aGF0J3Mgd2h5IHdlIHByb21vdGUgdG8gdXNlIEZvckNFUyBw cm90b2NvbCBsYXllciBzY2hlZHVsaW5nIHN0cmF0ZWdpZXMuIA0KDQpiZXN0IHJlZ2FyZHMNCkRv bmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGV4IEF1ZHUiIDxh bGV4LmF1ZHVAYWxjYXRlbC5jb20+DQpUbzogPGRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuPg0KQ2M6 IDxkYXZpZC5wdXR6b2x1QGludGVsLmNvbT47IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+ OyA8Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPjsgPGxpZGVmZW5nQGh1YXdlaS5jb20+DQpTZW50 OiBUaHVyc2RheSwgTWFyY2ggMDQsIDIwMDQgMTozOCBBTQ0KU3ViamVjdDogUmU6IFtGb3JjZXMt cHJvdG9jb2xdIChubyBzdWJqZWN0KQ0KDQoNCj4gSGVsbG8gRG9uZywNCj4gDQo+IFNvcnJ5IEkg YW0ganVzdCBjYXRjaGluZyB1cC4gSGF2ZSB5b3UgdHJpZWQgdGhpcyBleHBlcmltZW50IHdpdGgg YQ0KPiByZWFsLXRpbWUNCj4gT1MsLi5saWtlIEx5bnhPUyBvciBWUlRYPw0KPiBMb29rcyBsaWtl IHlvdSBhcmUgcnVubmluZyBpbnRvIChvciBleHBvc2luZyApIGxpbWl0YXRpb25zIG9mIExpbnV4 IC4gSQ0KPiBhbSBub3Qgc3VyZQ0KPiBpZiBMaW51eCBpcyByZWFsbHkgcmVhbC10aW1lIG11bHRp dGFza2luZy4gUGFydGljdWxhcmx5LCBob3cgdGhleSBoYW5kbGUNCj4gcXVldWVzIGluIHRoZQ0K PiBrZXJuZWwgbWlnaHQgYmUgc3VzcGVjdC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEFsZXguDQo+IA0K PiBkb25nbGdAbWFpbC5oemljLmVkdS5jbiB3cm90ZToNCj4gDQo+ID5oaSwgRGF2aWQsDQo+ID4N Cj4gPkkgYW0gYXR0YWNoaW5nIHRoZSBwZGYgZmlsZSBvZiBteSBwcmVzZW50YXRpb24gaW4gdG9k YXkncyBjb25mZXJlbmNlLiBQbGVhc2UNCj4gPmNoZWNrIGl0Lg0KPiA+YmVzdCByZWdhcmRzDQo+ ID5Eb25nLCBMaWdhbmcNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPkZvcmNlcy1wcm90b2NvbCBtYWlsaW5n IGxpc3QNCj4gPkZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3RvY29sDQo+ID4NCj4gPg0KPiA+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+VGhpcyBtYWls IHNlbnQgdGhyb3VnaCBIVUNOSUMgV2VibWFpbCBzeXN0ZW0uDQo+ID4NCj4gDQo+IA== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 01:55:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06835 for ; Thu, 4 Mar 2004 01:55:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymlO-0007ML-Pq for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 01:55:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246tM4m028288 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 01:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymlO-0007MB-Lv for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:55:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06811 for ; Thu, 4 Mar 2004 01:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymlL-0002Iw-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:55:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymkU-00028g-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:54:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aymk3-0001xb-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymk5-0007Ex-Ua; Thu, 04 Mar 2004 01:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymjN-0007Bh-7D for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 01:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06660 for ; Thu, 4 Mar 2004 01:53:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymjJ-0001v6-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymiT-0001jG-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:52:22 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AymhZ-0001MK-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:51:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i246sQ0K017636 for ; Thu, 4 Mar 2004 06:54:28 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i246iVJ3002100 for ; Thu, 4 Mar 2004 06:45:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030322504932280 for ; Wed, 03 Mar 2004 22:50:49 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 22:50: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 Subject: RE: [Forces-protocol] [Fwd: Your message to Forces-protocol awaits moderator approval] Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0023A11EC@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] [Fwd: Your message to Forces-protocol awaits moderator approval] Thread-Index: AcQAz2k0QI9S5+IORx+WD19zzY0nkQA5MDbA From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 Mar 2004 06:50:49.0083 (UTC) FILETIME=[06F7D4B0:01C401B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 22:50:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have also noticed similar problems while posting to this list. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Tuesday, March 02, 2004 7:24 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] [Fwd: Your message to Forces-protocol awaits moderator approval] I got the message underneath when responding to Hormuzds email. I also got a bounce on emails of: gyf@htrdc.com and alex.audu@alcatel.com The first email has bounced everytime i posted. Alexs email has bounced for the second time now for me. cheers, jamal -----Forwarded Message----- From: forces-protocol-admin@ietf.org To: hadi@znyx.com Subject: Your message to Forces-protocol awaits moderator approval Date: 02 Mar 2004 22:19:00 -0500 Your mail to 'Forces-protocol' with the subject RE: ForCES Protocol Analysis Design Team Administrivia Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message Either the message will get posted to the list, or you will receive notification of the moderator's decision. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 01:55:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06854 for ; Thu, 4 Mar 2004 01:55:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymlQ-0007Mi-DC for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 01:55:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246tOxq028306 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 01:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymlQ-0007MT-9Q for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06815 for ; Thu, 4 Mar 2004 01:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymlN-0002J9-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymkV-00028o-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:54:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aymk3-0001xd-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymk6-0007F5-2V; Thu, 04 Mar 2004 01:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymjT-0007DY-2g for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 01:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06669 for ; Thu, 4 Mar 2004 01:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymjP-0001w0-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:53:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aymic-0001kg-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:52:31 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Aymhk-0001RC-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:51:36 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i246sc0K017789 for ; Thu, 4 Mar 2004 06:54:38 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i246jKIR002437 for ; Thu, 4 Mar 2004 06:45:29 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030322504932278 for ; Wed, 03 Mar 2004 22:50:49 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 22:50:48 -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 Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0023A11EB@orsmsx410.jf.intel.com> Thread-Topic: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcP/n308GweMyOGoRPGFAjNQHSLVogAg/70gAEf1lsA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 Mar 2004 06:50:48.0989 (UTC) FILETIME=[06E97CD0:01C401B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 22:50:47 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is a starter list of common high level ideas/features/principles that I believe we all agree on... All ForCES protocol messages should consist of a fixed size header and variable size payload fields. Further, the protocol header is made up of CE ID, FE ID fields in addition to other fields (TBD) All ForCES protocol messages should be 32-bit aligned. The ForCES protocol payload consists of a number of variable size TLVs i.e. all ForCES messages must use TLV encoding. The FE ID field in the protocol header is assigned or allocated by the CE. The ForCES protocol/model must support the discovery of static capabilities of an FE. The protocol/model may also support dynamic capabilities when they are supported by the FEs. The ForCES protocol should support logical addressing for multicast in addition to unicast. The FE ID, CE ID fields in the header will be used for addressing FEs, CEs. The ForCES protocol should have separate channels/connections/(any other terminology ?) for data and control messages. By data messages we mean control protocol packets such as OSPF, RIP packets, etc. which need to be redirected from FE to CE or forwarded from CE to FE. By control messages we mean all other control/capability/configuration messages. The ForCES protocol will mandate a minimum set of transports for data and control connections/channels for interoperability reasons. The ForCES protocol will take advantage of underlying transports/ interconnects to provide features such as reliability, security to keep the protocol design itself simple. The ForCES protocol will run directly over layer 2 interconnects. It can either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. This is just a starting list, we should continue adding to this one as we discuss more ideas. Pls feel free to give comments or make any changes to the text above. BTW note to the list-admin, gyf@htrdc.com address is not working. Regards Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Tuesday, March 02, 2004 4:55 PM To: 'hadi@znyx.com' Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; zsolt.haraszti@ericsson.com; forces-protocol@ietf.org Subject: RE: ForCES Protocol Analysis Design Team Administrivia Hi Jamal, All I briefly chatted with David, Patrick regarding our deliverables by March 20th and I got a feeling that they are looking for whether we can merge the protocols and what are the high level design features that we all agree on. I think most of us already agree that we can achieve a merge if we work towards it. I would suggest that we first try to get all the high level features list out and agree on it, then proceed to the details. So in that spirit I would suggest to postpone getting into details such as length of bits in the header, what the format is, etc for now and quickly come up with a list of common ideas. Some of the items below that we all seem to agree on may be a good start. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 02:00:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07340 for ; Thu, 4 Mar 2004 02:00:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aympf-0007rp-0X for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 01:59:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246xkm4030235 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 01:59:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aympe-0007ra-Pb for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:59:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07107 for ; Thu, 4 Mar 2004 01:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aympb-00036T-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:59:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymoX-0002s5-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:58:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aymnt-0002fY-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 01:57:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymnw-0007cR-IV; Thu, 04 Mar 2004 01:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymnA-0007bE-TQ for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 01:57:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06919 for ; Thu, 4 Mar 2004 01:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aymn7-0002d7-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aymm8-0002SH-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:56:08 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayml7-000290-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 01:55:05 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i246wA0K019882 for ; Thu, 4 Mar 2004 06:58:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i246mvIZ004183 for ; Thu, 4 Mar 2004 06:49:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030322543400126 for ; Wed, 03 Mar 2004 22:54:34 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 22:54: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 Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0023A11EE@orsmsx410.jf.intel.com> Thread-Topic: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcQAzdwK1Drou7DQSmmHKKW5movCcAA5dx4Q From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 Mar 2004 06:54:34.0365 (UTC) FILETIME=[8D3F22D0:01C401B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 22:54:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal Your list below looks good to me, we can start more detailed discussion on this soon. (We have already discussed some of the items below) I sent out a list of more high level ideas that I think we agree on. Let me know what you think about it. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Tuesday, March 02, 2004 7:16 PM To: Khosravi, Hormuzd M Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; zsolt.haraszti@ericsson.com; forces-protocol@ietf.org Subject: RE: ForCES Protocol Analysis Design Team Administrivia Hormuzd, On Tue, 2004-03-02 at 19:54, Khosravi, Hormuzd M wrote: > Hi Jamal, All >=20 > I briefly chatted with David, Patrick regarding our deliverables by > March 20th and I got a feeling that they are looking for whether we can > merge the protocols and what are the high level design features that we > all agree on. > I think most of us already agree that we can achieve a merge if we work > towards it. I would suggest that we first try to get all the high level > features list out and agree on it, then proceed to the details. >=20 > So in that spirit I would suggest to postpone getting into details such > as length of bits in the header, what the format is, etc for now and > quickly come up with a list of common ideas. Some of the items below > that we all seem to agree on may be a good start. >=20 We could make the encoding discussion the last thing but it needs to be discussed as we are discussing the mechanisms. The main discussion points as i see it (to extend what David posted) are: 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast=20 { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC}=20 4) Congestion control 5) Reliability 6) Security 7) High availability Its almost like 2-5 are very closely related. I am doing this off the top of my head so i probably missed something. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 02:26:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22129 for ; Thu, 4 Mar 2004 02:26:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynEe-00007F-IA for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 02:25:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247PauS000441 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 02:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynEe-00006s-9d for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:25:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22079 for ; Thu, 4 Mar 2004 02:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynEa-0000uC-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 02:25:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynDv-0000iF-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 02:24:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynDA-0000Ty-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 02:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynDC-000831-Mf; Thu, 04 Mar 2004 02:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynCz-0007zB-L3 for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 02:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21795 for ; Thu, 4 Mar 2004 02:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynCw-0000T5-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 02:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynC6-0000Dm-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 02:22:59 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AynB9-0007dl-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 02:21:59 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i247NT2G029181 for ; Thu, 4 Mar 2004 07:23:29 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i247FTIl014498 for ; Thu, 4 Mar 2004 07:15:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030323212603026 for ; Wed, 03 Mar 2004 23:21: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.6713); Wed, 3 Mar 2004 23:21: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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0023A11F3@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQAVxdbpPHWaZ5SSA2tld74bEVMgABXv0/w From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 Mar 2004 07:21:27.0001 (UTC) FILETIME=[4E73DC90:01C401B9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 23:21:26 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi David Your summary below of the discussion with Ads on the different issues seems like very reasonable approaches to me. I agree that it will be a good idea to present transport alternatives at IP and non-IP level for the ForCES protocol. We can mandate one or more transport for IP and one or more transport for non-IP, this way the interoperability requirements are met and at the same time, the in-box, out of box scenarios are met. Also, agree with having multiple channels/connections to differentiate C & D traffic between CEs and FEs. On the unicast/multicast topic, dual mandatory approach again seems a good idea to support interoperability. The one thing that I would like to point out is that for any ForCES protocol implementation to work, unicast will definitely be required at the minimum. One could also mandate using multicast for certain cases where it will be useful (e.g. IPv4/config table download), if it is supported by the interconnect as you stated. But just multicast without unicast will not work, atleast not efficiently. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Tuesday, March 02, 2004 5:06 AM To: forces-protocol@ietf.org Subject: [Forces-protocol] Comments from chat with ADs Patrick and I spent about 90 minutes last night chatting with Bill and Alex about ForCES, with maybe half of the time on the protocol. In the conversations with them, along with some follow-up chats I had with Allison Mankin, the following topics where covered: multiple=20 channels, multicast/unicast, and congestion=20 control. Below is what I recall from memory=20 (Patrick please correct me/elaborate as needed :) Multiple channels: =20 I discussed the interference issue that=20 was identified by the GRMP team. Bill & Alex agreed that many OS implementations can have an interference property (i.e. where two different connections will have queuing interference lower in the networking stack in the OS). So it is necessary to make sure when implementing a FE (or CE probably as well) that this is taken into account. Methods of doing that include: * Manually queuing packets (i.e. feed OS few enough packets that it cannot get into trouble - although you pay a performance price for that, in that fine grained scheduling takes cycles) * Indicating to the OS to treat flows differently -=20 some real-time OS will let you do this, that is they are implemented to internally retain QoS between flows. However, it was also mentioned that intra-FE=20 interference is only one kind of interference. Good FE implementation (e.g. by manually queuing above the OS) helps to fix intra-FE interference, but it does not solve inter-FE interference. That is, if all (C & D) packets are always on the same connection, that makes it impossible on the wire to differentiate them from one another. Imagine you have a bunch of FEs with some of them being subject to DOS attack for D packets, and you want to query one of the FEs for statistics. It would be good to have some way of ensuring the C packets (or any high priority packets - OSPF HELLO maybe) get through. Separate channels (as Jamal indicated, don't even have to be C & D) makes this possible. Putting everything on one channel makes it impossible to deal with inter-FE interference in a differentiated fashion.=20 Multicast & Unicast: =20 The discussion on this started out with a discussion of the IETF protocol design BKM that options can ruin compatibility. That is, if there are four ways to implement something, all optional, then you can have client 1 implement A & B, and client 2 implement C & D, and even though both clients are 100% compliant, they cannot talk to one another. Better to say all clients must implement A and make B, C, and D optional, so that way you know that all implementations will be able to=20 at least talk. Patrick & I pushed on this a bit, explaining that we actually had potentially (at least) two different environments - very close environments where multicast support could be present in the interconnect, and=20 not-as-close environments (and some close environments as well) where multicast was not available. Bill & Alex indicated that if there really are two quite different cases, then it is possible to have a "dual mandatory" approach. I.e.: If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. Congestion control: Several times over the whole conversation the topic of congestion control came up. Also, as part of some TIPC discussions, I ended up spending some time talking to Allison Mankin (transport AD) about congestion control as well. All the ADs I talked to where consistent on=20 the following: If you are running over IP, you MUST act in a RFC2914 compliant fashion (i.e. respond to congestion like TCP or SCTP or RMT does). Two reasons where put forth for this: 1) Any time you define an IP-based protocol you cannot guarantee that it will not go out over the Internet. As such, the IESG will NOT standardize IP protocols with "bad" (non-2914) behaviors. 2) Lots of implementation experience showing that other congestion control mechanisms don't work (congestion collapse etc). They where very firm on the above and my impression was that convincing them otherwise would be very difficult. That being said, a second alternative did arise: If you are not implementing on top of IP (e.g. running on Infiniband, ATM, Ethernet) then you could rely on mechanisms for congestion control built into what you are relying on, or even consider building your own congestion control mechanisms (ala TIPC). This makes it possible to define (for example) a multicast transport for forces without having to go all the way and implementing RMT - as long as it is clear that it isn't over IP. The ADs went as far as saying that the IETF could even accept standards- track drafts that say nothing about IP (e.g. define an Ethernet-only transport for ForCES), if it is necessary=20 for ForCES. GSMP and (some other group I forgot) was given as an example. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:01:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14128 for ; Thu, 4 Mar 2004 16:01:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzxZ-0007iP-6K for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:00:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24L0nMA029648 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyzxY-0007i7-D4 for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14090 for ; Thu, 4 Mar 2004 16:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyzxX-0002q9-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:00:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayzwc-0002fS-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 15:59:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayzvp-0002VR-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 15:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayzvp-0007dQ-My; Thu, 04 Mar 2004 15:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayzuu-0007ck-Gl for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 15:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13943 for ; Thu, 4 Mar 2004 15:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayzut-0002Ij-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 15:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayztt-00027K-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 15:57:02 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AyztT-0001vL-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 15:56:35 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i24KtxDm021643; Thu, 4 Mar 2004 14:55:59 -0600 (CST) Message-ID: <404797DE.2060506@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia References: <9CB758BBEE58754F8F33234D75B9F4B0023A11EB@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0023A11EB@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Mar 2004 14:55:58 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, I don't understand this requirement (reproduced below): ------------------------------------------------------------------------ The ForCES protocol will run directly over layer 2 interconnects. It can either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. ------------------------------------------------------------------------ Can you explain this? Which L2 are you refering to? (Internet Protocol layer 2 or OSI layer2). Regards, Alex. Khosravi, Hormuzd M wrote: >Here is a starter list of common high level ideas/features/principles >that I believe we all agree on... > >All ForCES protocol messages should consist of a fixed size header and >variable size payload fields. Further, the protocol header is made up of >CE ID, FE ID fields in addition to other fields (TBD) > >All ForCES protocol messages should be 32-bit aligned. > >The ForCES protocol payload consists of a number of variable size TLVs >i.e. all ForCES messages must use TLV encoding. > >The FE ID field in the protocol header is assigned or allocated by the >CE. > >The ForCES protocol/model must support the discovery of static >capabilities of an FE. The protocol/model may also support dynamic >capabilities when they are supported by the FEs. > >The ForCES protocol should support logical addressing for multicast in >addition to unicast. The FE ID, CE ID fields in the header will be used >for addressing FEs, CEs. > >The ForCES protocol should have separate channels/connections/(any other >terminology ?) for data and control messages. By data messages we mean >control protocol packets such as OSPF, RIP packets, etc. which need to >be redirected from FE to CE or forwarded from CE to FE. By control >messages we mean all other control/capability/configuration messages. > >The ForCES protocol will mandate a minimum set of transports for data >and control connections/channels for interoperability reasons. > >The ForCES protocol will take advantage of underlying transports/ >interconnects to provide features such as reliability, security to keep >the protocol design itself simple. > >The ForCES protocol will run directly over layer 2 interconnects. It can >either use additional TLVs or encapsulation headers or transports such >as TIPC to provide the missing functionality such as reliability, >fragmentation, etc. > >This is just a starting list, we should continue adding to this one as >we discuss more ideas. >Pls feel free to give comments or make any changes to the text above. > > >BTW note to the list-admin, gyf@htrdc.com address is not working. > >Regards >Hormuzd > >-----Original Message----- >From: Khosravi, Hormuzd M >Sent: Tuesday, March 02, 2004 4:55 PM >To: 'hadi@znyx.com' >Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; >spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; >ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; >jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; >zsolt.haraszti@ericsson.com; forces-protocol@ietf.org >Subject: RE: ForCES Protocol Analysis Design Team Administrivia > >Hi Jamal, All > >I briefly chatted with David, Patrick regarding our deliverables by >March 20th and I got a feeling that they are looking for whether we can >merge the protocols and what are the high level design features that we >all agree on. >I think most of us already agree that we can achieve a merge if we work >towards it. I would suggest that we first try to get all the high level >features list out and agree on it, then proceed to the details. > >So in that spirit I would suggest to postpone getting into details such >as length of bits in the header, what the format is, etc for now and >quickly come up with a list of common ideas. Some of the items below >that we all seem to agree on may be a good start. > > >regards >Hormuzd > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:20:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14621 for ; Thu, 4 Mar 2004 16:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Fz-0000ro-Lb for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:19:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24LJpQg003326 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Fz-0000rZ-1V for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:19:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14569 for ; Thu, 4 Mar 2004 16:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Fx-00065k-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0F2-0005wC-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:18:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az0EC-0005mP-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0EC-0000pi-BA; Thu, 04 Mar 2004 16:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0E5-0000mB-Q3 for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 16:17:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14496 for ; Thu, 4 Mar 2004 16:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0E4-0005lY-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:17:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0D7-0005b7-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:16:54 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Az0CK-0005Gz-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:16:04 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i24LHP2G002438; Thu, 4 Mar 2004 21:17:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i24LGFd8006055; Thu, 4 Mar 2004 21:17:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030413151609619 ; Thu, 04 Mar 2004 13:15:16 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 13:15:16 -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 Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243EAD0@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcQCKzHoQv1ZYTlLSKuLUKg5cW70KgAABglw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 04 Mar 2004 21:15:16.0506 (UTC) FILETIME=[CA5C7FA0:01C4022D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 13:15:15 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe layer 2 protocol is the same in both models (internet and OSI). Common example is Ethernet. May be the use of the word "interconnect" was confusing. What I mean is that the ForCES protocol should be able to run directly over layer 2 protocols like ethernet. This might be useful in some in-box scenarios. Let me know if you have any other questions. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 12:56 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Hormuzd, I don't understand this requirement (reproduced below): ------------------------------------------------------------------------ The ForCES protocol will run directly over layer 2 interconnects. It can either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. ------------------------------------------------------------------------ Can you explain this? Which L2 are you refering to? (Internet Protocol layer 2 or OSI layer2).=20 Regards, Alex. Khosravi, Hormuzd M wrote: >Here is a starter list of common high level ideas/features/principles >that I believe we all agree on... > >All ForCES protocol messages should consist of a fixed size header and >variable size payload fields. Further, the protocol header is made up of >CE ID, FE ID fields in addition to other fields (TBD) > >All ForCES protocol messages should be 32-bit aligned. > >The ForCES protocol payload consists of a number of variable size TLVs >i.e. all ForCES messages must use TLV encoding. > >The FE ID field in the protocol header is assigned or allocated by the >CE. > >The ForCES protocol/model must support the discovery of static >capabilities of an FE. The protocol/model may also support dynamic >capabilities when they are supported by the FEs. > >The ForCES protocol should support logical addressing for multicast in >addition to unicast. The FE ID, CE ID fields in the header will be used >for addressing FEs, CEs. > >The ForCES protocol should have separate channels/connections/(any other >terminology ?) for data and control messages. By data messages we mean >control protocol packets such as OSPF, RIP packets, etc. which need to >be redirected from FE to CE or forwarded from CE to FE. By control >messages we mean all other control/capability/configuration messages. > >The ForCES protocol will mandate a minimum set of transports for data >and control connections/channels for interoperability reasons. > >The ForCES protocol will take advantage of underlying transports/ >interconnects to provide features such as reliability, security to keep >the protocol design itself simple. > >The ForCES protocol will run directly over layer 2 interconnects. It can >either use additional TLVs or encapsulation headers or transports such >as TIPC to provide the missing functionality such as reliability, >fragmentation, etc. > >This is just a starting list, we should continue adding to this one as >we discuss more ideas. >Pls feel free to give comments or make any changes to the text above. > > >BTW note to the list-admin, gyf@htrdc.com address is not working. > >Regards >Hormuzd > >-----Original Message----- >From: Khosravi, Hormuzd M=20 >Sent: Tuesday, March 02, 2004 4:55 PM >To: 'hadi@znyx.com' >Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; >spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; >ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; >jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; >zsolt.haraszti@ericsson.com; forces-protocol@ietf.org >Subject: RE: ForCES Protocol Analysis Design Team Administrivia > >Hi Jamal, All > >I briefly chatted with David, Patrick regarding our deliverables by >March 20th and I got a feeling that they are looking for whether we can >merge the protocols and what are the high level design features that we >all agree on. >I think most of us already agree that we can achieve a merge if we work >towards it. I would suggest that we first try to get all the high level >features list out and agree on it, then proceed to the details. > >So in that spirit I would suggest to postpone getting into details such >as length of bits in the header, what the format is, etc for now and >quickly come up with a list of common ideas. Some of the items below >that we all seem to agree on may be a good start. > > >regards >Hormuzd > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:26:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14725 for ; Thu, 4 Mar 2004 16:26:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Lm-0001SZ-7z for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:25:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24LPoiT005605 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Ll-0001SK-Ve for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:25:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14712 for ; Thu, 4 Mar 2004 16:25:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Lk-00074Q-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:25:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0Kq-0006ue-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:24:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Jz-0006kn-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0K0-0001IE-VZ; Thu, 04 Mar 2004 16:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Ju-0001Hr-O7 for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 16:23:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14686 for ; Thu, 4 Mar 2004 16:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Jt-0006kE-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:23:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0Iw-0006aI-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:22:55 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1Az0IY-0006Q1-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:22: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 i24LM0Dm027253; Thu, 4 Mar 2004 15:22:00 -0600 (CST) Message-ID: <40479DF7.2090004@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <9CB758BBEE58754F8F33234D75B9F4B0023A11F3@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0023A11F3@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Mar 2004 15:21:59 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, Why should multicast be "mandated for certain cases where it will be useful" if there is a simpler, more robust way to do the same thing? I'll say we don't mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: >Hi David > >Your summary below of the discussion with Ads on the different issues >seems like very reasonable approaches to me. > >I agree that it will be a good idea to present transport alternatives at >IP and non-IP level for the ForCES protocol. We can mandate one or more >transport for IP and one or more transport for non-IP, this way the >interoperability requirements are met and at the same time, the in-box, >out of box scenarios are met. > >Also, agree with having multiple channels/connections to differentiate C >& D traffic between CEs and FEs. On the unicast/multicast topic, dual >mandatory approach again seems a good idea to support interoperability. >The one thing that I would like to point out is that for any ForCES >protocol implementation to work, unicast will definitely be required at >the minimum. One could also mandate using multicast for certain cases >where it will be useful (e.g. IPv4/config table download), if it is >supported by the interconnect as you stated. But just multicast without >unicast will not work, atleast not efficiently. > >Regards >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >Sent: Tuesday, March 02, 2004 5:06 AM >To: forces-protocol@ietf.org >Subject: [Forces-protocol] Comments from chat with ADs > >Patrick and I spent about 90 minutes last night >chatting with Bill and Alex about ForCES, with >maybe half of the time on the protocol. In >the conversations with them, along with some >follow-up chats I had with Allison Mankin, the >following topics where covered: multiple >channels, multicast/unicast, and congestion >control. Below is what I recall from memory >(Patrick please correct me/elaborate as needed :) > > > >Multiple channels: > >I discussed the interference issue that >was identified by the GRMP team. Bill & >Alex agreed that many OS implementations can have >an interference property (i.e. where two different >connections will have queuing interference lower in >the networking stack in the OS). So it is necessary >to make sure when implementing a FE (or CE probably >as well) that this is taken into account. Methods >of doing that include: >* Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) >* Indicating to the OS to treat flows differently - > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. >However, it was also mentioned that intra-FE >interference is only one kind of interference. Good >FE implementation (e.g. by manually queuing above the >OS) helps to fix intra-FE interference, but it does >not solve inter-FE interference. That is, if all >(C & D) packets are always on the same connection, >that makes it impossible on the wire to differentiate >them from one another. Imagine you have a bunch of >FEs with some of them being subject to DOS attack for >D packets, and you want to query one of the FEs for >statistics. It would be good to have some way of >ensuring the C packets (or any high priority packets - >OSPF HELLO maybe) get through. Separate channels >(as Jamal indicated, don't even have to be C & D) >makes this possible. Putting everything on one >channel makes it impossible to deal with inter-FE >interference in a differentiated fashion. > > >Multicast & Unicast: > >The discussion on this started out with a discussion >of the IETF protocol design BKM that options can ruin >compatibility. That is, if there are four ways to >implement something, all optional, then you can have >client 1 implement A & B, and client 2 implement C & D, >and even though both clients are 100% compliant, they >cannot talk to one another. Better to say all clients >must implement A and make B, C, and D optional, so that >way you know that all implementations will be able to >at least talk. > >Patrick & I pushed on this a bit, explaining that we >actually had potentially (at least) two different >environments - very close environments where multicast >support could be present in the interconnect, and >not-as-close environments (and some close >environments as well) where multicast was not available. > >Bill & Alex indicated that if there really are two >quite different cases, then it is possible to have a >"dual mandatory" approach. I.e.: > >If your underlying interconnect supports multicast, >then you MUST implement the following (multicast) >method of communication. > >If your underlying interconnect supports unicast, then >you MUST implement the following (unicast) method >of communication. > >This will guarantee interop, although at a potential >extra cost (cost being having to potentially support >both when both are present). While this isn't optimal, >it does at least give some flexibility. > > > >Congestion control: > >Several times over the whole conversation the topic >of congestion control came up. Also, as part of some >TIPC discussions, I ended up spending some time talking >to Allison Mankin (transport AD) about congestion control >as well. All the ADs I talked to where consistent on >the following: > >If you are running over IP, you MUST act in a RFC2914 >compliant fashion (i.e. respond to congestion like TCP >or SCTP or RMT does). Two reasons where put forth for >this: >1) Any time you define an IP-based protocol you cannot >guarantee that it will not go out over the Internet. As >such, the IESG will NOT standardize IP protocols with >"bad" (non-2914) behaviors. >2) Lots of implementation experience showing that other >congestion control mechanisms don't work (congestion >collapse etc). > >They where very firm on the above and my impression was >that convincing them otherwise would be very difficult. > >That being said, a second alternative did arise: If >you are not implementing on top of IP (e.g. running on >Infiniband, ATM, Ethernet) then you could rely on mechanisms >for congestion control built into what you are relying on, >or even consider building your own congestion control >mechanisms (ala TIPC). This makes it possible to define >(for example) a multicast transport for forces without >having to go all the way and implementing RMT - as long >as it is clear that it isn't over IP. The ADs went as >far as saying that the IETF could even accept standards- >track drafts that say nothing about IP (e.g. define an >Ethernet-only transport for ForCES), if it is necessary >for ForCES. GSMP and (some other group I forgot) was >given as an example. > >Cheers, >David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:32:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14867 for ; Thu, 4 Mar 2004 16:32:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Ra-0001lX-8h for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:31:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24LVog3006781 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:31:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Ra-0001lI-4K for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:31:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14842 for ; Thu, 4 Mar 2004 16:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0RY-0000GW-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:31:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0Qc-000068-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:30:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Pq-0007jy-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Pr-0001e9-EQ; Thu, 04 Mar 2004 16:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Pd-0001cl-1N for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 16:29:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14788 for ; Thu, 4 Mar 2004 16:29:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Pb-0007jU-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:29:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0Oc-0007ZT-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:28:47 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Az0Nf-0007Ot-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:27:47 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030413282745:62095 ; Thu, 4 Mar 2004 13:28:27 -0800 Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0023A11EB@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B0023A11EB@orsmsx410.jf.intel.com> Organization: Znyx Networks Message-Id: <1078435665.1028.100.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 03/04/2004 01:28:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/04/2004 01:28:29 PM, Serialize complete at 03/04/2004 01:28:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Mar 2004 16:27:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-04 at 01:50, Khosravi, Hormuzd M wrote: > Here is a starter list of common high level ideas/features/principles > that I believe we all agree on... > > All ForCES protocol messages should consist of a fixed size header and > variable size payload fields. Further, the protocol header is made up of > CE ID, FE ID fields in addition to other fields (TBD) The general term should be ID (PID is what we called it). Essentially this is an application Identifier. There could be more than one application per FE or CE. So the description FE ID or CE ID is limiting. > All ForCES protocol messages should be 32-bit aligned. > > The ForCES protocol payload consists of a number of variable size TLVs > i.e. all ForCES messages must use TLV encoding. > The TLVs being 32 bit aligned as well would be a good thing to have. > The FE ID field in the protocol header is assigned or allocated by the > CE. Again, note my comments above; btw, i did describe this detail in the implementation experience notes i sent. I could resend. It is also acceptable that the CE issue the FE with a range of PIDs that it can be used by the various apps. We did this in our implementation (i realize its an implementation specific, but its a good experience to share) Maybe we should start with resolving the header? It's the easiest thing to come to agreement on. Actually before that even, lets identify the value of the ID. Is this acceptable? > The ForCES protocol/model must support the discovery of static > capabilities of an FE. The protocol/model may also support dynamic > capabilities when they are supported by the FEs. However, note, this may have some protocol semantic value. Perhaps, part of the capability exchange can resolve the may. > The ForCES protocol should support logical addressing for multicast in > addition to unicast. The FE ID, CE ID fields in the header will be used > for addressing FEs, CEs. I take it this is application level addressing; i think we need to resolve this first as i said above. > The ForCES protocol should have separate channels/connections/(any other > terminology ?) for data and control messages. By data messages we mean > control protocol packets such as OSPF, RIP packets, etc. which need to > be redirected from FE to CE or forwarded from CE to FE. By control > messages we mean all other control/capability/configuration messages. Is there a good reason for such separation? >From my reading, you have one connection less reliable than the other, is that correct? > The ForCES protocol will mandate a minimum set of transports for data > and control connections/channels for interoperability reasons. Refer to the mail David posted on some of the suggestions the ADs were making i.e dual mandatory" approach. I agree on the interop part. We need to scope this out. > The ForCES protocol will take advantage of underlying transports/ > interconnects to provide features such as reliability, security to keep > the protocol design itself simple. Agreed > The ForCES protocol will run directly over layer 2 interconnects. It can > either use additional TLVs or encapsulation headers or transports such > as TIPC to provide the missing functionality such as reliability, > fragmentation, etc. Agreed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:37:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15093 for ; Thu, 4 Mar 2004 16:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0WS-0001yW-6r for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:36:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24LaqoG007586 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0WR-0001yH-Uf for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:36:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15078 for ; Thu, 4 Mar 2004 16:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0WQ-00018G-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:36:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0VU-0000yQ-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:35:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az0Ug-0000oZ-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0Uh-0001rn-BK; Thu, 04 Mar 2004 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0UX-0001pP-8I for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 16:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14968 for ; Thu, 4 Mar 2004 16:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0UV-0000n8-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0TT-0000c9-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:33:47 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Az0SV-0000RR-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:32:47 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030413332830:62100 ; Thu, 4 Mar 2004 13:33:28 -0800 Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B0023A11EE@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B0023A11EE@orsmsx410.jf.intel.com> Organization: Znyx Networks Message-Id: <1078435966.1029.107.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 03/04/2004 01:33:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/04/2004 01:33:29 PM, Serialize complete at 03/04/2004 01:33:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Mar 2004 16:32:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, Based on your other posting i would like to suggest we start the following: 1) start with discussing the value of the ID to the app. 2) Lets then follow with a little bit time on the encoding. I am sure there will be changes on the header down the road as we keep discussing; but lets have a start on it. 3) lets move to the transport discussion on the dual approach. For 1) & 2) above i will repost some of the ideas i posted earlier and lets take it from there. cheers, jamal On Thu, 2004-03-04 at 01:54, Khosravi, Hormuzd M wrote: > Hi Jamal > > Your list below looks good to me, we can start more detailed discussion > on this soon. (We have already discussed some of the items below) I sent > out a list of more high level ideas that I think we agree on. Let me > know what you think about it. > > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Tuesday, March 02, 2004 7:16 PM > To: Khosravi, Hormuzd M > Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; > spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; > ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; > jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; > zsolt.haraszti@ericsson.com; forces-protocol@ietf.org > Subject: RE: ForCES Protocol Analysis Design Team Administrivia > > Hormuzd, > > On Tue, 2004-03-02 at 19:54, Khosravi, Hormuzd M wrote: > > Hi Jamal, All > > > > I briefly chatted with David, Patrick regarding our deliverables by > > March 20th and I got a feeling that they are looking for whether we > can > > merge the protocols and what are the high level design features that > we > > all agree on. > > I think most of us already agree that we can achieve a merge if we > work > > towards it. I would suggest that we first try to get all the high > level > > features list out and agree on it, then proceed to the details. > > > > So in that spirit I would suggest to postpone getting into details > such > > as length of bits in the header, what the format is, etc for now and > > quickly come up with a list of common ideas. Some of the items below > > that we all seem to agree on may be a good start. > > > > We could make the encoding discussion the last thing but it needs > to be discussed as we are discussing the mechanisms. > > The main discussion points as i see it (to extend what David posted) > are: > > 1) Encoding > 2) Multiple channels/connections > 3) Transport: unicast/multicast/broadcast > { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} > 4) Congestion control > 5) Reliability > 6) Security > 7) High availability > > Its almost like 2-5 are very closely related. > > I am doing this off the top of my head so i probably missed something. > > cheers, > jamal > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 16:52:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15513 for ; Thu, 4 Mar 2004 16:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0l0-0003Ql-Of for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 16:51:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Lpsxp013184 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 16:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0l0-0003QZ-KA for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 16:51:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15495 for ; Thu, 4 Mar 2004 16:51:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0ky-0003lh-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:51:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0k3-0003ab-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:50:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az0jC-0003QC-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 16:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0jD-0003Hk-4Q; Thu, 04 Mar 2004 16:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az0iz-0003GJ-Os for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 16:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15464 for ; Thu, 4 Mar 2004 16:49:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az0ix-0003OF-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az0i0-0003Dl-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:48:49 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Az0h3-00032U-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 16:47:49 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030413482798:62111 ; Thu, 4 Mar 2004 13:48:27 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243EAD0@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B00243EAD0@orsmsx410.jf.intel.com> Organization: Znyx Networks Message-Id: <1078436863.1028.121.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 03/04/2004 01:48:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/04/2004 01:48:31 PM, Serialize complete at 03/04/2004 01:48:31 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Issue 0: Application addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Mar 2004 16:47:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, heres some text for application addressing ---- Source and Destination IDs: These are application level identifiers. They could be used to address the following: - an LFB on the FE, - a set of LFBs on an FE - a set of LFBs on different FEs - proxies for LFBs, - proxies for control application in the form on the CEs, - the FE, - a set of FEs - all FEs - the CE. - a set of CEs - all CEs The above shows need for having the ID being able to be IDed as unicast, broadcast or multicast. For clarity, i could create a diagram of what we used. I will post the header i posted earlier next. Or maybe we should stick to resolving this first. Hopefully we can get to a good way to beat the several issues, i am doing this to hopefuly come to a style that we can use to beat the issues. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 18:02:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18941 for ; Thu, 4 Mar 2004 18:02:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1r6-0000Ef-KL for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 18:02:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24N2Gp4000903 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 18:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1r6-0000EU-DY for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 18:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18921 for ; Thu, 4 Mar 2004 18:02:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1r3-0001gY-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 18:02:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1q4-0001T3-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 18:01:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az1pQ-0001Gq-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 18:00:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1pS-0007RX-5F; Thu, 04 Mar 2004 18:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1oD-00072e-Ox for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 17:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18659 for ; Thu, 4 Mar 2004 17:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1oB-00012z-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 17:59:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1nG-0000pR-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 17:58:19 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Az1mc-0000bq-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 17:57:39 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i24N0c0K025227; Thu, 4 Mar 2004 23:00:38 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i24MojIl032709; Thu, 4 Mar 2004 22:51:25 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030414565326094 ; Thu, 04 Mar 2004 14:56:53 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 14:56:53 -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 Subject: RE: [Forces-protocol] views on different channels vs same channel Message-ID: <52D13A805349A249960B9943E5590BD80287CA16@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] views on different channels vs same channel Thread-Index: AcQAWuUNjmRSutQJQ6matElhsmxB3AB32zuw From: "Putzolu, David" To: "jeff pickering" , Cc: X-OriginalArrivalTime: 04 Mar 2004 22:56:53.0637 (UTC) FILETIME=[FC88DB50:01C4023B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 14:56:53 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable [hat off] I agree with Jeff's clarification. :) The fundamental problem is shared resources - which can occur in the OS, the app itself, or the physical link. =20 Every component in a ForCES protocol stack implementation has a role here: * The app (ForCES agent on FE) needs to be properly=20 implemented - it may need to compensate for OS=20 deficiencies (by queuing as described in Ligang Dong's=20 presentation), it may need to appropriately signal the=20 OS so that the OS does proper queuing, and needs to=20 signal the OS with QoS hints so that the OS uses the=20 appropriate link level mechanisms. * The OS needs to be properly implemented to differentiate flows and queue them appropriately (but some OS do not),=20 it also needs to accept QoS hints from the app and relay them to the link layer - that is, either direct different packets to different physical wires (some routers do this) or tell the link-layer it needs QoS support. * The link layer needs to be properly implemented to=20 support QoS mechanisms - this can be physically separate wires, or treat packets differently based on=20 QoS hints from the app (via the OS). Examples of the=20 latter include DMA channels as Jamal mentioned, or=20 other QoS mechanisms such as IntServ, DiffServ, VCs on=20 an ATM fabric, 802.1p in Ethernet, etc. -David > -----Original Message----- > From: forces-protocol-admin@ietf.org=20 > [mailto:forces-protocol-admin@ietf.org] On Behalf Of jeff pickering > Sent: Tuesday, March 02, 2004 5:31 AM > To: hadi@znyx.com > Cc: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] views on different channels vs=20 > same channel >=20 > Jamal, >=20 > I pretty much agree with 1), but would like to be careful=20 > about the term=20 > physical link. > In your example, if you have multiple DMA channels "listening" on a=20 > single physical > backbone, you can provide reasonable DOS protection. So maybe=20 > think of a=20 > logical > link as one where there is no overlap of underlying physical=20 > resource.=20 > The example > above would be a reasonable approximation if the backbone is=20 > much faster=20 > than the > DMA AND there was backpressure preventing backbone usage if one=20 > channel's DMA > is not available. >=20 > Jeff >=20 > Jamal Hadi Salim wrote: >=20 > >Hi, > >since i have just scanned through tons of emails (halfway there), > >let me share my view on the the topic.=20 > > > >1) If you are using the same physical link at the lowest=20 > layer it doesnt > >matter how many sockets/channels you have. The DoS impact is going > >to be at the lowest layer i.e the physical link for which=20 > the only cure > >is to have separate links. The next level up is just before=20 > the packet > >is DMAed into RAM that the OS can get to it; there is some smart > >hardware you can program to have multiple channels and drop at the=20 > >earliest level. Majority of the hardware you will find cant do this. > >Once the packet hits the OS, you can play with=20 > differentiation/QoS/rate > >metering of either the CPU time and/or bandwidth protection. > >Summary: having more than one virtual channel within one=20 > physical link > >is going to offer little protection against DOS.=20 > > > >2)On the sending: the value is going to be in having multiple queues > >just before the packet hits the OS. > >For this you need to recognize something in the packet. This does > >not imply the ForCES header needs some speacial signature; rather the > >packet can be administratively recognized and classified=20 > into a queue. > >Example could be recognizing a destination IP or MAC address. > > > >3) > >The idea of having such unique names to "channels" is almost=20 > bell-head > >approach. Reminds me of my ISDN days. There doesnt have to be a clear > >cut explicit use for each channel (i.e thou shalt only transport data > >packets). I am in agreement of having more than one=20 > connection, but the > >approach is different. > >Like i shared earlier on our experiences: the way we had the=20 > two or more > >"channels" was to have different granularities of reliability. > >We typically sent on a cheaper but less reliable mass=20 > transport and on > >failure if the message needs to be reliably delivered then it goes > >retransmitted on a more reliable unicast channel. > > > >cheers, > >jamal > > > > > >_______________________________________________ > >Forces-protocol mailing list > >Forces-protocol@ietf.org > >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > > =20 > > >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 21:17:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28546 for ; Thu, 4 Mar 2004 21:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4tl-00025d-7h for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 21:17:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i252HDmu008027 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 21:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4tl-00025O-3D for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 21:17:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28535 for ; Thu, 4 Mar 2004 21:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4ti-0007ML-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4sh-00079R-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:16:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az4rd-0006xy-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4rf-0001wv-N0; Thu, 04 Mar 2004 21:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4qo-0001sf-Hz for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 21:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28486 for ; Thu, 4 Mar 2004 21:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4qm-0006nx-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:14:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4pp-0006dB-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:13:09 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Az4p5-0006GL-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:12:23 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i252FP0K015274; Fri, 5 Mar 2004 02:15:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2525nIb024034; Fri, 5 Mar 2004 02:06:15 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030418114626162 ; Thu, 04 Mar 2004 18:11: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.6713); Thu, 4 Mar 2004 18:11: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 Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis Design TeamAdministrivia Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243EDB9@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] RE: ForCES Protocol Analysis Design TeamAdministrivia Thread-Index: AcQCL40ZstGGj/I6RkyDJs1zyL2jBAAI7IJA From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 Mar 2004 02:11:46.0917 (UTC) FILETIME=[3645C950:01C40257] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 18:11:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, Thanks for your response. See my comments below... -----Original Message----- > Here is a starter list of common high level ideas/features/principles > that I believe we all agree on... >=20 > All ForCES protocol messages should consist of a fixed size header and > variable size payload fields. Further, the protocol header is made up of > CE ID, FE ID fields in addition to other fields (TBD) The general term should be ID (PID is what we called it). Essentially this is an application Identifier. There could be=20 more than one application per FE or CE. So the description FE ID or CE ID is limiting. [HK] I am responding to this issue in the separate email that you sent out. > All ForCES protocol messages should be 32-bit aligned. >=20 > The ForCES protocol payload consists of a number of variable size TLVs > i.e. all ForCES messages must use TLV encoding. >=20 The TLVs being 32 bit aligned as well would be a good thing to have. [HK] Agreed > The FE ID field in the protocol header is assigned or allocated by the > CE. Again, note my comments above; btw, i did describe this detail in the implementation experience notes i sent. I could resend. It is also acceptable that the CE issue the FE with a range of PIDs that it can be used by the various apps. We did this in our implementation (i realize its an implementation specific, but its a good experience to share) Maybe we should start with resolving the header? It's the easiest thing to come to agreement on. =20 Actually before that even, lets identify the value of the ID. Is this acceptable? [HK] Yes. I will respond to your email on ID/header separately. > The ForCES protocol/model must support the discovery of static > capabilities of an FE. The protocol/model may also support dynamic > capabilities when they are supported by the FEs. However, note, this may have some protocol semantic value. Perhaps, part of the capability exchange can resolve the may. [HK] Yes, that's the direction of the FE model. > The ForCES protocol should have separate channels/connections/(any other > terminology ?) for data and control messages. By data messages we mean > control protocol packets such as OSPF, RIP packets, etc. which need to > be redirected from FE to CE or forwarded from CE to FE. By control > messages we mean all other control/capability/configuration messages. Is there a good reason for such separation? [HK] Yes there are several good reasons. One is reliability, the second is robustness against DoS attacks, yet another one pointed out by Steve was efficient delivery into CE's networking stack. I thought we had a common understanding on this, but I will be happy to send out a more detailed email on this topic if that helps. >From my reading, you have one connection less reliable than the other, is that correct? [HK] Yes and we clearly specify which messages/packets are sent on which Connections...important for interop. > The ForCES protocol will mandate a minimum set of transports for data > and control connections/channels for interoperability reasons. Refer to the mail David posted on some of the suggestions the ADs were making i.e dual mandatory" approach. I agree on the interop part. We need to scope this out. [HK] I agree, we need to have a discussion on this soon after resolving some of the other topics that you have raised. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 22:05:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28545 for ; Thu, 4 Mar 2004 21:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4tk-00025N-OY for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 21:17:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i252HCaN008011 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 21:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4tk-000258-Aq for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 21:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28532 for ; Thu, 4 Mar 2004 21:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4th-0007MG-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:17:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4sf-00079J-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:16:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az4rd-0006xt-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 21:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4rf-0001wn-GL; Thu, 04 Mar 2004 21:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4qk-0001sX-PY for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 21:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28477 for ; Thu, 4 Mar 2004 21:14:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4qi-0006nJ-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:14:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4pk-0006cY-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:13:05 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Az4ox-0006GJ-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 21:12:16 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i252Dd2G022926; Fri, 5 Mar 2004 02:13:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i252DLcM015810; Fri, 5 Mar 2004 02:13:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030418113503670 ; Thu, 04 Mar 2004 18:11:35 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 18:11: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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243EDB8@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCLs7nL03OZJM+QgqTRTug7WuVqwAIJBbg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 Mar 2004 02:11:36.0208 (UTC) FILETIME=[2FE3B900:01C40257] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 18:11:35 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alex, In general, I prefer using language such as MUST so that there is no confusion or interop issues in the protocol implementations. However, you raise a reasonable point and let me tell you my thoughts on this. We will definitely need Unicast between FEs and CEs at the minimum in the protocol. In addition, if the interconnect technology supports Multicast and there is a case where it is useful to the application (such as downloading IPv4 routes) we must allow it as well without breaking interop. In order to do that, we will need specific procedures in the protocol that will allow the CE and FE to negotiate on using multicast dynamically at run-time (say during the binding or joining phase between the CE and FE) and also associate different multicast groups with LFBs. We will also need to define how Reliability/CC etc. will be provided for multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, then applications will be able to use both unicast and multicast without any interop issues. Let me know what you guys think about this. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 1:22 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs Hormuzd, Why should multicast be "mandated for certain cases where it will be=20 useful" if there is a simpler, more robust way to do the same thing? I'll say we don't=20 mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: >Hi David > >Your summary below of the discussion with Ads on the different issues >seems like very reasonable approaches to me. > >I agree that it will be a good idea to present transport alternatives at >IP and non-IP level for the ForCES protocol. We can mandate one or more >transport for IP and one or more transport for non-IP, this way the >interoperability requirements are met and at the same time, the in-box, >out of box scenarios are met. > >Also, agree with having multiple channels/connections to differentiate C >& D traffic between CEs and FEs. On the unicast/multicast topic, dual >mandatory approach again seems a good idea to support interoperability. >The one thing that I would like to point out is that for any ForCES >protocol implementation to work, unicast will definitely be required at >the minimum. One could also mandate using multicast for certain cases >where it will be useful (e.g. IPv4/config table download), if it is >supported by the interconnect as you stated. But just multicast without >unicast will not work, atleast not efficiently. > >Regards >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >Sent: Tuesday, March 02, 2004 5:06 AM >To: forces-protocol@ietf.org >Subject: [Forces-protocol] Comments from chat with ADs > >Patrick and I spent about 90 minutes last night >chatting with Bill and Alex about ForCES, with >maybe half of the time on the protocol. In >the conversations with them, along with some >follow-up chats I had with Allison Mankin, the >following topics where covered: multiple=20 >channels, multicast/unicast, and congestion=20 >control. Below is what I recall from memory=20 >(Patrick please correct me/elaborate as needed :) > > > >Multiple channels: =20 > >I discussed the interference issue that=20 >was identified by the GRMP team. Bill & >Alex agreed that many OS implementations can have >an interference property (i.e. where two different >connections will have queuing interference lower in >the networking stack in the OS). So it is necessary >to make sure when implementing a FE (or CE probably >as well) that this is taken into account. Methods >of doing that include: >* Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) >* Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. >However, it was also mentioned that intra-FE=20 >interference is only one kind of interference. Good >FE implementation (e.g. by manually queuing above the >OS) helps to fix intra-FE interference, but it does >not solve inter-FE interference. That is, if all >(C & D) packets are always on the same connection, >that makes it impossible on the wire to differentiate >them from one another. Imagine you have a bunch of >FEs with some of them being subject to DOS attack for >D packets, and you want to query one of the FEs for >statistics. It would be good to have some way of >ensuring the C packets (or any high priority packets - >OSPF HELLO maybe) get through. Separate channels >(as Jamal indicated, don't even have to be C & D) >makes this possible. Putting everything on one >channel makes it impossible to deal with inter-FE >interference in a differentiated fashion.=20 > > >Multicast & Unicast: =20 > >The discussion on this started out with a discussion >of the IETF protocol design BKM that options can ruin >compatibility. That is, if there are four ways to >implement something, all optional, then you can have >client 1 implement A & B, and client 2 implement C & D, >and even though both clients are 100% compliant, they >cannot talk to one another. Better to say all clients >must implement A and make B, C, and D optional, so that >way you know that all implementations will be able to=20 >at least talk. > >Patrick & I pushed on this a bit, explaining that we >actually had potentially (at least) two different >environments - very close environments where multicast >support could be present in the interconnect, and=20 >not-as-close environments (and some close >environments as well) where multicast was not available. > >Bill & Alex indicated that if there really are two >quite different cases, then it is possible to have a >"dual mandatory" approach. I.e.: > >If your underlying interconnect supports multicast, >then you MUST implement the following (multicast) >method of communication. > >If your underlying interconnect supports unicast, then >you MUST implement the following (unicast) method >of communication. > >This will guarantee interop, although at a potential >extra cost (cost being having to potentially support >both when both are present). While this isn't optimal, >it does at least give some flexibility. > > > >Congestion control: > >Several times over the whole conversation the topic >of congestion control came up. Also, as part of some >TIPC discussions, I ended up spending some time talking >to Allison Mankin (transport AD) about congestion control >as well. All the ADs I talked to where consistent on=20 >the following: > >If you are running over IP, you MUST act in a RFC2914 >compliant fashion (i.e. respond to congestion like TCP >or SCTP or RMT does). Two reasons where put forth for >this: >1) Any time you define an IP-based protocol you cannot >guarantee that it will not go out over the Internet. As >such, the IESG will NOT standardize IP protocols with >"bad" (non-2914) behaviors. >2) Lots of implementation experience showing that other >congestion control mechanisms don't work (congestion >collapse etc). > >They where very firm on the above and my impression was >that convincing them otherwise would be very difficult. > >That being said, a second alternative did arise: If >you are not implementing on top of IP (e.g. running on >Infiniband, ATM, Ethernet) then you could rely on mechanisms >for congestion control built into what you are relying on, >or even consider building your own congestion control >mechanisms (ala TIPC). This makes it possible to define >(for example) a multicast transport for forces without >having to go all the way and implementing RMT - as long >as it is clear that it isn't over IP. The ADs went as >far as saying that the IETF could even accept standards- >track drafts that say nothing about IP (e.g. define an >Ethernet-only transport for ForCES), if it is necessary=20 >for ForCES. GSMP and (some other group I forgot) was >given as an example. > >Cheers, >David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 4 23:12:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03471 for ; Thu, 4 Mar 2004 23:12:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6gd-0005A9-QV for forces-protocol-archive@odin.ietf.org; Thu, 04 Mar 2004 23:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i254Bl6t019835 for forces-protocol-archive@odin.ietf.org; Thu, 4 Mar 2004 23:11:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6gc-00059p-U9 for forces-protocol-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 23:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03430 for ; Thu, 4 Mar 2004 23:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az6gY-0005nH-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 23:11:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az6fP-0005Wo-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 23:10:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az6cy-00052w-00 for forces-protocol-web-archive@ietf.org; Thu, 04 Mar 2004 23:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6cz-0004kH-Pd; Thu, 04 Mar 2004 23:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az6cE-0004Zj-29 for forces-protocol@optimus.ietf.org; Thu, 04 Mar 2004 23:07:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03173 for ; Thu, 4 Mar 2004 23:07:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az6c9-0004z3-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 23:07:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az6aB-0004cM-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 23:05:09 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1Az6Yg-0004Fp-00 for forces-protocol@ietf.org; Thu, 04 Mar 2004 23:03:37 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Fri, 5 Mar 2004 12:14:34 +0800 Message-ID: <038e01c40266$85c88fd0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Putzolu, David" , References: <52D13A805349A249960B9943E5590BD80287CA16@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] views on different channels vs same channel 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 12:01:22 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCkkgYmFzaWNhbGx5IGFncmVlIHdpdGggeW91ciBjbGFyaWZpY2F0aW9uLiBU aGUgb25seSB0aGluZyBpcyB0aGF0IGl0IHNlZW1zIHF1aXRlIGhhcmQgdG8gInNpZ25hbCIgdGhl IE9TIHdpdGggc3VjaCBRb1MgaGludHMuIA0KIEknbSBub3Qgc3VyZSBpZiBvciBub3QgdGhpcyB3 aWxsIGluZHVjZSB0byAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgY2FzZSwgIGJlY2F1c2UgdGhl cmUgYXJlIHNvIG1hbnkgT1MsICBsaW5rIGxheWVyIA0KbWVjaGFuaXNtcywgYW5kIGRpZmZlcmVu dCBzY2hlZHVsaW5nIG1lYW5zLiBPbiB0aGUgb3RoZXIgaGFuZCwgZXZlbiBpZiB0aGlzIGlzIHBv c3NpYmxlLCBpdCBzdGlsbCBuZWVkcyB0byBiZSANCnJlcHJlc2VudGVkIGluIEZvckNFUyBwcm90 b2NvbCBsYXllciBieSB1c2Ugb2YgbWVjaGFuaXNtcyBsaWtlIEZFIGNhcGFiaWxpdGllcywgYW5k IEZFIGF0dHJpYnV0ZXMuIFRoaXMgaXMgcXVpdGUNCnRoZSBzYW1lIGFzIEdSTVAsIG9ubHkgR1JN UCB0cmllcyB0byBhdm9pZCBiZWluZyB0b28gT1MgYW5kIGxpbmsgbGF5ZXIgc3BlY2lmYywgdGhl cmVmb3JlIHRvIGRlZmluZSBhcyBtdWNoIGFzIHBvc3NpYmxlDQppbiBGb3JDRVMgcHJvdG9jb2wg bGF5ZXIuIA0KDQpJIGFncmVlIHRoYXQgdG8gYmV0dGVyIHNvbHZlIHRoZSBjb25nZXN0aW9uIHBy b2JsZW0sIHdlIG5lZWQgdG8gdXNlIGVuZC10by1lbmQgUW9TIG1lY2hhbmlzbXMuIEFjdHVhbGx5 IFRDUC9TQ1RQL0RDQ1ANCnRoZW1zZWx2ZXMgY2FuIG5vdCBzdXBwbHkgdGhpcywgYW5kIE9TIG1l Y2hhbmlzbXMgYWxzbyBjYW5ub3Qgc3VwcGx5IHRoaXMuIFFvUyBwcm90b2NvbHMgaGF2ZSB0byBi ZSBjb21iaW5lZGx5IHVzZWQuIA0KDQpCZXN0IFJlZ2FyZHMsDQpXZWltaW5nDQoNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUHV0em9sdSwgRGF2aWQiIDxkYXZpZC5wdXR6 b2x1QGludGVsLmNvbT4NClRvOiAiamVmZiBwaWNrZXJpbmciIDxqcGlja2VyaW5nQGNyZWVrc2lk ZW5ldC5jb20+OyA8aGFkaUB6bnl4LmNvbT4NCkNjOiA8Zm9yY2VzLXByb3RvY29sQGlldGYub3Jn Pg0KU2VudDogRnJpZGF5LCBNYXJjaCAwNSwgMjAwNCA2OjU2IEFNDQpTdWJqZWN0OiBSRTogW0Zv cmNlcy1wcm90b2NvbF0gdmlld3Mgb24gZGlmZmVyZW50IGNoYW5uZWxzIHZzIHNhbWUgY2hhbm5l bA0KDQoNCltoYXQgb2ZmXQ0KSSBhZ3JlZSB3aXRoIEplZmYncyBjbGFyaWZpY2F0aW9uLiAgOikN Cg0KVGhlIGZ1bmRhbWVudGFsIHByb2JsZW0gaXMgc2hhcmVkIHJlc291cmNlcyAtIHdoaWNoIGNh bg0Kb2NjdXIgaW4gdGhlIE9TLCB0aGUgYXBwIGl0c2VsZiwgb3IgdGhlIHBoeXNpY2FsIGxpbmsu ICANCkV2ZXJ5IGNvbXBvbmVudCBpbiBhIEZvckNFUyBwcm90b2NvbCBzdGFjayBpbXBsZW1lbnRh dGlvbg0KaGFzIGEgcm9sZSBoZXJlOg0KKiBUaGUgYXBwIChGb3JDRVMgYWdlbnQgb24gRkUpIG5l ZWRzIHRvIGJlIHByb3Blcmx5IA0KICBpbXBsZW1lbnRlZCAtIGl0IG1heSBuZWVkIHRvIGNvbXBl bnNhdGUgZm9yIE9TIA0KICBkZWZpY2llbmNpZXMgKGJ5IHF1ZXVpbmcgYXMgZGVzY3JpYmVkIGlu IExpZ2FuZyBEb25nJ3MgDQogIHByZXNlbnRhdGlvbiksIGl0IG1heSBuZWVkIHRvIGFwcHJvcHJp YXRlbHkgc2lnbmFsIHRoZSANCiAgT1Mgc28gdGhhdCB0aGUgT1MgZG9lcyBwcm9wZXIgcXVldWlu ZywgYW5kIG5lZWRzIHRvIA0KICBzaWduYWwgdGhlIE9TIHdpdGggUW9TIGhpbnRzIHNvIHRoYXQg dGhlIE9TIHVzZXMgdGhlIA0KICBhcHByb3ByaWF0ZSBsaW5rIGxldmVsIG1lY2hhbmlzbXMuDQoq IFRoZSBPUyBuZWVkcyB0byBiZSBwcm9wZXJseSBpbXBsZW1lbnRlZCB0byBkaWZmZXJlbnRpYXRl DQogIGZsb3dzIGFuZCBxdWV1ZSB0aGVtIGFwcHJvcHJpYXRlbHkgKGJ1dCBzb21lIE9TIGRvIG5v dCksIA0KICBpdCBhbHNvIG5lZWRzIHRvIGFjY2VwdCBRb1MgaGludHMgZnJvbSB0aGUgYXBwIGFu ZCByZWxheQ0KICB0aGVtIHRvIHRoZSBsaW5rIGxheWVyIC0gdGhhdCBpcywgZWl0aGVyIGRpcmVj dCBkaWZmZXJlbnQNCiAgcGFja2V0cyB0byBkaWZmZXJlbnQgcGh5c2ljYWwgd2lyZXMgKHNvbWUg cm91dGVycyBkbw0KICB0aGlzKSBvciB0ZWxsIHRoZSBsaW5rLWxheWVyIGl0IG5lZWRzIFFvUyBz dXBwb3J0Lg0KKiBUaGUgbGluayBsYXllciBuZWVkcyB0byBiZSBwcm9wZXJseSBpbXBsZW1lbnRl ZCB0byANCiAgc3VwcG9ydCBRb1MgbWVjaGFuaXNtcyAtIHRoaXMgY2FuIGJlIHBoeXNpY2FsbHkN CiAgc2VwYXJhdGUgd2lyZXMsIG9yIHRyZWF0IHBhY2tldHMgZGlmZmVyZW50bHkgYmFzZWQgb24g DQogIFFvUyBoaW50cyBmcm9tIHRoZSBhcHAgKHZpYSB0aGUgT1MpLiAgIEV4YW1wbGVzIG9mIHRo ZSANCiAgbGF0dGVyIGluY2x1ZGUgRE1BIGNoYW5uZWxzIGFzIEphbWFsIG1lbnRpb25lZCwgb3Ig DQogIG90aGVyIFFvUyBtZWNoYW5pc21zIHN1Y2ggYXMgSW50U2VydiwgRGlmZlNlcnYsIFZDcyBv biANCiAgYW4gQVRNIGZhYnJpYywgODAyLjFwIGluIEV0aGVybmV0LCBldGMuDQogDQotRGF2aWQN Cg0K _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 00:41:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06899 for ; Fri, 5 Mar 2004 00:41:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az85B-0003xG-Nn for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 00:41:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i255fDAG015199 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 00:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az85B-0003x4-Gm for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 00:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06891 for ; Fri, 5 Mar 2004 00:41:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az858-0006nM-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 00:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az84B-0006dZ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 00:40:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az841-0006UB-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 00:40:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az843-0003v5-Nh; Fri, 05 Mar 2004 00:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az83C-0003tB-Cq for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 00:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06841 for ; Fri, 5 Mar 2004 00:39:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az839-0006Sv-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 00:39:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az82C-0006I1-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 00:38:09 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1Az81H-00065t-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 00:37:12 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Fri, 5 Mar 2004 13:48:20 +0800 Message-ID: <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Putzolu, David" , References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] Comments from chat with ADs 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 13:35:08 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClNvbWUgbW9yZSBjb21tZW50cyBvbiB0aGUgbXVsdGktY2hhbm5lbHMgZnJv bSB5b3VyIGxhc3QgZW1haWwgYXMgYmVsb3c6DQoNCkkgYWdyZWUgdGhhdCBtdWx0aXBsZSBGRXMg c2hhcmluZyB0aGUgc2FtZSBwaHlzaWNhbCBsaW5rIG1ha2VzIHByb2JsZW1zIG1vcmUgY29tcGxp Y2F0ZWQuIFRvIG1ha2UgdGhpbmdzIG1vcmUgY2xlYXIsIEkgd2FudCBzdGF0ZSBHUk1QJ3MgaWRl YXMNCmFnYWluIGhlcmUsIGZvciBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIHNvbWUgbWlzdW5kZXJz dGFuZGluZyBvbiBpdDoNCg0KMS4gR1JNUCBwcmVzZW50cyB0aGF0IHB1cmUgc2VwYXJhdGlvbiBv ZiBDL0QgaW4gdGhlIHNhbWUgcGh5c2ljYWwgbGluayBpcyBvZiBubyB1c2UgdG8gRG9TIHByb3Rl Y3Rpb24uIERvUyBwcm90ZWN0aW9uIGNhbiBvbmx5IGJlIGFjaGlldmVkIGJ5IGluc2lkZSBGRSBt ZWNoYW5pc21zIGV4Y2VwdCAgYSBzZXBhcmF0ZSBwaHlzaWNhbCBsaW5rIGlzIHVzZWQgYnkgQy9E LiBUaGlzIGFsc28gYXBwbGllcyB0byBtdWx0aS1GRXMgc2hhcmluZyB0aGUgc2FtZSBwaHlzaWNh bCBsaW5rcyBhcyB5b3UgbWVudGlvbmVkIGFib3ZlLiBBY3R1YWxseSBJIGNhbiBub3Qgc2VlIHN1 Y2ggc2VwYXJhdGlvbiBoYXMgc29sdmVkIHRoZSBEb1MgcHJvYmxlbSBmb3IgbXVsdGktRkUgY2Fz ZSBmcm9tIHRoZSBhYm92ZSB0eHQuICANCg0KMi4gV2UgZG8gbm90IG9wcG9zZSB0byBoYXZlIHN1 Y2ggc2VwYXJhdGlvbiBpZiBpdCdzIHByb3ZlbiB1c2VmdWwgZm9yIG90aGVycy4gQWN0dWFsbHkg dGhlIGtleSBHUk1QIGhhcyBkZWZpbmVkIGZvciBEb1MgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBp cyB0aGUgRkUgYXR0cmlidXRlIGZvciBEb1MgcHJvdGVjdGlvbiBwb2xpY3ksIHdoaWNoIGhhcyBu byBsaW1pdGF0aW9uIHdpdGggbXVsdGkgdHJhbnNwb3J0IGxheWVyIGNoYW5uZWxzLiBJZiBpdCdz IHByb3ZlbiBzZXBhcmF0aW9uIG9mIEMvRCBjaGFubmVscyBhcmUgdXNlZnVsLCBHUk1QIGNhbiBl YXNpbHkgYWRhcHQgaXQuIEJ1dCB3aGF0IHdlIG5lZWQgbW9yZSBkaXNjdXNzaW9uIGlzIHRyeWlu ZyB0byBzZWUgbW9yZSByZWFzb25zIGZvciBzdWNoIHNlcGFyYXRpb25zLiANCg0KMy4gQSBjb21i aW5lZCBjb250cm9sIG9mIEMgYW5kIEQgaXMgdXNlZnVsIGZvciBEb1MgcHJvdGVjdGlvbiBhcyB3 ZWxsIGFzIGZvciBjb25nZXN0aW9uLiANCkkgaGF2ZSB0byBub3RlIHRoYXQgdGhlIHNjaGVtZSBw cm9wb3NlZCBieSBGQUNUIGFuZCBhbHNvIG1lbnRpb25lZCBpbiB0aGUgcHJvcG9zZWQgYmFzaWMg bWVyZ2UgcHJpbmNpcGxlcyBvbmx5IGFzc3VtZSB0byBwcm92aWRlICBhIERhdGEgY2hhbm5lbCBj b250cm9sIG1lY2hhbmlzbSAoIGEgcmF0ZSBsaW1pdCkuIFdlIGp1c3QgYXJndWUgdGhhdCB0aGlz IGlzIG5vdCBlbm91Z2guIEFjdHVhbGx5IHdoYXQgeW91IG1lbnRpb25lZCBhYm92ZSBpcyBhbHNv IHRvIGFzayBmb3Igc3VjaCBhIGNvbnRyb2wgY29tYmluYXRpb24gZm9yIG11bHRpLUZFcyBjYXNl cy4gR1JNUCBzY2hlbWUgY2FuIHN1cHBseSB0aGlzIHZlcnkgd2VsbCBieSB1c2luZyBhIEZFIGF0 dHJpYnV0ZSB0byBzcGVjaWZ5IERvUyBwcm90ZWN0aW9uIHBvbGljeSBpbiB3aGljaCBDIHBhY2tl dHMgd2l0aCBoaWdoZXIgcHJpb3JpdGllcyBjYW4gYmUgZW5zdXJlZC4gSSBkb24ndCB0aGluayBv dGhlciBwcm90b2NvbHMgaGF2ZSBwcm92aWRlZCB0aGlzIG1lY2hhbmlzbSAoTm90ZSB0aGF0IHRo aXMgcHJpb3JpdHkgaXMgZGlmZmVyZW50IGZyb20gdGhhdCBpbiBGb3JDRVMgbWVzc2FnZSBoZWFk ZXJzLCB3aGljaCBhY3R1YWxseSBkb2VzIG5vdCB0YWtlIGVmZmVjdCBmb3IgdGhpcyBwdXJwb3Nl KS4gIA0KDQpUbyBzdW1tYXJpemUsIHdlIGp1c3QgYXJndWUgdGhhdCBhIERvUyBwcm90ZWN0aW9u IHBvbGljeSBsaWtlIHRoYXQgcHJlc2VudGVkIGJ5IEdSTVAgc2hvdWxkIGJlIGluY2x1ZGVkIGlu IGZpbmFsIEZvckNFUyBwcm90b2NvbCBvdGhlciB0aGFuIGp1c3QgYnkgc2VwYXJhdGlvbiBvZiBD L0QgY2hhbm5lbHMgc28gYXMgdG8gZWZmZWN0aXZlbHkgYXZvaWQgRG9TIGF0dGFjayBhbmQgYWxz byB0byBtYW5hZ2UgdGhlIGNvbmdlc3Rpb24uIEkgdGhpbmsgdGhpcyBpZGVhIGlzIHF1aXRlIHRo ZSBzYW1lIGFzIHdoYXQgeW91IHByZXNlbnRlZCBpbiBhbm90aGVyIGVtYWlsIGFzIHNvbWUgUW9T IGhpbnRzIHRyYW5zbWl0dGVkIGZyb20gQ0UgdG8gRkUgZm9yIERvUyBwcm90ZWN0aW9uIGFuZCBj b25nZXN0aW9uIGNvbnRyb2wuIA0KDQpZb3VycywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJQdXR6b2x1LCBEYXZpZCIgPGRhdmlkLnB1dHpvbHVAaW50 ZWwuY29tPg0KVG86IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBN YXJjaCAwMiwgMjAwNCA5OjA2IFBNDQpTdWJqZWN0OiBbRm9yY2VzLXByb3RvY29sXSBDb21tZW50 cyBmcm9tIGNoYXQgd2l0aCBBRHMNCg0KDQpQYXRyaWNrIGFuZCBJIHNwZW50IGFib3V0IDkwIG1p bnV0ZXMgbGFzdCBuaWdodA0KY2hhdHRpbmcgd2l0aCBCaWxsIGFuZCBBbGV4IGFib3V0IEZvckNF Uywgd2l0aA0KbWF5YmUgaGFsZiBvZiB0aGUgdGltZSBvbiB0aGUgcHJvdG9jb2wuICBJbg0KdGhl IGNvbnZlcnNhdGlvbnMgd2l0aCB0aGVtLCBhbG9uZyB3aXRoIHNvbWUNCmZvbGxvdy11cCBjaGF0 cyBJIGhhZCB3aXRoIEFsbGlzb24gTWFua2luLCB0aGUNCmZvbGxvd2luZyB0b3BpY3Mgd2hlcmUg Y292ZXJlZDogIG11bHRpcGxlIA0KY2hhbm5lbHMsIG11bHRpY2FzdC91bmljYXN0LCBhbmQgY29u Z2VzdGlvbiANCmNvbnRyb2wuICBCZWxvdyBpcyB3aGF0IEkgcmVjYWxsIGZyb20gbWVtb3J5IA0K KFBhdHJpY2sgcGxlYXNlIGNvcnJlY3QgbWUvZWxhYm9yYXRlIGFzIG5lZWRlZCA6KQ0KDQoNCg0K TXVsdGlwbGUgY2hhbm5lbHM6ICANCg0KSSBkaXNjdXNzZWQgdGhlIGludGVyZmVyZW5jZSBpc3N1 ZSB0aGF0IA0Kd2FzIGlkZW50aWZpZWQgYnkgdGhlIEdSTVAgdGVhbS4gIEJpbGwgJg0KQWxleCBh Z3JlZWQgdGhhdCBtYW55IE9TIGltcGxlbWVudGF0aW9ucyBjYW4gaGF2ZQ0KYW4gaW50ZXJmZXJl bmNlIHByb3BlcnR5IChpLmUuIHdoZXJlIHR3byBkaWZmZXJlbnQNCmNvbm5lY3Rpb25zIHdpbGwg aGF2ZSBxdWV1aW5nIGludGVyZmVyZW5jZSBsb3dlciBpbg0KdGhlIG5ldHdvcmtpbmcgc3RhY2sg aW4gdGhlIE9TKS4gIFNvIGl0IGlzIG5lY2Vzc2FyeQ0KdG8gbWFrZSBzdXJlIHdoZW4gaW1wbGVt ZW50aW5nIGEgRkUgKG9yIENFIHByb2JhYmx5DQphcyB3ZWxsKSB0aGF0IHRoaXMgaXMgdGFrZW4g aW50byBhY2NvdW50LiAgTWV0aG9kcw0Kb2YgZG9pbmcgdGhhdCBpbmNsdWRlOg0KKiBNYW51YWxs eSBxdWV1aW5nIHBhY2tldHMgKGkuZS4gZmVlZCBPUyBmZXcgZW5vdWdoDQogIHBhY2tldHMgdGhh dCBpdCBjYW5ub3QgZ2V0IGludG8gdHJvdWJsZSAtIGFsdGhvdWdoDQogIHlvdSBwYXkgYSBwZXJm b3JtYW5jZSBwcmljZSBmb3IgdGhhdCwgaW4gdGhhdCBmaW5lDQogIGdyYWluZWQgc2NoZWR1bGlu ZyB0YWtlcyBjeWNsZXMpDQoqIEluZGljYXRpbmcgdG8gdGhlIE9TIHRvIHRyZWF0IGZsb3dzIGRp ZmZlcmVudGx5IC0gDQogIHNvbWUgcmVhbC10aW1lIE9TIHdpbGwgbGV0IHlvdSBkbyB0aGlzLCB0 aGF0IGlzIHRoZXkNCiAgYXJlIGltcGxlbWVudGVkIHRvIGludGVybmFsbHkgcmV0YWluIFFvUyBi ZXR3ZWVuDQogIGZsb3dzLg0KSG93ZXZlciwgaXQgd2FzIGFsc28gbWVudGlvbmVkIHRoYXQgaW50 cmEtRkUgDQppbnRlcmZlcmVuY2UgaXMgb25seSBvbmUga2luZCBvZiBpbnRlcmZlcmVuY2UuICBH b29kDQpGRSBpbXBsZW1lbnRhdGlvbiAoZS5nLiBieSBtYW51YWxseSBxdWV1aW5nIGFib3ZlIHRo ZQ0KT1MpIGhlbHBzIHRvIGZpeCBpbnRyYS1GRSBpbnRlcmZlcmVuY2UsIGJ1dCBpdCBkb2VzDQpu b3Qgc29sdmUgaW50ZXItRkUgaW50ZXJmZXJlbmNlLiAgVGhhdCBpcywgaWYgYWxsDQooQyAmIEQp IHBhY2tldHMgYXJlIGFsd2F5cyBvbiB0aGUgc2FtZSBjb25uZWN0aW9uLA0KdGhhdCBtYWtlcyBp dCBpbXBvc3NpYmxlIG9uIHRoZSB3aXJlIHRvIGRpZmZlcmVudGlhdGUNCnRoZW0gZnJvbSBvbmUg YW5vdGhlci4gIEltYWdpbmUgeW91IGhhdmUgYSBidW5jaCBvZg0KRkVzIHdpdGggc29tZSBvZiB0 aGVtIGJlaW5nIHN1YmplY3QgdG8gRE9TIGF0dGFjayBmb3INCkQgcGFja2V0cywgYW5kIHlvdSB3 YW50IHRvIHF1ZXJ5IG9uZSBvZiB0aGUgRkVzIGZvcg0Kc3RhdGlzdGljcy4gIEl0IHdvdWxkIGJl IGdvb2QgdG8gaGF2ZSBzb21lIHdheSBvZg0KZW5zdXJpbmcgdGhlIEMgcGFja2V0cyAob3IgYW55 IGhpZ2ggcHJpb3JpdHkgcGFja2V0cyAtDQpPU1BGIEhFTExPIG1heWJlKSBnZXQgdGhyb3VnaC4g IFNlcGFyYXRlIGNoYW5uZWxzDQooYXMgSmFtYWwgaW5kaWNhdGVkLCBkb24ndCBldmVuIGhhdmUg dG8gYmUgQyAmIEQpDQptYWtlcyB0aGlzIHBvc3NpYmxlLiAgIFB1dHRpbmcgZXZlcnl0aGluZyBv biBvbmUNCmNoYW5uZWwgbWFrZXMgaXQgaW1wb3NzaWJsZSB0byBkZWFsIHdpdGggaW50ZXItRkUN CmludGVyZmVyZW5jZSBpbiBhIGRpZmZlcmVudGlhdGVkIGZhc2hpb24uIA0KDQpbV2FuZ1JlXQ0K DQogDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 04:45:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28795 for ; Fri, 5 Mar 2004 04:45:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBse-0001mb-8t for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 04:44:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i259iVnE006837 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 04:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBsc-0001m3-S7 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 04:44:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28601 for ; Fri, 5 Mar 2004 04:44:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBsZ-0005PV-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 04:44:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBqR-0004gD-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 04:42:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzBoU-00046M-02 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 04:40:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzBcQ-00033K-Hr for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 04:27:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBcE-00080Y-3h; Fri, 05 Mar 2004 04:27:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBZ6-00073i-Q6 for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 04:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27647 for ; Fri, 5 Mar 2004 04:24:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBZ3-0000w5-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 04:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBYM-0000mH-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 04:23:34 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzBXp-0000as-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 04:23:02 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 5 Mar 2004 17:34:18 +0800 Message-ID: <048401c40293$2f90bfc0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0481_01C402D6.3DA818E0" 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 Subject: [Forces-protocol] Fw: Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 17:21:05 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0481_01C402D6.3DA818E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 08q8/i0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiBXYW5nLFdlaW1pbmcgDQpU bzogUHV0em9sdSwgRGF2aWQgDQpDYzogaGFkaUB6bnl4LmNvbSANClNlbnQ6IEZyaWRheSwgRmVi cnVhcnkgMjcsIDIwMDQgMToxNSBQTQ0KU3ViamVjdDogRnc6IEdvb2QgbHVjayENCg0KDQpIaSBE YXZpZCwNCg0KUGxlYXNlIGhlbHAgdG8gY2hhbmdlIE1yLiBHdW8gWXVuZmVpJ3MgZW1haWwgYWRk cmVzcyBmcm9tIGd5ZkBodHJkYy5jb20gdG8gZ3lmQG5kc2MuY29tLmNuICwgDQpmb3IgdGhlIGZv cm1lciBlbWFpbCBoYXMganVzdCBiZWVuIGRvd24gYSBmZXcgZGF5cyBiZWZvcmUuIA0KDQpIZSBh bmQgSSBhcmUgc29ycnkgZm9yIHRoYXQuIA0KDQpUaGFuayB5b3UuDQoNCldlaW1pbmcNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IGd5ZiANClRvOiB3bXdhbmdAbWFpbC5o emljLmVkdS5jbiANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjcsIDIwMDQgMTI6NTQgUE0NClN1 YmplY3Q6IEdvb2QgbHVjayENCg0KDQq63LGnx7jTydPat/7O8cb3zsrM4qOsx+uw79b6u7vTw2Vt YWlsILXY1re00yBneWZAIGh0cmRjLmNvbSC1vSBneWZAbmRzYy5jb20uY24goaMNCg0K0LvQu6Oh DQo= ------=_NextPart_000_0481_01C402D6.3DA818E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT7Tyrz+PC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiPg0KPE1FVEEg Y29udGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+DQo8 RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJv bTo8L0I+IDxBIA0KdGl0bGU9d213YW5nQG1haWwuaHppYy5lZHUuY24gDQpocmVmPSJtYWlsdG86 d213YW5nQG1haWwuaHppYy5lZHUuY24iPldhbmcsV2VpbWluZzwvQT4gPC9ESVY+DQo8RElWPjxC PlRvOjwvQj4gPEEgdGl0bGU9ZGF2aWQucHV0em9sdUBpbnRlbC5jb20gDQpocmVmPSJtYWlsdG86 ZGF2aWQucHV0em9sdUBpbnRlbC5jb20iPlB1dHpvbHUsIERhdmlkPC9BPiA8L0RJVj4NCjxESVY+ PEI+Q2M6PC9CPiA8QSB0aXRsZT1oYWRpQHpueXguY29tIA0KaHJlZj0ibWFpbHRvOmhhZGlAem55 eC5jb20iPmhhZGlAem55eC5jb208L0E+IDwvRElWPg0KPERJVj48Qj5TZW50OjwvQj4gRnJpZGF5 LCBGZWJydWFyeSAyNywgMjAwNCAxOjE1IFBNPC9ESVY+DQo8RElWPjxCPlN1YmplY3Q6PC9CPiBG dzogR29vZCBsdWNrITwvRElWPjwvRElWPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPkhpIERhdmlkLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5QbGVhc2UgaGVscCB0byBjaGFuZ2UgTXIuIEd1byBZdW5mZWkncyBlbWFpbCANCmFkZHJl c3MgZnJvbSA8QSBocmVmPSJtYWlsdG86Z3lmQGh0cmRjLmNvbSI+Z3lmQGh0cmRjLmNvbTwvQT4g dG8gPEEgDQpocmVmPSJtYWlsdG86Z3lmQG5kc2MuY29tLmNuIj5neWZAbmRzYy5jb20uY248L0E+ ICwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5mb3IgdGhlIGZv cm1lciBlbWFpbCBoYXMganVzdCBiZWVuIGRvd24gYSBmZXcgZGF5cyANCmJlZm9yZS4gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhlIGFuZCBJIGFyZSBzb3JyeSBmb3IgdGhh dC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5rIHlvdS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+V2VpbWluZzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBzdHlsZT0i Rk9OVDogMTBwdCBhcmlhbCI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCjxESVYgc3R5 bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4g PEEgDQp0aXRsZT1neWZAbmRzYy5jb20uY24gaHJlZj0ibWFpbHRvOmd5ZkBuZHNjLmNvbS5jbiI+ Z3lmPC9BPiA8L0RJVj4NCjxESVY+PEI+VG86PC9CPiA8QSB0aXRsZT13bXdhbmdAbWFpbC5oemlj LmVkdS5jbiANCmhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+d213YW5nQG1h aWwuaHppYy5lZHUuY248L0E+IDwvRElWPg0KPERJVj48Qj5TZW50OjwvQj4gRnJpZGF5LCBGZWJy dWFyeSAyNywgMjAwNCAxMjo1NCBQTTwvRElWPg0KPERJVj48Qj5TdWJqZWN0OjwvQj4gR29vZCBs dWNrITwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+utyxp8e408nT2rf+zvHG987KzOKjrMfrsO/W+ru708NlbWFpbCC12Na3tNMg PEEgDQpocmVmPSJtYWlsdG86Z3lmQCZuYnNwO2h0cmRjLmNvbSC1vSBneWZAbmRzYy5jb20uY24i Pmd5ZkAmbmJzcDtodHJkYy5jb20gtb0gDQpneWZAbmRzYy5jb20uY248L0E+Jm5ic3A7oaM8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+0LvQu6OhPC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0481_01C402D6.3DA818E0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 08:40:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08152 for ; Fri, 5 Mar 2004 08:40:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzFYB-0005SD-Ag for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 08:39:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Ddd30020961 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 08:39:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzFYB-0005S0-35 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 08:39:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08138 for ; Fri, 5 Mar 2004 08:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzFY9-0004RF-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 08:39:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzFXO-0004GQ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 08:38:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzFWf-00044T-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 08:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzFWf-0005Lb-TC; Fri, 05 Mar 2004 08:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzFWM-0005F4-Bk for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 08:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08022 for ; Fri, 5 Mar 2004 08:37:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzFWL-00042L-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 08:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzFVO-0003mi-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 08:36:47 -0500 Received: from ms-smtp-03-lbl.southeast.rr.com ([24.25.9.102] helo=ms-smtp-03-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1AzFUT-0003Uy-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 08:35:50 -0500 Received: from creeksidenet.com (cpe-024-163-075-077.nc.rr.com [24.163.75.77]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i25DZhs1023565; Fri, 5 Mar 2004 08:35:43 -0500 (EST) Message-ID: <4048823F.1040108@creeksidenet.com> From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: alex.audu@alcatel.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <9CB758BBEE58754F8F33234D75B9F4B00243EDB8@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 08:35:59 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, Given that I dont believe we can scale well without multicast, I would like to see it as a MUST. But thats just due to a focus on larger systems. For lightweight implementations, one could envision unicast being sufficient. I agree with Hormuzd that some negotiation is necessary if we make this a SHOULD. Then the question would become what happens when 1 FE says it can only unicast. Does all traffic revert to unicast, or can there be a mix? Jeff Khosravi, Hormuzd M wrote: >Hi Alex, > >In general, I prefer using language such as MUST so that there is no >confusion or interop issues in the protocol implementations. However, >you raise a reasonable point and let me tell you my thoughts on this. We >will definitely need Unicast between FEs and CEs at the minimum in the >protocol. In addition, if the interconnect technology supports Multicast >and there is a case where it is useful to the application (such as >downloading IPv4 routes) we must allow it as well without breaking >interop. In order to do that, we will need specific procedures in the >protocol that will allow the CE and FE to negotiate on using multicast >dynamically at run-time (say during the binding or joining phase between >the CE and FE) and also associate different multicast groups with LFBs. >We will also need to define how Reliability/CC etc. will be provided for >multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >then applications will be able to use both unicast and multicast without >any interop issues. > >Let me know what you guys think about this. > >Regards >Hormuzd > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, March 04, 2004 1:22 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Comments from chat with ADs > > >Hormuzd, > >Why should multicast be "mandated for certain cases where it will be >useful" if there >is a simpler, more robust way to do the same thing? I'll say we don't >mandate this. >We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >and make MULTICAST optional. Any issues with this? > >Regards, >Alex. > > >Khosravi, Hormuzd M wrote: > > > >>Hi David >> >>Your summary below of the discussion with Ads on the different issues >>seems like very reasonable approaches to me. >> >>I agree that it will be a good idea to present transport alternatives >> >> >at > > >>IP and non-IP level for the ForCES protocol. We can mandate one or more >>transport for IP and one or more transport for non-IP, this way the >>interoperability requirements are met and at the same time, the in-box, >>out of box scenarios are met. >> >>Also, agree with having multiple channels/connections to differentiate >> >> >C > > >>& D traffic between CEs and FEs. On the unicast/multicast topic, dual >>mandatory approach again seems a good idea to support interoperability. >>The one thing that I would like to point out is that for any ForCES >>protocol implementation to work, unicast will definitely be required at >>the minimum. One could also mandate using multicast for certain cases >>where it will be useful (e.g. IPv4/config table download), if it is >>supported by the interconnect as you stated. But just multicast without >>unicast will not work, atleast not efficiently. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>Sent: Tuesday, March 02, 2004 5:06 AM >>To: forces-protocol@ietf.org >>Subject: [Forces-protocol] Comments from chat with ADs >> >>Patrick and I spent about 90 minutes last night >>chatting with Bill and Alex about ForCES, with >>maybe half of the time on the protocol. In >>the conversations with them, along with some >>follow-up chats I had with Allison Mankin, the >>following topics where covered: multiple >>channels, multicast/unicast, and congestion >>control. Below is what I recall from memory >>(Patrick please correct me/elaborate as needed :) >> >> >> >>Multiple channels: >> >>I discussed the interference issue that >>was identified by the GRMP team. Bill & >>Alex agreed that many OS implementations can have >>an interference property (i.e. where two different >>connections will have queuing interference lower in >>the networking stack in the OS). So it is necessary >>to make sure when implementing a FE (or CE probably >>as well) that this is taken into account. Methods >>of doing that include: >>* Manually queuing packets (i.e. feed OS few enough >> packets that it cannot get into trouble - although >> you pay a performance price for that, in that fine >> grained scheduling takes cycles) >>* Indicating to the OS to treat flows differently - >> some real-time OS will let you do this, that is they >> are implemented to internally retain QoS between >> flows. >>However, it was also mentioned that intra-FE >>interference is only one kind of interference. Good >>FE implementation (e.g. by manually queuing above the >>OS) helps to fix intra-FE interference, but it does >>not solve inter-FE interference. That is, if all >>(C & D) packets are always on the same connection, >>that makes it impossible on the wire to differentiate >>them from one another. Imagine you have a bunch of >>FEs with some of them being subject to DOS attack for >>D packets, and you want to query one of the FEs for >>statistics. It would be good to have some way of >>ensuring the C packets (or any high priority packets - >>OSPF HELLO maybe) get through. Separate channels >>(as Jamal indicated, don't even have to be C & D) >>makes this possible. Putting everything on one >>channel makes it impossible to deal with inter-FE >>interference in a differentiated fashion. >> >> >>Multicast & Unicast: >> >>The discussion on this started out with a discussion >>of the IETF protocol design BKM that options can ruin >>compatibility. That is, if there are four ways to >>implement something, all optional, then you can have >>client 1 implement A & B, and client 2 implement C & D, >>and even though both clients are 100% compliant, they >>cannot talk to one another. Better to say all clients >>must implement A and make B, C, and D optional, so that >>way you know that all implementations will be able to >>at least talk. >> >>Patrick & I pushed on this a bit, explaining that we >>actually had potentially (at least) two different >>environments - very close environments where multicast >>support could be present in the interconnect, and >>not-as-close environments (and some close >>environments as well) where multicast was not available. >> >>Bill & Alex indicated that if there really are two >>quite different cases, then it is possible to have a >>"dual mandatory" approach. I.e.: >> >>If your underlying interconnect supports multicast, >>then you MUST implement the following (multicast) >>method of communication. >> >>If your underlying interconnect supports unicast, then >>you MUST implement the following (unicast) method >>of communication. >> >>This will guarantee interop, although at a potential >>extra cost (cost being having to potentially support >>both when both are present). While this isn't optimal, >>it does at least give some flexibility. >> >> >> >>Congestion control: >> >>Several times over the whole conversation the topic >>of congestion control came up. Also, as part of some >>TIPC discussions, I ended up spending some time talking >>to Allison Mankin (transport AD) about congestion control >>as well. All the ADs I talked to where consistent on >>the following: >> >>If you are running over IP, you MUST act in a RFC2914 >>compliant fashion (i.e. respond to congestion like TCP >>or SCTP or RMT does). Two reasons where put forth for >>this: >>1) Any time you define an IP-based protocol you cannot >>guarantee that it will not go out over the Internet. As >>such, the IESG will NOT standardize IP protocols with >>"bad" (non-2914) behaviors. >>2) Lots of implementation experience showing that other >>congestion control mechanisms don't work (congestion >>collapse etc). >> >>They where very firm on the above and my impression was >>that convincing them otherwise would be very difficult. >> >>That being said, a second alternative did arise: If >>you are not implementing on top of IP (e.g. running on >>Infiniband, ATM, Ethernet) then you could rely on mechanisms >>for congestion control built into what you are relying on, >>or even consider building your own congestion control >>mechanisms (ala TIPC). This makes it possible to define >>(for example) a multicast transport for forces without >>having to go all the way and implementing RMT - as long >>as it is clear that it isn't over IP. The ADs went as >>far as saying that the IETF could even accept standards- >>track drafts that say nothing about IP (e.g. define an >>Ethernet-only transport for ForCES), if it is necessary >>for ForCES. GSMP and (some other group I forgot) was >>given as an example. >> >>Cheers, >>David >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 10:57:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14437 for ; Fri, 5 Mar 2004 10:57:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHgs-0006Rz-3R for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 10:56:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25FukGZ024794 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 10:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHgr-0006Rp-Q3 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 10:56:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14407 for ; Fri, 5 Mar 2004 10:56:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHgp-0007Bi-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 10:56:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHg0-00070r-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 10:55:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzHf9-0006q0-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 10:54:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHfB-0006Pi-66; Fri, 05 Mar 2004 10:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHen-0006IL-Lc for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 10:54:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14291 for ; Fri, 5 Mar 2004 10:54:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHek-0006n3-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 10:54:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHdl-0006b8-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 10:53:35 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzHcn-0006GD-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 10:52:33 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25Fq1TN000839; Fri, 5 Mar 2004 09:52:02 -0600 (CST) Message-ID: <4048A221.4030806@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <9CB758BBEE58754F8F33234D75B9F4B00243EDB8@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243EDB8@orsmsx410.jf.intel.com> Content-Type: multipart/alternative; boundary="------------080703060902050307050600" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 09:52:01 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080703060902050307050600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Hormuzd, My point is: multicast's main purpose is getting the same data to multitargets quickly. But I am not sure I'd want to use it all the time. If I am sending to less than a certain number of targets,..say 4, would I want to use multicasting, given all the other problems it has? I can achieve my goal with unicast. I think what we need to do is mandate the basic (simplest) mechanism here (UNICAST) and anything else (MULTICAST) as gravy. Regars, Alex. Khosravi, Hormuzd M wrote: >Hi Alex, > >In general, I prefer using language such as MUST so that there is no >confusion or interop issues in the protocol implementations. However, >you raise a reasonable point and let me tell you my thoughts on this. We >will definitely need Unicast between FEs and CEs at the minimum in the >protocol. In addition, if the interconnect technology supports Multicast >and there is a case where it is useful to the application (such as >downloading IPv4 routes) we must allow it as well without breaking >interop. In order to do that, we will need specific procedures in the >protocol that will allow the CE and FE to negotiate on using multicast >dynamically at run-time (say during the binding or joining phase between >the CE and FE) and also associate different multicast groups with LFBs. >We will also need to define how Reliability/CC etc. will be provided for >multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >then applications will be able to use both unicast and multicast without >any interop issues. > >Let me know what you guys think about this. > >Regards >Hormuzd > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, March 04, 2004 1:22 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Comments from chat with ADs > > >Hormuzd, > >Why should multicast be "mandated for certain cases where it will be >useful" if there >is a simpler, more robust way to do the same thing? I'll say we don't >mandate this. >We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >and make MULTICAST optional. Any issues with this? > >Regards, >Alex. > > >Khosravi, Hormuzd M wrote: > > > >>Hi David >> >>Your summary below of the discussion with Ads on the different issues >>seems like very reasonable approaches to me. >> >>I agree that it will be a good idea to present transport alternatives >> >> >at > > >>IP and non-IP level for the ForCES protocol. We can mandate one or more >>transport for IP and one or more transport for non-IP, this way the >>interoperability requirements are met and at the same time, the in-box, >>out of box scenarios are met. >> >>Also, agree with having multiple channels/connections to differentiate >> >> >C > > >>& D traffic between CEs and FEs. On the unicast/multicast topic, dual >>mandatory approach again seems a good idea to support interoperability. >>The one thing that I would like to point out is that for any ForCES >>protocol implementation to work, unicast will definitely be required at >>the minimum. One could also mandate using multicast for certain cases >>where it will be useful (e.g. IPv4/config table download), if it is >>supported by the interconnect as you stated. But just multicast without >>unicast will not work, atleast not efficiently. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>Sent: Tuesday, March 02, 2004 5:06 AM >>To: forces-protocol@ietf.org >>Subject: [Forces-protocol] Comments from chat with ADs >> >>Patrick and I spent about 90 minutes last night >>chatting with Bill and Alex about ForCES, with >>maybe half of the time on the protocol. In >>the conversations with them, along with some >>follow-up chats I had with Allison Mankin, the >>following topics where covered: multiple >>channels, multicast/unicast, and congestion >>control. Below is what I recall from memory >>(Patrick please correct me/elaborate as needed :) >> >> >> >>Multiple channels: >> >>I discussed the interference issue that >>was identified by the GRMP team. Bill & >>Alex agreed that many OS implementations can have >>an interference property (i.e. where two different >>connections will have queuing interference lower in >>the networking stack in the OS). So it is necessary >>to make sure when implementing a FE (or CE probably >>as well) that this is taken into account. Methods >>of doing that include: >>* Manually queuing packets (i.e. feed OS few enough >> packets that it cannot get into trouble - although >> you pay a performance price for that, in that fine >> grained scheduling takes cycles) >>* Indicating to the OS to treat flows differently - >> some real-time OS will let you do this, that is they >> are implemented to internally retain QoS between >> flows. >>However, it was also mentioned that intra-FE >>interference is only one kind of interference. Good >>FE implementation (e.g. by manually queuing above the >>OS) helps to fix intra-FE interference, but it does >>not solve inter-FE interference. That is, if all >>(C & D) packets are always on the same connection, >>that makes it impossible on the wire to differentiate >>them from one another. Imagine you have a bunch of >>FEs with some of them being subject to DOS attack for >>D packets, and you want to query one of the FEs for >>statistics. It would be good to have some way of >>ensuring the C packets (or any high priority packets - >>OSPF HELLO maybe) get through. Separate channels >>(as Jamal indicated, don't even have to be C & D) >>makes this possible. Putting everything on one >>channel makes it impossible to deal with inter-FE >>interference in a differentiated fashion. >> >> >>Multicast & Unicast: >> >>The discussion on this started out with a discussion >>of the IETF protocol design BKM that options can ruin >>compatibility. That is, if there are four ways to >>implement something, all optional, then you can have >>client 1 implement A & B, and client 2 implement C & D, >>and even though both clients are 100% compliant, they >>cannot talk to one another. Better to say all clients >>must implement A and make B, C, and D optional, so that >>way you know that all implementations will be able to >>at least talk. >> >>Patrick & I pushed on this a bit, explaining that we >>actually had potentially (at least) two different >>environments - very close environments where multicast >>support could be present in the interconnect, and >>not-as-close environments (and some close >>environments as well) where multicast was not available. >> >>Bill & Alex indicated that if there really are two >>quite different cases, then it is possible to have a >>"dual mandatory" approach. I.e.: >> >>If your underlying interconnect supports multicast, >>then you MUST implement the following (multicast) >>method of communication. >> >>If your underlying interconnect supports unicast, then >>you MUST implement the following (unicast) method >>of communication. >> >>This will guarantee interop, although at a potential >>extra cost (cost being having to potentially support >>both when both are present). While this isn't optimal, >>it does at least give some flexibility. >> >> >> >>Congestion control: >> >>Several times over the whole conversation the topic >>of congestion control came up. Also, as part of some >>TIPC discussions, I ended up spending some time talking >>to Allison Mankin (transport AD) about congestion control >>as well. All the ADs I talked to where consistent on >>the following: >> >>If you are running over IP, you MUST act in a RFC2914 >>compliant fashion (i.e. respond to congestion like TCP >>or SCTP or RMT does). Two reasons where put forth for >>this: >>1) Any time you define an IP-based protocol you cannot >>guarantee that it will not go out over the Internet. As >>such, the IESG will NOT standardize IP protocols with >>"bad" (non-2914) behaviors. >>2) Lots of implementation experience showing that other >>congestion control mechanisms don't work (congestion >>collapse etc). >> >>They where very firm on the above and my impression was >>that convincing them otherwise would be very difficult. >> >>That being said, a second alternative did arise: If >>you are not implementing on top of IP (e.g. running on >>Infiniband, ATM, Ethernet) then you could rely on mechanisms >>for congestion control built into what you are relying on, >>or even consider building your own congestion control >>mechanisms (ala TIPC). This makes it possible to define >>(for example) a multicast transport for forces without >>having to go all the way and implementing RMT - as long >>as it is clear that it isn't over IP. The ADs went as >>far as saying that the IETF could even accept standards- >>track drafts that say nothing about IP (e.g. define an >>Ethernet-only transport for ForCES), if it is necessary >>for ForCES. GSMP and (some other group I forgot) was >>given as an example. >> >>Cheers, >>David >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > > --------------080703060902050307050600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,

My point is: multicast's main purpose is getting the same data to multitargets
quickly.  But I am not sure I'd want to use it all the time. If I am sending to
less than a certain number of targets,..say 4, would I want to use multicasting,
given all the other problems it has?  I can achieve my goal with unicast. I think
what we need to do is mandate the basic (simplest) mechanism here (UNICAST)
and anything else (MULTICAST) as gravy.

Regars,
Alex.

Khosravi, Hormuzd M wrote:
Hi Alex,

In general, I prefer using language such as MUST so that there is no
confusion or interop issues in the protocol implementations. However,
you raise a reasonable point and let me tell you my thoughts on this. We
will definitely need Unicast between FEs and CEs at the minimum in the
protocol. In addition, if the interconnect technology supports Multicast
and there is a case where it is useful to the application (such as
downloading IPv4 routes) we must allow it as well without breaking
interop. In order to do that, we will need specific procedures in the
protocol that will allow the CE and FE to negotiate on using multicast
dynamically at run-time (say during the binding or joining phase between
the CE and FE) and also associate different multicast groups with LFBs.
We will also need to define how Reliability/CC etc. will be provided for
multicast...may be using RMT, TIPC, etc. (?) If we do this correctly,
then applications will be able to use both unicast and multicast without
any interop issues.

Let me know what you guys think about this.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Thursday, March 04, 2004 1:22 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from chat with ADs


Hormuzd,

Why should multicast be "mandated for certain cases where it will be 
useful" if there
is a simpler, more robust way to do the same thing?  I'll say we don't 
mandate this.
We can make it a "SHOULD" strength, not a "MUST".  We mandate UNICAST
and make MULTICAST optional.  Any issues with this?

Regards,
Alex.


Khosravi, Hormuzd M wrote:

  
Hi David

Your summary below of the discussion with Ads on the different issues
seems like very reasonable approaches to me.

I agree that it will be a good idea to present transport alternatives
    
at
  
IP and non-IP level for the ForCES protocol. We can mandate one or more
transport for IP and one or more transport for non-IP, this way the
interoperability requirements are met and at the same time, the in-box,
out of box scenarios are met.

Also, agree with having multiple channels/connections to differentiate
    
C
  
& D traffic between CEs and FEs. On the unicast/multicast topic, dual
mandatory approach again seems a good idea to support interoperability.
The one thing that I would like to point out is that for any ForCES
protocol implementation to work, unicast will definitely be required at
the minimum. One could also mandate using multicast for certain cases
where it will be useful (e.g. IPv4/config table download), if it is
supported by the interconnect as you stated. But just multicast without
unicast will not work, atleast not efficiently.

Regards
Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David
Sent: Tuesday, March 02, 2004 5:06 AM
To: forces-protocol@ietf.org
Subject: [Forces-protocol] Comments from chat with ADs

Patrick and I spent about 90 minutes last night
chatting with Bill and Alex about ForCES, with
maybe half of the time on the protocol.  In
the conversations with them, along with some
follow-up chats I had with Allison Mankin, the
following topics where covered:  multiple 
channels, multicast/unicast, and congestion 
control.  Below is what I recall from memory 
(Patrick please correct me/elaborate as needed :)



Multiple channels:  

I discussed the interference issue that 
was identified by the GRMP team.  Bill &
Alex agreed that many OS implementations can have
an interference property (i.e. where two different
connections will have queuing interference lower in
the networking stack in the OS).  So it is necessary
to make sure when implementing a FE (or CE probably
as well) that this is taken into account.  Methods
of doing that include:
* Manually queuing packets (i.e. feed OS few enough
 packets that it cannot get into trouble - although
 you pay a performance price for that, in that fine
 grained scheduling takes cycles)
* Indicating to the OS to treat flows differently - 
 some real-time OS will let you do this, that is they
 are implemented to internally retain QoS between
 flows.
However, it was also mentioned that intra-FE 
interference is only one kind of interference.  Good
FE implementation (e.g. by manually queuing above the
OS) helps to fix intra-FE interference, but it does
not solve inter-FE interference.  That is, if all
(C & D) packets are always on the same connection,
that makes it impossible on the wire to differentiate
them from one another.  Imagine you have a bunch of
FEs with some of them being subject to DOS attack for
D packets, and you want to query one of the FEs for
statistics.  It would be good to have some way of
ensuring the C packets (or any high priority packets -
OSPF HELLO maybe) get through.  Separate channels
(as Jamal indicated, don't even have to be C & D)
makes this possible.   Putting everything on one
channel makes it impossible to deal with inter-FE
interference in a differentiated fashion. 


Multicast & Unicast:  

The discussion on this started out with a discussion
of the IETF protocol design BKM that options can ruin
compatibility.  That is, if there are four ways to
implement something, all optional, then you can have
client 1 implement A & B, and client 2 implement C & D,
and even though both clients are 100% compliant, they
cannot talk to one another. Better to say all clients
must implement A and make B, C, and D optional, so that
way you know that all implementations will be able to 
at least talk.

Patrick & I pushed on this a bit, explaining that we
actually had potentially (at least) two different
environments - very close environments where multicast
support could be present in the interconnect,  and 
not-as-close environments (and some close
environments as well) where multicast was not available.

Bill & Alex indicated that if there really are two
quite different cases, then it is possible to have a
"dual mandatory" approach.  I.e.:

If your underlying interconnect supports multicast,
then you MUST implement the following (multicast)
method of communication.

If your underlying interconnect supports unicast, then
you MUST implement the following (unicast) method
of communication.

This will guarantee interop, although at a potential
extra cost (cost being having to potentially support
both when both are present).  While this isn't optimal,
it does at least give some flexibility.



Congestion control:

Several times over the whole conversation the topic
of congestion control came up.  Also, as part of some
TIPC discussions, I ended up spending some time talking
to Allison Mankin (transport AD) about congestion control
as well.  All the ADs I talked to where consistent on 
the following:

If you are running over IP, you MUST act in a RFC2914
compliant fashion (i.e. respond to congestion like TCP
or SCTP or RMT does).  Two reasons where put forth for
this:
1) Any time you define an IP-based protocol you cannot
guarantee that it will not go out over the Internet. As
such, the IESG will NOT standardize IP protocols with
"bad" (non-2914) behaviors.
2) Lots of implementation experience showing that other
congestion control mechanisms don't work (congestion
collapse etc).

They where very firm on the above and my impression was
that convincing them otherwise would be very difficult.

That being said, a second alternative did arise:  If
you are not implementing on top of IP (e.g. running on
Infiniband, ATM, Ethernet) then you could rely on mechanisms
for congestion control built into what you are relying on,
or even consider building your own congestion control
mechanisms (ala TIPC).  This makes it possible to define
(for example) a multicast transport for forces without
having to go all the way and implementing RMT - as long
as it is clear that it isn't over IP.  The ADs went as
far as saying that the IETF could even accept standards-
track drafts that say nothing about IP (e.g. define an
Ethernet-only transport for ForCES), if it is necessary 
for ForCES. GSMP and (some other group I forgot) was
given as an example.

Cheers,
David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------080703060902050307050600-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 11:28:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15356 for ; Fri, 5 Mar 2004 11:28:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIBW-0000bd-Sf for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 11:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25GSQXj002323 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 11:28:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIBW-0000bO-CF for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 11:28:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15276 for ; Fri, 5 Mar 2004 11:28:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIBT-0004q5-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:28:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIAD-0004WX-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:27:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzI9G-0004IZ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzI2P-0001uF-U9 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzI2O-00084h-LU; Fri, 05 Mar 2004 11:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzI23-00084L-FY for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 11:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15068 for ; Fri, 5 Mar 2004 11:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzI20-0003Bv-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:18:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzI13-00032r-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:17:38 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzI0h-0002tU-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:17:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25GGhTN006646; Fri, 5 Mar 2004 10:16:44 -0600 (CST) Message-ID: <4048A7EB.2030808@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" CC: "Putzolu, David" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds952.usa.alcatel.com id i25GGhTN006646 Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 10:16:43 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Weiming, I still believe that the result you got from your experiment could be=20 much more improved if you allocated two separate queues, one for C and the other=20 for D data. Then create two separate threads to process the queues (one for eac= h). Give both threads equal priority and you should be fine. If you want to s= kew things in favor of the C, then you can adjust priority accordingly. Regards, Alex. Wang,Weiming wrote: >Hi David, > >Some more comments on the multi-channels from your last email as below: > >I agree that multiple FEs sharing the same physical link makes problems = more complicated. To make things more clear, I want state GRMP's ideas >again here, for I think there might be some misunderstanding on it: > >1. GRMP presents that pure separation of C/D in the same physical link i= s of no use to DoS protection. DoS protection can only be achieved by ins= ide FE mechanisms except a separate physical link is used by C/D. This a= lso applies to multi-FEs sharing the same physical links as you mentioned= above. Actually I can not see such separation has solved the DoS problem= for multi-FE case from the above txt. =20 > >2. We do not oppose to have such separation if it's proven useful for ot= hers. Actually the key GRMP has defined for DoS and congestion control is= the FE attribute for DoS protection policy, which has no limitation with= multi transport layer channels. If it's proven separation of C/D channel= s are useful, GRMP can easily adapt it. But what we need more discussion = is trying to see more reasons for such separations.=20 > >3. A combined control of C and D is useful for DoS protection as well as= for congestion.=20 >I have to note that the scheme proposed by FACT and also mentioned in th= e proposed basic merge principles only assume to provide a Data channel = control mechanism ( a rate limit). We just argue that this is not enough.= Actually what you mentioned above is also to ask for such a control comb= ination for multi-FEs cases. GRMP scheme can supply this very well by usi= ng a FE attribute to specify DoS protection policy in which C packets wit= h higher priorities can be ensured. I don't think other protocols have pr= ovided this mechanism (Note that this priority is different from that in = ForCES message headers, which actually does not take effect for this purp= ose). =20 > >To summarize, we just argue that a DoS protection policy like that prese= nted by GRMP should be included in final ForCES protocol other than just = by separation of C/D channels so as to effectively avoid DoS attack and a= lso to manage the congestion. I think this idea is quite the same as what= you presented in another email as some QoS hints transmitted from CE to = FE for DoS protection and congestion control.=20 > >Yours, >Weiming > >----- Original Message -----=20 >From: "Putzolu, David" >To: >Sent: Tuesday, March 02, 2004 9:06 PM >Subject: [Forces-protocol] Comments from chat with ADs > > >Patrick and I spent about 90 minutes last night >chatting with Bill and Alex about ForCES, with >maybe half of the time on the protocol. In >the conversations with them, along with some >follow-up chats I had with Allison Mankin, the >following topics where covered: multiple=20 >channels, multicast/unicast, and congestion=20 >control. Below is what I recall from memory=20 >(Patrick please correct me/elaborate as needed :) > > > >Multiple channels: =20 > >I discussed the interference issue that=20 >was identified by the GRMP team. Bill & >Alex agreed that many OS implementations can have >an interference property (i.e. where two different >connections will have queuing interference lower in >the networking stack in the OS). So it is necessary >to make sure when implementing a FE (or CE probably >as well) that this is taken into account. Methods >of doing that include: >* Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) >* Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. >However, it was also mentioned that intra-FE=20 >interference is only one kind of interference. Good >FE implementation (e.g. by manually queuing above the >OS) helps to fix intra-FE interference, but it does >not solve inter-FE interference. That is, if all >(C & D) packets are always on the same connection, >that makes it impossible on the wire to differentiate >them from one another. Imagine you have a bunch of >FEs with some of them being subject to DOS attack for >D packets, and you want to query one of the FEs for >statistics. It would be good to have some way of >ensuring the C packets (or any high priority packets - >OSPF HELLO maybe) get through. Separate channels >(as Jamal indicated, don't even have to be C & D) >makes this possible. Putting everything on one >channel makes it impossible to deal with inter-FE >interference in a differentiated fashion.=20 > >[WangRe] > >=20 >=16=8A=DCz=CAk=A2=DA=1C=A2Y=9A=8AX=A7=82X=AC=B4Z+q=EB)=AE=8Bhr=89bz=D7=E8= =AE=08m=B6=9B?=FF=0C0=D6'=AD~=8A=E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F7=E8=AD= =C7=AC=A6=BA-=A1=CA% > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 11:49:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15854 for ; Fri, 5 Mar 2004 11:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIVC-0002Ml-1z for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 11:48:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Gmkd3009095 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 11:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIVB-0002Mc-KD for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 11:48:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15774 for ; Fri, 5 Mar 2004 11:48:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIV8-0000mj-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:48:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzITY-0000JS-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:47:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzISa-00006D-01 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:46:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzINi-0002No-Km for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 11:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzINh-0001nQ-2e; Fri, 05 Mar 2004 11:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzINP-0001mn-JU for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 11:40:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15537 for ; Fri, 5 Mar 2004 11:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzINM-00070n-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:40:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIMR-0006rM-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:39:44 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzILv-0006hY-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 11:39:11 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25GceTN011235; Fri, 5 Mar 2004 10:38:40 -0600 (CST) Message-ID: <4048AD0F.7000705@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jeff pickering CC: "Khosravi, Hormuzd M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <9CB758BBEE58754F8F33234D75B9F4B00243EDB8@orsmsx410.jf.intel.com> <4048823F.1040108@creeksidenet.com> In-Reply-To: <4048823F.1040108@creeksidenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 10:38:39 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jeff, We can have the protocol fall back to UNICAST in this case. Supporting a mix in a given transaction may add unnecessary complexity to the protocol. What do you all think? Alex. jeff pickering wrote: > > All, > > Given that I dont believe we can scale well without multicast, I would > like to see it > as a MUST. But thats just due to a focus on larger systems. For > lightweight implementations, > one could envision unicast being sufficient. I agree with Hormuzd that > some negotiation > is necessary if we make this a SHOULD. Then the question would become > what happens > when 1 FE says it can only unicast. Does all traffic revert to > unicast, or can there be a mix? > > Jeff > > > Khosravi, Hormuzd M wrote: > >> Hi Alex, >> >> In general, I prefer using language such as MUST so that there is no >> confusion or interop issues in the protocol implementations. However, >> you raise a reasonable point and let me tell you my thoughts on this. We >> will definitely need Unicast between FEs and CEs at the minimum in the >> protocol. In addition, if the interconnect technology supports Multicast >> and there is a case where it is useful to the application (such as >> downloading IPv4 routes) we must allow it as well without breaking >> interop. In order to do that, we will need specific procedures in the >> protocol that will allow the CE and FE to negotiate on using multicast >> dynamically at run-time (say during the binding or joining phase between >> the CE and FE) and also associate different multicast groups with LFBs. >> We will also need to define how Reliability/CC etc. will be provided for >> multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >> then applications will be able to use both unicast and multicast without >> any interop issues. >> >> Let me know what you guys think about this. >> >> Regards >> Hormuzd >> >> -----Original Message----- >> From: Alex Audu [mailto:alex.audu@alcatel.com] Sent: Thursday, March >> 04, 2004 1:22 PM >> To: Khosravi, Hormuzd M >> Cc: forces-protocol@ietf.org >> Subject: Re: [Forces-protocol] Comments from chat with ADs >> >> >> Hormuzd, >> >> Why should multicast be "mandated for certain cases where it will be >> useful" if there >> is a simpler, more robust way to do the same thing? I'll say we >> don't mandate this. >> We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >> and make MULTICAST optional. Any issues with this? >> >> Regards, >> Alex. >> >> >> Khosravi, Hormuzd M wrote: >> >> >> >>> Hi David >>> >>> Your summary below of the discussion with Ads on the different issues >>> seems like very reasonable approaches to me. >>> >>> I agree that it will be a good idea to present transport alternatives >>> >> >> at >> >> >>> IP and non-IP level for the ForCES protocol. We can mandate one or more >>> transport for IP and one or more transport for non-IP, this way the >>> interoperability requirements are met and at the same time, the in-box, >>> out of box scenarios are met. >>> >>> Also, agree with having multiple channels/connections to differentiate >>> >> >> C >> >> >>> & D traffic between CEs and FEs. On the unicast/multicast topic, dual >>> mandatory approach again seems a good idea to support interoperability. >>> The one thing that I would like to point out is that for any ForCES >>> protocol implementation to work, unicast will definitely be required at >>> the minimum. One could also mandate using multicast for certain cases >>> where it will be useful (e.g. IPv4/config table download), if it is >>> supported by the interconnect as you stated. But just multicast without >>> unicast will not work, atleast not efficiently. >>> >>> Regards >>> Hormuzd >>> >>> -----Original Message----- >>> From: forces-protocol-admin@ietf.org >>> [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>> Sent: Tuesday, March 02, 2004 5:06 AM >>> To: forces-protocol@ietf.org >>> Subject: [Forces-protocol] Comments from chat with ADs >>> >>> Patrick and I spent about 90 minutes last night >>> chatting with Bill and Alex about ForCES, with >>> maybe half of the time on the protocol. In >>> the conversations with them, along with some >>> follow-up chats I had with Allison Mankin, the >>> following topics where covered: multiple channels, >>> multicast/unicast, and congestion control. Below is what I recall >>> from memory (Patrick please correct me/elaborate as needed :) >>> >>> >>> >>> Multiple channels: >>> I discussed the interference issue that was identified by the GRMP >>> team. Bill & >>> Alex agreed that many OS implementations can have >>> an interference property (i.e. where two different >>> connections will have queuing interference lower in >>> the networking stack in the OS). So it is necessary >>> to make sure when implementing a FE (or CE probably >>> as well) that this is taken into account. Methods >>> of doing that include: >>> * Manually queuing packets (i.e. feed OS few enough >>> packets that it cannot get into trouble - although >>> you pay a performance price for that, in that fine >>> grained scheduling takes cycles) >>> * Indicating to the OS to treat flows differently - some real-time >>> OS will let you do this, that is they >>> are implemented to internally retain QoS between >>> flows. >>> However, it was also mentioned that intra-FE interference is only >>> one kind of interference. Good >>> FE implementation (e.g. by manually queuing above the >>> OS) helps to fix intra-FE interference, but it does >>> not solve inter-FE interference. That is, if all >>> (C & D) packets are always on the same connection, >>> that makes it impossible on the wire to differentiate >>> them from one another. Imagine you have a bunch of >>> FEs with some of them being subject to DOS attack for >>> D packets, and you want to query one of the FEs for >>> statistics. It would be good to have some way of >>> ensuring the C packets (or any high priority packets - >>> OSPF HELLO maybe) get through. Separate channels >>> (as Jamal indicated, don't even have to be C & D) >>> makes this possible. Putting everything on one >>> channel makes it impossible to deal with inter-FE >>> interference in a differentiated fashion. >>> >>> Multicast & Unicast: >>> The discussion on this started out with a discussion >>> of the IETF protocol design BKM that options can ruin >>> compatibility. That is, if there are four ways to >>> implement something, all optional, then you can have >>> client 1 implement A & B, and client 2 implement C & D, >>> and even though both clients are 100% compliant, they >>> cannot talk to one another. Better to say all clients >>> must implement A and make B, C, and D optional, so that >>> way you know that all implementations will be able to at least talk. >>> >>> Patrick & I pushed on this a bit, explaining that we >>> actually had potentially (at least) two different >>> environments - very close environments where multicast >>> support could be present in the interconnect, and not-as-close >>> environments (and some close >>> environments as well) where multicast was not available. >>> >>> Bill & Alex indicated that if there really are two >>> quite different cases, then it is possible to have a >>> "dual mandatory" approach. I.e.: >>> >>> If your underlying interconnect supports multicast, >>> then you MUST implement the following (multicast) >>> method of communication. >>> >>> If your underlying interconnect supports unicast, then >>> you MUST implement the following (unicast) method >>> of communication. >>> >>> This will guarantee interop, although at a potential >>> extra cost (cost being having to potentially support >>> both when both are present). While this isn't optimal, >>> it does at least give some flexibility. >>> >>> >>> >>> Congestion control: >>> >>> Several times over the whole conversation the topic >>> of congestion control came up. Also, as part of some >>> TIPC discussions, I ended up spending some time talking >>> to Allison Mankin (transport AD) about congestion control >>> as well. All the ADs I talked to where consistent on the following: >>> >>> If you are running over IP, you MUST act in a RFC2914 >>> compliant fashion (i.e. respond to congestion like TCP >>> or SCTP or RMT does). Two reasons where put forth for >>> this: >>> 1) Any time you define an IP-based protocol you cannot >>> guarantee that it will not go out over the Internet. As >>> such, the IESG will NOT standardize IP protocols with >>> "bad" (non-2914) behaviors. >>> 2) Lots of implementation experience showing that other >>> congestion control mechanisms don't work (congestion >>> collapse etc). >>> >>> They where very firm on the above and my impression was >>> that convincing them otherwise would be very difficult. >>> >>> That being said, a second alternative did arise: If >>> you are not implementing on top of IP (e.g. running on >>> Infiniband, ATM, Ethernet) then you could rely on mechanisms >>> for congestion control built into what you are relying on, >>> or even consider building your own congestion control >>> mechanisms (ala TIPC). This makes it possible to define >>> (for example) a multicast transport for forces without >>> having to go all the way and implementing RMT - as long >>> as it is clear that it isn't over IP. The ADs went as >>> far as saying that the IETF could even accept standards- >>> track drafts that say nothing about IP (e.g. define an >>> Ethernet-only transport for ForCES), if it is necessary for ForCES. >>> GSMP and (some other group I forgot) was >>> given as an example. >>> >>> Cheers, >>> David >>> >>> _______________________________________________ >>> Forces-protocol mailing list >>> Forces-protocol@ietf.org >>> https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> >>> _______________________________________________ >>> Forces-protocol mailing list >>> Forces-protocol@ietf.org >>> https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> >>> >> >> >> >> _______________________________________________ >> Forces-protocol mailing list >> Forces-protocol@ietf.org >> https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 12:17:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18307 for ; Fri, 5 Mar 2004 12:17:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIws-0006HN-FH for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 12:17:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25HHM6U024131 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 12:17:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIws-0006H8-7x for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 12:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18286 for ; Fri, 5 Mar 2004 12:17:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIwo-0007gN-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 12:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIvm-0007Mn-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 12:16:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzItc-0006gi-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 12:14:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzItd-0003GA-W6 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 12:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzItc-0005ye-Ps; Fri, 05 Mar 2004 12:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzGCi-0000P6-GK for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 09:21:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09368 for ; Fri, 5 Mar 2004 09:21:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzGCg-0004SJ-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 09:21:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzGBh-0004GP-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 09:20:30 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzGAJ-0003th-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 09:19:04 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 5 Mar 2004 22:30:11 +0800 Message-ID: <05aa01c402bc$84b8d770$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <9CB758BBEE58754F8F33234D75B9F4B00224B3DC@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05A8_01C402FF.92CB4E90" 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 Subject: [Forces-protocol] Share experiences Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 22:16:57 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_05A8_01C402FF.92CB4E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpIaSwgDQoNCldlIChHUk1QIHRlYW0pIGFncmVlIHRoYXQgdG8gc2hhcmUgdGhlIGltcGxlbWVu dGF0aW9uIGV4cGVyaWVuY2VzIHdvdWxkIGJlIGhlbHBmdWwgZm9yIHRoZSBtZXJnZSBwb3NpYmls aXR5IGFjY2Vzc21lbnQgYW5kIGFsc28gYmUgb2YgZ3JlYXQgYmVuaWZpdHMgdG8gZm9ybSBhIHJv YnVzdCBwcm90b2NvbC4gQWN0dWxseSBHUk1QIHRlYW0gaGFzIHN1Y2Nlc3NmdWxseSBlc3RhYmxp c2hlZCBhIHRlc3QgcGxhdGZvcm0gZm9yIEdSTVAgbWVzc2FnZXMgZmVhc2liaWxpdHkgYW5kIHJl bGF0ZWQgcGVyZm9ybWFuY2UgdGVzdC4gVGhlIHRlc3QgcGxhdGZvcm0gYW5kIHNvbWUgb2YgdGhl IHRlc3QgcmVzdWx0IGhhdmUgYmVlbiBzaG93biBpbiB0aGUgRm9yQ0VTIG1lZXRpbmcgaW4gU2Vv dWwuIEkgYWxzbyBob3BlIG90aGVyIGNhbmRpZGF0ZSBwcm90b2NvbCB0ZWFtcyBjYW4gYmUgZ2Vu ZXJvdXMgZW5vdWdoIHRvIHNob3cgc29tZSBvZiB0aGUgZXhwZXJpbWVudHMgcmVzdWx0cyBpbiBh IG1vcmUgZGV0YWlsZWQgbW9kZSBhcyB3ZWxsIGFzIGdpdmluZyBzb21lIGV4cGVyaWVuY2VzLCB3 aGljaCBpcyBvYnZpdXNseSBvZiBncmVhdCBoZWxwIGZvciB1cyB0byBmaW5hbGx5IGdldCBhIHJv YnVzdCBwcm90b2NvbC4gSSdtIHN1cmUgc29tZSBjYW5kaWRhdGUgdGVhbXMgaGF2ZSBkb25lIHRo aXMgcXVpdGUgd2VsbC4NCiANCkFwYXJ0IGZyb20gdGhlIGRldGFpbGVkIHJlc3VsdHMgd2UgaGF2 ZSBwcmVzZW50ZWQgdG8gSUVURiBtZWV0aW5nLCB3ZSBhbHNvIGhhdmUgc29tZSAgZXhwZXJpZW5j ZXMgd2l0aCBHUk1QIGR1cmluZyB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHByb3RvY29sIGRlc2ln biBhcyBiZWxvdzoNCg0KMS4gIFRvIGRldmlkZSB0aGUgbWVzc2dlcyBpbnRvICJGRSBtYW5hZ2Vt ZW50ICBtZXNzYWdlcyIsICJMRkIgbWFuYWdlbWVudCBtZXNzYWdlcyIsICJEYXRhcGF0aCBtYW5h Z2VtZW50IG1lc3NhZ2VzIiBpcyB2ZXJ5IHJlYXNvbmFibGUgYW5kIGhhcyBtYWRlIHRoZSBtZXNz YWdpbmcgc3lzdGVtIHZlcnkgY2xlYXIgYW5kIGVhc3kgdG8gdXNlLiBUaGlzIGNhbiBiZSBzZWVu IGZyb20gdGhlIHRlc3RiZWQgQ0UgbWFuYWdlbWVudCB3aW5kb3cuDQoNCjIuICBHUk1QIGhhcyBi YXNpY2FsbHkgdXNlZCBUTFYgdG8gZXhwcmVzcyBlbnRpdGllcy4gTW9yZW92ZXIsIGEgImxpc3Qi IGRhdGEgc3RydWN0dXJlIGhhcyBiZWVuIGRlZmluZWQsIHdoaWNoIGhhcyBiZWVuIHByb3ZlbiBx dWl0ZSBlZmZpY2llbnQgdG8gZGVzY3JpYmUgYSBidW5jaCBvZiB0aGUgc2FtZSBlbnRpdGllcywg c3VjaCBhcyBhIGxpc3Qgb2YgYXR0cmlidXRlcyBpbiB0aGUgcHJvdG9jb2wgUERVLiANCg0KMy4g SXQncyByZWFsbHkgdXNlZnVsIHRvIGRlZmluZSBhIGJyb2FkY2FzdCBtZWNoYW5pc20gaW4gdGhl IHByb3RvY29sLiBXZSBoYXZlIGFscmVhZHkgZGVmaW5lZCBGRSBJRD0weGZmZmYgYXMgYSBicm9h ZGNhc3QgRkUgSUQgaW4gR1JNUCBvcmlnaW5hbCB2ZXJzaW9uLiBJbiBvdXIgZXhwZXJpbWVudHMs ICB3ZSBoYXZlIHVzZWQgdGhlbSB0byBzZXR1cCB0aGUgc2FtZSBMRkIgYXR0cmlidXRlcyBpbiBh bGwgRkVzLiBPdXIgZXhwZXJpZW5jZSBpcyBqdXN0IHRoYXQgd2UgZW5qb3kgdXNpbmcgaXQsIHRo b3VnaCB3ZSBub3cgb25seSB1c2UgcG9pbnQgdG8gcG9pbnQgVENQIHRvIGFjb21wbGlzaCBzdWNo IGEgYnJvYWRjYXN0IGluIHRoZSB0cmFuc3BvcnQgbGF5ZXIuIEZyb20gdGhlIGV4cGVyaW1lbnRz IHdlIGFsc28gbm90aWNlZCB0aGF0IGFuIExGQiBJRCBiYXNlZCBicm9hZGNhc3QgKCBhcyBmaXJz dCBwcm9wb3NlZCBieSBOZXRsaW5rMiApIHdpbGwgYWxzbyBiZSB1c2VmdWwuIFdlIGFyZSBzdXJl IHRoaXMgRkUgYW5kIExGQiBicm9hZGNhc3QgbWVjaGFuaXNtIHNob3VsZCBiZSBldmVuIG1vcmUg ZWZmaWNpZW50IHdoZW4gd2UgdXNlIG90aGVyIHRyYW5zcG9ydCBtZWFucyBsaWtlIGRpcmVjdCBF dGhlcm5ldCwgYmFja3BsYW5lLCBhbmQgVURQLiANCg0KNC4gR1JNUCBkZWZpbmVzIHRyYW5zYWN0 aW9uIGlkZW50aWZpZXJzIGluIHRoZSB3YXkgdGhhdCB0cmFucy4gSURzIG9yaWdpbmFsbHkgcHJv ZHVjZWQgYnkgQ0UgYW5kIGJ5IEZFIGFyZSBkaWZmZXJlbnQgYW5kIGFyZSBlYXN5IHRvIGJlIHJl Y29nbml6ZWQgYnkgaXRzIGZpcnN0IGJpdCAoMD0gQ0UgZ2VuZXJhdGVkLCAxPUZFIGdlbmVyYXRl ZCkuIFdoZW4gd2UgY29kZSB0aGUgQ0UsIHdlIGhhdmUgZm91bmQgaXQgaGFzIHNpbXBsaWZpZWQg dGhlIGNvZGluZyBxdWl0ZSBhIGxvdCwgZm9yIHdlIGRvIG5vdCBuZWVkIHRvIHJlbWVtYmVyIHdo ZXJlIHRoZSBtZXNzYWdlIGlzIG9yaWdpbmF0ZWQgYW55bW9yZS4gTW9yZW92ZXIsIHN1Y2ggZGVm aW5pdGlvbiBkb2VzIG5vdCBuZWVkIGFueSBwYXltZW50LiANCg0KNS4gV2UgYXJlIHF1aXRlIHN1 cmUgdGhhdCB0aGUgcHJvdG9jb2wgbWFuYWdlZCBvYmplY3RzIGxpa2UgRkUgYXR0cmlidXRlcyAg c2hvdWxkIGluY2x1ZGUgdGhvc2UgZGVmaW5lZCBieSB0aGUgcHJvdG9jb2wgaXRzZWxmIChsaWtl IERvUyBwcm90ZWN0aW9uIHBvbGljeSwgQ0UgZmFpbG92ZXIgcG9saWN5LGV0YykgYXMgd2VsbCBh cyBkZWZpbmVkIGJ5IEZFIG1vZGVscywgYW5kIGV2ZW4gc2hvdWxkIGJlIG9wZW4gdG8gYmUgZGVm aW5lZCBieSB2ZW5kb3JzLiBUaGlzIG1lYW5zIGl0IGlzIGltcG9zc2libGUgb25seSB0byByZWx5 IG9uIEZFIG1vZGVsIHRvIGRlZmluZSBldmVyeSB0aGluZyBvd2luZyB0byB0aGUgRkUgbW9kZWwg cGVyc29uYWxpdHkuIFRoZSBleHRyZW1lIGV4YW1wbGUgaXMgRkUgbW9kZWwgY2FuIG5vdCBkZWZp bmUgYXR0cmlidXRlcyByZWxhdGVkIHRvIENFIG9wZXJhdGlvbnMuIEFzIGEgcmVzdWx0LCB0aGUg Im9iamVjdCBjbGFzcyIgaWRlYSBpbiBHUk1QIHNob3VsZCBiZSB1c2VmdWwuIFRoaXMgY2FuIGFs c28gYmUgc2VlbiBmcm9tIHRoZSBDRSB3aW5kb3cgaW4gb3VyIHRlc3RiZWQsIHdoZXJlIEZFIGF0 dHJpYnV0ZXMgYXJlIGNsZWFybHkgZGV2aWRlZCBpbnRvICJHUk1QIGNsYXNzIiAiRkUgbW9kZWwg Y2xhc3MiIGFuZCBWZW5kb3IgY2xhc3NzIiAuIA0KDQo2LiBEeW5hbWljIGNhcGFiaWxpdHkgY2hh bmdlIGFzIGFuIGV2ZW50IHJlcG9ydCB0byBDRSBoYXMgYWxyZWFkeSBiZWVuIGluY2x1ZGVkIEdS TVAgZWFybGllc3QgdmVyc2lvbi4gV2UgYmVsaWV2ZSBpdCBpcyBvZiBncmVhdCB1c2UuIE1vcmVv dmVyLCBHUk1QIGhhcyBkZWZpbmVkIGEgRkUgRG9TIGF0dGFjayBhbGVydCBldmVudCByZXBvcnQs IHdoaWNoIGlzIG9idmlvdXNseSB1c2VmdWwuDQoNCjcuICBBICBtZWNoYW5pc20gdG8gc3luY3Jv bml6ZSB0aGUgdmVyc2lvbnMgb2YgdGhlIGJlaW5nIHVzZWQgRm9yQ0VTIHByb3RvY29sIGFuZCB0 aGUgRkUgbW9kZWwgYmV0d2VlbiBDRSBhbmQgRkUgc2hvdWQgYmUgc3VwcGxpZWQgYnkgdGhlIHBy b3RvY29sLCBiZWNhdXNlIENFIGFuZCBGRSBhcmUgcXVpdGUgcG9zc2libHkgYmVlbiBzdXBwbGll ZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBhdCBkaWZmZXJlbnQgdGltZS4gR1JNUCBoYXMgc3VwcGxp ZWQgdGhpcy4NCg0KOC4gQXMgcmVxdWlyZWQgYnkgRm9yQ0VTIHJlcXVpZW1lbnRzIGFuZCBmcmFt ZXdvcmssIHRoZSBzY2hlbWUgdG8gc3VwcG9ydCBuZXR3b3JrIG1hbmFnZW1lbnQgdG9vbHMgbGlr ZSBTTk1QIHNob3VsZCBiZSBjbGVhcmx5IHByZXNlbnRlZCBpbiB0aGUgcHJvdG9jb2wuIEdSTVAg aGFzIHByb3ZpZGVkIHRoZSBzY2hlbWUgYnkgZGVmaW5pbmcgYSBzZXQgb2YgTWFuYWdlZCBPYmpl Y3QgKE1PKSBtYW5hZ2VtZW50IG1lc3NhZ2VzLiBBbHRob3VnaCB3ZSBoYXZlIG5vdCBkZXBsb3ll ZCB0aGUgdGVzdCBmb3IgdGhpcywgd2UgYmVsaWV2ZSBpdCBzaG91bGQgYmUgZnVsbHkgY29uc2lk ZXJlZCwgZm9yIENFcyBhbmQgRkVzIGFjdHVhbGx5IGFyZSBpbiBvbmUgTkUuIA0KDQpZb3VycywN CldlaW1pbmcNCg0KUC5TLjogVG8gcHJldmVudCBhbiB1bmV4cGVjdGVkIGFsaWdubWVudCwgSSBo YXZlIHB1dCB0aGUgYWJvdmUgdHh0IGluIGEgYXR0YWNoZWQgcGRmIGZpbGUuIA0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIktob3NyYXZpLCBIb3JtdXpkIE0iIDxob3Jt dXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tPg0KVG86IDxoYWRpQHpueXguY29tPg0KQ2M6ICANClNl bnQ6IEZyaWRheSwgRmVicnVhcnkgMjcsIDIwMDQgMTE6NDAgQU0NClN1YmplY3Q6IFJFOiBGb3JD RVMgUHJvdG9jb2wgQW5hbHlzaXMgRGVzaWduIFRlYW0gQWRtaW5pc3RyaXZpYQ0KDQoNCkhpIEph bWFsDQoNCkkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHlvdXIgZG9jdW1lbnQgYmFzZWQgb24gb3Vy IGltcGxlbWVudGF0aW9uDQpleHBlcmllbmNlcy4NCg0KSSBhZ3JlZSB0aGF0IFRMViBlbmNvZGlu ZyBpcyB0aGUgbW9zdCBvcHRpbWFsIGVuY29kaW5nIGZvciB0aGUgcHJvdG9jb2wuDQpXZSBoYXZl IHVzZWQgYm90aCBPSUQvQkVSIGFuZCBYTUwgZW5jb2RpbmdzIGluIG91ciBwcmV2aW91cyBpbXBs ZW1lbnRhdGlvbiBhbmQNCnRoZXkgd2VyZSB2ZXJ5IGluIGVmZmljaWVudCBhbmQgcmVkdWNlZCB0 aGUgdGhyb3VnaHB1dCBhbG1vc3QgMTAgZm9sZCBpbiBvbmUgY2FzZS4NCkFsc28sIGhhdmluZyBh IEZpeGVkIGxlbmd0aCBjb21tb24gaGVhZGVyIGFuZCB2YXJpYWJsZSBsZW5ndGggcGF5bG9hZA0K Y29uc2lzdGluZyBvZiBUTFZzIGlzIG1vc3QgZWZmaWNpZW50IHdheSB0byBlbmNhcHN1bGF0aW5n L2RlY2Fwc3VsYXRpbmcgbWVzc2FnZXMuDQoNCldlIGFsc28gaGF2ZSB0aGUgQ0UgYWxsb2NhdGlu ZyBGRUlEcyBvciBQSURzIGFzIHlvdSByZWZlciB0byB0aGVtLiBUaGlzDQp3b3JrcyB3ZWxsIGFu ZCBpcyBhIHNjYWxhYmxlIGFwcHJvYWNoIHRvIGFkZCBuZXcgZWxlbWVudHMgaW50byB0aGUgTkUu DQoNCldlIGhhdmUgbm90IHBsYXllZCB3aXRoIGR5bmFtaWMgY2FwYWJpbGl0eSBhZGRpdGlvbiwg aG93ZXZlciB0aGlzIHNlZW1zDQp0byBiZSBvbmUgb2YgdGhlIGRpcmVjdGlvbnMgb2YgdGhlIE1v ZGVsIHRlYW0gYW5kIEkgYW0gb3BlbiB0byB0aGlzLiBIb3dldmVyLA0Kd2UgbXVzdCBkZWZpbml0 ZWx5IHN1cHBvcnQgdGhlIG1vcmUgY29tbW9uIGNhc2Ugb2Ygc3RhdGljIGNhcGFiaWxpdGllcy4N Cg0KV2UgYXJlIGFsc28gZmluZSB3aXRoIGFwcGxpY2F0aW9uIG9yIEZvckNFUyBwcm90b2NvbCBs ZXZlbCBtdWx0aWNhc3RpbmcNCmluIGFkZGl0aW9uIHRvIHVuaWNhc3RpbmcuIFdlIGRvIHRoaXMg dXNpbmcgRkVJRHMganVzdCBhcyB5b3UgdXNlIFBJRHMuDQoNClN1cHBvcnQgZm9yIGxheWVyIDIg aW50ZXJjb25uZWN0cyBvciBJUCBpbmRlcGVuZGVuY2UgYXMgeW91IGNhbGwgaXQgaXMNCmFsc28g c29tZXRoaW5nIHdoaWNoIGhhcyB0byBiZSBhZGRyZXNzZWQuIEkgdGhpbmsgYWxsIHByb3RvY29s cyBzdXBwb3J0IHRoaXMsDQpob3dldmVyIHRoZXJlIGhhdmUgYmVlbiBkaWZmZXJlbnQgYXBwcm9h Y2hlcyB0YWtlbiB0byBzdXBwb3J0IHRoaXMuDQoNCk9uZSBvZiB0aGUgb3RoZXIgdXNlZnVsIGxl YXJuaW5nIGV4cGVyaWVuY2VzIHRoYXQgd2UgaGF2ZSBoYWQgaXMNCnNlcGFyYXRpb24gb2YgZGF0 YSBhbmQgY29udHJvbCBvbiBzZXBhcmF0ZSBjaGFubmVscy4gVGhlcmUgYXJlIG1hbnkgZ29vZCBy ZWFzb25zIHRvDQpkbyB0aGlzLCB3ZSBoYXZlIGFscmVhZHkgZXhwbGFpbmVkIHNvbWUgaW4gdGhl IHBhc3Qgc28gSSB3b250IHJlcGVhdC4NCg0KQW5vdGhlciB0aGluZyB3aGljaCB3ZSB0aGluayBp cyB2ZXJ5IGltcG9ydGFudCBmcm9tIGludGVyb3BlcmFiaWxpdHkNCnBvaW50IG9mIHZpZXcgaXMg dG8gbWFuZGF0ZSBhIG1pbmltdW0gbm8uIG9mIHRyYW5zcG9ydChzKSBhbmQgaGF2ZSBvdGhlcnMg YXMNCm9wdGlvbmFsLiBLZWVwIHRoZSBwcm90b2NvbCBzaW1wbGUgYnkgdGFraW5nIGFkdmFudGFn ZSBvZiB1bmRlcmx5aW5nIHRyYW5zcG9ydHMgb3INCmludGVyY29ubmVjdHMgaXMgYW5vdGhlciB1 c2VmdWwgZGVzaWduIHByaW5jaXBsZS4NCg0KQW55d2F5cyBJIG5lZWQgdG8gc3RhcnQgcGFja2lu ZyBmb3IgS29yZWEsIGJ1dCBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIHN0YXJ0Lg0KTGV0cyBrZWVw IHRoZSBtb21lbnR1bSBnb2luZy4uLi50byBnZXQgdG8gYW4gaW50ZXJvcCBpbiBTYW4gRGllZ28g OikNCg0KDQpSZWdhcmRzDQpIb3JtdXpkDQo= ------=_NextPart_000_05A8_01C402FF.92CB4E90 Content-Type: application/pdf; name="GRMPexperiences.pdf" Content-Disposition: attachment; filename="GRMPexperiences.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjQwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA0MyANL0ggWyAx NDkxIDI1MSBdIA0vTCA4MDg5MiANL0UgNzM5NTUgDS9OIDIgDS9UIDc5OTc0IA0+PiANZW5kb2Jq DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTQwIDM0IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDEwMjcgMDAwMDAgbg0KMDAw MDAwMTM1OCAwMDAwMCBuDQowMDAwMDAxNzQyIDAwMDAwIG4NCjAwMDAwMDIxMTEgMDAwMDAgbg0K MDAwMDAwMjI3MCAwMDAwMCBuDQowMDAwMDAyNzYwIDAwMDAwIG4NCjAwMDAwMDI5NjIgMDAwMDAg bg0KMDAwMDAwMzI1MCAwMDAwMCBuDQowMDAwMDAzMjg5IDAwMDAwIG4NCjAwMDAwMDMzMTggMDAw MDAgbg0KMDAwMDAwMzMzOSAwMDAwMCBuDQowMDAwMDAzOTgxIDAwMDAwIG4NCjAwMDAwMDQwMDIg MDAwMDAgbg0KMDAwMDAwNDczNiAwMDAwMCBuDQowMDAwMDA0NzU3IDAwMDAwIG4NCjAwMDAwMDU1 MjcgMDAwMDAgbg0KMDAwMDAwNTU0OCAwMDAwMCBuDQowMDAwMDA2MzM2IDAwMDAwIG4NCjAwMDAw MDYzNTcgMDAwMDAgbg0KMDAwMDAwNzA3MiAwMDAwMCBuDQowMDAwMDA3MDkzIDAwMDAwIG4NCjAw MDAwMDc3OTMgMDAwMDAgbg0KMDAwMDAwNzgxNCAwMDAwMCBuDQowMDAwMDA4NTE2IDAwMDAwIG4N CjAwMDAwMDg1MzcgMDAwMDAgbg0KMDAwMDAwODkzNSAwMDAwMCBuDQowMDAwMDcwMjU4IDAwMDAw IG4NCjAwMDAwNzAzMzYgMDAwMDAgbg0KMDAwMDA3MDU0MiAwMDAwMCBuDQowMDAwMDcwNzU3IDAw MDAwIG4NCjAwMDAwNzM0MzQgMDAwMDAgbg0KMDAwMDAwMTQ5MSAwMDAwMCBuDQowMDAwMDAxNzIx IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNzQNL0luZm8gMzcgMCBSIA0vUm9vdCA0MSAwIFIg DS9QcmV2IDc5OTY0IA0vSURbPGMxNDA5NDRkYjFhYTQ5YjBlNWM0ZTg1ZDJhMzAyZjYyPjwzMDI4 NGFiNzg1ZWMxN2JjYzkyY2Y0MzhjN2FjMjBlMT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAg DTQxIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDM5IDAgUiANL01ldGFkYXRhIDM4 IDAgUiANL09wZW5BY3Rpb24gWyA0MyAwIFIgL1hZWiBudWxsIG51bGwgbnVsbCBdIA0vUGFnZU1v ZGUgL1VzZU5vbmUgDS9QYWdlTGFiZWxzIDM2IDAgUiANL1N0cnVjdFRyZWVSb290IDQyIDAgUiAN L1BpZWNlSW5mbyA8PCAvTWFya2VkUERGIDw8IC9MYXN0TW9kaWZpZWQgKEQ6MjAwNDAzMDUyMjA4 MTApPj4gPj4gDS9MYXN0TW9kaWZpZWQgKEQ6MjAwNDAzMDUyMjA4MTApDS9NYXJrSW5mbyA8PCAv TWFya2VkIHRydWUgL0xldHRlcnNwYWNlRmxhZ3MgMCA+PiANPj4gDWVuZG9iag00MiAwIG9iag08 PCANL1R5cGUgL1N0cnVjdFRyZWVSb290IA0vUm9sZU1hcCA0IDAgUiANL0NsYXNzTWFwIDcgMCBS IA0vSyAzMSAwIFIgDS9QYXJlbnRUcmVlIDMyIDAgUiANL1BhcmVudFRyZWVOZXh0S2V5IDIgDT4+ IA1lbmRvYmoNNzIgMCBvYmoNPDwgL1MgNDggL0wgMTM0IC9DIDE1MCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDczIDAgUiA+PiANc3RyZWFtDQpIiWJgYGBmYGC9zMDKwMAiwyDIgAAgNlCU geMCQ1cakAYTUCAAxLJQzMAgyiDAGMPQxXiVYSsjN4MQAwcDA1MuEJ8E4rdA/B+ItwHxciBeycDA WPm+jMGSYSfDIa4EhuNQE5UZGPWXAGkmIPYGYhYGRqXrQFqegYHnLEQJQIABAOMwFBsNZW5kc3Ry ZWFtDWVuZG9iag03MyAwIG9iag0xMzIgDWVuZG9iag00MyAwIG9iag08PCANL1R5cGUgL1BhZ2Ug DS9QYXJlbnQgMzkgMCBSIA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNlIDw8IC9DUzAgNDggMCBS IC9DUzEgNDkgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dTMCA2NyAwIFIgL0dTMSA2OCAwIFIgPj4g DS9Gb250IDw8IC9UVDAgNDUgMCBSIC9DMl8wIDQ0IDAgUiA+PiAvUHJvY1NldCBbIC9QREYgL1Rl eHQgXSA+PiANL0NvbnRlbnRzIFsgNTEgMCBSIDUzIDAgUiA1NSAwIFIgNTcgMCBSIDU5IDAgUiA2 MSAwIFIgNjMgMCBSIDY1IDAgUiBdIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJv eCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANL1N0cnVjdFBhcmVudHMgMCANPj4gDWVuZG9i ag00NCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMCANL0Jhc2VGb250IC9O TkhFR08rQXJpYWxVbmljb2RlTVMgDS9FbmNvZGluZyAvSWRlbnRpdHktSCANL0Rlc2NlbmRhbnRG b250cyBbIDcxIDAgUiBdIA0vVG9Vbmljb2RlIDQ3IDAgUiANPj4gDWVuZG9iag00NSAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RD aGFyIDEyMiANL1dpZHRocyBbIDI1MCAwIDQwOCAwIDAgMCAwIDE4MCAzMzMgMzMzIDAgMCAyNTAg MCAyNTAgMCA1MDAgNTAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDUwMCA1MDAgMCAyNzggMCAwIDU2 NCAwIDAgMCA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgDTAgMzMzIDAgMCA2MTEgODg5IDcy MiA3MjIgNTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgMCAwIDAgMCANMCAwIDAgMCAwIDQ0 NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgDTUw MCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IF0gDS9FbmNvZGlu ZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW4gDS9Gb250RGVzY3Jp cHRvciA0NiAwIFIgDT4+IA1lbmRvYmoNNDYgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgNjU2IA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgMzQg DS9Gb250QkJveCBbIC01NjggLTMwNyAyMDI4IDEwMDcgXSANL0ZvbnROYW1lIC9UaW1lc05ld1Jv bWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDk0IA0vWEhlaWdodCAwIA0+PiANZW5kb2JqDTQ3 IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjE0ID4+IA1zdHJlYW0NCkiJ VFAxbsMwDNz1Co4JMkhxOhpeksVDm6J2uisS7QqoKYGWB/++kuAk6EASPPJwR8pze2nJRZCf7E2H EQZHlnH2CxuEO46O4FiBdSZuXclm0gFkInfrHHFqafBQ10J+peEceYVd358Oag/yyhbZ0ZiQt+r2 nZBuCeEXJ6QICpoGLA5Cnt91+NATgizEF9ivAaEq/XHT9hbnoA2yphGhVkqdmkdBsv/nD9Z9MD+a xWu7Uo1I2xueefmmpw+zMCeL5fBiJFtwhM/fBB+yWg7xJ8AA0xNqZAplbmRzdHJlYW0NZW5kb2Jq DTQ4IDAgb2JqDVsgDS9JQ0NCYXNlZCA3MCAwIFIgDV0NZW5kb2JqDTQ5IDAgb2JqDS9EZXZpY2VH cmF5IA1lbmRvYmoNNTAgMCBvYmoNNTY0IA1lbmRvYmoNNTEgMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCA1MCAwIFIgPj4gDXN0cmVhbQ0KSImEU2tr2zAU/e5fccknCWpbUvxK CYHlsdCxQOn8bYzi2qrrkdjBStv9/N0rJU3KHEawI10dnfs4x+E9TKfhZnG3BAGz2Xy58MLFDwGl wT39wJStJ6EBL3zQ2+LQvOlFt+36ZqcPfVNC33jhGi/UxpvnXpjnAiTkz54vAiHkBPISTqt3kCKI E0vrVhMBaZwFUSbGkO+8n2zN/ZQ9cD9mm3uuBAP9Z6/7RrelNrfAf+XfvFXurTZY5blweSz8U35h M19LGqkgy4SkpAx4/nuAVQ2x2q5EcuqKVsMJVBqodJK5rr5wP2F77ktW9AceM3juux2XCQPavdCB hkrTpmjwtcVHV9Br80pLihuuGLzzBIEvxRuXdGOPAN0eHJj+OmKCOy4jtsq/coVXbBptqYm5rW+O LAUxm+7MZocrwJdBlKYoxxILN65MDcB9FQvm1OARs4JYJtod8LFdwJo6Rf0iqx8GqleLb2v4AGmg iCXeb4nL5WgJUNCLjrsWirbCFjuKdGVHSJyRocMaDw08aYrZnqmQW9tAuFCP/zpAOXUUREmMboNU yiA5mm6KMo5ngxYYD1lgQO1kkgTiSMfgip+i//pJZVF6xU9YLH0l0vlJBsARjM5F5XKenJS3wUpb QUntSl8azI3ZmBqVOyFaOjpbZ2RNs3LQoi3qszYxO+X08a4L26UxCDMjLgW7gdF3njFLMicTXIA/ s+FX/lHPxXUroZtJ5mYix6mimVwa868AAwB27Rw3DWVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBvYmoN NjU2IA1lbmRvYmoNNTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MiAw IFIgPj4gDXN0cmVhbQ0KSIl0VMFu2zAMvfsriJ5IoHYlO7ZjoOihSTFsWICi8HYpdlBspfaQ2p1l N9vfj5TTrBuyQySaovgeqccEj3hBWuGawgzNSAs0L35r4Jk0uzrzZL1lO3HPXuscu52/CS27HcUI r6Q12oHCAn9RzI7BGtd3ZrvnCAtGjrsaGuNIJ8dMprbg4SjkuxLxDkEyd0/gfDYneSV0pgN8QeNf kHKZvpWfglBFSqkUygrerAMoCHW0yPMEynXwiNWeUrRmAMOUmOfMeGRnD5OzEVCcYNm07PDFVaaD rQVnbQe7oZ85SHhj/WadrFtbw+ruXOtShANlKPm6uj9QvsBoZntXBnebVXB1D9fXV5vVxzWkcHNz u14Ft2VwVZYKNJS7QPlypBKtojRjUx2tQkGWJFGWFwsonwMEoPL7mbTZubS+V8mxVUVS/A9ALyOV F1oAHjGmMMFIFqBC+7dYLPEDhUt8ECFt5C3uKWF1NLREQyG/H2zlwmy3ldnvueUcMInXWUmB9ZyS L5eS5jPra4lfSXPzxt6f2Z+yvcgykBaZgO3ka2zH1rqZ08bHDtZvr0yAFbLI8NIfGrhgz75lPekY R/mA+sRsNODGwXOqPKWRH386wXE5pxrmeqzYlgrsJNEf+en82NN0eU5+td21na0v4dC0VSMzweqS cWJ5vQy9WK/+U+aiA0pz/DG1owW7ozjFXVu1rKp5CMb+PW56wk0EN1bybqkop/a4rhpaFrKB7dQx sjS738HIMnbmWVrtIbmr0lF5UesuwU0cyhzNv0OWnYYsE7TwDe5UrIDKqL0Nkp8EBjRiyG+gxB9u p3mMwI+I5+DHy/8xSE/8bFa9JIN79ibzn9YXWSIfz0+RKqH3W4ABAIBWLkkNZW5kc3RyZWFtDWVu ZG9iag01NCAwIG9iag02OTIgDWVuZG9iag01NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDU0IDAgUiA+PiANc3RyZWFtDQpIiXRUTU/jQAy951f4tuMVCTNJ8yWxHCiwAi1a tIq0hxWHkE5pUMlUSUrh32N7UpQD28PE47H9PO95Wt0GV1VwdbcMTu/h7Oz0bnlzCTmcn19cLoOL KjitKg0GqnWgoWqAlgMYHaUZmXqySg1pbqI4L1KoXgIFgNXzF2WLr8qGOtJal1I80mme/w8hTaMs L2JG+KeSCG7QLNSIYa6+YakGjBX0tt7iQm3Z+Y7GKNgPdr1nH4y0OAzJt7LrljadhRoee1evGg6t B46AFzSZss2m7jiGq4oHJEPSBXLDpoVd76Ru4xgjAi70F/OSjjb1K+8IhI+osxVvfVefHayA6hh1 jbFRVxgSPj5Ut8JJvCgmTsQ6QPWd7n1D8VpdYpho9QPDuFSa1lS9ybqmHxmEUNOH2w/j+LiBR4np JcCJ7Q9WYjdiz/PoorFWcE2NxYXync7xiRMO6CQdforvj8TeSew9yQJuBurjn8Qzz/WgWw/3SrmJ suLyab6b9pMZrbOJGbEOEJuoLAqel2pFHLluGg6vl9v3YN92tm8x9WLabiRzOAE4YOalsjwpK2C/ l/YF43ymhk7yCTM3JWOGR9DQRIs8Tzz06ETEwY57NnayGzf8sTDImBFN3IVcMVHw6xpNoS54pqAe R6G3b0kqkyqpMSJ1M0DbSa16uwXMCiVZJEymhkgOfmNY+gS+LRYeWzD61tJe8hsL7QDPEjeMU2f1 CAcro2sl6FkuQZNK8vlIZqSV1iTgSRDb8WR2PcnZ+9OCOCzm5Ol0Is948mSUPfed4y+4bkvUvyOP K3dCasDOsWKilQjjxENEeVe1xJxmLEmOp3XjRN4dl+JUfr0bGPbN5vOl8ytPeXKpsFfbyqfHRNXd sHO9nHOFWoZYHqztMdP8vKfHGks8/5sc/x6mUvjwIcAAvO9ALA1lbmRzdHJlYW0NZW5kb2JqDTU2 IDAgb2JqDTcxMCANZW5kb2JqDTU3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggNTYgMCBSID4+IA1zdHJlYW0NCkiJdFRNb9swDL37V/AoDbUrf9tA20M+NnRYh2LwsEPbg2LL jddUDmxnaffrR9J2m0N3iCJRFB8f+ejiq+MqTyk/h6IE3AVRAsURFLi+F6VpCMXKuRPmZW+65ln6 sTDS9YUdejga0Lu+BdsOTWkqNIcChq0eQFvAky++yVR8loESC+nGYrRdS3RbSTcVsNHyoZjwg3DG jwnez7w8yxJMo6gQvjcVbLpWVzIXpe4HuBege5BBKOqmw/O+a/cteyFIJF4JFL4TCqYbiGHX2KcA 7iUcm510c8ELvMOrbIKPU6bvzgm8VYHS0DsZCWS8MXDoTX2gowe/ZJoLrEVnoD/gMqB1S0VqyFsG E3EshC/W0o0wdVvNBcpG+2KkR9zwEWChE2HKrbZjDEyWTdBvW0atKAfzR2IMY0f3liAR3tQSK1DT w5IWYweu9gnZZCLLuyMUn5DbUSZj1hiP9kwR2kHGYms6oP9OhkLbft92dJqSRAPs8Njg74nfQ0X7 zpTstZ4iWEObM2x6+bSnB9qaM67ET+kmpIhE3Epf+VhRbFmspozXhbO+WTrnt3BxcX6zvF5BDldX i9XSWRTOeVEo8KGoHcWUWDrKi0k4atrlCqIowS4mSPbZEQCy+P1BWF99FHcsWP6mjvR/EKHysjSJ COJORMgBW/OFSP3AIbgh0d/KEAekMtwaa3oWylRTTe4lGeiytUB/1diO2VqjKze06/na0vW72gyF wNZhZVH+wcmNZk2doHlwTRrhmvfQdhTtcVYsh2Wl70g3Yyycr+pQMgRnBZvRvlwzUWwjo59oLBpL ho2M3jRGwxlMEeeZCGgmsC40PiycWgYJczUdcY/HcaFro/uTt3TFo4hKax8tPf2LHwDKY0PLK2dE ZvLkOaylm7FQ8ZNBgTcNMeTtvVCXM5tHY5FpIDpNV6Y6A//yJFP58E+AAQD3aUcADWVuZHN0cmVh bQ1lbmRvYmoNNTggMCBvYmoNNjM3IA1lbmRvYmoNNTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCA1OCAwIFIgPj4gDXN0cmVhbQ0KSIl0VE2P2jAQvedXzNGuNsEOcT6k1R4W qNRKSJVqqYelh5CYjy0b0wSK9t93xnZY2m4PwPjrzXtvZtCfo1gkQogSdAMYqSIHfQEBsUyyopiC nkdPbGs609cnnjHTrngC37iUbMdjyUwHF54zAw1t2dbAics8nMGMF2zB44zdhVu7+hfdM7Cx546i FvaISsh4NnA5ZTDQzguhHAnlwOOC0dZm7/IDXQ74jW1ps9vCz/OIY4BwazhgbOkabd5RgEl7zwNX uOTfdZAvlZcvsyol+foDim4tdPYESFMwQ3kt9ESQXhM/dROtHZ8eHPCFq0CwRzt2Bt4uD0O9NbAf bnKLasxdOutTDEtZYgl0iyxsT8K29NhJdeJ8JaDuXmnpvLK9SWCJ39Y73POsRNuHc7OD1jjvutEi +rXdLYeg30cXiEcS1y5onSFmIEtQHnQm5E9TBsfa/ToepqPzBJ1IlQgeL3S0WM6iyRe4v58sZ5/m ICU8PDzOZ9GjjiZaC5CgN5FwLIiAFInKMRQhqgRMVZqUhcL6vEQMgOvn93DT93C9xtxrnIoi+1+K aZGkhaIMT0xRm5dYeqixjNRfipE0g55SXcci186P69LAsXcW2cYe6MS5UndY9xbs+pkQGjofgI4J 9Yd/53rnIxmJI4Nz4IDp0/O4dBfXZ0cAuwdF4KDs7JkwaIYUdgaiNLQ+t4b/2d9/j7frbzdHdsDE qmBjiyDJtS/qzZg5RZlXhIM6ttHAU2ZoZ+O5r9ghNFdQNOdx7mfw64hB2t8aEB8d7fiocSCvvBJh XGcL2NR0ch3l0Nrw76Oi8o/Mif4umhWHevCzfggAuMHjilz5LcAAk7c2Gg1lbmRzdHJlYW0NZW5k b2JqDTYwIDAgb2JqDTYyMiANZW5kb2JqDTYxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggNjAgMCBSID4+IA1zdHJlYW0NCkiJbFRNj5swEL3vrxjtyZYCAgIhOVbbtFKlSlWF eql6MPFkQ0VxZJPd7r/vzBhItM0F/PH8ZubNR/PlIcnSLMtqaA6QpUVWFdC8QgZJnpZ1vYbm48NP ZfHY6VINaKF900WhQCd5rj7pIld7nawV/NH5RjmLPcGCLtQKzGA1YQBf+IcDhJPj1YWeKoZZXkCL gnLnCTXSjeCglRO42o6n0f5Eap0PKfC6OXWT6egLmiEAHzEhLHf6VzOHXMWQszzf3Qm505USorML gTdtTx+UuMENvU5q9SYejXTuwOPNkRsmgfY3wlQzVCKqKCKIdDEWr5PtDeNJIHRfqGdwr3ojHg3P E4dAcElDMaVB9leT5BCc0Qc3GLbPDGP0cpepVMihYZpFlWIqhGxb3CsE/MtmRo9ko6TkxL2R3ZmX PYmM0IXZs3zHnlVXzzi7hOPklyxnoXo4mEG8l69cj5wryyuBHLthWYMZR9+1vL/MUAzgNQUT+cyI 8hRG4YInnWxmL8gJOTwvfN6MnRyJiZBGHQn3gRMSZGkovUGs9eMqUp+E4F49VSzWf8o96jxTrv3N RXTg7MGBU2JC0Mku3gLnx6KR/wCf2e3vOinVV5btm16TXWqiC7+jRkS4BDzKLoVG6kVKnNSMTvNN cAwMSJ119E4qY66dpz0sZWWlwkBXddyDu3g2ehvfdoqv3NyLj9sMA39btCthPnGDo0eY50TJyZta 0nPY3JbtJT4FQ8gDDwY0fuol7nSLLwyzNHtkDjBpHBI8PkS4SamahVqTUGQtMpG6UdnH6ML7/ijf 4+SeJhf8oO1WyWziIUM6/BNgAAZ+QVINZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iag02MjQgDWVu ZG9iag02MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDYyIDAgUiA+PiAN c3RyZWFtDQpIiZRT32vbQAx+918h9nSC2r07/4qhFNYkKysESmvYQ9mDY18ab65d7CRl++snyc5W WMLYg8+6k/Tpu0+n/M7zdaC1mUFewtF6Aw2+CaI0DSFfeE+qbIphGD5gpiAA9G2sFeDX/M5b5t5y Nfcu7+Hq6nI1/7wAE8L19c1i7t3k3mWeazCQbzwt8IxsdBAnZOrJyjRYY6lWaCF/8RQA5t9O4Uan cIW8TSbycRadKWGyJJilNuMSTypBP1QBL7BAf6Z+oNWq5X2BvgnVC5pI1RiqEsriVc7XvNZNvUM/ o3gSotyKQ9KeeXEkjIJigPEM3IHCnNg76J3gdLz0aOiEKtFPDmCOfqKW6McKthMNqwio6V1RUWA0 UgRh4UZMqOVXNnv+Vb8ZiAW3Dwy5QmPVvaS6om9qN+zGvo1NN5NuM52caPoBjVauH2qMVNdS34nv F0zpTrB2DbJCkXJjFLC9o0+MAUmIbiMZz3QFcewHF3AsrLredRM4RjN1IXG3zPeBJSDSIZGOKGdL arKzchvGbV0lCAV8QmtYMIph/4KTSUqjHseA3USnKNn9nT2kJvPthcxEu5XNH0V0ehwDtv5ShJrY Sf6FAL5horZsMbdy++7q6wOXFeH2A5el9lmRYLPnbXB2euL/nh4TE9/U/mN6krPTo4/TE0bpuRJh RCrYcXhSIh+yaplRHzEmHcYtLTQ3iXLltmhrjEUKOYEd7aQ7MIzjQ2K0Zd9J2E8nfhHSgQgnj45S 2oFf0Tvv2vF5y5tnDmRFK34MdsTv58tHeO07KSit7xoyaSIrgjHJEUcyljIowrCr6EH7KT+FXwIM AKC4LTYNZW5kc3RyZWFtDWVuZG9iag02NCAwIG9iag0zMjAgDWVuZG9iag02NSAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDY0IDAgUiA+PiANc3RyZWFtDQpIiXSQUWuDMBCA 3/Mr7jEHMybWGgulD7VubFAoI29jD1pTdLTaGV3Zv19itWWDPSTcHcl99516IR5nnPMFqD1M0QU4 eIKFUs5AbcgbzXV3wTnVuoYkhQyFoHUBjxgImqIXUjBl0xeQazD9+XystI2/MQgooGffdqWGc9t0 zR7f1UgUE1A4XsBZHEeh5arC8prjg222z3qjIUE5QrLfzKzV8NlXne3dGFPlR/QkvVJzN+mdxeOb Xexo3oS7STroMDqGtLLnLlC49IDB3F4zqltdd7YAX24Hui6a1kA2VP552I0dTygiqhk8oRfRVyew 3TkXKDMDf9DuT2k3N+QGA8quMqki6TYh/g6WS3+bPG9ASFit1puErBXxleJgt3kgfNB1poKzeWRD PkYLDrFkkRTW+UQoAKqPqe2PAAMA/vGB3w1lbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNjEyMzEgL0xlbmd0aDEgNDIzMjA4ID4+IA1zdHJl YW0NCkiJtFYLVJTHFf7m/3cXBLErD+Wl7malQcFgMCg+UmlhUVGRcgQXY3AXl9dWlBZF1ETRxKNd CMZHTKLUUINEPSb5sdag9dmmtaZi06ZJaxM90ZMmbdpYExvTY5W/3//v8tLtOX2kMzuzd+7MnXvn u3fu/BAABqAeMsyLapdZ/j7k3TBymoHQnWXV5VUT5myIAgamA6ZflS9eWRaVdrMQ8tzfcU1WRanL 3fna2YswLbvO8fgKMsKb3moBIgZyPLKialld6KK/3uR4LOQRyuKli1xIi1UgF8RzfLjKVVf927zg TZR/k+st1d8prV5oGGeHnPo+YP0CejEeQwz7Nq3vWwwJPo76UX9+V4XG0fpb2YgxfIQw6Yx6g7uE 4T8uwf72P5fvYjpi1RVqh/ohWuFEmLpAbVFviLPSxL7LDDWGGixQW3EOp/BjdOAwDrAH/4H92NGH bgSkFZxtwSscb0ObPreN7RXs9e0mioVH7BZLRaH4+l32VLF1slZglrAGsHcfawtWkmrEOjzGel7E YCHrZpySqrFaDtZ1+co8db9/13x9Z6CQ7dvqZtrUifOswHpav/wuLRtRjA3UtBllPbxROCi9LK2S logmFEv1aBYncF46iFvSASyR5mCXb5mxCjHSBgTTv4exBWvwFDU/hwT1Oo5x/CB+gmHIEM9wdh/1 FCJHp3b7aPEuIzwEQxALt9qMVPUCcvW6nfUQEdSw38O6FmvlFskhr5Wy77wtJ9A/hWqwoRkS646u MajEMhQaqhBiijS1qje7nHKVSKIvfqgb2UabPkENz/88dqIaTfqos+esD5O7k30ZFiNHjsA+cVHn P0+0/tsyFFaMwUTkoQSr8TSjrX+ZhGzMJ+IvBpDdhSP0+hFG1R5itYM1cLmCy2iUy5An30aamMzo TpQOiHVEo0DOQrVow0zUcZ1LrMTfxBAk4a0+OrbgcaxUr6jXpJMIZ73ASFqCn7L1Lc20fhu26mdZ Su+loiCgLSWs0zFdDGIdJUbBjVS5Vd7G2mpcjhIxApfl1w0xgUTFRfFL+ZC8X7wpfi8+QBpSGDeT pJPSz6Tj9NUtnmGW9HN6Zx2qTYdMh8TTxjqTdsfKOL8cj2AV70OroRhHpWI8IaID6TB0YKZcLY7J lwydUrno+BeIBizGU8g2xONPqJV/QQTO0ae1/7bwRuK8i97ci1dxlLehEysC8Gphx+digJjQ89/J eJzEepvnTmPttkWnmAt3MDpyeIeeYKskVcz1yfIRGInnQpHBWIB6rVvqztv63/fFXmkoasQ+/LrH vieZXQoxBwv62NzLy+aN+P+UezEIzKvkTX3cP9PND8T7sssq1qVw8DbMpL+d1LeeeOSQ0788GsCa uzlacVPWgzxRytheAj1rm46YtiPSFG4sgdnwgmGb7KHP/qF+qv75zjW1T+Gdm0JP5DFfuClbw1dg Pd+DHUTqALNpCMLEFnEAJ+9ZV9dv3ceigJlwH/frUL+0gvHqG1iE+WobuowzYOOpJ1BzG9zCzlhu ufMGUsVm6nZKZ25v6bpIJG8jjtZ9i1n/UWmADMMZ+S+0rkW39D1xDF4MYhRPlQfKl5lTjsJjnCy2 4B3TMVFOuVzcJ5rlIGIQgi+IogOZhjDSN7BCehlGKVqsoE/q0YArcguGiHnM4hek2T5nmTqJkXZ7 6pkvByMRU5klB8FF1HaJyYb3oL3BtXiB9853e7I0Kf/t2U40W/m+HeSKfCke7bxldbx1z/HMTXiJ J9K1cPfvoclwGeHiB0jAJhGFTcyqm/Ap1qmH8XpQIq5y98uYRt4aEcIay5xVzld2OCWLmGf30F/L ef+eIlpr8Czv+DxivJXtAeqeBTMtXEKMmzC5z+vfU2hBO9+EQiKcjxPMH+fwGvLlO8SqldGhGHdr q9SP+dWxkRofIVf7gnlMGHnSRmmslEV7TyJHmi7V0Za5koMWXNBO1asjaJBf0076fDUz8zN8Xbai i0g+K8oNl+gREOFbnIPKL09q6ESXH0kwW3kpo71uDbif/x7mmamUX6p98XYXgxmjdR0O7pPDL4Hf MLJbSRfznYmRz4GZXrwoT5FWUccfKZDHmXK/jl3yJb4lnYyXdXyx1lO6RnTIB8XZoHicEa/e++4G 5fpPVE0tZcwoq+lxr06fkEYbj2va8JIYSr/4tcmp0nC/tnT6Zbsw8ZV7ktFUw3u+Vf6c0TEX9VJV rw7jFL6jmo5I5pKR/G4uoIZInq2ZZ/fIn/Bm+HLKQ9TxB1I/ov+a/DoeZiaqlez8lkwWx+m5YfgQ yJg8aWL6hPFpD41LfXBsygNjkpNGj0q8/6sJI233WS0jhg+Lj4uNiR46JCoyInyw+SuDwgaGhgwI DjIZDbIkkCyilehMh92jxGQ6lWxbls1sUbJzr89OURAeZ7UNtoxLKRrjX6UYkxREzFQi8xztyEgv UkxJdy/JVeQE82dWCs+Os9gVQwJ/thyXW0nMd1ht5nfieuaLKKPEZjqs1jhFSuBvBqf4y3FZ3Io5 j3xrnI8zQ0GeQ2sd6tV0MpFuLWKf71CGdw+LigIZeZQQnu4xcxyX5AqvuT07JjNLQWQ7sq8qiNIW XU+HgilKYhLNMJPS90KKIiI/U0SEIqJm0+D+CjSx99MDIGB3e2x2dyXxdDt7Eb3uw9Nq8Vq8+Y7B 40jqJreHhmTaMktDxiSjPSSUZCgpSlW3i+yvCZ2Qsu2T2iUEhxGvcM1Cu9Y8SkaDk4Qti0BxJqJ3 pkM93dh3ChTrpiJ8lFBMmUqQrtdSqWS4FDRY2pNPexs7zChxJg1029yuBQ5FdtHGdsgJ9oq5SvzM vPlkUQmbs8KieTZL7zQ/WewVFi/H2lone1uW5t9+fHdFqVOLCOG0ZXFuQKZjo/V0nBLOf7syOEmZ xmXTVn0QJ3vt0ZUWbej1brQoLd909J21aj39HU3TvXYbtXEzu+cbGv4pPT7SA2+GW/dERoPLotSX eHxh5mrsDnWr16xk37TSFXSGhokm6AfR7fRoJntc2jHtHou3oVQ/aqN+NIamxe7J0pomyEBHAaXn O+wVNnuvQh6chJxwt6zVqsQkaYJer10z0eWm9T6TOdFrvxb+cUnin4xXbUhc6RU+c79makUmrluT Tu3OMAQJUysiYqbJMMGYQUYrJpkdVAaZ2GCtENIgQSQEEySIYyUNAUklSBC7pFNZZvNDRGxJSxcJ i80ui4T8KIuVUAIm7I+Qpl3Z2+ec+97JRDfdFR7Pe9/v95znfAzuc7xwLCWCUmIDnHjsTGuP6lIT enkZj2Rbe3pCjsUxteA9OGH+NBzM8Y7eg4WqiD/0N4zdr/tJ+6nuE60BeX1BO94de7Y/8Azt9q5i t2c/5uTqnwUcHbWfDrefdFgw6P7Lphxf1YqWx1Q1X3Zd3x9YRzsRTmRzuUQ4mMhlc2eW7Sv94aA/ nPuovT336xPZoDi5B/0rU4FC4jc9BX920PMzGJn5ljjFlkkEB884ISEeDh0OhPb1uMNdbxsmsBxc h1fl/Nu4TzkCTiCY4OixDLcPFPyH2Q9x+vvd4P4vhKfyDz5xGrsG2Dv0noMnfnVaKQUMVCThsHZS 9WKTUIj9Zmr5GPXjo3DlZLfzHaT+wD06Vh+BvbI8ct8defd9HrnijhSXZ8Owz/7209/C41IO5/aF K4PRetG5RNOzhfspvPHV4YLvsDLxO8e79YCmWlpA51ZZBPHpaKE6IgtZJwiDOX84+Gm44I8UzOPd 9wNHe4L+fYhfniIB1I5MTf+n4QcejpJU5S94jhY8P+B+QtSU0K1XH8ZgcWHwRC6rqMXPg9FEkYUn iCIfPaFW8LaOM50HOXKas17lO/9++tUnle9yT+nf2rZPdWnRIj7UHlHKGKZqoNNbQzNmmro9E5TR 8nQJSOo11Gos0gXMXcR3C+QSr8X8DLAFxIFe4D0grdCvZDfmLvNa3qOIYerzvUfDZtr+GufdMtdo EFhAe97YogUrivoV31i3ahA1o38Ga2atPN1G/zzGs+ibE+msy2BdHY+hXe6dpgOQZQz0H8Q+U+q9 If0v1GSQ/QJv4ft1ApM4owsyCXRhjh8ywf2eNYa9gPEJbuP8a+ifAtqU7MQ+4xiPY10Y3xNoB3CP MsgKIAQc0hYpqlXRKmQD3s86+at2mwYYnqi97WF5237O0M7TAHRu8D1wZp+Gyg1yHBhWspehwdAa 732dLgLDQEKQpwMMzyRNQNYAW/zWku+09A1QnlHcbxk2Z8SAJ3QNc+qAV8A8sARYQFT0mKd/4q0X lM1Zhxq/j22OsbiJKkx7SRF8Twt3wBvuY73rjdCh08f3DPFdxAYd9tfCrTwNCbapjtdbizSm0ARb /s7hzF74uFJkHqWFA0Vgzx8Df9Si9iakF3M0l0O7gXtxf0p4VAqHS3M4/6Z67x7AdxKKR28AZ/6w 5Pzvq/kuh94E+8YWXRUelYJ5xGsg+a28xx6Jt/P5/0cumAYlzTWZnxRfw/2+TbIvsj+8TfK+bD+1 L3hr/x0+c5PfC5mH/A/kCt6+Ap5l2KctjVb1afG7ZozNi3/Dx/Qxee8s5v1SyRFj2P4Yc37P39oU 1gwj1Ckbsk72SM3+ynxAH3BbbAq97pbgylXEiE6JMfBfJc8rGZV4Ap9+m+RYI/4Oqccdyd/qDhPf VUqcWlNxSmzrxCuOGbslxx/oYsvcBs9jovNr4jeie9gpBDvPi501q0vmMKdSxkVqw77nzA3cfQMx b8t+BJtsWSnE2AYii+PcS5rUbmKNsgO3OY5xvINdN1xdWk1Kf7Vot2DfTckDUyoGDwn/P6Os9hxx iPVzg+pdPWHtvPESb9/BfRGjLYNajG3wWr3PtOgU0Gc0UVp/JLGY80oA3x2cL/gc5o6+BHxCjZy7 yvK08D2c7QOffTHkhyjNMq/QNw/dsi9Puf6BN/8DPPqDy4HvaiPHF970NY417O97fEHpT53R6koj gXwI4Py50ju/Xrdn3xTHgb2+/qZv4k2/xZ4Z5WN/2s1zxecfKfnzb3jbKZX3rguQU0pyYdKNYVYz pfRN1AKb2PMyeFVLSa3KvqXyZAIcSzJfBM6+wkvPl/aO1gJuPaZWoEIfcHhsVkkuHVcAj+0piW8j Tlw0lxGfzmLPEZyTt5+8Bo0Lxhj2lhFD7o05+dezYqe1JvsmS+iCc32lcO9j+NCIvKU0N/sBQ/xr HIgh18SoCdwKAUmWooenWNdEt/i98kbcj/fGmE9PyRuT7hrvigPwMGmOU1j/AvHgzxTGfQ/hHhWe KPL9IXw3kE+bBX83ETN2w83NTm7kfFujahU3F8eRszMqJ0edeR6eOwb9FNS8ul31wnBxX/gIcA/t jGeW87jHUmOMGwD4oGnGsN5cPM85a0vl5SV1XgcQc2sN99zSO6t7y7f+GDVYHrHLT7zvF2r9h2qP FuBfbk2mzrIcaT/lMX2VDgD12gjmM6JSGy46taj9gP1Di9OSOW/ftSrtu9o1yKj9wnwF6bdfwGbT bq1pDNAH5kUqV7XmQfYN9heOLey/HIPdOtNspHMlNeYcxzapM3nOiNSgZdZ56rP80E2ULInft6lN H6UjzGeJ2YPgNPqMqw7/OB7zuH6tWENmeJ6+Az/g8XPOPP2iUxOY58DFG8iNa/h+gbUV+MaeZi2+ 66gCcX0Csb8Nb1yXs7iOgOQ+OfM51ZvleO9DOy+yAfEhTrVSF9xBHrlOfeYkNXrLoIc8Ys4ocu4I +i5g7Ag14r59Rhni1w5Zxueo9zZpDDpoM6aoFu+oNtbhPzfkzl1cK7NerW2sm4TOVkVHkvMBnfO9 7xFV+ipx1pdSCy8gFpQhXy+IfWKi51uydgg5Hnt5+3HuhuQ1qcVkzQJVKhuJ7Zz1NCdvYvtgT6sK +YTrtm26w2/yZmjBO4753YixfsyPyf06feWQa87vH2MGOTIOXfvxnrzkti6z1/6vnsddR9E3qmqU G1RtjkAOSaxrM9ISC7g+68JczmchawZ5i38D8PxWcGQItewM6uGXyLOr6KsHqqjBfAGZlvqOY60h Z1fJ2jjzgmtG1qu1Q9XWZTnPkDtwTYhzvQ+Ri2FrM477Ruwd7yx4PC15b8dYw1vnUG9N4vsIxtdJ 8150vqHTDtw1yvwVDrk5A7lZ4qSSZUco67v0Oqe45xXPZZ3XQE+XUdMv4m4ViG+Q0r4EP13CXSeJ dL+9gztKrcg2Zb2yXUW3sKm86bUkfczesWow1gF9Pce6GdRLjbBVBvkLvxGNS8ghfKdL6g4cr7co wvpX9VSgRPrYFt4UaqwkxpnjsEmJ5Hpx0pqHP6WpwpXM2+Jd1d1Q87DPTBTXsp6/oTYo5mquu0rk nrezhC8It0dVbh59bY89Ob1K1Yq7pbqPcBv8Qn8juLwMHseBBNoxYFgfombIJYvoAeb0od2gE0Ux p8GcgQ/EqQVzopC8judexbwmjD2ETAItsm+cptF3B/IC+gq8v8mcz9NDfYPuQW6grx59jwG+9zrO vK1FkH8i+N3ZiBoR9YD6rtEzODsPXQzRkMJZhX5gQPoW5fsU0KvxWXHqRDsDnFNyUM31y5wIlUMu 430d0k/QrXPGBeCI2r8bfWn3TOzbInOIssAQ2neMZvRHwOVNWgM6gCfapodz9mNgA20/5F2A0N5w +v7Hd9kHV1FdAfy83b277z2jUktBZFAxYu1goAiYCkQ6IJAEG1IhDL6EJMIzCi+GAA8DogLlS6Wh AepMFEoDtGAZKYoMAzENIEr5poAgdEBHEZxxnKrABD/y3vZ3dzcUHOsfvznn3nv23nvO/Trr1a9H noFO6K8ga6AJvgxsJl2ldwr6/9K38b7V/Ukw1pNQ6+OVDwZc8mmz0TI0lBy8l64PHZRlQV1W6FP/ W2ulzORtKDDzubs7sQd3YrNQuhorWHd0WKTL1g20Z2P3ITmsX5/j2W1mrY6zvyqI1Qvs61rWIgpd 0Ndjx3fqFVnGe9/d2ko/AaFG1ugh7z3YqmE/l/PGTApdcP8VuiCl5i43U0t1SgYhV9vdeWu6yCwt PT3GegSYk5mXptR9QhOplUJNdJSP3SwzNMz5SY3R3007r9JPBfn1DTJLPcSZ2CI1vH3eGHpsPa6G fdneKOUeq5B2nl4R6FPJ41aLbb4fivKPsh9yoRDmQAn0h+4Bo61y9oqfp+wy57DXK0IWvn4EDVDn +RyV1Xpsa5ybaWfJoDZf/x9Xx+D7XInJjxHE6xpi15bbYvn9eOo46hj+EF5cNQ0yK1xDGanjfIWG H0avwxVYi2tYSx7F2lg3kasH6Fj9GHr97Eb367a11LBPl2j0HtD9qcPcazXkoksk11gkUaOJu6hV eqtG7qs5+HCE96tAGjRmZ3LLg8yNtlB396wxyF3Pm5avMR/29vzQ0C7yrwBt+wP7Q8sc2Hn1/hBp dUXSHY0YOcoiGe0MY88MdlMe29yU2uymnBJkgvLZa9G2V8P7k1KnaWtGdkGmkLP9Pjy5Cf5IvQr6 Xw89qVuE3Ii8xR9b3Ybc6NdZ8ynXu99ZTci5MkK1o+6gmzLP+qhqeN/Hs5khv7E+QN5DudRN4d+7 xLWfsdhN+aQuUzdcJJUDY2ESFIl8Vw9v0dYbu7PG4nQPbD9H7iE+9zs/lXJkATadsb8PPrvG39lX +aPne/B/caPPV2GdsTZkW7eEbNUllAVVqovsQwryZlgHX8FLsAEuGudkLuOsMqvlefiHncdP3wPk UPRGHiyqpwj7Wsj9q1RUHlRPkwN8DW/INLsvkG+RY1ZZpySm7kbPlwkW3lp/Rz/Od4o8oRv3KLmR Cvn9ad3ay3taTfluedz6kPK73KlvU24vxbYevxl9IvJrOByUb0Pu8WxF3ezPkbnfFCLX9EmNpHwn dIVniUeLMZ23BcgHPYjvnFBLOuTNo9Lvq8037C8aG1v3Wx/Lc+QmpcznKfyspPwCfs2CBPW1yMnk mJV6Th6HJc96wS1A9lX1Ukx7lZEpR/luohnnn2KcsO7pHep55vAM41X6qAAriXw+KCP5//JipPBC zUZfAE1wFBphFDwFj8BaeMePjRcf3T4v0OcF7VpOgKchDjW0ZyMf9mPsxbkmgPbQN7IhRNx90vuI y7kAvmodAFuA1nTcm+f8YFzNXz1ZBW9AJSSgFqZBPeTDPMArN4s+kp7/+O78XO6n36XUzeMd2sz/ W144Rmy3cFY1M2UmazXTniK/0G1taJs2zAIZZvckVzzFu11D/M8gD0qeWijV9jNSobJkiOorvc0/ S7X5sswwK9CPSTX/EnusIeQLlbxvSyRGjLPZX49YyyRKPlyhCqTCzpAKa4dkm1+Rm2WyXz/lu4G8 SbSRk08kH3gZuzHWJqll/5XSb8LoKXt80nX4NpT6BPwFDlAez1n/D6ylfSkshoX4f729nRy3G/mF SCN8BLuhP3QLOA694SsYRn+mMYU7+XaZTg5SZD8lRWowd5mmHQyAjjKCNR9BHOPO7yROXKY7e7A/ Rl1LwEns3kSuCtgO3InsoyrrBLKB2LS1nQ70TUH5SFDWfRz161S3oOzIVOsi8v6gz2AsD+yYf73x N1kaapZ1xOOYUezq+EwLzvLj5gmZrgnf50OMOBnffRxqTjVcmc9++eUVH5mneZK89yT/S9+SA2XI 3db77M0B6ONlAPngOqsfPrEnGOe8+kKGh5X0CF+QHs5FuUsNk7pwJ6mOnGKND0lC/VsSdov8yu4s cc31HSSuith/a6TO2iB5jiH9nLMy205IXbQE+4HuZXWd69JHgr1Vp45Inf1bWW+VoDeLZS+hv8u0 7Zfn+OdNhDfBXklE72WOj0pd6NF0VLanmq0v/HtLtcqzaopMddZK4vqR8ixMvfGicMelOnj9MBc9 X9uk/8+ZT1zqeE/y9Ny1X/Yr6E2yXu2UJXYv97LxuSS5r5LGO7JA7ZIq7v0qznJeZAj/R/MlGS6X ZDQuSadAii3XR23innxAkhr7vGRYt9FnNf+k98kI5/f8++i2GXyvKZFkZA3l08ylM2PtRn/Nx54u s9U29JXydBvspWKrVXI1+JnU4HdxpMH/lrOQVBnoH3CftmA7Usbhcy73XC8nXwaquyTDGC93QHvj E3elmuauNJrS5Wp1eoiVYq7g9JEMe5+Pc0gyVLGMwL5cLn27JqMFfwfy9mwLPWhv4+7ZJpPQ66Ej +kw4hb4COV/r5gIpMwwp41yVQxlzG+7cLoPJEcuiY6SMu2i4ugR9AobwPo5G+hSYb7J/UpLJHT6B NzSmHqM+Cbn0hU2kVKqcJyiXcj6TxL044BjrVIzNo+gBnOcyNSZgCt/MYi7/lHj4kJTx71GlEoyV jz6WO2EU576ScgnyMcZ9izNS4b5nNLrnyHPOGe+5LWqL22J2kCzVWe61hpMTz5VC+iyMLJbCjH7k eTPSW43X3WPGDr7tL33UOM5DHWMeleG8H0UwFLJgIhTAYBgN5ZAPZcYFGWtUSzyyXOLRQ9xHD0j8 ug3M62fUvcQZ+0RixDIeeV1ikT9J7IYttGXi02fU1dF+Voqc08i0xKInpFDbhrvKrVFgn8auW4Xd Vnycw/mfL2MiL9LPJWy7MZYDjbKcsxh3wh6x8K9pr6D9Nb4h9upOWeLUE587KE9mLn+Q5axxMbGL OczTGcE33/DNAuR57poDUmSOETFfJN/YJoUac6+0Y3/GLXyL9ocL8BP8XEbcspnXk8QWP8MHmPvb 9Fklt9on6HMK4w5mnN1SFdmI3ps2PeY93K+7ZBK5S456WHKsM8QXtG6+yzs3lfwjm7ZCmCo59kL2 8H6ZxHnJ8RhFOZf6FfJf1ssHMq5sj+O/e+feO7N52cirUFHVFzUiIioqYqwIFREVVVGxKiIiIoaI GFERMaIi8qIiSsSIWhGRF3lrX0StitKtvqg1aj2rqlZVVJWotWqtqtz3+d17JpmZTpM++4aP7zm/ +zvn/M7fOScZrcb+mPJPQeu8GH7X8tQZwJ3om4B50vOmjjXYloxjU55yzi1iUnut1HJHSbrtpHXc vjJlZpjvJThPjHcYJ+UPaYr8cTDv1EkBdp3MOnWWhz5gvW3aSdpZkAz/o82cNS1QpWU5y1vwX8Tv GfoGukj3OUHeSkGSOZugfxOM/yBvnQxnWsa9RFqpkrh3l/wc+7oW7ZeW6Dvp8i5yJ12XYVfHrJG3 0LR0usOMyXfwgLHbhCbpiV7D7x22fRQCu/KzQeuhDvc2ZKQ3YENuBOUygX3YbZORyBh3onYZizzh f/uJ2F7COluIfQP9AHXQwJ4djfTwbkvhPyoJ7inn7UfcUxewJewf8bkAV0i3olta3n0Uxs5ZP0s/ rruT5CdNvOVhnNFWGSlrkFGFO0HScNog8DzUg8dO1qohvQrtsBNiV2GfRvGx0jDC2+Qp3+pJvwYv RH5E243/W2gKkQ8wQzpmfG3yXbALzaa9NmiEMVin/onPw/opjEHWaFfr3UI1NgfOQAremjjjpC9A NzQYbgP94V4Xph8ZTRtVfiphy+alc7QU1aW0mnL5Zb8zWltkT4bxWRthPwLUrv2ZLMSqDmFPBeh4 Rxrzvs+F2GNhnyxs9hW0k/y3KONvkWcPZuV7WArnVfZN31DrlMk/N/llOFvCVm1s+0c2nY+gnntF tn0z//umb7l6KrR9t1O6ea/0sJ963AXm6YX0eF38B19l/3Rwf5jg7nFKZrxLfF9mD8dkxh3jnrDq H7iz8IJ1u89a28E+in1Ev+EXx/aB8f3A+aBlKqXDq8NX/Tr571Fbnz/uvuTev4zvM+bhKeWG5IbX zX6c4IxLSSf/Nd3ee9LlUudc5wx8LI3eb9TTApc4Z1b5liQ9TX1baB8sSZc7gY4QN3vbm5AGr5m8 Q/2T+FdzxlKGs2/GmaP9ZBDXJepoJz3jviU9QD/a2TPjUsXZdSHyPGjja+82Y1IuWzGxYjGRN+gK jEMj9MP3hjq+P4eXpNPoC3gaqrUGN0O71Qq1RTQWQT3WeaN1hcgePIH7RsE6Z8j5abnbUJaHHCFj IUH6V3hX+D3gHvadmNj9Yd12ZQmf43ge1iu7YT2BKh8MJm85cId0FtW4JCTSS5sP0XKU8bWTfJ9E 11Ht9wTgI0MwafLMjczBMMzDbdPXWephDiVtfNJ5rBifXHoqj/QxzBnGjO9Kni1Hvn3FME0fFmCy sP1IxxFqszdg5WjdHa693JoZN+uveO3kc9zaLLEug3YyJdZn3hqV5Y/TqvkEttWiWM4XIptFtuK1 /vzjtZtbgzqv+evsMJ1bS28Lscbcbv+A8+UKb4MldPYj3eUdJtzTd/mvTMnlE7VbVtCrJ6mzJ6t2 Qiq9BGcjZ5MpP1tCm1Enl7cT/r+tXf/vlI3CX6hvkfhmihXfjLXL/1Og/j+N/sPov7wNWYbpYqUd jW+utFpfEm8f+Y5PKe3fCfxzStz2htws0rNG/4pfD/G2nqSMVwP9PV+o/huT/9LEOXOidvNmFTmT 0+gtqeZb2UmKfxn+FUVaQ/txtO4jDeZKIlo28GON6XwfrbdS6v9w/PfP0RPXX3vYTunvxNjGumlD d3T9HD/f/g+f/N70eVo8P9hXePecqLnx/5Ryl+g4Dh2vgFE/Y1iBLfe+v65ExuWrUnDXWYc1b9Ff N4xAWtf6cbjvKffeX4t6/rphBNLRftLAWI/DMHvzleGl4a5iD/vrsBYZ19gCRiAd+Zk06FiWwkv4 D2ErWks7tf4D2Ia7zhBxHYPXjH8cqmCaftZQ13FU0k6lv+Ud4Kv8Br9S9nJIbtxz45gbF/rcYc6p MOZc+6bePzuPf3Ze/l/9Pjb2PNh338FeqP7vSsm454h7BT7Q3il0N/g/qQnxf2fN3INNmDdo/r6p c88eYT0peWU+WgcL/I8oJq97K4D+uX/AnJb3H4fIfMnxSfi/wDvG6BdAJYnvJmw75k6XU/4PxEat bmwp0gkyWRiUgh9+lxTOn3eO+Nwl0ZvSFBmWHc2znm5CKtxPchPfr+Gy4Xrw/6tnXVaGQOO5S/6u 3nk1nWuHfLxsVeLU0Wu/l16nQXqtNWmxn/HeLEfTQH2gd6e3kUe871L4EUN0XjxFfbx5zlPitboP EtQ/F4z3hpyD06DpUya2BohDZw7rW8p9K38jPWTKJKE6KDcYsGR4A/0QMzoAY/AMGrx6ex+d9Crs K169pL1B3kMV6BVJRxOSjjz1DyL3WH//Q0z0Vf/nhqAH9H5yRu8QaL0Sa5R4dJo7TjvvzZTucX+P N2cC+p2sfVZxM9x9MsxlaO/hLVp/hLyC7uhFmYL7cErT+CeiZ6VXYT12xhqY0z25Rn5YcWzest28 CXuxV/nZaKtciL7Gd1dqWWsB7pRUOsPSxHu3374mZfxvee6u/zq2KCvuKxF3nxhT+O1KZzQpC15P 0FZtDn1nfTGgbxPJ4lNF+6edbhn04pJQ3EVJ2Avc27iP6b6mjqduPbFxxkWquM/sS4YYOijXF9uX y5FW6SR/E2btB3IRve1tShKq87QGTpt8TZ4qi5rX/21nVHa8ddmJ3pAdvedEx6U81ipOWVwc7jNq 03tNWayD/0rug3rH1fND74B6Fkduce+8BhnmTO9KGe5JfXLmi1rSW4GtAq2g3org7JZgP13WuY/+ In1aV6Db0uVuW8slNIt6IZpW+yFXS5fLkW8v/iZd3lQI35bI/4525OlumKZv2/R7W9aCMoMyoRzV Y28U1l2Q78lrrydPr+bs0UxBvDU59V4f5rXPTYZsidiXPzFuJetV2CfNsBp5F+ylfYU+9TqvuOcq A/K14S4MGR7BY29RLirUd97ZZE0a3CqJK/g8dAasVEBWrh0yIBnQN+Qe/vWGNmfTjjubVieMkd/B J2UI2y2XKS8lU7FnMkW6jXQb9onwuxULkW9CrJnIkvwnH2fAtp0BP09lADbo77hCuh2aocm9KHGv hXZCnx5Q/z3qbTvUcmtUY9L+K3ruG77PYa/wn7MiLaSTlBuDM5CFK4Y16DCE/czSp6x1LtSP+Nno JmyU+H4Grpfwf/+J+o75ZnUcU6aovJUIOWxvBAaxXTD1/Jf9qo+Mc0vj553PV11XRelWrbtXXd2I qoiIGBEiG2N2jDE7xhgxxoiIEBERERERIyoqIkpVRURURFVERFVEuO7WVW1UVVXFVVVrlbjq6q66 qru/55zfyXuafmy7l+1du3/8POec93mf73POc+4DO1xz5fZxLQN6A2g+pF/mE5E7uDvvqD8Sf3JQ B/whcserI36H+WPSv4H+xkB43kKbI+/3/Ifzg/+tXCujDPwZ8yORB/DpgbpHasf3YupNYE3yv/Lr RqgPOAu0ADHgDPA1UAKagA5feRngHNBGdL0H45/fn/9eRHb/8cwgdBR74Ma/ngu1Y/e7y/cp3w/j MP+vFW58vCrnVYO3+D5h/WN1u2O8RQ5wEOOdgE/nbcex9xD9RXHAearuvqk/0oTx2sfBmzF4a75M XDc46LmPE+sGB7IO8aka8TMxRsw6cG1Z/zh7BdpndQhc198+5O/593y77qAeZ/k09uco6ALwUPZq 7JxKowdKo5fdA5LoI+YCeJdBd6PfqjMaj9ErELETnh9fUy1AKl5T1+K1UAY0LxSyG+VOBB0GypEr qju8phrRXyfRl2wIxVthELI3Y7tqLtqrljAW3poAb525DwE845aXuAxcA7ai+14T3jC7xHi0Fbr3 0Q99qbrRD52NjKPf31QZjFPwIxk/odfz/hW8txpUp9DYoKrGflIJ9P6p6LzCfaCuAgXcCwmOFzC+ 8L51vAN6ILsnil4IsnoOz2NP1HC4infWNvQog3BN7RGJ+G01HF9XGU0fqi9iWXU+llNtsTz6tGnd 39ViD9VYPIU37Ch8EDqHPNyG/CPo+27ijXtCVWLHEft5vOn60eeeRMyPYb0O1Mdb7AX6tX70Hmn0 cIvwc0YlYinUQgY8ghzeNUXMS4gV6gM2tMe2YLuMryJG58CzAt1V+PVCJaK30DO/huwcUMAbaA58 zTrPMk+K3uiqase7sys6gvfUgmqILWB9GshqlPC9NTqpOhDzRLSGSzwFn9N4025CXx45T6rm2CuV h29nNeqILpXyTqpEqEUlwjngFOILRIsqo7GnNiIl9GMl1RpPwo4CfDqGPXBMKfia/ByIn8Z+eqUe xXtUJ+jLeBG29SPnA2pVgDdtEr6mYkt4g6K31iio+/Eh1OmwKoTx9oofRQzXwbOOmDxXEwLELi2I vYaPr7WfX8XnEaMGxHBftYDWx0+qnfi2GgG9JTmEHtF9Nf4deIvYC0op4FtgHX3TEOgu6voEgP5K PfJVZAN0GTQE2gs6Zngi0jfNgT7lP1XgtK+iit/xTc1i3gj6GvMl0JdAFuMk/xkGve6rMHhDoKEj WGsFxXdvzPRmwuNJr/EXALqiEfwPeWqN+/A8+KWPuwT0ACh5b8/YriYw/hGYxPivoNvGRukL9Rz9 orx9dA94D7giZyZwm/bVE2nMvzc9pYI8dcvEzFvlv8+MH3r9giPrhVn35J31GBTxUz8bWfbdpfvU jOH3vvDNWb0J7Bt/1TXgO+AVddwHLgI1kw/Jm4b49MTkStsWogzE3Dti4ic5Et+8ReAYMGP80TFB HNUq9YvvSfrwE+Xv02boj6LXjiKfEcQ6vG9ypnGJuneoV+SgHrwa/ZPauUn/NunHPPB3YJE+1RjH FfpeY56XaZ/UzIb5LvHSMZP/x7m+SH0Sq7vUAYRQ66HLlLHIPE4zNpKzioHORxP3QDPW9ihrxMGc A9SResBY/UC7lsyaJ/sJOr0rjKusid+ThserA26b/WHvFJ3nPQNd04MYb9OPVa6nDH+owcDrYD1j r3lnGL9d2o+xd9TkQ2IkeyP0JeewyTvlm31yz/x/ICdDnpemdvX+W+X6UyPTyzPfWZNPzze+aHs2 mONxrj8z8JZZb6e5xxt5djR+ADcI7kcdnyfc148Z28fmnJDcy7rXjtosw1fsnTBqJIT/Q/1Yh68h 8eMuawY8qs/EQM+lzmQvDDC/F5hz7JWw+KTMueFCziIduzXH5lMO9hzbn5q69L7i2p7pL6QODyBn 6HPYeZT7dY/7SJm9q3M7YuroAP0Bwqi7EM6D8I7xWe+ZImtceLvpW8mpqyxjIfu+DcjQ9/91tP0f /xbk7pP9L3eHPY/lXpQ7RM5DqbmKg89t7y+BnNGyr2QPoQfRe0ruZrlvZB+NOn6OvgN970CGMmTc SZSpS6jcLTmOBXL/V4lB86+cgQLNOwGkD2GY9j4i5C4e8IN7LvsB5N6DIcpMczxC3RP8b8bBGHmF h3eengvkTpTeY5njT62nD6H6Dsi5Os2YS+8xRdlpxrOV9kpffI36lvmf6F8ippjTSYfvCiG8W4Ss y/ki53OJvOu04ZUf9HVy58xR7lXGbYr3zeo75pe5Jj3JLG0Zogwb923asE2Z24ztNvmkf1ugTRuO DVu0eYNUbF3zg76tl3ZOcL5lcuR1MZYSL/YTujdZZg+xSZmzju5Z6pdeRu7jvv9ADbwLJeIlbbnH GG8T+05ubnNN7JZ9NE/b1/jvEu28SB4bu0v0+TzzI/nqZ8wlf7v8JjV1jrJknOE6ZISBkJwROI+8 48Ar9sbztI19sK4tqeP7xoZQ1vShWt8lxnCFVPKIt4v32uRb953nKOc57V/jf/KGHGQMatQ7zHxK ndh9fp25ztJ+saXXwIP93veMod0vk5zLWXDT9OVap7x1pPeWnu0uZW/x2zjzgph6DbQhy1guMq8T tHuS67L2A/3rpf4Zrs/QpxX6kTK+hnDeeRXaJjbOUvc4c3aL/tr9Mc8aKDC+U35w1s4zB1OMV80P 3kSX/ODNZ/M/R1/l3ybHlxWOB5zYv2Scc7R/g/oS5CtR96BZD0nddDAncrd0MQ4VyivSh7P81957 4ncn5dh77xvy2LtS7qNmxrhMPbK3hyh3iHJExjC/DVJ/2aEZP7jzFqhDYtHCschtpO156uW9qH2t knbT5lbqH6WMTvKe9YN7spWyevivHXf7wf3XxXjkGd8eyqlw3Ef7S1wf4j8FP7jvs4xzN3W2kfY6 8trI18782zu9g/J6nbzYs2KS8lPUV2AuJhiPLicmOdpf9IMz0J6J3Q7a/aBXKdAGy5Pnt4rjY448 ScbYnsU52jHCtTTzW2S8viZfht9KtN3KL9Jfm988+Wx9W9uFV86EQceOAX4rkPeMb2pA9mIjZZZo R5GyvyGdou1Vxr6D651+8CZLEVkn7kVnbGOXcXy054ztD7K0peLoOUZea0sH7U6TtjDuJQdlyqpS fo8f1HGa8e/zg3Op37E3SV/r+U+B41bSASfHgjHO7dli4+72kRXa0U7eJv5boj6x054zHbSjiWjm tybyyvfTnBc4tr1zgXk9RT8r9KGLMUnR7y7SvBP3LMe2Lu16hx/sf7FrkrTX+U++/5ZoYYx6mbcy 7Rqk/fX+wd2iZV7kep68thYS5BP/26i3w8lnO/lP+EEdlpiPMT84gyq0sZ/jDPW1+UHfmyCPPbOq 9MO+O+xZ101fppm/FGV2OnLT5LWxbyeGKGvCsS1NmSX6VOa3HO0qMdaCVkdOhTG2eu05lHP4S7TV 7rUB6qvjN1tvefra4Ad3Vg/1WPvlbhhlzEqHkHJiY89qq0/WxhnfBHMgtMl/c5/aM8PWrD3jC/Tb vR/cPd/mv7n3M4xBB3Ph1pXde1na0Mr42T1o1yt+cGeUyXPK8dPeQWX6UeQ8R3+TlGHzXfWD+nNj niHPkJPHScZtivae94O6yjpyBknF90babe8UiUk9Ye+5IqmNYcWx859cl39E5V0ex/e263k+nj/W Wsv+sR7rscZYY63HyhgjkUeSJEmSXEmuxHXluq4kSZJkJEOSJBnjGleSjCuJZDwykiRjjCRJhowx xhhjrb3v+3195px5/jjO93vO58f78+N8zud4vjZHOlqj2GYt5EUzeJot1ESPXXsk22u63xNDFvqi Rgt573dZW8Sbw2/qAwejeHgvMMi3/P0Ddnid6EVOp4X7qYnZbWrAX55D/lby81+CX/2Wv10WWVOf O2OhD/S7z99u+lYfvY28SXAUsaHRwjlosHAevOfqAVcObA8SDCm9T/4AhjFsfoLOCexTf666pHdb xULP4Pk0aaH39rzOwCP/691aSNb0pkr9KdFX+5Zv1Yu/Qd4w765+7H0PXdVXqV72hFM9ufJf76Y8 /pe+d/ikERuE4ynfy/Cu4LNZ9MgXL4lPdb9um70Z/OL9rvdCI+hqx+YccSsyhqHxnqkx2ptize+T AvEcQdYg/uuCroCeMQv9judxzr7tB5qQ6e+AnyzcBYr542h4r3rHQn/po4XZe+E5sE0wj6LvuhqP 6jlJfUce1VXHXfx8hd9P4NlI6OregmmQuE/ji1Uw+7v3MWsLFmqX9Pp9dGDJuZNfnlmS68r7CvYX wK+3nN6Myv0j1meJRQ49RXQXwDoPpntgWAJnP/HzHi3HvnA9Apfjn7BwDuXPdbA+QJcw6Jy95vsj Np5DLxwr8EnuNryrYJOsDHSX7Pu9cIpeYVFOz7AnTIvY4bXe+3mvzfNRHEaI45KFO3AUujl07ePv HD7wXrEJe64t1OE29Hr/Jiw/40s/W33seb+oscO/n4txZuFoJn49+DGNDX5feo0tWujNZtHpfesi tmbZm8SGKfwsDC/h/Y+FPlDyfiSOa/hE+fc/S3LpOTKL6BshpqcWes48WA/s2/5xEJteQT9gIV8V 62nkrkZ7/l4bYq0LfxeJ76yFOuV9ocdlDF757gHzMli8v/Z604fv7iMnB3bRKt/2iFEJ+5RLZfu2 L/H6OBX9+5tpjrFk4X4btVBPvR4vM/cFXbW7ZS+Jl2pT7ftFUntqd8YtNLuW5GY8jqvjbULzu63v P9buaNU4q46/Wu0uqt1H4teduMH6bhLX1J/ZU7yu2FtIaGvriqXuuRv8m8Ze5U8lyg+dI+XgDrFQ PPfxVYnYx/fOHHtFYlgdvxffIj6UL0bJlY5Ev7DV8Cn2F4mP6qp8dUfIPgOj+HRvq7+csHC3DbKn utuILsmuh66KOfV3S3K1C5ktFnpRrwEdzBr+hvScFH0vORT3+Xn21DvfR3cfmDLQpfkuWLiv9H/H vu15lVs6Z/8E5x3Wvbf+dyTP31C13u77xpru9+D5FV36Vs1W/s+yPk78O5Df8HXUfe3D9+Fbxldt 6PL6UfPR9yc1XPrP8N1D7LVfve9TP+Ejz627Ft523Pm1XNCdqTxaY6hmfUK28lN5qFw9ZGj/Hdge oVfnqYKcK+iqPKk/Qqu8+4slZ9DlnDALm+6+F/x3JnakVBOVex8s9HULyJIPH7NfHak2vl/i51OG bD/AD1kw6oyuYp8w6J69Js6i3WTewfeSe4TsfuQfgPcx9r/Ehn1suMBuyX/O/jx5cJjQphSHLUvO 5Qti/Ahsfv+8QM4Vs3Qfs3/EWEfvDnrK+O6KcQyfxmWE/4h4PI9iIjkd4Pdxzt55kF/zyQn+9H3h uEXGDf54xd4v8Byw/wW9Z/CoP3zD//NonGPrFbjW0am9XGTXDrz7/B8Rx5MI53u+5Wflxjj2eO9V YZ7C76qvLeDfAZ/L+cjYRlfZQu9VhH6H/4/oe2Uhh96xf47ME3SfI2sp8teGhZz2GIh+i7VD1vaw +RRM/tY5Bod4l8E5gQ8/IWcevU+J+ZGF+2kNn+jcfMBf0jmJ3nPkH6J7H9otcB5EY9pCDr5jHEPr eb2NDPnjGrk3zMLYi3znfwneEvqb4fOzMoovdy2c6wvWNvF1fD6eIHOJsQVtt4XcusU/pQjnDbjX 8OMlfDfoLjN7H7eHvDK4VA+U48r1FfYvwCga1bKPxK2M3Bz2iEd1/L/oVM6ssvYMeaJrwb8HyH7G up+hCuMz+G+J8z5+KIFnM/LfLTZtWqhDPnaR9xYMl+iWbefs55lL+HETjLvgG0bXNXavg3cXeTv2 bU49xf519jbBt2qhhr5hDIPvkrtqHXph1VlRHciAJ4vv3Uce/11o98Exzb7wPmGtAq1kDVo4j/us b2NbHrlb8L1mPo988AH6FWytWKjnr5BzBZ2fO2H03BnAr0fI89wU1mYLOeF1do//SXD522aB2d8h z/BdkW/VyUNwlCzcD1tg/xzRlfg+RlcGusUIi2SP8S+/eB2sEFfZcIGep8hastBbnML7FLteI3MH nPeRpf819j3fdvCj54f4lU837Pl5PcKPfi4q0L0hJiV4NqC5ZP+Cda/nfhf4OdjAH34/VbBtD0zT yC6h3+u4/z+BrgPbKqx9gVbfZ8zKzyG+43N4hj/8zuQ9UcPm98cxvngNj+emx8H7oVsL9Xgd3mdg mWb2GnJk4Q5ehm8XGj97ZWw9s1B3rqAps6aeXrmofH2EL1rhL0V+8RgfgnUX/D3445SYqV4r19P4 oAS9aP2svMYfK8hZsHDWvP+T3QW+r9g/BOcuOkeIewa82xbupjVkLCV9sd6ougdq8+fku9aLW/Im SP3A+gXxv+Rf41P4Tv2NeF4RJ/Xd31mtltf2vqDjIortFwv3wW00XI/3sxrX8B1H/ycW+o439vU9 Wlt/Z+EcXbHmZ0Z73pNd878H7jMLfYJ8pX5AOaW7c5x/xU11Tf2+8r/bwttWY5H4K2fyxCHPEJ96 kjFmf2PqrThBPDV3wteLLI0h/lWT9W6b5l9D+ar8ykI7gAxhUQ9Z+M14YEmf3cP/MN9drLfwPYGs NNimGQPMY+DPgCkPbRa/jCJ3DP9p7gPbAPR9jDw26i2jvF2I/LaBb5vxu/A18C998+hqIBY+u/+H 4RtlzPKfAd8gs5/RbrC0oSODHxuhzWLvAHvyVROz+7ETGV0MtzsDBrfX9WtMgjuHjl+JTxq+NH6f hDfN8H7Q81T6WuEZgXYc/SPo74KnB7sasecf1VEPfwc4+tnz/yZGfeQvt6cF2j72+sAxwV4/vAWw tDLSxKmbeRY5oi+zlrWQM2PR9xz2FODvxUcZ9rMW8ryIXmFfYR6KfD5lIVdaiLPkzIAnhx9bwNCO PZ7/M6z3gGMaW3rA1gGGYQv5OUb8+5HvOD1enZHOPmg8jzw3p/DhA/j9zsoy59Gfi2h7WeuCrgt9 A8x+dibAk0PnFN9eAwfR5/Htx/9eX36JYtcLb561rIVzJCzNyPP6NIy8DjANR7zD2DuJD9MWzrDX FMm+a6HOuC/bkan5IXq9nkmun4dO8LRCN8i+15d2C2decW5idjskryHyyxhzG3KG4XG70vhX3/X4 vtVCPul/nX+PvXCOW6jb7RbqlMd50kJ9akTmKHrHoW1hfYi4yd77yGgnPl7XFZ8FviXvFJ3L6HF7 l8DcHekbtVCHND+2UKtGwDLBt79L5NM7+NLrZo5474Alh3/HkFGOfDCHbQfgS2Pjz5bc6eoX+rBZ vcGPlpzlGXAuoOtf2LJBnLROT1XjLUe4VF828dUMNvl9XoT+Ifv3wC26RxbOht8ZnlujFmrMhIU+ 4t5vYij7vL63YusANA0W6tFD8NYTr3lmz6NeCzlRj8xOC2eyCXmdFmrAEHL9nu/GD1PEX7GYxE7R qMeajvbdrklsXYhwqp9uRL9sHEffCvz6zhMP2TqIvIKFXsix90U0M8TE12eQXbBQB9PEoRc+z1W/ w7xOFuGd+j/X5RsZd57HcVPHfR7co3OsfXDWOmvVqaiqiIgQMWKMUWOMMSLGiDHCGBFRI0ZERERE RIiqiKiIqFNVVREVaq2qE7VWrahVtdY6qg/68Kxz85l5vffzTR98/b6/7/fz/fz/y1kDuI5FDyT8 6lWOgO1Y9FYtvjsWPdQCeFXH8thMOXUCfS9b9E/rFjXlrkVfovwmOhsWfU0B2Y+wQwGcNYsc2MaW aY3fwK6rnFfh29dD7pQ/V6C/Cg/erx5Ct/PZ+Z5FvzvCO5ctm+hZ/VA+0ZP2Lu8Jcq5AYxld7Frk XNV5+d46cq6BS7qVLtRT3+FuD1xabo8K8s6guw3wqadXf7YJLvWehURP6u9X4akMvg6wVXC30bH6 qAara1Gz0x5CtV51ds4iHjRjqO6rRpXBkbXoD9sWfd+WRdz4d9vCd1X3itxJDw2+6kNW0FMDmM9n GOFdtMinioHFBJ9iaQm6iv89i5zotCYt+rF55FacaT7YsIj7Nkt9bTmhrfqi3rwCH6qV8xb9r/rm gkXu+gZela/LFr3mLrjU669bxGOTr3zBaZzY1TlSNSzHueJdvYj0WMVWeYt6q55wzKJ/2AJGOV06 zHFXgpemxWzrsZKFhuaHRYt6k09kn4Kfae4LdrU2FbBTFv7VpxS5H7Po/WQX9UpZ+FQsqVfQrFWw 6L0Uk/LVEu/Vl2XhuZrQ20xwSv9Fi5rscg1bzHjSj/q4JjjqFjNbmkvq2L8EXc2B6n9fWd9fMt/3 vi+wxz3g/V8zbYfzJXDeBK/X7OvIoP68DexjC58TfeUrxW8J/MR15m8WOaMEjVVg1MfsIIPr5NQG va771Dtwb3PmsN4L7PNGM8BdZNDdpQ16MtfJj+C9z5tLVsmid3TcexZz7jNs4mfnyPIDunU9POH9 GXx3uHO7ee18+Off+7RV+55AXzZyGzxFNt8fo+sKMKrTbfC10FsNG7iO3G/cN72H7fJ2JaHh7y+g +xB9+vtd8K9Z9CDq4WSjKfC14KEMjSOL+HV+T8DxMLG/+jjZbQMc2+jipQ187cCiT/I1iy0uLPq3 Lvsq+FUDquhaNlPfsoPd59DBBGs2weW0PvbWexv4YMUinkrIqpxxAh8T0NxGN9VkCUfDoidSPlR8 KDf6OgT/Fv/q9xct+mTX1whL9XcV/c7y/oZFfzmJbf0/z36NVbeoSXXWlMWsKP16zhyy8D/NkM77 KG+GLOJeeW8R/l8gWy9mM1/2vv+Djw2LHvoFy+k+xga/sdyPe36d8TrofvbGBnPbb3xfAu+x6TH9 yQZxvASuFd7sw6Pnv9fYxHXYi+PMX20Qi9L5h97ZV/yfQeMdNI/YO+1XFv32EbZzft1vjuHnR96/ Qu4n8HLOV33llEX+UC+hvrPHb+ZbdPUWfGfc/YKN3g50n3G/uuD/NbK94b+F7D/D1w7vL9CZ6v29 gQ37NBXTD+DXY+sEfZ+jL89ZHrcV+Mbeff5c7jz3mtPu8L+OvRzXT5yvQ2sL3Z4jx19s4Ktn6GmL 9Qg9PQfnKjy+4/yA/Sn8b4FTfe0MOvL9ZGKPU3R2Buw7+FSv9gC9ua5Gge3gF137I7Yzf7KBH14m eC6h5bqf4+xnlttPPraErt8NbNv/VoDzuuO+4rlgGvkv4Us1Icfeec7y/t+99R904z7wkPfK2bfh bQmcTWx2Cc5L+HbbeNwdYzvp+xic+xZz2wFnP/HG/eEQ2x8M7NuX7wF4nK9fbeA7ro9Nzh3nMvZT 7pSf1dG16msTm/i3yP7YIm6nEx0/x4aO/ybfPHg/Ar8PHqdftvCVDXR3AT6HUWy+4Fu16C+UF12u D/DhtO9b9HxO2/1qDj353mPD/VpznfLnOTK5X7vfeR2vwGMhgTm0iHHl/O+BO0lWfvA+U0pg5+Hh BjR8/Re68wM7Z1T3nsLLCravBc6+3/VWZpb82sG2Q+hvEv79/osBjkwFvvZYu/D1Hj6+Q+/yLeXk Vb4eJ6fYpAk/p6xP6MDvVCO8R/479372y8BGmSL436PTGvbzWvosuXP4Xy3mzjYwR+D0vfvhS878 reeHF/z7eg7se2zm8A/AXUAP/u4RS/noKTBO81+8XQaP+jf3s7cWPdN99KT8Ng/ONyy34yE8ua12 4OcZ+ncffQ1tr48fwbEOzHNkO+b8AhyPsf8+cA6zhC1arA8W/Znmv7sDe/TznseqelTNYn6n2db9 8ZZFz3ebd8MWc1iR+1vg8v0C+rqZnJfZ1y3iZ9Ri9qomsG2L2bXEeToblZBJM6X6w9vAauachUfH OQ5cE17y8O61X7NnkXfjvFH859mXE31NcH4HXamPdpivLfq8HPjy0NHcN8t5LrHFGDrx/Q3ea2ZQ XptKdD4NjOaLWXipcF4B/wO+NWzTtehZt8HjvuMx7z7lvub5SrlTKz+Qq99Lekx84o3jPGA5bq8f 7rdrnHk+W2a5v65YzDSK4V3ONhLYOjxrFlKf6HceM/ctZtN9+FgBn9YC7xbZH/FO/c8ZtJ3XTXS5 B5xirneeKUPXff93+OxCr8G7MVaR1ebL/HGtin7zwPv/pMWM4va6ji1rFj2s5ll6kkwLO9+1mFv8 fYEzp6m+w++yvJ2E5gL7PLTbFr7cHdDo+2k6j00hp/xmAXjNfjnodhLZFrifBzb/Gc4yb6Ys4qXI mxl0nUvuahZ5eJylueu2hX+3knun6/46YlFHeziuNdBZCR3P8G3yrfH2Bvwrx1SALfN+xiLXzEJj K4HpWMyuC+ApBh9/6NPlXIJ3hx9LbKgc5DBDyFsHRrrRvpbw6HIUoDPPe+lvBj5kJ/EzBw7nswv/ U5xXkVF5p4t+HH7UoleR7toWfivfaVjEv2i2kXsC3C3oFoAvJHor8K4AL/5mlaXcvJLw6Pqa5F/+ ru88co0C5/oehh/F1hB8ay9dlMExxfkWMFXeDyH3EvxO8y4H/XFk6Fjk8hnOHG6Ed7JNm7VkkT80 DzYTPhroQfVLNFoW80newqcVh9PoqYkcm3zV58h35W/jFrVS/lZhfWGRu0ucjVr4xBx7/95gzVrM B3PwKH8YTd5ULHKXZhbFi+qG8/JPdJ3lX/afQ0bXy7cJ/3PwPJzQk39m4UV5fpz7WfSpPlWxVrSI oRp2WYC3Oxb5cSqxoeyXt+hNrkNryKKeS8/q05T/lTMdv/KI+Ogg0whLOlCP10Gnql+zwKzZ1d5o Hhpj7BWPY9AZ4X/XIj41M4yj73yi5zp8iif1hYrxRWRZYD8NzyPQnLOIh2pik2ULf5oAl+qp6loB eo1EjoZFnVNuLkGjxr90XEI25/8r9Fuw6BXlO9ct4l501BMoTieQSX1DGXpVi7ynGlqHhmq24l1x OgHdHLI4ve0+r9f6uOY5q6LLSYv4L7Pq4JQ9Zyx6ghyy3Uq+ipd8gkN5fAieVKv/AXwn0YN0r35V dS9rkftV/8XDlEX+LyRyKwdNW/iS8gX9a/9sFJ6ET/npG7vqIy0LX1KPVwdnF15vcbeU0MlbxKZo yi/0X7WYfZSr1PvVLGKnnpxpDhsGdiLBOcq55ogyd7LLHQv/yvLf4Xtqg77XY957ffcNr6nrwDeQ 15f70yP43oYHn0t/4P0x516HD5BjE53JNpPYXvPNGv9tdKHYVp3QTOn7m7xxnrbQvfJDkzfPOFNP WYafLnCFZDkPaW7syXbta+RvoY919tPwuA4PRxa1tWtXc2rLIsdNJHbc4ayF3eQ/ZexWtYh35eIG sqlf2Ezs4uvQIobryfmKhf/rX3VIc6nqu2pGGVnK0FxArhqwxeSNemDNlOPosYkMZYveNYe+3a7D yOa6PMe2ymWK9yp49K8+usFb+YDqgvzTz/cseol6cjcH74q7VqIb6Vq97R78L3G3YlG/XQf3oOWw a8D5+y1kd/htu9p/j2Pj7v+5Lt/IuNMtjm+u++K8uO6r5brui6qqioiKGhE1hhhjxIiIERExxhgx whgjItaIiIiIqqil1lqrqupaq1atqto3q1ZVVVVda9WquqqWWtd1rX1xX9zf6Xy+95z0xeP5/Z4/ 5znne/7b6XygPLoLJqp1VLe4fHWL2FflPfV4I+4NwUjyydal8wX2R4wbFn6nfLttUU90WFNPNLLI tUdJn37+AnSEmdu1x5kSa+JfNbBi6Ih99S+yOcXU9cRvttNFaC2xrl5RfZ1yhu4qx8iP9qClGrtu 4bPCTbFnyJ1jG8eFL3i3hW4O0/4xb2tW7VgBky7Y+b3rFjl1ljvK7Rqy+Q1o6Q2XsQwWA9YuQqeP nDqrfLxlkdtaiY78uMPaTQvf20NPqoua8K16RbVe/lfc8/vKa6p31i38d9ki3quOVSxoWdQrvvYV 76p30nvT7B9a1OGOy0riq4F+FB+UC1sWdb3e8/9t+Gpb2ITqU9+rJj3tcka9h2TytTrn25wXL+o/ Vdd3edexOuLcdfQlmz+2qEkUc2rwNGdRt81b1EbLFjlWPvgwvSV9qB7tp9FLepfv+PqsRYxfgd82 +0Pelv2P4Gsr8bFm4Z/yr08s6r6NpF/55laSvw2+XYvYqLfV98q2VN9tgVfbou/yc8pX6gFVbw6h O7TIv+KlB23VmtV0R7Irlqhu6VvYkmqyTdbkG41EfxveRUM22uNcOeG0aeHfffTaQzb1DiMLG1DM qfDtmA+QV3WiamD53zHnlcuU1+VHTYtcNbDTdV4PPKYtYojqjyH8DhM95TTPk/MWuVO+4/NfbRxL q+n9evqXjSxCfx1aztss/+vw0LXo6a6D5+estS16pFV48v8cD1TH1Div99fRk/SiOt91u4ucijmq 244T/qp7aryh2lJ1tPxPMVk2WWFvwPo+99WbqfdQrJIu/O4k+Oxa5FbFSael/LIFFq7PEuck32L6 3rSofRXbhV0V3oSp4rzeLXH2Bus7nG+CyQPwusa5F8X4xsb5WbFYvdYv9tGE2bh3uMubA/hz/881 SAMZFSMU7xVbV7grufaZneY5MHIa/yjG99BUnHcahxb+JT0fWdSe9bTnWDxhTTFGNdKIN1T/7TAv MDfBQjT3LXokxY1NsGqjH+W8BfC/nP7F1yr0FY/2LPLuMdipTmlZ9BEt7jmW7l+3wc17xA2LPNKA 9hML262xrhi+wLfz8pNFLlFPt5HeHfDOCffkT/Ljg0R/KQ31HHUL3znPump1xe2GnfZXxaoK7ziv 9+D9tb2304k3xfx1MZ8pxsl47f2ZexZ974Dhtn4HDP9ZjGfF+N3GNu/2/BCsHljk+O9sHM/8/Mti vLHoh9xuXhXj72D0FryvjLGZqLL2Cr5e8dYLdHcTHp6hvwP0d8RaF/277/xQjG+L8e9i/LcYT4vx HLw24PFXZuflnb33149+Y/8K9E/Q9W9j3N7LUOUNx/Q/YKQc41j0keMt2L8Fz5/h4Tl0HPNPofMZ eGnsjueJvxTzo2LcR4YDZL3F/D33nab6BcepzJ3XyPIc3J2/x7xdhvZrZHzOv/O/w/9L9nfQgevy X0ne19D9EZn8/buMl/BwAHb34e0+723Dx+/Q/gY9PGR2Xvc4s8BbP/P/mHeF40uwdkzc5l6Bqe+7 TbaY5aOP4PU1+vE6/4i7PbB+yv03af8ZdN7B7w5vvYMfn5/A0zPeuMddp+e+qljzQ8L3F/T3xqIP 8rmOjifBy3G8DUZO/wX7zucd/h9By31wAD8PGM67+8Wv6KHD3OX8Y94odD9R6HeiwGvCY5vync+7 YPu1RZ2xOuZv4o82joVXWR9Z1DNOex9+L4Kf6rVD1lSzKt9uWuQw5RnV4VV4d/xVX37KfcV8v3fF olfbha7j8iXjELz8jNvJ5xb17CG4b1nUXBpH3FMdO0C/naRj1Vmqr3p8Vy1q71X4qnLez7jPLEPP xzxy1fhXvee0NuCtm966Zqdr6h6jyz2X02vjKdaF+XL6Vl9UgYZ6SfHUBWflrp5FP1SxqDOuQUd1 gPLXjkWOFn+qPz7kRzV5h1GGB9VKF9PeDLyKp4pFXzrJ2gXubPPOmYSd+i/V39Jbj7Pt9C+e1SOo fvyzRf0vmdXvfni3lnQo2srrywm3Dpg5zSrfyvnqQUW3AS8l/heYNxLuHYt8qL4r83aAvKsWdtfg fDXdH7Lmb8wy1BeoHlb9dgk+3e7OoY9zrE+lMc+YhF9/131wH92O+N636LeWmLdYU28o+5xPOqgm 3cwx97mnWT2C9LGIjOcY2lN/pNpNddzATtd26hPLiXf5bxXehH0F3PqJ50U7HX82Em9aa8Cj+/b5 hLGfK7F3ieF6mkl67XCmaVFzN+HtgkX8kD8o1tXhdQHsJYP4F5/zFr1RFxmbyKYeTb6i8zWL/tHX pixi6wK0Rb9sEXP2WVO8kt+2LPwsy9lOcq2A+TJvrCX6TfietfCpFnhWLXxgALb+f9HCLmag0+Fd t23PWZehLeyq8NGBnmKTYmeHb8djm3eaFj3DhkW8lg8IW+XTNYt8Og9fmtXX+LlpC5+uJzlzXlOs a/FdQneVNMRvjvN7FjbUA4cG33X2Fj6QWVhplh01LXqx8/AzxXfVIobNsqZ5JZ35ON2d43uBvQpy yRcv8H2euZT+ywn3MqOavtXTOV7K601kLicZ6tBQrleskv0pDq/Z6VijHKGY0+WusDoPf1U7bVeb 6X4DvmYs/FB2o7y1BB+SW3Y++4H8FXShPtZ1d5Zzc2kWTtXE74xFPKymuWFho35vkO7PpPWZRF+x ZxFMS9AWTo73VdZqSccuY5/1RsJQMXVokbOyDny+mDBSPTHDkJ8sJ3n93CUL31u2yB91aHT5rrH+ N8YSs/Kof0/ylnS6yDuX4asETeFeS/TKYNdP69MJh0bCbzHp12muo6tR4mcp0ZRfzzFK6a5m8Scd lC3qiWzjysFL7Dct7E64/Yl3pGfhXLLwBQ35/TRyKxcpfvhQPMo6z76uvFq38KEp+KtY+G8tfSu2 KO9obyGtrab7sxZx9WySTdi2kp5Eb96i71qw8AXVsH2LeDDDPJ1orSb8lI/dls5YxOESa7qjPkJ+ Kf4a6VtyTfM/xb0V5FSfMJv0JHzlN032LyNrLZ2tW+QMrU1D/ww0lhmLnL/EvAytetKPfGndIsb4 +o/wLtuV3mSjHXSgOkK9kup9f0N2qtpbtY3i7kq6s2QRF5TD5eteX0wip+QWNuJr3qLOL7Ne4Xsp 0b/A8PNnkV1YrcNzByxlz4oVwk55oMId3c8xv2WRWxSXs28qHrrNKg6KlxFrqs26yN9Bxp84/8yi Vv22GEdg8Q4aQ+Sv8c5L7rQsYpyve+21a1GHqp4fcPaQfdfDc95sg4v0MECuQ4se0/l+bRE/FWf6 ScZNdHxgEY/34b3DWV/7ohhP+d7mzDLv9NN/K915zDvrDOHnct+ysJebxbhWjBsWvcMOcqpW6LI+ gP4h/K7x9i6YVOFPOXKTMY/OtpFNNnOFNfUhstVli95LPcKAu8rBmxY5RHrcsPD1oUWNu8b5x0k+ 1bm3LWp22aLs/DpnN5l3eP8qOAzBzml+V4x7xfgSfR6AzRpYOq+fQMPX76LXJvs3E143mGUjeqeT /vfAZBN+b1n0dGXealvUnSd8y+7vQ2eOf9X4a/zXoT9C1tz3qU5z/TUSH85flftf2dhmnacH9tGE JX32mOWLJe7nPOl0P0ZHi+hWvZD6JJ+nLPKf7KfDPcX/S/b/HvEPJ7zfZr6D3FeRYxasR+y7vnb5 H4GratgTeNpmfQ95+nwfM4aMEWcH8NixsDvVb23ePGTfvz+zsX31wGkNfk+gK79ULFtN9Dcs4lGf sQK/AwtfV97fZ94Dwy3OdCx6nX3+FX+7FnFvi3t78HHE/QFD71aR5X9cl9+Ho2kWx2WuztXa27lY ezVaa62UUloppSilRERERESJiIiIIiIiSpRSShmllVJK09oobbSxymhjtLH2og1rjLZG24ux1lpr jTHWshd7sX/A5nS+H+ckF4/3fZ/3ec5znvPje75noLvWdZ9dPeua78jGx8nnvm9Lc/Wk55n8P9Ua 7kvcuv7PdSZ2uEj+OJJdn0r3lvRtWcQXfZiv/50t4ztY8y7JBvP6WnshXd1Pn+vsSvLBWPr5XciR vr5n6Z7EE34lBo7kH3qkmQUHO5Y+LT1zPCg/Psj1/V9Lj6kFRt/qvSM9+jpnIhktC6ycSBZ2Hyd/ YbOO9vUkt2JR+1o6/1Y6gm34ifoyls/6WtdPvh9Jj6me5AO6EYtj3R8OQN77+pqePYsc8Jpflh/a ko/OLYt+cqR/bQsuCK/wOLiUPdZ1n47+owd86Fw6H0l+wyLft5MeXclop3uRd/h7rP/wz2Y6E7lD i9zGH9h6S37o6w5dzU9kI2rwuezbk84vLPoScpTewc8/tchtuDa8w/V4LDnkAvV7aBErnrd3Orsq HxIPl7qrn+vx8pVFXD2TDj2tu0928/G55HxqwU26+n4tmVvS41LjG4vagj38XK/T5CXY5rJuZaOa fErv52teWcRDzSI+yEX6Vo+jG4tYrsiOcCO4ML4Es/B7Tz4dSM6dRZ2sW/QqjZXnzCI34ALU874t 45jvgZfeJ52IQa8L4Co6bWueugM+tiX7VPIu5JN+ktmz4JxnFljTS//pWY4lG+zPHOxQvoN/1i3w BIw7kkywFEyg7uFD503XaVAD0PVEdhonX3VX9CI/WhZ5t2HRk3CPXFfIFfZwvwuLHuHTZBfiB9zt Sn5Dz3aax/89rS8nXzWTX+DyLpseEn7U0tqMK0W9Vyz6HfzkY1NjmAb5fixdsMdEAz5LLQUffZSS jcban/kqGErfRc2Ep2KHou5CvNX1fKK9cDRkg8OHeif/K3r3UdU5bQ1fV7PAxeKKLU8tcgNeTb0+ l+xcb3K9dPn70mfNohaM5XvsX9e5PMHbtnxAb1a26Ps6ab/Hf8MC66jP/m9L79iAPgAZpxZxUUpn kQ812QwO3LGozcQnZ6HTebJXc8VGA/0r619T9ilZ4DhPuPqO9o4t8Bpcc/vuWvDmoeTB1WpaB/e4 lb3oZ69tOY97FlwZ3GeAw8So79nTYI562NNa+pxBeqfWHlr0WOBgWbqD+/AeON6eRWyU9V1PeoBr jo9nyX8zi/i6tMAJn3sj215qj9vogWyDL13euvYXk46+xmPsMwtedSPdbi1qva9xDHkhfTo6+8Si F3upO95o3ZVGVWdvWfQd1xY86CgNOHxDNi1a5PfMov6T59lfxJX7/qH0wwfUDLgEsd5OdqF+YFuw si07utw7yaHnIk+IHzgsuTmT3eoWvVNZNqN+DvSvuyKrZoGjcGTyD5s09J45LVhGzWQN8U9fgA7U c/C1J72bFjyYXgFblpINBsnO5KDL2U/2a6c9dYt8PpA9y5JB7djTmR2dAd+GYx7ojNNku6/SuU8t 8m0ej4VHOvdYd6K+uh1epXkwCIzb05OY5C6ui3O059JltjIu03tXeo/TN/z/TM/3ukvRotZNJH+k dT7o8/imz4XXDbUXDpX7NPgN3BFcQR7YUJEcbLwtO/D/yIKb0F/UZR/y0ueuJGMkP8IDXPa9LeP6 cGVvWzpRn+Bf1JyDJHtXw2VtWuBdR2sbshM1ZmJRy4YWudKx4PdgPrjjNnE83E96w3lfpvdpek4t eOGxRW/w0CI34DMej7/oTGpJK/2nXnVtmYvCC3l3jnmtOWK5LP3o3bJtr9N5xOW1BTegztekI7XK 5Xt8bUkvuAx1ZZzkUq9qFpyiJv3A7IpG24Kvtizi7lKy8Y/Lfqp/8HR4EX0NcUR92Ez+J4766f+h Ra9AbehZ1PqO9JpqbmqBkXAO7EDfw/nHFjxrkvY0JGOgu8Jf8Gs1yUTungWuUsvReSfZhHgjD5qy /55s0bTgH2XdraFzSyt7wX3qPvYoJp9x17ZF7aXeEVt7FvX1sUXuw/k5y3V5LR2oqfRh+9IRbC7r 3qeS5c+xRe9Br0NdqlrU3rrWneusqkV+jdKaqUW9pzbAXzt6wqlLej5JdzqVPGoHeUhOgEXDpF8p Dc5hwDnhR67/l5J9a9FD+JlH2u957bzM8/g7W+QPvIh8vdS37/+HBZ7lGt62yEHyoS8/+fhEo6rn nta5nmt639W36zXT/ef1tLBjwc3oERsWPRnjwILnXFngH/xlbNED9S1ix9fcS+6xBU5sWnDQu/RO LZlpfUt2BM9PZbMNi77FdXCs3bLIl4YFh/CzT/Scpjk/77EFpzqTfeg76P+2JXtfNqTH8nPnteij X0n+iWT7uh/n450t4mVqgbHbktGRHHj3Wwu+Dfda1xO9n8u31Kjc115r7Flw4Y4t8wjXj57VZd5o LznZli4nsh0c4kL/LyxqY9+C+21rgHU+91BzxIPvo+fZTX4qW+Ac/h5Z4DNxQZ35VKMjW/n82CI/ uvLjny2wbi3dBwyfWWA2NQCcKEpGU+9g7TPpRG/p/plYxP+pRWxdyQ4lCx4wlb5w8h3Zyec2tHfH ogcF96rJjn0LDCI2wTBy7oFFfjBmFli+pvXUd+ok/W7mQdwdPTIn2dT/j20R29hxqnt0LPC5qn/E OLlVtOAo2AVu4vPfyX6Hsr+f/19b9B6eM94TeLzeagwke6q1U53nckcrA55B3aTegysn6UkdwFZg yjitr8i+q34baC8xSlxdWOA8/PZSo5/OHKb/2GnbIhefWtSyI/kG/MwYDm+kLzuRHai1tXS2Y7Ln wEYafYschf+dWOR3JQ3qdc+CA5a0vyTZJQtsZM1UusMtqIdF2cLtvWPBA+FMU1vGumZ6Z2/+BsPp gc71PkxnwGnw27n+31nkIj1W9tW5RewfSM6t5FP/6L/2V3RuaT38E64KL6lptNKZbckDl8GP3K9U bDmGvVbsJlvS25b1j3sQn+fyS0n/qXcjW+bxQ61x/eCRGVd9XOk/MXss/c40P7HAoEGap++qpzWs Y3DXI91vkHx1YpEL/p35bMcCh6rpzO7KgFtzNn0cXAyeiV+4O7h9Jv1fW/QkQ+nm8/RF4BF8Fb+D /RMLTrclveBP1AZwlnicWvD7tnw/s+gviTHiGfu4Hl/q36Ge1OK6RS35iy1z6In2n8lGn2n+B+1H ztcWeALXBSt29M/P+l7+OZAdfO6vtuDYN7JhWbq6nuta65jmOeW5dmeBs3tJ1ovF/oJJBrntNee5 RW4eLc4trC3uVfitRe7N7Vz49Xx8vJgvzM8vdBZr/f1DzSpL77/LHn9a2KPwkS04C7Hq83+Yz28t nh/s8oP2uR2+0V1G+v7JFvXkmUXP6/b4di7D9fM6+c/5eKVzvX78LBm+9uXi3MIn8seJbPM3yf69 Bb58rzvf6z4u+4+2wIVnWrsv3e515o86453uOZLN3+rff6RHQ/MjyXxvi1xxrvFG9qd+b+n7ygLL 6RHJa4/9UvpPP0U+Zz6wrphwuYcWdZtafGSBoVWLnvOJ9KP/rOrpMjYku6d9nm/1JLOmM1lf17Mp eW5nctn/PZCe1KoDre0kufCYvgVmPrHAZTB2P+33M6dauysbtZI9p7rXRLb0+HHuCv/Zsah1LYv+ s5LOLSXZM4v+YdeiFqJvRTLx428kE3zIXGNswb3q6Y5tC46Hj5DbkB3xQcmiXhflE2qf2+ex/Ijc R5IHB960wAfqu8tYk165v6U2Ea9l7d/W+jWdsZ++e/qfOQz9xHqyE/yXHoW+gno81DPXsa7ucyh5 A81vWPDnzEepc3BQ4ixzraps/kh38Tz+QgMuonpU8Hx3vPvX/P25dPQ5xzjHCseBC+11DHAM/J/s 815zjpE/W/AzcMOHY5lj2rf6dv0dd/5tC2xz3PKe4hdb4NPbNF5J9r2Gy2pK3zea+0nnEr9+77pF bJM7pWQr4gibus1vbJmvdy16j/+zXX6RcadrHD85N+dxnIu9OBzncq+qKioiIiKGGGOMiDHGGDFG jDFiGGPEiIgYERVRVRWqquqoinWsqop1rN6svai1elFrrRWratWxN72odZyrdfJ0Pl/P05y9eL2/ 3/vn+f8+z/dxX+5a5A/hRPW7/q3YU57a4/yBxdu9Aa99zh5wzuedxHcHnSbMCxbvec8ivnemNGdO sYn76z303E/ev3nduc/cxBfv2H/Jncn0zMyfof0r4y1+8O8zfNjnjmNqjxevR0+Y3ac/cv49Or5L 9Bqsux1+Y/i/Y5dDdPB4K3HP5fd38QA/q/aesXcGDZ8fM6tmun4/w/crfOC6fwc/0fse35xxxnXz 9/mCvXPkepN4n7P/EhqvsZX+3/P9A+tv+ZYeL7jjdE9Yk6+esT6G//fQfDHFNh9o/wO/uF4X7/YP PyHX8zRrnKfvn6H9Ou25TRyPeYzXOFNFJvf3I866zP9l7Tl8/8X6lzbNz7/x/Qy5n8PvF/z5BbzP kfkcu7juwiq+7/mnx/+2RR6Qnk+h+bUFTvH1J8j9I3s/QO8nvr9BBrfnTXj28UGVtW+h+QD5Tzn/ Jd9O4zt0fGXTHPMVZ7+FxkPO+38dm+4n/7yClvomf9Me56pVnhP9rTzm29+nv4m1dGeR8+pP/XsX H/rZY87tM6u+OI2r3KumO+7/6xb13XPcrEU/5PJ4zsn9lueKpkXv1oTuqkXO9XNeh7xeLfG/gF3m 8HOD/1X032A0uFdHRtU/4SXhQOFFYZQycrbRqYGeFfaG0C0kvYrsrVj0XmV4l6FVt6jnZfRZsei5 monHPLMwz/Kl9TK0eolH6xLPImd0vsv5IjaUTNJ9K/lKOKqavsvpfwOblJFNdlywwOrqN+uJ5iDJ o7hrJrqFRD9/C+dmfHL9d/ReQy9h9lV01hvZwO5tZtm1ZIF9xUMxlXHbPGfU68nnDeQV/zyvMuro 4TF6lbUr3C1ZxLH4zjMvJxpz9nGfUrOI3yp3FE8FC4zSRBbXUdh7g/8Vi/gtWuDnehprzNvMKxb9 TYP5HvR8fWj/3xMpxhVzFc4qVqoW2DT7XPoJV4tuPf3PJpqKO8VElbs91l2/Bf53uevr3cRvAfv5 92HytfO7yM0zb9B7iH09Xzy0iGMN2Vu9q+TSu2gxq+cqWcSg8qT6hWX2TiziwfdGyOg5ey/ZQHGs PHcXPVyOxfTdw5/NpGeLe4pzp7nEvTFrBYv+QvlUPspYWdhZb+82e6Kr2tJGpyb/q8xLyber8HV5 z5J80qHL3EF/vy+crHw5go76yz3Wqxb5y//11tTLeh3+Dzj3oq7O/MWihz2GTy3ZWbVPQ/VM73E3 2bmDPMoRiu+qRV7I613k9DvC8zq3dule3yKfVdgvWeTlDroqp+d3f8TdTQuM0YL/CNvso3+dc4rx Gt9u0wnyz3FXOaifztTxdRM6K8wLnC0lPVrI4rHkMfkAurKT8IPOlbDRCN+UoFuER9Ei97kMV9jX mGPM8q+4Fq4YsSY9ihYYq8RZP6eaVrV4P1X4rnB/xKz3WEt6yRaqLfWkh/LBrEXNVrzVkE9xv2Tx toRBrjHrrbnvHZt2LGqFMOiRRY/rY4fh314jPC/6e3gNPT97wnB5HLsfWuDnU2h6b3c/6b2IDs+Q 9YA9p3EXG9y3yBnqbw+Q3ffH0PW9V8jXtsCgI86dsubnPZaeotMEOQf4coxOiuEDaMpuegcP0dv3 95F7yP2vof+Uu8oRrvM/bfoOtdaB9x46t/HFEfYR5vZ9vWPh1JuclU8eca8Fr2PoN1nrpLHGXMVG VeS5iX7DNJRHNi1q/ppF7B0jwybrE+5tY9t7yHDDou4XLXqPjANaFvl1j/t5yJ8t+DT4X4e2ZPY9 1fgu50fwGCU9NtDhDvcWLXoqvWPh5wKjjc/20W0IPddvB1up/6pZ1HrVBuW7gUWNdlupt5C/lO9V Y9ctcmTRomeT3RsWuW7dPo7voUXNvwr/ZYs47PHfQG5hS5dP/YTe1SJ7eqvqwSrw2LLoVVXXOhY4 WTF4gP172NJlHiN/l+82cx176a7ieZE92WYMzRFDvcERtG5Z1OWWRR3V+2xeGj2LuHLax2me4Df1 XQML3Lie1oSlNVqc2U12VY1R3RngP9loxSLmT9hXbvFzwsPujzvIPIZPEf2PWBMv9YM95g32B8gm 3zqfQ4s8Jazbxad6X8KOet83kEV+0ZtfZuh973BP72HZIncIi27j611kVc/RsahrbWTuW8SB+iX1 jfJlA3tct6i/exZvbwN+yiEen8Jeg8RzM/FR3W4ib9EijvzeUqKT+wfhU/Vbkl81pYHswmc1zpYT XccFJc7U4LNlEYsF7FpLvshYsGOBG5zmHDrofSjXqOcVnvRxC5ssw7eDT6vsKc4+5Oo/vf1gJ+X7 LnbrM2+ht/e619DR5dB7Vj/r7+ARti0nGrnODZC3z6z8Jd/pbRwjx7IFZpW8LYu+9xrfBxZ1oYJM 8ol4CaOvYAP5V3lH2F21VXhd7zrHizBiD9vrLe+xJ97z3HPcrP5IOFvn1tBb9UJ9HblkxrCtsJ+w R5n5c5vGj3rZW+l7L+0Jh6veq96tI0/JIt+Ufmd4XT1Mfj1g/QZ3fHxmU8z0OXM57a1iuyN8XUKv W/hMeaBskcdKFm9KcdCB/nE6U0KPDWRUn6C+SPhI3+rnhD+HFrmthJyqcRX4jPn2fX9LdxLvQ3TR vnrdOv+nFrX3MwuMobuq+dK3ju+K/Kt+Oo0VzrWRW71sJ8lYsci369hqH/6ui/Cu5g3oqf6tWcRI KX3LZlrvpG9hOOUu4R3hiRxL1USzaBEf2tO5Rvrv2ccyqSZvW/SezWRL5QrFs+p4jf+ufSzPIP3L ty3mITYURhums/me8tjIohcdIFf2tWq06zNnETcD5HNdJ9hwizNbaZQTfeXWEueK+FDv87J/1uGx m+wpXKnvNegoZysGipf4yHZDi1quHDOBxxh5haklj/RSXI0sclbJ4u34mLeP467B/d20nt/jLrIL uxxYYHz1VXpXoreUdGta5ETFQSv9C4cucFdYe43780kf+bWKHMLm8l3XosaqHxG+zDEoWymeVcuE MyrYd+uS7QoWsT6Ajut+Jflc9FdZV52qoaPWqYd/9Lp7giz3mIVv9/G98qrPdy36hoc2rYf+fQSP PvTq8LrPefep6t69xEt1SqOcaO9h64kFzh0keerpXgMex4nuA86Lh2L4HvROL/G+i++EveYtetF6 4u06LnHG4+BG2uuxJjnk5y5+GCSaA9ZGSbcB9IULxM9nYR2t6fxu+j5K9lpKdNVTZh7Cloq3gUW+ y/JULTCVcMYYPoNLdMfpjPPMdWOX/8cWOHYzjY4Fps29qDDKiUUuumnxppz+6wt8ddFvzPz94vsX m+bnN9Abwv8bm8bJI/Tchs4m9Ecxz3xq0/rua8sWsaNc6+de2jSGPO5q6KO8eHF25m/Qf2JRJ+us VZDP5TpH50OLXtHt14TPhHOuv8dFwaK3Ed7p861+Srikknwzm3zUQC/hta5FnK1a4HlhuI5FDVeO K1rUItWWtkXP8KlF77KVePj5u9hM+Vn5ss93weKN/9uiT20k3gVk9eH52t/1bYvecQFb+H6LffVZ ilNhjza8/LziRHj4jD3VIsW957Yj5CxYYD31Aqq5TnPJApe5fCucPbLoDa9xRzmvaNED1rCf0/vC pnHRxv5bnK+x1kaeAr6owON6snOB7y58le90v5pst2QRJ7nfEP4uQrtl8a460KxZ9JfL0OuldcVx F57CFz34+ps6scgfW8guLNCFr2J9C9v3sK1iRfs9i7zyKz7sJbl6Fv1gD3p9C3wrLNKz6DGXsceE /Y3kC2ET4Wn972BPfwevkw7SWzGpt/YeXW+iv9viHfyd7oOp/Wb+atO4urg384lF33gbeylHqBY7 rVn4NJFPWHUvjf+xXX6Rka9nHLe96feqt0f16lhrrXVErIgYMYyIGDHGGGOMMcaIGGGMMSLGiIgY ERFrhbXWWmsdtVatOqp60ZuqXlSve1m96m0vqxdVzXPO53ueN9GL1+/3e3/v+/z/832c355Z15U5 Ed8Rz79XzpRN/LDN3hxe/9YPsRLrv8oY3fxBz0d3dnh0hD32eZY467iQ23irr5zrjA167Df1I9b5 MV4dw/vQDv9FDY94GcKrwXqizKVd+OwpY2hL9/vjnjLX4/kX7g44f4Cu58huzFyH5g7rtRK3OWbm 7O8g2z60jXM3lflq/WMZ2+4U/I1X3Zccoyec60Hbdda8gv4KutWC1wKfbj6wV7Xgv1v8W+Nu9cEa KOuT62JN2RueK2vt35R5Zjme4M+NB3R34TlQ9hfrYEzdUPbWp+hZ4u4qdrNsW9Bah28X+9m+zoEO cj/nzkYh3zfsOU+Wuo99+tD2HHCrjOOImT9w70VxzzVoG/5NlnV/Cs+2Mkee8L7Du+/Fmcfw2oDv TBmbjj3nqWO5pYyxTuGjDucbnNtjbcPbfA+V/dAYxv2hBT/f70M/dDYe2EaemRJndKHnWmyMPGXd /X8UOgau+xe+bPB+d+9R1NjvlPUscF3EZPTJvyN7YNtFYacTaA/4d3fv0Z3fH/0CW0S9+oy+PWjG nRW0Q/ZraEV/ibnonbJPnyrjrq/sq8fYJ3R0rJtH6H5DLLxSYoIrZa2cFu+7nN9X4t893ce05hUY a8y7a7ZxnGttGb8T7rgmN/nXgIdrrs+GTdag4/yq8zQG3lDGkWPwgqfjwD0i6DxT9gfLUVHWjAr0 LPc+sv0Df5W4a6qciUZ8H+C7G+S4xLaxt2Rvji+HShwaPeKX0Flh+xXnY13D6wN0PuHPo4J2PF8W 9y75P0O2OnKfKeeOkCHipwo9++Nb5cwVPN2LjCMr0D5RYtVPyHkCz9DhVtnHR9xxfytnxik2CDpX 0FywV0Gn00JXzzWv2LvF5u61L9H/mtVTzpwRgx9Zx9z9Fr4z9i95xt332OGE+/b3CFmMI8bK/A09 usr6MC/ufauc24655xq6UOLZONeE3gD7byKHdXuL/jNodvjnmFois/Xw/HaK7b6Dp+vAtPDxKf/m yDLBVhEfX9i/ZK+tnEfj3HN0c/yvlLhoxd5YGSc7yDpVzkHXylwKn0UcVJVzqOmUs1cXvhvK+In+ 4N4TvXO3uBv39tEl/H+hzP8Pyh7XV846r3lfsH+BLU3vGPvt8Ryha4fzN8r5YYysZ0o8W84CHfTt 4Jfg28SuninjzjvoTpT1P+g/U8bofkHvmL1L+LnP2H832KjLXp/z08ImZyzPEsbLK/Y7yvmvrszN sNUX+LTZj5iO2nDL/diPeI08dj0KPX7DGc+CA+i/wg8vkD18+WtscK7Mq9DlGlofkdEz0iF3b5Hf dbdZ+L9b2Mm2+CMyvFbWNvvX2HAI7S7/bPMuvBfKmtCB7rTgM8EeHWV/vIJuj39X6PACm9mmK3St F3YYY8OwjWMo1ht0acPrPXoNuOeZb4HNB/jImKKKTK7H75W5MuEZ53a5P4HGHk/3cGPVAedqyl7m XL9Cj7YS15xzd6zE9Pb5Z+gYX7/j33vufVLm5invffzjutJW4lzX5kvs9qbwX/Bfh8aNsqYt8MMt a6zsG85Vrza+NE76qMzBG2WfW/AcKXvhZ+Rwzk+UmOpSme9z9HfNWVNiin30DjtWdL+HDZT1YYqd LpXzVpy74H8d+d2Hv0YW6z4q6LyEdhu9XNsHfBs/nBf6xtOxcI6fop80lD0lzrnO9gofN9DNM4pz 71BZ1xrYYgcec3S/RMeWsua4VraU+DTOGz85bsMWES+vkPlAGXvGEkNoHcArlnHuEHscQ2cL21Q5 Y0wRdnyLDK4b50qMfMy/2C+xzwm2cG/5oJwzQpcasvXguWJ/XVnT3fc9z+1wb66cI9w3q+jvWaQB rXecPeR9Wfh+osRCnYKHa98+9pxjD89Np8g1ww415azQwD8L/h0Vvpjybw+610rc0+HfSBlfV0rc +7qwZ1+JX9wDR9hjk+8BNh/ikzPdx3/O7aUSO54o+8EYe5qn5zPX/Rb6HSpz/ZTvW/gbB8adinJm mcOjjKUxdE7YN+454V8XW86xt7Fp6PxGWbsX8Kop58W5ErN4lvDc2UaXK2V/CLt+VvbHM869VuaU MY5ruDFTD3ru955xe8q62MSulnGOb4zDPfMcKOfInrLGuW5OsJFrnefCAf+G8A4Z3innyJmy3xpj HUJnjh3dr27wbb+wr/GrsXfI8FLZJ7xnrGi8NUGPEj+7dvXw5QX2KXtYiz3j8xr/evCK72toel4b wfsMO+wVdJq8t+Ad3xX4V6C7rcQRP+P+hDsDZa5XlbWjVejRgq990VVik5UyL4bF8uwUtfg5PnH9 HKBniQedr44D+/w5su0gv+t2XYlJXHvHhYzuk+6rptfDlhX4HClrQIWzxlsTZe+Le/vFMnZ3PXHd H3LHMW+9PFO5V7rnz6Ax49szT5u9XeXsGPH0mT1j4rlyThwXNIxTZ5zZUGJV53V8nyt7XoO740JH 581Sif1Dv03o1/HNNu9x/kyJE22fG55hD8f+tXLm/II8N8hjfh3OHxX3TrCt/dVS5p/tPUbXNivu vsEOQ86/UeZkXVkHTpU4e4ROC2UfdJwaj5ywVkpcGN/Rq6rIPuTuBXYzLvqdMjccN0t0M161DiP0 WsLH+HoIrUN8MS981eD/CPl3lbHmPHOcn+p+Lj9l/4A7tk3w6CGje4P9cIjOjhPXeOeN/8edD8i/ VNahlrKO2s49ZX+7gLb/OaZ8/pCna2PweovMr7k7w99e10pM/xhajq8NfOK8HGDDJnvuI/H+SYlP XS/dD21f16tDZb7Yfs7VBvu2abxHfh3Bu6/EMgtlHPTYM5Y90P1ZzfPKb9nfKXjXoe26dKTML/f7 Ofe2eVaV8diF37YyZurIeoR8Bw/87Bmli3zGqJc8j/hX0ih7lu94BjhExl0lxnMd72HXI2WMeAac sXeFPH0l9o54i1qwUs4x7r/byHKszCvL4drovF4p8c0QHxhz2J4x88aMe/DT/3yvl3UIO7/EXm1l zno53ivwPeDcemGvfWg1kL/J/x3+3e3/5GtlrWkr421PifHcd/rKfF6DjnPkTPexWMhnPN3kXthm ic1r2OBrJVZ+uHrK2WJfWX9Mv6+sjwMlrhgq58AtnkfFP8eY8cq0WEeFTvWCp/+7Ftovdc42ivNt ZHYNMCby+U5xro0eW0oM0Cz8h5++17Nb0Jnx3FPivTh7rPs5U2NvD3l2uPcMH4Zu68q8rbIcswd8 T5W1c1fZz/YKX7gneS503G4p8WeHtVus0pYt9FxXYj7HsG3snK8VvKdKbO4cXUP2Mv7XlHE84ttx vs65uBM94Knu55plHMMj1s85vwudOjSN0Tq899kPGl8p++EB+66Na4WcNd5N073I+GCb/Q3k9pw5 UOI96zKEjufQTc7EvWcP7OM638Z39vtOId8YGhXWNyzHj33m/1FPIw6N+QKHGVuFjSOez/HJEttF j3/CGedsA/2Ney+U80uc/5MSyxrjHSpnwBo0nD/Wy7H0CvnDho8Lv7s/1Qp5bK+/wqPG+zZnvkH+ IfzPsfM6+y/wTQWef1bWrJfc73K3puzPcc9z0BI7ttBrHXk3Ob+FfubnutQq/juvXC8ayjgLPxpj PFX21ArPtjLelujoeumc7Snx46/ues5XnF2yv0Sf90ps4bVixfs17wP4xF7E08cHd2L9Uz/Eg7+N 2cpvzyyveF7wfFecu/0/8pTfnltK2mfF/qSgffzg3PJ/bJdPhOtZFsenZzNnObtZzWo8bTzPU0op USKUiIgSERERERERpYgoESVKiSglSilPCc/zlNKeZ7SntV6MXsyiN7Mco1e9nHWb/Sx6Mcb06ff9 vHMSvbju797fvef/Ped7LLAg599YYKRLiz5j+St3LxOPUwt8nWVsp++qfP6UdL9MNgcDZrr3OjvS 3tgCgyDfuUUPA9690h493JV0Yp+ecZH0477LXJQ88LqS/6Ezt+ituH+ls67/beJLj0NPST+60P44 +RA6c51bJP4+wACzHfr3mrHbIt31vf/om/sXyfdji/w33dFlkni5PQ60nljEyGW6v0z6cd/leLDA vPQLuccjfqZa++y5+MiiZ0TvC/kCrHEumy/SINbvkh0Y+NrlpZdzup4Dq/Kpr9/Krv+yiNG1aGPr pdbjxPc66TFPNjhNsmCnhUV9Xkimsv5jF5/pRbJdsf1fdH8l+c4k94Nov5MdyBfTtPbh77FiUfeQ 6a34t5Oes0TntXzDG1wnO/Fe6Xf4zjFDbmjq/lA88vvKNInfmm3niZX2oM+5Dxoli7ftujUs4vnR Ig6IY/qGdeIDRmppfWbxfvEl+Yg3A8ZY2ieM8dsvtE9e21jU85Fsvhb/xzSu5bP3WpOzXVZwA/3r Uuc5h18fxNvv3Gp8Idludf4+jb7obETHz3Rko1v9nyWftbRP/Zjr/CbZYCk5bpPt7mUn/DNNepPv iQefX4nmSLZyGYYWOXooGtjntfTsWuS7sWjcJn3Bc+SkjXx+ZVFT57L3G9Ek9xA75CZq9Rvx+sEi 92KLVfLHG8l3Kx74c2ORR8grxBW5FBvRy9Cvun3ov8DDVd2hB/HhOfaf4odsc/mTmoxN3fYF0etp fCe9W/L3UrwutC5rprd6J9k64l1La/q2v8q3A4ve09/tk/R1HX+06CcqH+999hvbfsNN3R9a9IU1 +cb3+jrfT+c6FvWHXnco24FLTyz6vapo+t5B0hOc/61t1+O+vm8ke1/zVPNYd8EpZ7o3lD/+KPr4 qaPZ6a1kMz/32gJbuH03OgO+aIqnj+faX0uPlua17nZ1p2TR2/je9+JVkq4jyeBxcW+R3x80u94e k6+SvVsWPRQ1faX71MCm/jn9mexzKhnO9f9eNHzvQrq3NP9okbvpX8FkTqcsP1Rkv0uLWKlpj7d/ LvnRl1zckv/dFkULDPAku88taia1j/ztNqG3KmtUtO/fBfl5KNqvLLBqS/o7nQ+i631YVbI09I9e p6jvuvzSSOca4tuQn31+FO+vtOYtNtOd5s6/luj/wwJX0d+90Jo6UrLI4U3pui+/1PRd1d2+/FxL /vXafJh49DQzuunb7fAsrevJ94ym7HogWzUs3nhB/w713dCdudYFyVTQ+Wqie5Fs05fefdmZfDzT XkP6tiTfgeaS7Afudfk8D1zLfj3JQm6epu+q5pm+G1q7TeiToOE2eK598h969NK9nmREL7BuQd89 ycz9M91ri8dY+z53NLoW2J/6dqo1Ob1rkaOgcya92rrHe4E3tYzvU8kHP9bkjveiP7DAl0XZo5vs 2002HInOwAJvdMSTeEEeZKtbvOOF9qDfFl/qSUc8BqI11jnnvZH+nPc1se20j3UXH28s3rjTriQd /2zRn1XEB3xRlS+QoSWafv7QtutvzaL2w6dmkZM6Fu/Vdb+WzGfiUZYtTmSLos5xh3y5b4F5eO+V ZHOGr3l3yOHv5aXW8OvIXkvpiz7Uqp7u7uveIt0/sagbFQucRX4sag2OKVvkHOzperyRP6h9LdmX Hm4iG470jxoFVujpX1O6EE8j8eR9Huj/RP7xsUo8/ib9cw96btGT3MhOq2QnMPHaok9bWuD8iWbO LSQ7vanXmlP5qWOBWei1Nmk430f9v9B8b9ED0MOdW/RmXQtMNki0ryx61ILu0tvdJH3GFn0vOG0q Wn2LXmyls/NkgycN+IE1keFcd8GENzt3B9K7Y9HfzXSup/XK4k21LfrZhQWeX8se9A8XGtgH3doW PZ362E8y0XeRM+mvLuWDtuRY677jjWOdGVnUl7bO3+rcXeLnZ/zNvk4+OUs+XGm9r7mlPZf5RLJB Y6V72JbcWZU97yQLvqOPpSfE5n3p3RQ/ZJpb1LknyXekNXnC395zzQ3xu5BdTixqaFODnoM3AHbr Jn51i74B/DiWXl0L3F7SPt/k8EPJdyw9qVszC9wx03/qOfkEfLzWf3LfnuRx+6g/+4X2yqIuTCx6 p5l81tFeU3vOb5Poch58PrLAsPkMeR5sC9YqSW72Oct+wQJrghVaFtgLHOi0iuk+uRvMA7bZS/eR MdeEk+QvathJGtDrpPMMMDK4zL8Pdmj7vT9YYAfkGCWbjHbsBv1c00q/MjhHHTrTuruj52BHbvft vkXd9vHVzrlR4kuMNRO9mcX7y/fqtt3DglOJd0aWlTh4lv43dQ961L//SVb3vcfl25/Hvy36XZf7 a/uYr+a6T/5wenfyGzXd9XgU/YVFj3gsOfzdfyv53opO3+K9MPzeyqIfc72+0znfeyeaTnsi/iXR /1I6Eu8/58bPfi9dwN9Ow2PLc8oHi7xbssC8P9nHOrWW3u+lk+fCz8W7ZVGLyGvgLOox+fe1vnOP trDAtMTcwgIfkz++sajVP4kXWNL5HVnUZa9LFQtcNNHZl5r3Ler6nf7zvnjzKwscR8ydWuBZ8Am9 3o1F3O6J/vfSycffk72oodjJ//9gEf/PdHYh/SuSx+V+kf7Rdzm9ry1iHJvXPvr+l7Nul2vRQe+Z BjinaYHzHizwCDWV+jqVn690FsyBn9HP39Cj7FbUXk/7+OVG9MBkcwss15SNwXD7FjHc0b+pBaY7 tcCfvk/tG2nvQjxHFtj0QnLNZNuq+IKnrywwpdN4Jz7EIz0i+BqbXWoPPAjmytjyMvH50qJe5jxw pjNL3cl9wjLJ5d9tC4xKfiMeatpz219bxPzUop+qStaGRV82suhl3E5d2+7BvrHAzsNEc5juUcvI y+10n/WRBX7KfWgrnaXWTC2wCniKd1S1qBUVC/xLPjyRT/Fzy6IOcdfzKpisaVEz2LuxwKPUNHIq /Wo3/e/Zdr3sJH4l6V7VQM66/EbdyBjjWjrP5H/e8aFFXvT1XqLreQssVNVZn1+JV2mHx0miu5B+ rMFyRxZ4FD+XLLDcLA3XaWVRPyvyL/zAYfgb2zj9os6Dp+GBnmcWMUJ9o/ZULPJFX2u3wYH2yqJR 1bmy+A1k56lFPNUtYmRggePIQ5wdWuRMeqZTi3isWtT7ogaYl3oz1j6+utSZgvgd6Xti0S+Qx2uS AVyOrXuiVxCftmzRssDK9CTcrVrgfbAj74OYKVvkGr7Bnw3R+Vx0WFNvqraNbRuicaDvfYt3sdS/ fcl6pH3nN5LsI8lWl/3ou55b4NOa7g6TvwsWeMHj6oXk6Vr0Uz7vJb9gt6FFf+I07nbk8u9zyVeT /4jXjUXeONoZ5SQ//QTvrSL6ZX1XLOKA/I8fHU8Qn+RLYqUrPXhPA+k9tsAu5GVG3j9O9DqyRd0C j2MHsFwrDeKrk84MLWLXdeqJz1w+yj0hfoaOy0/cYE/eNbivIj+Wk+2Od+62LfLQqfg20yAfdS3e BDI1LfJaU3bBtj3NdfEk1isW7wxZGL6XsTa6gWGoJeRE6k1BM/4oaQ+5mxZ5Fl5gbWShx+J/3yJu eVPEXSGd422VEj/ijDfLm6c+ud7gL+xDTLkP1rr7UvbADnu2XVvBXsRdW2eojQN9g2PI5Ue2/caP pOOxRV+Ab9uJPnToM31//rv/fuoVe7ad58iz+Mlj08/m/pUeAR3BFuTwY8k6t8i/xBdvDPrQnST7 gDHIfeSRgvah7777UzpPnGHrYdpDP+4QP8VE0/+Tnw/Fry77EGs1fZNXfP1C9KhrHYv+Bpww+T/b 5R9Z993F8aZmz/H88XjMqP0xMxMRERERV1wRruuKiOuKq+KK64qIuFRExEREVEVMRNWompqampnH 7I+qmQmPmqmpmaqpqqipGFNVNfOY7rnn3td75yT2x/H5fj+f8/t8PudHb7/vlUWv4DatYbOvmtem wd9LcV23yDWrFnOc/Kf8VbKoT27XEPb6mfL2MrL8bDPFQjVDdU05/m10Vp30dRDfzCS56i/0xuQf vaUJO5lLq9igPKNZcYh92aveW3zO49ORFA/dj6VEW8J2xXAgxfcNbJAd+c2+RxxdbsEix40gR3fD +b8Fb987B964Rc8tvxYt8o3smMG38tcIvCrJ5m14D7AOWtSNArGsJT9OEjvlT9Wk+USnfKK3JR/o /Z/urSYt+rlhi3epGpfvc9EinytmuktjSach9gbQtWiRy4axbZbzfvamEp9xbNZsNgK98N9hvx9Z 0+CMYO8I9P79JnSKmd7JQMIZO7Xvc+pt6+U4B39PPj9sWfT9Tzvv/V+d9VlnPdNZj3trFzr7fX5f jjrwBHjA/8MO/NqBHzo41oGziQ7aM48762vw8b3XO3svoP89yT5iPWYPHl15L7t7r3XlHbP3PPC6 fH5L/0fg/dHzdXfvKfBbT6cuj469ZzzPPUo6/zPJfQjuLz0bHa/L93mP9186vgL/Lvb9gV9c1r2w vcvjF/z3I3o/wz7f/47/FxGLLt2zk/y6/w+x5y7yjtD1ATiP0Mll/MT5tx34mfUle0fwc7o70D5m fcjqMr7n/4i9+9hzBK189Rj8rztwCN4hth2icye3nX0cd0fy+96A39NT8BJwOV9i2xFyXiY776On /9/ETsET5HX06Ou8ub43udeHxOJHaJ+BezvZfgser8B5kPT+mdg9wfb7yUfZv58mHz+Gv+7op+Dc Q4+fwfk+wT186DZcTvj5Td7Aj68jR3frPrK+6/13z2+n2DxJfruPf7/nzOP6lcUb+CbBPfCOLe7t C3z1DbZ8h15H8DtEt0P2Pof+GLuzTc7nAB3usj4Ez9ev0clpnsLTc/rHHfiiA7sW/aTnTH+3nnu9 Z/FaMMe3ekSn9bqr/mgNuhm+NbdUwDuf9jQ3qBfz/034z1j0ul6v3me/imyvrd4fXeL8Jnqqn/nM evn6W77r+GUVGU3guvXqnfpb5+Vv/6pFf34IL/VsbtcnyHOa/Q58SMw0Vzid37mP4OW+WsfPXve9 rnzAXo1v+etT9KwQ433iojvSTHbLN7ehcTtW8M1X6PsZNrfBXUHuFjrewrcXWT9Hpsejga7qZTX3 uR3/RV4Z+xehd12vJT9tI8fjeQd6r70PgBWgmvy7D80aPNcS/yVklIjpAftTSZ9t/L5lUcdd9yvA DjI0szXS90XOF1l3T/nH//eQu4+sNYveV/39HvwupBhspfOVBNvY5Tg1YrUD36vIvsSq/x2LPnSL mApcryb67MGnlWzQ2rK4Ly3wVpNea9graHF+gPyaxd24AM0euPsWb+Mqtq1C4/fwHfBXod2HVjmg Bt99ZCmOyj870Eq3HUC+dF09tyzDU3FcQq6v0+iXdRWf3WRPA5jGd66/3+3rvR6u+251X+S/OXxz Dl00LyyhR4N9t+kVNcZpNH9W4XneYm6Ub6rJ/3eAL+HpNbfId57j2vAuIXcRP/q599LeB08mudJ1 Idnu+a0OThU5zvdji/miwpne1DR61lMMd8BZxp4y/h5CtypyN9Dd7/SBxbynGWQH2ha2jCNnE11a 0G7z3YCf406wpznmBv+30Gs2+aRkUdecdwG7ZixmtZnky2liP4p+A9g2Dq8HKdbOfwQ65zXM/nP4 tsGZApYt5iXVzorFvXf6FYs8O8q56ngJnFlTzj3blV3HF2XwzqGv7l+D8zl4614JZz7BNDqOWNT5 cWAQeBcb/g0MYtsgNPN8X0J/9+f13v5Zn3uU6+sWfUQdXSoWPUQZv9SIe8Wil6mc2pMv25zXLO50 XjOUWedYZe8M9KOcNfH5DH6YTzpoX+9dvArEa9pO9lJaZxL/Fv9vJ57SYyrZJj5lfLYIzljiWTpl Y6arE7d+/Cqa2YSvdzqT6EaJZ5H/CVb3RWe2OPOe9e75qMWbW7DoDYvwm8RH9d5+33PO9UYnsWUw 6VvHzhZ+V29ZR0Y9xbGOXaUkp5b4NNK3fDUHbgt74m31/KN8Og99AV0L4BfR+47FXZ87BWVoPf94 b9QGdwH+/eAorhN8+/m6RQ3Qv3K763wBmGRPkO9eE79WE536M+EXLOpuLe23LGraHLJ172oWOX7e olZOYN8qstfYU36pIU+xrMG3aVFrK+m7iewFeF7iu8zZJLzVwysHNYmPanYDmefxp+6I+tNZ9krI KPOvOOlf+jaQ4TK3oCtAW0N2Hd83OVeeaGBTI/FdtJM1XvdcfixAU8TnOb+/b9EfDeLzWYveWv3E Brg5jzjvZeS0k4xh6F3GiEXPWkg+k97qMZRT2uytWuQX2dNEn3GL+rtEzBagHUfXz/HnAeuH6LcP fh2+2f6v0aMFvnoqvXOX9x/4y/fqX/38NnzVo2hVL6J1g1XvexZananWSs4a35cs+uFx9Na7+sF6 /anr4n3NdeAydi2jj8+IPpvs4mOnvwZf9d3qi2b5voGfXP+L2N3k32mvWPSau+j/AXoeoP8Oezfx 9SecbeDTH4HLyL4Mb802NTs5P02hywpyKxazrvrkJv+7Kf41/uX7ZfRooO8WMW0nvd1OvdUV9Nq0 6C1d3yL2tS3eyb7FzLFr0Uupp99IcWmio955NcEoeHPwVu55luBFB37Fhz914BHwpAP/s8j3a9DL llW+5/j2c+VJ3S/luHGLnHrNIie38P+QRX9V5czXMWj9W3VK/XQVmxYteliHW/h9nlgpPwvoBboy pv/mfC59ryRdtFexqNXzaV9vMOfbqUTbZu9dizmpyv4UumY9FljFqwbvKeQIr3FqdXjb4q6XLWry AnFSbs72NhJ/5fhS4qm5YsGi9zmX/NyfcIuc5X5aoDiKh/qqRejUY42fwqlb9ETqNUrpW/Hq6Pnn E4t6WLK4V1WLelu0qKlleIuX6nLTIo9f+Mfv3Zhr/tQcU7Oo8eoXVes1Ry7BUzVHPlEP4d/+hkb5 VgyW0Fm5oGqR91cS79Fky6TFLLF0Sqb095gf8L8Ov2LSR3fO5V3A9y2LnFmHf9HiHemtaVZVDd5E TuZZT/HI/fIUfCewQ36rJPtLnBUt7m8BcHz1yDV0H0s6+/q+xf3XvFJkHUsxKKbV8YcTXYEYa+ZT P6Iaqj5mGND71f8oMHwK8t41Vr2b0YQzwXc54b9l0eeuYssQ6xnr5Z2BxGsE+i1wss6jaW8Av8kv Op8Cp8b6Lmsh0Z620X3svWJ/8rX29T+d/ON7rURfZm/Mos+9kORLX+FMs1dP/P2O71nU/fle/Pra 4Ckfqw+YB0+9/xFxbqOb+vG5ROP/nqP9zivPvteT0+099CbXwM91z/XyO/+t9e6e17J99jyueQbd spjVVGN3kPkhdE30WMFuzWUV9o7huc236/eImLudV+CxiU3q8dctek7vF1U/itjlOfIDO5njZolX FR/V8Zv6GPlOPf0auj+23p2/YlGDH+CDqsUcuAr/fVbX5zK2qS67PpfQxfdG+F7GRrd/FHt2LXrp LfA0a7bt5BygWUAz6wZ4mkP9rICtwitbzEHjFrOFfKBasg2ubNqwmGvUH1+xuE/bFr3fXeu9DefT j+3O/yNivGzRsyp/bNlfd/jPZ/i3bTGrLeHvPCt5vL4gPuPwcH2vcbaHrG34XOXb+Xg+X8fnQ8hT fZxj3UHuJj53n/1q0TeXLN7GRXip51Se3kXmFjq2wF2H3yb+VU0qIXsZ2mP8qTlzx6IH9u8i9Kvo 9H+2yzey7jSL4+7u2j3Wvlj7Zs2LNcYaa9SoUaMqIkRUxBURccV1RUTEFa6I64rrioiIiKiIElVV VVVVFTWqaoxh1KgaNUatNWqMMVYNa6yxxr5Ya+83v8+35+nMvnj8fr/nd57z/znnezrE7SL748jc Kvwuvaah60f2pANo3De193EkDtom5m9EzgOtSHwqGbf4HkWfp8RXteUsyxjdvVP0z6KqH84P3SHX 5tvw3+TfCna/+RM+O5F3fov1FF3EVzmpmfKdyLo7QM5tbPQ9bMPzoKB9Cx220Evy3N8OkaGzzk3X WNHcxd/vsL8ETSMSf8mOk8j83MbO4cxZUz/9kCVffRLV3HEJv0m/j4iLzlyNzOlZ+HmdQb7O7KPH uZ+sOufqfJtm/v/QniPWnp3KfWNZ/e9G3q3zkRjYs8ki39ORs5XlOcc8x46hm8/r31n0dO3XmXV8 4byxHht8X4jEusbI4n2btVTYPcf/Ft+DyPu8UTzr2GZ824jEnk34eLY5B63nkdXIfHafaaKz9HXP 6qGLe+CPwxwZLXSTLsrTA3xuetHuoGcrEpdv86+cedyf+tjquqD3Nmsefersy+ebkfVJtfgaeuyx dpG3FlkbD5DT5V36Hkb2Q9fgZWg+iMQ71mO68Gu3sMXz41TkTNKJ13vQeGT9H4e2g8yNyHqyG4lD eui/iA2226sB/1Zkn9xh3zHYY3+78LVruc4c8z2IzNseMt0/nIfS92pk31yFZgEdVvGVc2mPeLru N+Hn2LtXDiLvp3uA4q37dob3twq+F3hXHDwzaf07qnp8FT6qiZ9FVbfuwfcG7yf4yLkztLv2u+Hz P9ihvLqNDccFveR+TJz6lT413a/rxE+ylljDXKgtsicbVVcfFnrcKezdhf8OMg+R2UOXK/jfsjuc W8JvrvMTRXx9n8eJi+I9H4kN3D/28J/7rXicx8/KM8+Ty9As8r6F3Pcja8sstC14iv9cZK0xBpwg /s4111TXG8V9EnnGP8Yb7pdTnGlE1kBjjWbkfWygl/typzhzJhJLeb46i5wJVp1z5m3bVyLxpXm+ A51ngVX8oT3jhGV8I/+/8Zsnp+fn8JntGCNm7kEN7J9m731oPItZzig6jhc6jPFuW9x7J+N1bOjZ Q9/vEf9Jvu0j+1j/1pA3y94IsmWXclt3y/fmGDrlv/JtwJLeun8PIuvJCbTG7LP4Ygsdr+LvbdYq sVAuPY9XuOP0Psu+Luf34bkf2R/0v8nZbfjPsa/7orpzOV71u9pvh2s4c9R+MVzCXbfRVzbvwku1 4IilGnGXeBjjW9Z1zlyH7hKyj9B5GV2/wg/b+HTA+3N8rlpxBR4L+MZ4ZJZv11fbd0hMNpDRKfzS wfbnkTOIMdPlwo46fnWeu39uIE/nznP2Dja5Zq2jc6PSu7bOfquiq/06Tut57ffD53fDZwzXH/in vb9FNbtoHngEP/lG+HUHecYBB5VNv7xQyaz10V21+2y8PoeNYc8K+rYicYrvgWvtzajy/xbLfafN mXl0kW8uVs+a80G6/YivXqK7+Kl//Xe4voeXcuJb9nvEc8izprj8EDljyq+f4ZsFZMov7kePsVl8 vh6uL6K6i4f4/lKRBzPQ/BUeT/G3nsofzQYvCtpH2K/zk9A9wDbl0CL2iO4ecd+qZJ/K2UFP2Svc 9TnLeftkuP7B2XvE+l9R5eBd1iNs7BL7v6OD+PqOyr/3seUmPlfMPiVeHc504fcDPB/C7yN430Tm CnRfs6d7rPxTj16G1wm0dyKx7LXqn3L6NMejqivK81PdZOuX+OBFES+tl9gufW4g5xidtyLnF+WX 69gxMVhifykSfykvfR+4E6e0erbR1/3B/VYx7kVi3lV43ou8M7pz05E925hf8n1/jCt3IvvnQuQM s1TYZDw9w9O4Ue/G4/vwG2d/JxJX2/fbvPcj8apx/nP8KR7Kscv4YR35j9FLvfEhOvSJ8RFxvoIf lJvKNd2BS+g0KOyZKnw7j60d3tci+6x0GYWuDc8deK4id4QztsVYfR/dtyLrlHFmnTNdluv3bHF2 GZoWe12ex5zfYk8+3cOHPc4eIHsPH63DqxHZvyaKuO9F4p1R7JMPqJunudqERvyewmMBn59gt7Hx fGQPbBRL9GP8v4W9h/DU/b0G3wHfPXz8JWsucl6axRcfo9cX6CW+d7FB9ewqPlyMzMMl+NxC3z3+ vyj+P+PsJDSTkfnRwCe38Isx13qho+x6gh3LLM+VvlPH+Nl22tdbyFN8b8BT9nhu7UViN9HswL9D XBdZCyzFdYRzQ361N6C9Bu+X8L/F3iLPa5E41t+utXWeP7B3GNnvr6HPArihifx+wf9iJKa6XvDf w/59ZFzBVvlpA99v4Gv9f8y7cEwTO8T/u2rVNAe+GdVcMZRXK3HUY3yn/Pm0kl/7U1S9V31AdV45 rB6mmqPe+w326vsE2ffSt6f2H3HmGe/3OTvA7x34K9bG+S3WfPE+F3lvnLP1yPpkfNTm3GzkXOnZ QeeFo8c424DPu9A7Fzfg4V7Vx/f1CnOf2i2busTLd0zPB5Ez4l18MhnZw9bjFYY/rS99dO8h07Ph IjTOX8+u4nMxEkO7fm7ih0bkvOr+OoV9y/ihHtnfPDNNwtO4c5Xvmci747vbhe8otsxxfhlfzqCT dXCt6ERi+Do21wu+7ufufVP8H+NMq4jpBfiadwt/HETOta6vf+Q5gl3v8o3/ar/CljPI/Etk3XYs zsbPsc18vLrbr3DEBf5PwHOXeDknpftleF7A3tHCD8YoDWh9xjGdi+zBI/xzvEw/Du8Gflnn7Aw0 6wV/58w5ePhe9CNnLefuNP+s43TBYwT+b0NjvGVanT8PnWU8wj+6b6o9e5F4UOuQ/238uYaMbuHP Bv7+M0/ZfQK/tSJGnoVaxbMOvw68FolHF31dk3xmnj31qq3CXyvI8L9B5F0z701s0T/XZWMu6zIZ 2WN8T4wzjafakfegyZ5rZpfYzhCTefiOo8NZYtCEp3jcRJ7rg/PJM+Z8JLaeg8Z+W8C+pciaMhuJ 54zr7Xvjq2ZkrrouG9vVI7F7B15zkT1ugjNjyBvBPtcK538rso4sQmfs59rSY28d+vJe21b7cile nz3U39SXj/gnzL4TeU8kpx/ZQ3qc07tq5id87yKniR7y1QBZA/TS3lbknDPJ9zTxHI/sjcJp6k3G JR34Kw5fEkdj0MPCn56n3ubcUK+aev6wn9dEdz8yF3W/PoT+Dvp9Fqe1tyZ+X0MvXZRfn2O/cMUD bNI9+X64fqzOnepyD308+73Ej19FVTPVgzfxXR/eo+ggfYR5H7L3JLKXb6DLP6G9gS960D/Gnw/h cQedr8D3LjbKH3vwk73PkPECnz/HN3p+W9laG8axpjg5TzyXGfv0iOOlSMx6Hx95hhgQ9zZ+c/8Y ENc14i16427ngvNrjdWMvNfip5w19hlHR+f9Ef/MbyUSM5iPsVSbNQePUWxbYnnGXSxoVyPv3Sx7 SwU/9y7zvQita+75SPwziKxLF/BjG/qVyN7htR3Z1zqRvbHBfod/7Ujc5RlxO7L2zhW2GEtZ3zH4 Kl9G2D8fWQdm8FGpn/xmDNXA5jORfXMK+0zr+lbabd4TrNnCN6s8x38iw/Sj6FLmZNlTZpFj20Y4 J3+8H4mBnGMT+NH+mITWOo4j82JkfZvCT1Ocdf02pns3sm6VNr7HmSY8XdNaPN1znGvOT/HfhH4F /rvo/E1kTmome8b7Nks2qp50I+fdXf5tIuuA5zq6+T5JB2PVGfz9UVR32RinHzkbfhDVXNqGp+tS P7Jm+n4d8dxAD8Vxv7DZvXEDfbV3iP7udd1IfN+F1v3L9s6z7/rSLnzXjcTzyrOdyFpwCX1so/HE ANoV6Dcj8Zj2tvg2xvKdNYbw+bL2rCPPd62LTGP89v8YL7/IyLMsjm+tpc/DPuzbmKe1RhutRYsW EdFCRCmllIgoEaWUEiWKUiJKlBIlIkqLaBEiWkQbLdpoMUZra7RmtDZWa62NttYYbYwxhjXWGmsf xtg6qc93zk3Jtnm4fr/f/d3z/55zvseizo3jl3X4TCOzZlErJM/ppxJdNcMcWdQZYbeWBTaqQfeI 2Ff5N22BQZXfLkM1rGqRi9LB9dE82Ep0dF3mLGZR1dNt4qPzUxbz7rJFr9jFZ8UkftJDmE61XvPX UuJz18HrQd8Cx6X1tmqBcVfg1WYvz37bAufewD+qB5qLpizmybxFLdTsmfKas7jH6m0bFj1YNb+S 6FGwmG99bxyZiuUU/hAOzlnUmCr7ynfNQQ0LTCmMXLCoiTX0qcGnbDGTad7MYuOZXcTcsqGD7zVj rljga+FK1Y0N+O8iU3mmeKvOnljcoTJne/ATrlxDH+khnOBnb1vkrOaMbGLjKj5yv6m3CXNrTspZ 9JMViznT/wk/FtkTtlcuqkYV4Oc6bmHjPv/msO8UWtWrul3E8FmL3jmHL0+TmJeIRx2/ypfH6LqL HfJrl/++9tC/a4HzatAJb5UTWboTmiNKvI9b1LWb7AsHLGOnZsNb+LnDGffhM2x23PzEAuuIRx99 fX/aor+U+ddDbtGi7upe5JI4q1fr7lWRkSUGR9At8V2E1x7+uIWsLYuZp8J/zVJFZCwmvlMOqiat E+sCflA9cR99jG13LWpzDjuPeaonHaJrY6hX5s+D9afBep93j8sZcnx2aBEL9+1TZHwLX/UqxyGP 0dPt8hnA54wvOOO19lOLmiT9hEnqSdxU61sWtXcBO5dYyk/VdNWjMku4bo04FdFzjj3FLwdfxbzC 2WWLnFfvzqHfffu1Z2Y89j6TvcJH/u+v+EFzlNPesYvYpoNf0n4gzCYc0xzGx23PnPLvGTb3+P8d MfFYeo14gz6P4PsJe8/5fkscNO8+4XwfvXym/Qw56zx9nj3j3evCA3h5bzi1wIYlnvP4LY+/b1vU vOkknmmtdPsnLHpHh+9SwsftnuHpunaJk/O8RUwL+OKaRT0RBlfPnIV3HVvr8NKsqZo9C3/31YFF LbrN+yH6tu0iFpi1wKbOd82ifv4HX6zBZwuewmu608qDWf5pLspb5ITyoIH9aQ1xe48tcLTzGU98 ILxfxt8z7IneYzMGneerz3h9fON35hE2bfB0O/yO38XOSej8Tr7GH8o799WJBb7w72f4cxI7uuiw i1xh8Xls2sUvnn+OF1eR27Do9Z4jreRMDb8op0v4ZgkfKPedTvc0xZHqxYq3Zs9KopdmitsW/bVJ fIS11Ac1Q1bReZI4LFvU+zkLTCJfKY8KFpi1wfmP8FuBfeXPNLGWbzT7KRd7yHDah/jDl+aS7G9Y Wzx3Ej376JhFj5ZF3RWd6u32yL6W/3vAezrHCNcsv0OnOfTQ93zCU3sr77BxeuSc3sVz/BIa7bUS e0bPdSzwma+pS/hsjfAcG/Hdh+jhzyo2dRKf/IC/2uy9tGE+aqbYxR+6817j/P75nd1E3jQyhGXl E4/pIXKdRnd9n3/CfqrvmsOm+K+5SBjd4/SYfzPY6PdlDd3TeUqzg3L5J3w5DS/NOZobD6GTPk7z b+wfyMoU0a1rgfFXLWZXl+f563WvAc0glzINC0yl2bRgMbsJo0xhk2bdQ/ipB6Z5rho5hU2qvV+j +xR2ThB31TW/H1ehuc4a4/xV7PgcHh+yr7npA4u5UHHJs6c8c37lOJNx+eplg2dGWPA+/rrP9xti sgPtLt/HFnPsMn6q4jvhW81mC+jvZ44s6oBywzHQGfwqFhhLcreJ0w7+ddvaxMTl30v830DHDXRo Q9tGN6+HfXSroc8B9nrNr/O+aYEN1Js2k2cT3/WhX0z2y8jes+hDqhfCTOphx/itzXn52XXdgvYO PPfR+QCfrPO/Ap3wrfNcQp8WOjnPE/v1/p/TrnBuBz7HyNxDXtui/lfR44D49pFbRZcl/K78q2Bz E1/PWfQ1Pz+BLYqR9FpFhxb6qI/m8Zf6sTBYkbh1LHI+b4Fr9pBZR/cKfqliv3qx+r7ucQ9fruG7 MnvtxG+aAZoWc+oScjaxV3Vl3mIGUTyUq8qhBXQRL/l+DX8tJOc38bfbdgb/jkWOdfG5sLzq8oJF jxBmzsOrZTFfCa93kSd82+N/HV/6U3mp+isfCosuoGcRvnoXlvHvG8l73gKj1/CNsJ6wWoNzuhfL 6JdLzs8Srzn0UL3IwUsxUD1Zt8Dr7u8U87xHHFVXdVcP0aWDDzT/qQctYuuMBc7bRr7z2WNvEdqH +FG+VN3rXrJ0xzvEZX/k/7rFHU33m8l7A9r0fw9blWs6X05kan+bvaZF/VXtFQ/xbFnki6+feG5Y zFvKd+Wy+1R1tcW+/6+xRL9jgZ3aiQzZtgBtn706Z7fhu8b5DnqsJf5vcEZ+Vk9YSXTsJzrKPzPQ KJ91T2SvsLNj45cjvJ/yz+eBR/CXL3aQ4zwfW9RZ1dwWsurw0LxTS/yqvR3sfZ7E6oB9zSsL8NxE D5freep5VoZmH9l3ktiU4L3KWflBPVSzTxYewotOq/lLZ0QrPFOyyGnNpmXWdXhULPJugVWzmJvS 2a5iUUPEp4BuOnMNOcLcN1kz6K764/fiCDr1Mn//DPoedm1Y3Bf3XdViRt3grHqj9rvYsGaRu9K5 m/hK97GOf0oWvdX3TpCpeqy+qDpYZL86slSfR/f/3578v3rJ2bxFX9S/xZFzl+kgev/33iX/0zXD GrWhMPL9Lh6/ZTVGdPPvX/DnMb6uWdxxxUJz1YkFTmxY5G+POC4SQ81jKxY1yXvQNvx6yK8jVzVP M6RyWb2hyX/hp6oFhuuhRxm9/X0PWU1iJx3KFrhaOax+rnwTRq3yT/dSuHDVAp+UodEM4fYIQ95C hyL7OYt6UEb3eYtZ0r8noZMffX+Xd9d3w2KealnUA/H188IKnvMTdhHbLCe6zljMY0ULbJdLzpTR RzGtJf4dzEOZ3w2ebwfrm8H65+DbBuv3w/3z9YfB/vfJWe+l/7LhTPc166vB+nlIf77vs9wPg/WF De/PG9bfButL9r3vvB6sF8h+wZlX0D6D92PkO/+X0HwLj2+g8bM/otuX0LxAhvN7wnL657zfw+6n 0L/EJ/9g+azo92fWAgvmLWrijAVmz2JnyaIXC8d6vDW3eP+9DT/NTn8nvq7HR8Q4x7l0pt1Bb+GS O8hSnfZeeoQ/Fi1wxix2ee62uBfKdeWl57Pf0b5FXh5wvsf7Af+30PN4eE/OZavPLFrMYZo1hXMb nFWOC7MLNxdZqjvrFth2Fr+U8GWWf/NXvjrnk/bd+eR9LpHl3xPJv7RPF0b2pniO2/Bu+PtV9qWX 6nDTYsZT3RVO0Hy6bZHjNfTaTuSuJH6oEP/alV/O/7uc3JXvzue1okV9dFteWeA4j8lr3l3Gj3w3 8flE4qcjZHh9mUz8rPlwxmIe0hxTSv4VLWrpgsWMofnD78mGBTZ6i84VCxz2Pf89x/3u+X12XOD3 S1hYmFBYVPhauLpHTfp85HzBIvcmLOakGxa46RT7hQm2WOoFNWLkzw466B4LmzUt7ozmkwrPOnxc l//asPbdRcbHNqxPns/3bYhpn3DGv302O0PmMf7ZGD4zf7RhffsZXY6w5QF+P4T2Exvew6f4DoyW 8Tt2gg+fWGDogU2ZKnvu55fIcV3vwf+hxWyxPXLuDjbtcvYBMl/x71P02EdelW/dq7Qnyn/uS8/9 VYt8ElZvWdyvPHZqDizDa5I95XPWou7orHK3jE+K6DRh0SuddpozwpmaE4rwyEKnulOFXlhX+K9v gRt0z65b1H3fG0P3WeSotnoNEpbTnKf6pn4jf3Z55i0ww6xFn3I9r1nU7OsWfavF97xF33O7b1rg oA845+f/kuh9HX2z0I3BQz1Suet748huJn6/Bp3qjuxU7SlB18OePHwVl/d53kj8ptwVj1VolvCD /LbOmf9xXb6RdadZHHd3Wce8WvtmrX21L9aaF2P1xaiKCFdEXNcVV0REXNcVESHiioi4IiIiIq6K EFFVVVU1xqiKqqoyYlTUqlFr1Fg1RvXNGGOstcZYe7+5n2/PM/Pi5/fvPOfP9znPOd+zEjlvLbM3 8zyPEPsVYrqCn/bVnGwmkpfWI3tfJzIHXUsXwHAcmWsFZsZf3z6O7AHVQodnSO3HaLHvI/hiPcJF 51I1RTVCZ/gEuzrDys1eJF85i2G+TRD76lD+khOuI6t69YD1snEjklP0I+cLz3t6P6CODb5V/oQe 46+9OcKWdLWH8pe4Wa9rlvdrM7J/TkZytA8jz/1x5NwiLvvB4PrrMJbK3wbffgIT1ao9bN7ClyNs fAI2u/i3jswtYt2OnHf7rNtnnw643Ht32Icez6+Qv899HF9O0XkYydsW+b7G+3Vw6vKsPXUNrSFz wHdzKO9fg3WvWDPGumPe32FX8dbxw2dS/+e57/Hfs+AusTwDjyP2ahd7p/gy+Fe54Lkf2bPE7b8f 7tXlvKH3L7g+xSf1lK+GPlbkk/Jb+fgYG8Ltc3w7426uO7D722tDfyub+L6JX+fo1xn4ku8d8NvG xzVwcl9YRM41Uxio74/ig/iZ+/8S8uYowlbnuTnEteJck7//i+FM9QCuI3w1b10Mr8uzeB553r7N f+/50ADzykB/5XeD5x/xZ449GWBd+QvYaU91js0LHoOLZgr1+RfkxWv0vwQfz1vX8alLjLeI+Xv2 41N0Pma9MPmOPdT7OL7pmziNuOEKNh+Dk9b8NIzpMhcmC71n4Ok58Ct8Ug49QeYJ8qfspbmLvr0h zl0wEKYPwXePeM/w6YI1c8Su/H2O72fYFG+6G5mn1rWKj9rjn7k/weeXxHUT2afE/xa9T5G/BxZa p/r7AzjfR+YAPYv4e5/1a+DwI+sfFbpP0SfZPjYW0W98jgvbb7DxjFifsn8P+SYdC5GcVv/NTbX+ BF03Cr91ltynzDm1votvd/Ghi+3Bt8rvB1fQU34mz1+A8T/ZE8m+Bl+dn3f4/2Xx/m+wcL4v46cw 246c4VRrdHZ1RnS+VE/M9/Yie7xrgmJaInbXmnok/3TNdW0wP1iKnFHN88x53Y9rkTNhB7y62Fzj 7potnz13NpDX+bnGv7lITj6Fftdyzzs1/reQNw/uRPYJ9dsN5Gci+fUytvTsGa+Nnw3WHvCtyv9d 9LoeN7C9w/smcvJzHXuvwME90fnSRY9iOMcH8bdHkbyjwT7pWedMZ2IEffLvAbHpWx8/e5H5UcOu +dZ6JHcxz1yN5HGO1TPKJL48IHZzqH18muZ5t4i5zfMKdpexfVDEv8jzXfbYPG81sp8tY898wbPN AnKekezTCvjrfsK+N5HZRecO/s7g6wK6DyO5xz56uthZYX2H9eZILeKU3jpyW+g5jswDY1uPzOt+ 4UODy7x2K3IWO8SO92ETHRfYkJ5T9uEZ+Jg39IhtD7y91z7H5uvL+LHP+78ia6Ly8mYR9y382WL/ VSO/RtcqMk18e4V91bgp3u+w5gQ7N9hHc7gWcZ+D5z4xfc0/2XCNnovMs0lw8QzoWWAZ3ffZz2li dW1Qr31OXM6rdS7pP8PnBntxhM6Brsof8Wkb+8qD29joR3LdddYcRub3Lhjqv3iG61Od/WoV12Fk rqhHPBr2l8ve1iM2z3PviOkMH75mTTuyp73kWTbFBz/jXXh9y7NqjXrypzwfIXcDHf8Br4F/lT8Q g3rXa76fE7/z9Q04iTerxl3g3zx2dSlHH3LdBEvlkvrfC3C9wbf7YHrG3myC0QZ+9sD3nH3X/+N4 3xsvuau4oWayt+Az8K8yEzlrnEfWNZ+DgZ+VPxPHW65F/FHd1rnxvKCYTvn+GVg+Ie51dCrGO5Hc x3PXA/y/yXOP/b6N7/qnGu06uM7zHHfF437XKv5PRfZaz25TkZxgObKPun5Lxxjf2+ibiKwn2hfl 0UcxzN9m5LncQOftSE6ivbg3xKZyFayUazoXOoefgNFdMNnhWmX/bxZ47WHnbmTf28SfJs+KfRbf pnOvL+/KhT7fXU8mijjnWOd5U7jXkJsEp07kbCubC+BWL3SYc0yC5WQk1xqLrH9r6PHZ30HPDHbW iMX2xpGbRXaTaxJ9C/g8nvG+52r2vRdZv4VlFV9X+NZBT73QuYoN99C5AmfLj/HN+dkAnynkXK+7 6O4W64XvYbyvMZf/x4p15ojuieZm9eH6ym/IAeO5gl5jN1bE4ZxoRubGHLKtSP66gGyLGITbSIHp HDqUP3vcu5Gc+RhZ7/UsPtbBfKHAyD1tPpILTGN3Cbtat4+uJpf1mOubZzkfncfm9eY8s6yVf+of M5HzxWYkH14i/gb/jdM010xk/k6BgeXM3zpc1QLjq8Q0wzdzZekYzIeVD8B0g33eJ7Ytrs/wWzL3 8HMRn5voMubiJJ4Fu9ydQ551XKt9BrrFPsjvI9bZznzkzDQOxtuRc4ryUPmyjj/rkRzXnM97vRhZ a+TvCbGZ43pWWyjWnqD/Oj6UdmeRMc/uF9jOYlc6J7l67Mk0/xrIeq4zR1pgn2bAYT5yFpzhn+tQ A19sdyOyXroO1It1+v531vnsmR/eieT+K8huYGsi8pysRdYv167ZyHNsDOvE4xmpFVkvOpG9wP3O +J9gw9gaJ+eE817r9iPPivzwnNKMnA1mImvNCj56DxvF9+uR9du1s87/8V/ptN+t4pvrnPm0c0BY HEfyh5HIWm4+YS5hvRNg79h8dqcj+8JU5Cy6E8nDa/wTN/CM2wHL3cg6I3/6keepGtkb28iITz6N zEfXL9cs97ge65fQVyP2Dd5d18wlhb04h2rKrcg5zzX2Nfu5yP16geU48UxF1pVpMPJsOoi5Ig45 4DwVrX2ArHSpBv1jcP0Qw9z+PHLeesL6H4nlYohrZZxaKb6s+eoV/uvMvMSvL2LIm1/i6/dc/yWO Q/DeYf04+yNs34Kp8mQLXc/QJbzE1UfR8QR8vsGu+eCXhU333/vIKzbl1yNi3eb5myFGl/qFyQn/ PyF+zS06Y+/Ys++Qe8le7qH7HrresPYVMT0crq8MfKnUI3PxFDnmuEvuLWw2weUCDM1DnWM1YroJ Vj30Kd5byPsctNjLPXDaj+TyPtfmOrvIuk/MReZbB79bkXze+s15lor1U/jQieSR5mHtyL5eRWaU vXFddJ33GW2jf+dXvlcj+9xE4Z97s32Vzg3wLTliyd26+KF4Dor4XH8Wed+I7N09fHG/H4us1c0C F2PqOWm12OdV4uog5x7hPvtxZO13nXStmI/sgbquRdZ+4bcWyQs8Y7mHuWfV+GebNb67j7rGura4 7qzHL3nQKDrmeJZ+zW2TyDgXa3wbjazpzciaNh3Zd8wtRyNnDK25ytWJ7D1T6PBM5G9NfLkW2ccd 0wT/Rlk7hp/jfCvnWsn2Izn/DhhP8q0WWXun0NUsLvn9Id9HeJedauG3fO6x/lqBf62Qd464D05G 8kf7an7fwl4N2QV8NI/2fOC8+BjfxiLnohF02lfjY7wcn+SvROaTZ5CpyHm0yv9q/JJ/NZCXnqXI mtMu9l75toW+Rd7b4OS5yLyyWvjvGqRe9SLe19vL/dtB3r1TvUycYQ0d02C5h+wWNqvIHOLzKt8W Izn4XGRfrmK3iy8nRRy2af4iPy54V+94jcxR5Ex6HdvPkVmJ5ND2wTVT63o8bxCDfDqIX9bcNv/3 eDcX3CpknHOuLeZJa6y1HtezNeQ9K2yg0/XPfN9753q1UtjZjTyHiq+P78Zinn/Co0WsM+Cwi/9a X84J7lvbkfOT67DzcRM9R9ydq6UN4zfPfRP9/ciZzXxurYjZ/cQ9czoy9937OvjXieTTK5Ez0Sw6 O0WsncKe6+Ap+BxE9tYSY/Ni57H3WTGJy7km3o2s1T5Tfvd5dG9tRc5e7hNtsDGH9pznmtRG3nzB /s3+n+zyiZA0P+N4mhy+x9xyiMghh5xWxFqjtda01lorrZRSSiuttFJKUUpprZXSSmultTJGadoY Y6wxYowxVqy2xlhi7GEOc4jYQ4yIiFi5RIycV/rZ+n72+bUcXu/7/v48//98H2U8ga1b1ndm2uTW 1HSHyhnhpLBX1Xr0Cj+ASbmDb0emjZ/qypkIvNUu6JAjZe9mNqvo7lxEzPQKXdte2yvW6taHntnS 3XlnTzmDsb6mxC4hx1hZX/eUsxt1rFvIs+sz68o6vKfMTWYXcCw9lDntuOAzKGhsFbr2zKuh7EPU a+y2o8Rkh/YPtTT4EKtVZezcV2IkasWhaY2U+cW8WStsva2M274y/ndN49Rn8D18sVfNetaUMY7s YK+xEr/VlDXolbJGzYozsTb1XeL6vXJmZe45NK+JZR6Z19R+CVnmylwnpsFLT0ybnOp5Hxz9QDm/ TpT1ifxoFDJ3lLGA7S6VcTT0/nbhg5bu5ij45cB61JX4p+U9ahQ+Br++VNYmYn5gW9JbiRtyuFLQ HyixXei2UM6kbwuf0mf/alrYjdq2bRlCfurm1HtD350rcVv8Pzbdsfcatjd464n/qbd1Zd2NeNi0 nhPzO1TOho9sO3BdS5kHbWVfo2aSm2CZutfI0Wpxbt/6b/r874q7Y98JX/zb8j339wvbF/pDZU3c t63pJ2Wt55/YGhc0iOML23tNWVOJabDKvrInE787tkejsA81n147sK/Io45yNsGe2PjYOg6U8Usc ti0X+Om+6a9b9jNlLB54f2I9yes925QaDU/8y/wAPiF+W7o7e9FrQo6+5WdmG5vOsX38ovgntk5M K2waeONr072wrcJ3c8t/bd6uKyu/Wuq48svb5+e3z6+X3z/UxZDjg5Z4+IMSowX9b+zfv3sfHBfn /nH73Fj2iLfvtMzhP98+X2mJm0eW6wvTXbWtekq8MVTWQ2rwvhK/Mu/Rv5hh6t4HF3SUswY4EjrE BLMqeRM5v6PsW+V8N1L22G2f69tfzK19nyev13yOuanl++QcsdNQ1uUdJWYyrlp5aHvf2m3lp7fv /3j/nWW+8fOFab25ff5lP5H3A8uPbVqOB2KKvIx1Zi58QF879PmxdXUcr/zeZ+bmE/Hwvvj/p+WN GIqYiPz8Xsta8gf75cZ6hw5/9NnQ729a9oHyO2T4dqnnyi+sb+xfWLfvzP+Nz9/YBm+999zfQe+l //Hday1rdujzJ8sX6/dt2/v2f9Vn+vbBpTJWQueIz12/sRUzR4nZ6bVd0yF+tm3nz5S9AIy/YZuB 2apKHB3rq8r46yoxX8WyNP3dMW36NvPNvmWJvXXvg81qSrxbtX6fmc9rZR2kX7dNd99ykxOsha1O iudcOddcW25645EyN/eV/TVonvkO+JCeuWr/RixQjy99nn7atD7YkppS9X6/oF0v7AaGafoMvImP mnJmu1Di/xLrdixTq7hT9Zmw0ye+s2rac+sRORZ9IGIk8iny68bvpm34znTjzLe23yvvU1sjH58o MXesvbVc1+Z5aZ2ulPWU2ZbYm9sGQ8sTvCLGonbNbGvqet8P+GzP31u2xb5leWg7zJSzXon5Vq1L yAZ+p79PdXdewaZxn9km6IE7uXtkG8R9sCA6Uv8ufC7uDcwn7kb8rnvtSBkn4PZzr82sa9f07ynz m9whHmNvw2unBe225drxXfD+jhJ71+0D9Ke3MnPNi3NPtcyjA/Moc65hn2/73rrpVXw/+IGRwaRg MvBr+JK4YO7AjgeF7vSXmd+bvn9cyA9matt/sVfOVBe+f6TMBbAKNRIbN0zjUv8fH5vK/Dq3f/Ep +PHK8uHvrnlT80deR++uv9cL/3dt2475UQvpJ2Be8og4ZVYEVzD/VawXcRDf04L3wL7Gzw3d7Ts1 f4Nxd3yvqozlUeE37EY+N4s18OyVdT71OvgH2cDv4KCW7b6wTnvWvW3ZP1HWgqZyPuNM3X6NM3Pz KOPKsf8D7g1M8Mz2jPWXyjo09v/YDzMpuI0ewZx0Zl4L8x5a5y3b+9j/m8qacma709Pi3rXvbijn p+Dx0Pttr9HLZqYdcRcxHjPAqmWe2h6Xynlkan5x78Y0R+bHGfQfK+vYpX1ErSFHmkoMFOc+WpY1 8wp6EQv00BPfuVLWFWz30bq7b678TFkXyOVjZW+NHKiYx9j++Mr0GrbHX3xuoJwFsBeYZaGsXbtK rHRqGZknTpV1jRmVmbRiP9Fv4j71spwZOLdZ+IE4r5nfqv2y4bvbPkPO7pjWW9M4sb0/NT8wGDiF 2kyv2LXMO34Toy3TrSnxzap98l8tsfXe8nvlkW3wzLZ/tvxfWVPmBfoFvbnlCD9/aT7MZLtLf/8g w5ntzFxVL/QZ+tlX5vyWst5WCr4jZT1wvV3ZXc69P9avoW0ytZznlpN6sTCdkO9YifHCF8+9v2WZ z702tz/G1inuTZTz7EI5M/V8Zu69oBt5/rmW+RE2jV7z1OcOTWtkW4Hbn9pm4LieEt/QpyemBZYI XV6Z7pWyPhEHY98Z+17YmBrR9To9Zkd3cdKBZYDGY693lT0r/l/7+74yThaWqe+18N8D24I8PVTm 50KJBbBHzzLVlHlatRzcI56wG1ig5nMT893w/1GhJ70H+R7bB1Pr0vJ9MEjoc+17ERsxk1Z89klh E3KgnJvO/A/+X/Xai0KGvm3NTDVQxkSsR2zGrLZlnviKunptGtgu3rvmU2KYYeFL8pl4GCpnHeLu wvyC757XmCvoxeQAfY8YDPwLBr9nvSa28RNljYH/lX1xqsSHIfuaz4zM71hZ60/N40SJIU+V+UC/ OLK8YCh0JN6mvneu7NEdZS9om3a/4H1R2LRjO1G77ilrNXzi7ML/4Ku6Mm7o49QZevXYcrSUWPrE 8s5tp5ESW4Mf4Qluiv2HPnvu9ZNCN2oTfEvcfljI/RvrRt2mPk+sB3ExNC/wALVjVxlHYFd81DQd cPOZ7UPfCX4Vn902nb4yhlrKWJ4pa3+v8CM+hVa7+MYuDb/blu+60D/OXVqmgbKGti17VTkLNv19 ZHtt+fvS+vSVeIY5kritW3ZqcU3Zhwe+B7ZoFOfPzGPTe+vKWRPs0PR7qMy5qhKXVXxmx8+GzyN/ 5ORCicPoJREn4MOe9+LMN0ocU/Vz6v1zZb4Hr+fK+rmlzGHmgne2HTMhfeaseC+8d+A3tQdMDcan Z7LHbNbzGjkzKfw7MQ/ivWcaYP2p9+fKmalb0AMbTQsZmB3pOWDqa9sHXuQo+GRS0Ib3fdMceT3k +KjENdQ74gRd4s7AawvLSC4d+s0dZowzZe2lztCTeILWle72w5lyrj3xGtgQGsw6w8LuLWVtwZfH pk8NoC+Sm/DrF7T6lgVe+PG3fqMT9gDbx/r7gi+1MWz+tZYxGn07YvZL/dhPV36ixHHUpaYy/5A9 evyHQv4Df9N7usraTH2+NK1BsU4eULcmttFMiTFryn4Nzt1RzrIT+y74P7Ce4EN6DrnJjEsvgOaB MlfB4O3iLrWQmAp7fup70NtT9tioB9S6lu+N/N1Szmld5bxWLexDjaXmH5hv1Mg100UOdAJrN32+ 5e9uwTdk2y58dmi56Dsjy7Fn3k3fa1jfVf9XlTWVekl/oW+tm9/n5tdV5k/8v1b2RPBWrzjD+lhZ d6kjJ0oMwp04B54u9ZoWelBru8o6hR/Iw7IWEhdVZa+P828sA72m7CXgmqDFrPXA949ND9uD3zq+ iwxh/0Xhx13TbRT6bhX2H5heXYlzG8pe1ynsdWF5mXuHBd1dnwer4suO74JRwLSdwnZgZGQmx8Bu 8V0p7FrxG8w8VuKrtjJ30KfmffBnr7A5cQA+OtHdHAk5v799HuluT52bb9jzeUH3deG3dz4D/mj4 H9t37VNmIrDRVNkH6YHE8FSJzcHa9NLHhc4zZc97ZNtQT5kV+taD82BtYp9+OFPWi4ES18F7bP8e mca571aVfYxacGFf/I/08o+MO0/jeKfWeqx1zv5z1to/1lmn1qqKiIgVxhgxxoiIEREREVEhIkaM GDEiRkSMiqGiIiqq1qpap6p/rKPWOeec/lFV/WPVOquOs06tqnXqvk/m9e7z6exMtuf+eHy+n+f7 +Ty/P88PxZd49MaqcqD6oqlknbDImy32/p3HNlWLfvMS/wsWvd4VfL2Z+H4uoetyeO0cgb/e8EJC x9cv0HUaehXsof54mbPSXTpJvpJF7yn9lct9HeJ/GZuPJncdN4YN1UuOoK/6YfFahMc8cu+D37N4 q07rU/yheUUxqncu2WagOYrMLudwot8oZ0vIOYeNJxNd0967CF59c9Gil1I9KQOStQTNPDQ0l6Zv X3zmsEkVGqk9pEPeIoepP3W6dzP4IYMfsx7n/Wz9PoPHGfwr27+bwTv0Pq+636e54gW4n7r3Tlen 8dK6vY/Tsmz9d+zP/Qz8k/OP+P5Ll9fpe3lo3T7XcX/lnM8dD6zbmz0A/z3nHiLrPzL4LoMb8PP/ z+B3B3DcH7nj3/etW6uk+wfWzW13OXMH/g/Af8P3n7vfp/p7/X6awVeA83+CTE+gfYx/5Y9tbO++ qlvUY/VUUxZ52c94PKuXnrPoldyHnpeVOzc5f8BZt+80djuxiLFZi3nWZfP37e9kEt4emy30v4ss NcDzyj40nK/mCpexg16H4B8h4zr0OhZ9tvrQY4uarZzbtuiXVDdW+aeZR3bYh/aCRe1zub5OaLbw jfPfBVfDJtc4qzlFNJQDVyz6FPdHnr2fvc9/511B3gl0Vp6TndQzqw9wPvPYu8YdX/2t+jse4kze Iico92wm/0oWeawIzSLy6V8e3JpFH1OxyIGjFjl4B14fo2/FIi+5zUe4L/3cTmPwH4GP5+dvE56K j1lw1UTnFfgs4OM5i75PMVIDP2rR+4qfbLiDDtKpmtwv8L+MLeqJbpqhCtx1Ghe5V7bIkap9y+ju +GHue5wfWdR5t/015Lxl3Rj1POG5Q+9HPbv6RPdLC1k8/nctZhX1rppnfwSes3oue4n9PMZP0P8C dN1uHuOaUSroMArdeYtesWjRk0wm9lN/uWgxXxaQvYR/FsFPWMS33sVsQlPxPG7R1yiGxatq0eco BisWPfc0Z4cs4nE3kcN5P8VPqnct8P5+Pkl0v81dj6dnFnGzBN+nFvF5gA+3LHrjFn65gUxrnFOe 1yyot+Cy3kpknoHXJj4eRs+8RW5zO6hfdXqaW+vUofsWefQzYAiYssgZ6pvq6FvGD0Vk0Py6zn6C Vf66mfhbMdxilY+m0de/xyx6/iJ3XyQ21mzob6KR+HsFGdSPrXDWdWjji6vst4Amd1SrZhOQntvo 04SO54VOYt8GuBo0NWup7txE7hY2bXF+Bx30Blf5r5oo2pqFVA/3+F/ju4S9mshdwWcbyN+xyF03 sOmcxRxVsMifY8hVT2z0JXLWLebKXeg3Ep+ks2YdWspvq8iqmN3mfyvxg2qe0zkA18Hmmr+uwHvf oqdYhKffOQE2uHsDfdbB77H6v2N7/R5O6S4n+jSgqb5qHxquxww6bKLvssVsu2URu5qhKpxdRnaX Se9FuXIEOaTbNYvYdJqaEbfQp4Fd2ugxjWxb6HYHnqv4YC3xsfJQDVkUfy7nbfC74JTXtzh3Ad12 kUn5cS7BjSf2KVj0fJt8C9xe3veNcWcdG7UsarF0ugzfYYv4UV5y8JxVTO76vbLFG1Etd12uc0c5 qQavq3xvWvSKBwm9DXszvy0il3psvVXhh6GxYTE/XkbHqkW/qr560iIGd7lzhE51eKiXuMA55d5q wmuBf/Pcn0/814beDDjlZOel3rAJaBbVLNkCX0WOKc430MttdZv9NDq43J6rOgn+GN9XLGLhjkWe mrPo0Q74P2Qxc+iNqi5Ll62E3oJFH72M3h2LPNPAbvL/DPy2sIXr+y04j4tRzon3Ivedzz73JdMR e+VX+UJ2W0v4KL6r2LLYI/8xOi9jg0piU/fHCfeUXy5b1HTFkMMhukzDS3lynnvzibwH7E/Qw/Uf R6YTfHds8VZWWPeQX72kemP1o/JtNaFf5X4jscUeOkzDc8ZiflMcFjmreSzP+SL230LGkwSa4NsW 79Vpb3B3CXmUm3ex22HiP5frkkXunWfdxA8dQH7wf3qrAuWrSXi2LXqftkWd22TVnOn63EKOskVe 0py7y5l5fKNvp3eRM+q5XG9/T2Porho2b5Ef1izyusfiOOd2LOZVl3+fu5/wz/l9ldj3ED1aFrOo cvs8sMJ+O9HXV8XCNn7yejJsUVOa7NX7yMfqIzW3VC3mBs0sFdYCONU91Ysp5N6zyJVT8B3m/FXu 61wbfdXLu32+5Fu9xAK0luDnoLlpAftsQGfBotebtOgp3I7XsEMpsd0OdDe4cxkZb8BnE1uotqhX 8vse83lkm4V3i/uX4LltUffbyFTgXo0zJYu6Oc65NYtadwne09w5Qg/53nHqharoU7DIfWX8XIO+ auMWcinOpMsMd/fQX+9Nvljj3wR09y36nir/NKeW7c0adDWx5xz31NOOWcxuIxaz43WLXNrEhur/ 9Lad/ih068jdtMgp4umxUAS/xN75L9ub/aPvOxb1XnPRmMXMovlH/ZXecpPzqxZ9j+6nc1beouaW LPLEDjTHOON0DuG3zp0Ni/cxia2msPUU51yvW+AWkGsaH8iPTnvXoudRzzQLnTnkP7SYNTRrqY+S jC6fYmId+x1hg9lkVa7UbLkKjyGLPltzwSqyXkaGI4s5UnNr2mMJVi16MpfbY6CMPtuJPWRT5dgr 3FlFVuVC5YslizxctHhz2/BdsOjxJuHr3wXsOYluM9itYRFDefjrTalOrEPfeVbgU4Fmgf24Rc1p WNSeccBjaQR9Sxb5pxfGWfPJ93gCteR/ie9LyKN+YroPvV4a4wmPqT5nSgmk9AbJU+vZj/fAxT64 UWTwdQ6c1s+TM477Ar9Pg/e1nNDawA4jCa7AqrgrgysDS8l3Ssvx6nV0bwvaQ+BKyb3JRPZhi1qZ 0ruY4FPbygbaL/SxU68/nManFu9ZOvaCbDkEpP8m+pwXnzL2Ft7vfoachZ47eo9z6Ci9VRfcZhf6 8LrAHYdi8q3/7l+fsbzmbLIeAf5G71nUDP/23tHz9hoyqEbsceaEfZmzXtNUhxct8qjfUz+0Ak79 5Z7FTLoOXcd5r3IZHm3oZnk/l8mTO5/B+3z/IYMsRnPZ+Zz3m6+y9WMgyw+5D5P9N8BQd3/uebZm +TyX+Sc3C40/ZfB1BhnfnNviJfyyXJX7HF6ZjLnMfrl3M3gvg99m8Ht4+D7rgXMrQOa/nMfVd/D5 XQbG9zZnMj3Pv4c+Ds/j+/xvMvgg+dcHzn/YhVxm09zdLr+c88t6w1yWb8+fy+AjzjwmBu4l670B e/Xs2mvu0yzlsbGBL1fZd/BhMznnPerN5O4OoP/XE7zXh23iyeVpgFs+Y++8J/rsRb+NXFeQdwfc SQ/sE3d7yNxKZLvZo4/b5j8ZuD2f/p+Q2vOQ704fO/VCB7/sIGvv/3YXn/uoC6/5/QT8r/teOXcS v/eT8whbHST3+smp+6+A+8DfgLfdC1L9N3r83k9O9/c2q8eA5rFevx8i/1P4PrTTd326Phywd3gO 9O7TuJM9679iz6O38Dv3X/v957eAH87Yi+5xYpfOGfzT+LxrMY8NkjP/Jm/fp7hf7N/pwi/2g+Rs DbDntcSeR2fICf5UDq+9j98SlDd7973xqfWs+GxZxGfLzo7PF906dPqvjp5N9s0B+3pyXvNhas8O /JXv+8l51aKXaPbYM5VT+CcZPOKs0/f6v5LsG+w7wDJ7ge+nErrryOVvefEMfx5iP9l7kJyqAZpb nmXw9wyyHuG0TqT729atP7ct4qp332tP1clBftc9t+cWsmwPOOf6eI72/ON9kOfcW9wftHeeNWjK Z6t95NQ6yJ6p35WjVMf6+V11cxMfzuLP/7JfvpFxb2kcP5P500etqr67eu+La8Xdqlq1qqq6oaIi IioiGxERFbNjbEQ2RsSIMSJGRHbEUCNmI1sVFRFVVbHWJapWVdWqivui6t5V19Jdq66+2G2TPc/8 niNnniZpZ+ecZ+6dzouP3+87c37nOc95zjnPc7ieoZgaPUYaa9Fh1m+BfMp9RNxNPD+0PnH9pay5 WoDK3Gd+n7fsmidf//Z8Gg4apx33Ehy838339yHIRzka4//znIH35/NDcd9vnKbdA6vdFOydX5if X9WIPZ82h8V9Cfby7AfiXq7hFc0L1n9r9DxIz9JvE7C3rtYOGOccHDzOAo1zv/ncL+63iY2PBPdW mmwYHWfjrDXu++RN9QSC9fAQgjPRsMm0a54J23sIlfcn3zS6f5hXixZ5pl0j7Z+5Wxry8P4ecknG c/+cbtirbZAU065JwN6Zg4wy7Zo0s18Av/5lhJFcKwjmxiWLVaZd0wPBnjPcYNo15n4ixaJw/HB/ r1jcYNo15o5gmPc8n3hmZy2WmXbNEFTm3zT4ze+9sHc3QuJMu6bpn1s6Ich5hg6mXdPo/qE/kucn nmcLFgWmXYNr1M5PKfCb//DMts/TBfB7XkvHT5oVqDxvboLf8wzPyzmLJaZdgzG06+0V8FvPr7P5 XfUcv5Tn/jk5qKx/i+C3vp7QvLXYZto1L2QJHZe32fTPoX8n6j8Gr/59JWwzA7Ln2TBU5vsi+K0n +pn9gmf/Mp79+dTqpQVhe1kI1ohhk2nX5Fk8Z6uMf7UsCs+ndL2ENa99X5oFr/ex0ElZ6pKXfhCk 6V/Tvx+zf41eL00zPerZXrNecp//ShZLTLsmCUFNYbjBtGua9ZJbcp7nj4Nn6I4gW8I8EqbpX9O/ av2TtCedb/n9LwVe73/lMy1vkWLaNWsge15PCcdPmoJmziLLtGviTM97tof+5ATh87vqOX7S9RLO adFilmnXPIPKu+4jpl3zWvPU4jnTruH2fPOp+SdhT5pG9i8DsudZEoIcZCgy7ZppqKwvJsFv/ZLx 3P9+9iTjJw3WvCVBcH0WLDaZdk2exXO2yvhXy6Jw/OpRLwnuv1Cr5qQgEW33Pw55ffj/zu19gE/O v5c/sfn8xP2rS720bJFj2jXTzH7Bs3+8PvOd/9LC8ZNmQdheFirrmXvgt15KQLBGpGjWS27rpTOa y3uUz/DLNdB6+P/Oz//XH25Tkz9N/yqRzu9UU0jSyP416yXH4Hza+WkG/OY/6fhJg/XSkkWJadfw eqkEfuulfI3xb9ZLlczJzievl0LnPdcT9zXbgjTt/bTtbQrT6P6lQfY8S0CQAw0ppl3D+/dtbxJE 77fi8ZMGa4o5i1mmXZNget6zPV5P58Bvjufzu+o5ftL1EsaraDHLtGu+1bzZI3S0UjvnGsXMMMm0 a/qh8j6RAb/3Fe5fpsH8mxL2b4jZn/Ts3xCz73t9or1Bi2GmXYPxkjzPML8vWxSYds0YVOanFPjN f0mozE88H7pGOn7SYA163aLEtGuymrxFhmnXZGuMf7XcYfO76jl+0vXSivB84p3zG4tnTLvmFARr 0lBg2jWnNeMWSaZdUw//0hZJpl1zinySAu3FLZJMu+YU2ZCC+9fj2T/pfNsLlftjBvzuv24IcpLh GtOuwfut5HktHb9bwvYwnxctcky7JgHBmpQiXWP8q4XHr9HqJbyz2PfdWaZdg+fJvCDPNd9bPGba Nduary1uMu2at3X2b8Ozf8hdiw2mXYP92+u1BH73Q6P7J51vsSZctigw7Zpp8Hs/4aB/kvlWOn7S XAfZ/TCqyVtMM+0Du57Jgt96aVE4fvWul3JVxr9KQif08weL50y7BvfDmsUi066Ja9YtSky7ptH9 m6+Df3a+mAC/+WgSgjPMkGfaNd1QmX9HwX+OlzzPcE4l66URYXtJ8JvvOI1eL+F+u25RYto1Zo8b SuC/XipZFJl2zR02v6ue4yddL62A7P77l+atxTbTrunUTFnEmXZNu2bAIsm0axrdv16orC/GwW/9 Uo/4jVmMM+0a9G/EYphp16A/kucZrn/7vCmA3/MM7S1a5Jh2Tc6zP/Wul24J28N8XrTIMe0aXC/z gqRrjH+18Pj5rpcmPPfPyQrPZ4liaEgx7ZrbUHnezIDf8wzXx4LFDNOuQf/s/TgDfvf7qvB8on/2 /s+B3/MFbdrr1Xd+us10xrM97p9vpPMtrsdliwLTrkmRDSnmGjx+0uQ1SxYlpl2TJZuGEtM+kDzP 7rD59V0vpTz3v996kdx/rzT3LR4x7Zp1CNaIYYFp19wQtlcUtift3zNhe3/9xPyb8WxPOt9izWuf NwXwe56hPcn67C+e/al3vcTzrUT+k6yXpkG2XpKur3n8HniO35zn/jno45QF1655Qz4atph2zasG 5x8/gjE0aXIQ0vl2FPzWK5x+YXvoXyPXS7eE7ZUguHMalph2zQQENbahyLRrpOslHr9Vz/FLee6f IzyfIaU5asG1Y9Q6VN53V5h2zXXNmsUK065p+ueWLFSu2TXwuyfMGWqYZ9o10v5J51ucP8n6ZYrp Oc/2pOultHD8pMF4FSyWmHYN7oe8RYlp1yzWGP9q4fPbrJdqY0NzW5AtsinFDWF7je6ftL0FTdwi zbRr7kFwRhs2mHbNiGd/OPWulwrgt36ZFraH9bXkeS0dP2mwprD3Rwn87r8syNZL+RrjXy13hOOX FLYnXS+ta55YPGDaKS253cXIMXUKCb/YHUciSn1epleNKfXfNovfKvXuT0q9fan5tX7/RfC+o3n3 TjOg33+nGY89Kn97T/92RD//oJ9/3Oe7rH7/vX4+bllTf2/pUj+H4Py5BsG+yUGQv97S3HQR/Zox zUtqf1nTp+mG4Hxu1/TQWsF8nqI+BzUTmoRmhvqe0nRAcC819xv8LU5tO6gd9jesGSKdobEkaKxj ZA/HdomePTSmKbJ9EYL9maDvO2lsV8i/FDFujXmE+pqg/vH3beoTx3KV2g1Rv9jXI/JlnvrqpTm5 Qu3u0/dpAn3HPLNA9sxdb5B8wbkdgOAu1kffzNJ/1+j7ERpbgp4T9H2B7H9L36RpvkZpfjboHTkP KoTjxTr+DI25n+L7b8050iM0j13Ud5y+6aTxmXWSpP+Hyfc+Gq/5v1WzBsEef6qZJD9TNLZLwZjK 723UfzfN/036/Sr1tUBjvgDBmumnOe2jMaSDuQkdC2IfGqbfe2mc3dSml2J0jvqN03ge0tiuki89 VnyWqP0V6idD7Z7SuNtJJy0f0hSbr6l/jO1F6itB4zDr36yzfmu8uH9ew966N/FHHpPdczQ+nJM3 EKy7JPnVA3vr5Rr1u0g+or1Rmrs8/W/2HrZ/QrHqsOwOWvOJddM9K85t1G6Q+hwnf7qpPf5+ncZq YjpF33XRnA3QPCJbNNeGnkiXOmnOTfhGtUd+tkfs+1AyIBzBZ2RddVj0MTo1m/TecQB91v/mefeQ 9r5oD+yHJp3aH1GtRL8m8RFPm33/i8XV1EeQttHfpa2xtIbPqjRCv5eJDu+rW/cjelf1GOi3u+z/ i5rz+n2CoPGH2lr0mtXvV6Nn1aXoUd2OQX18RVT4Hs2qm+X/aX5Bv4OlD2GGcWh7UGHcvzonh9aR 2AX1m5jS++KymosdV22xK2rAov9IqxrQef9MZFN9GYmry9F1Nan9OxvdVoVom+qObKv28vtxdSo2 oP1aV+PRJa0tIst6vg1Z1R3u1LXMZ+psZEsVWnLqy5bS7j/1+zy+l+uc87rNC71ut9SllrvaxjP1 q8icGowsqK7IF/q5pvvU7cr9H1eny9/pfvG7cptl1R56vftdyy93v4udVplYt8q0nNvd0b/tuNZH bqnMkQsqE/7z7k54+30dGVDJaLsai57e3Yl+Vr0Oj+u5WNMc9BzaTYSnNfSMrWj7c9p+Svc1osdb pY7q9+hDvYbpafzU854J/01l8Bk5oSJ6bnfCSd1+Va9tZFq/a/QaWQzf1m3oGTv2P9bLPTaq4wrj 587OrPflffAoIdSwxgVEVkCA8rgyFC84N66h1CUOIZA4LsXGFNEtQu2CnAohGhJAhaSlFIEEkgnU KSmBXTc1EJtSSMLL4l1qwIEUklJICUKkIRR7+829c73OGiuq2j9++82ZOTNn5ty5d2YxTgsZ9viO g6k85CbnodpFm3MC9ciKU6E9l/Y5lVMNz6Ma5yTiTidxcTOVI3aCLtRdS4Xu+dhXeak210qcCVPI kGXRTBOdM8hof6Y/oZhJCc4v6beZjKxq2DbTUb8W9a+j3vbN9M+wPQsp5plC8S+pKntjFGunGPYJ 6O+U2kg7D/5t6Avc/6KY+1QHxRlv47oInx6IOZiMTBvPqsa1D3U2zZjfevQ/Ad9rXa/H3Q9jK1z3 Md5IjFfUtb/nIOa6GXM+T4b3k679zH2MvSufASsjF6skv6K9LBaiHWR1p3hWA859PDfX97GW/1O9 Zzgw0up8jWrch7DmZVjnXtQhN7KP7e9chPYf4DvYxXhyL3XVllWM/aVwLsLe+1Ha/qo6qR4j1eaO dVZvYRrPAujrFp6mdNm2PfdALvodw3twN62uc2my2jroq2nEPNTtefj8zDFsch7u49mAeAesb8VD 1zgaOrxrlWtzV6XVOQOxaq32TF+GMRm+UWx2qs03hgwfnoHXA/ql1bccbEir9yWwsbP6roJ7ac18 Z921qSqJx2Vhx/McAR+ktVO8ReCVzvrfxst8/jI3Zp5yv7w3vuSXa8GGUY12B9/SJqrlTdp47xrk 6ymK+Srgt6Yz/q0U869KtQWOkxH4IxnBF1JtkhDe50CSYoFX0CZZQ3H/brTdoFhwP+xbFA9WUFy2 hZIdfJVfqA1jvYv266ibi7ZxiIU5BF8lw7+D4tlnwVi0ZZMhy4H+GANlP96xbJyV2c9TLHscxX1D Yb8In7nIXYVaC+rM+b+I/Mk1BOA/1lqDXe6o/ktAWOs1x1H9zfI2gDl5n8H34WPUyVgqXntc5SPH D66x8iTz0607NGmp9JV+dn9Z9n8GVqm63lZ8c529rLXI8cx5HLHWKdcW3IoYW61Ydl9vq7WOQMjK tTn+MFrqLgcGLfVcSFUFr9HUbiGKh/Au+ObT0uALeA44DwIL8d9sLW1wbKSFgGy17o6OXRYp+V+R 1P+ycvW/0/7vOa1DfSazM9hogfeYUg862tp0qsSduhC6QJZBjL1JOrSKN6XuaRupGAwBeSAHlIJc +PgdI2mU1kKDWRP6b6RBUm3Qn+AzjBfSTH4Z534l9ZDfCPP8mU3BdlueQeb3A3Vl8nuC8wjfFC2f nFo+7h/5FMN94RTuQifx/pThPSqz7yy2nXm3kO+ZfN8y75H2/eqr7pv/8/0x477o/gWVSJyDEQtk 2p5SKpE4V8Je2dl2NuI/WSMtFi2I19LZxh1+AV+E/0W7UI6l7mfamfdl/KcznOuppN3OuD8KfFPF bORzmMrH2ziH+1Hc0YzyxPT9NTOv8rxxjE/fP+3nYuqC9PPhVakT/EzqFK+iID8DMhR7/5cuYtfx 3+ky9FGoE2xA/ToQAH7U14Ecq47dgq6HXgNh8CnoA/qDLGsM1hcMVAofhxrP9LMZhPdiCmLh/dLO gSWgBlxEG+alzQQH0G8z7JjVxkZBDdAIJoJTYJTqWw/2qjb5HpZAyxXvYBwd/a8qlTHvooz/j6wX GAmGK5X2ERABU+GzHcj6IqusDUMZYzO/8pdcttpZm2rrDb9BygdlNtjycSSUL3HCviGcUUSbQYyT 9hr0JbAMlKm2n4GpoEqVZd0isB3MANPBUlAKDOUr66eBElCtfIqBDmaCOcqWfZ5Tel/5lSodCX4I isBB8DIYBYaAShVH79C/XKmcYxw0gwHgKpDrWq7aI6ovqXEmgMFqTvlgvJULc+wlai4lHbDXOVHl QjJF0QdwNe880AsMAr9SOVuq1n9erekMqFc6TWmJyt9wMEbpeNU+QeVlgrJ1q01LWHtHu23ta3Nf oU474jLH02qVf2MHlXktUufNTqJWP4gSPVgNFoO1RP/eB92C+vnQ3eAWyt2hv7H8WldBb4MKy8/0 xUnQWmkpBdLjtk61eNBClBqJsuzzvkUrpvLgXXAa5dPpeDJW61yU70LnqHiNYJea5+p03I5zNudt 2yko5nJ/Hfovt/q3htUYdSg/bfm3r3+xijkLuoHo838Q3SP+U6ICj0ZaX83QyK1FA/wiHvUNOsuu k4Yz8CP6OVgHHOwaO5YQkXA9O53sG9YfqWdnkuFcvWg/O0kaO8WOk6AIO8GaLKcLifAAfQ87DptJ uymp5+tSE+E8PephzewIjcAJ/Nd2bU7wiLeBNdN8wNhRM9yz0d7sGM0DjJ1jf2HnycfeY++zw9AP 2d/YVcpmF9kl1kLZ5GHnSBOHRW2ib26faC9xmJ4H80E1WA0EDRTvUb44TpNBBcq/BoIKxP6kt6de vQ8HgkZhUZ8cMRqTFfWJnLDeII6Jt/BhiYi3xBsJR+TxetGY8IdQ3yga5KLFTrEbc9/UIHbTDsAw wtFk7gA5wtFkt69JPZgYOkLfIw6J32OEFfvQUcZpSOQMRO0b4k0k6ZF6yIhqPTpU1Ik/iLfJJ7aJ 7eK35KOA2E5eUYdQdeSAJUvbTGsymIVyNdhhUkfHwE3gEX8SB8SfKVvsFfvEO9BKMQc5PRTtLubQ WcDoMVFC3xDP0TdBifgulYMfAydyMi/Z81G9T9QjimmCmEp1YhZ9Bjg9LoqTPXvrSERpYkyBHu0m ysUTZoZKlX5baZHSJ0SBlblJiZ599D2pK2JSMtRDjvBkMthDL2wUTyIhS8RMPMCZwkA2Jke9wsDS DDxAA4vehF8tdVIUJgMhfTQaZ6PDCvkrykQBHCLiaTMIkl2QHKPrpob7yxjRBGLIoNFkdkD3RnNE BTrPkr9ispgivoNUjxPjxbeQaq+YjNpnxAzxLBL2PTFNPCW3Fv8c0a/wuwlfUI8+Jrhw4DsQEQ5+ y1TGv5DKU7zF1Pu8GXmK8C+UfsovyDzwj/g/Tb0MW4PeRjumzi/wloQr4ol+XRCiE6JlYVSNf2K2 tvE75ih34I39xm+pXtcQTerHZu9wPQS7Lurnf4eDEw0fqPAfKr3C5Us2NhqCrfGL/BL5Sb7y/UAR cPAb/CYFkKmXZaaQuhXJUHeke6hYZmZsC7bNFqzACztbrADrKAeaAx0CImITXrT/MF6uwVWUZxx/ 971kJgnkcpKc5OR2zkEIl0PMIYSkiwpnSZgGCRBp1Fo+gDPa0qaN3CxqsGQq1hstqYMzgnZACW2V YnAXO8GUJu1g1eKFduhMW+2ASjudYTpmHNoPAkl/72Y77cd++D3/d599970+++6zPxTPwhvUKRCu eYYnF5rvi6NmL+H5DHG0V4yiZyHP/Mh8h93OjZgBf0Yx79SAeShc0afNzunN7PfLq/A/b3aFkfSw 2cUUerx8rh3xBPZAeCdldgU3Zu2u7wp4aUONlbsZKh7kjT9IlSfMAyzugzQsM3ewiTu5+q55xOxh +7ebHeZ+9AdmnxlkWo+bJ8yTbHy+qRIPmVrxJPzNLBL/AiOWcLUSDsJL1Ph56E2ZuqC61jXeQlPP 2FaaOuxSU8EIm4U0raY8nMGSSFtQG7bZSG+MtBFls0wmqlcZ+ctNESuy0isys8XtIM1CUxTWXIDa GjFqCI7MxVzbtbH2IPZlkCZhqk0NUywwhWYGkb7KFIi7QJo5psHMZdJJkzJpJq31BlEOZ+EDuAxX IS+80wNyalxvCGJVbolXoTk5YACeAy3GsefgCij9FX2XSBBhd6nX/KLkbq9af1nsg0MwDGPwPuRR 5w68dzDp2fpOsQfOg5o6p9cH+UXuBh5dj3s941kvJkCLQt1DdtJj9193ixxsgi0wAEavU7/yV6fL vRv0KjEL7gFFfr6K+qtENvJsgwEYhMNwAvKZzBpxDCQ54Vpel1vVh/6CZKGX1F302cXr1EVm1UW9 Lup1MYH/9Y6CxtOOp502NvAP6eiV6i2/LnnFi2tOM+p9UawGKWbqTup2UrcTbyfZXqd4CvJY5xVB QcwVTH4Fj2jtiQ7ogf1wCYxo0TfjuVnsgP1wEgzTa/M7b3NP6zb1oahiedt0nT8/eY9Xolup2kq/ e7D7w9J+/lEPg13JZX5VLY8tU2+Fj93CoOcni725OstjWZYpy/5mxUUwnB9NjKiJO03s9ia9KNzt jZEuQevRlkgXR9qsF/n1yQ6vjOsesENZxPwu6/nYQmwNZEBx7C4I8me6vd5TeiF590Iqr9aNrE+j +AdcBU28NtJQI/NoZIc36AbRC5IYnkcMz6PUoeeKM3Ae7Kk5l5X+r+cSXIE88p85RMgcnrhHp/Gl KfVg7dV5uASaHlL0kGIUKeqkwr2up9V64qGe9nux/bAPPoCrYEKPLUmxTt8gNoKdyyxamxX6cuTo OV4C+0ErxjbBIAzDGFyAPJbanizHrGVxaoPiavcWL6UTxEE1zSWYajXU0KHWcZYmzhsVF0O6ksio ZEniDCnOWsfJkrfocpuL6LIgf4b7HNFdRstlxG8ZY5itLokW4LcKWw7WcwbsL0ExEV2ETehSHROJ qXH1sT9vvus1qD8ScbNEUv0JTaJ/RpvQD9Dt6AV0AfoXdD56EZ2BfoQSNurjaZ3C78cq3dPqQ2Kx G8e4ei/q4gwe28UbqO3iN2gWfTPSt9GfoL9Fl6JnUdvVO6jt6l3UdvUe0V2RLBzlktVUf7dfjdQI Tk63UypQPnFa7M1Sx0WxehV8njkumkJOwKvgs653Exh388FLqZPCUcPqFVGhfO5WiELuO6Ld2e5n 0+0jzrZp2WrlF84WBpueuuhsDcrjrjjtbBUlIPFsCUrjbm7EWeFXVpK9jDue7y6NCvMzUSFRHRXY PFtY7i9fHhXIt6cLzYujQmNTVCAtmi6UxacLQX6Bmx1zWkQOukE5Lc4Sv7yi9pTT7CwOKIyNqaPi U5gCxUa86Ccb7NPqaFAwwy0ZVUMs4Lg64i9oDButCZrb3EGvxKll9sKpYWI1IgWDoMUE1rHV/NrZ 0/X90qqowGhsocwvrYgK//HkHq67wb1wMV5Ze/4PmP5d8ZqN/ff17+5X/bsSv/s9rm/vxHxrC+ab 92F6++I16/o29t3Xd6hPi97dvQO9J3r1+71Ob9/ubdU77mdmX/sG5qtfx9y7ubxm9+Z9m9/ffGGz zt7r3Lv50a3Vie3xh9oT6QdBjsjb/faGtJcv18pu++2Vq+XaUDuD9vp0ziuUneGPU6fogf3AUnEz v9C97M2QnPqyW3bY7I4WOmw2N3VOdvhVCaZ3TrKNZe5p6cmbbA6EI+fPmRveyfnxOncEaZ+bHpHL AyRllYN6lNEsp9OTcpk4A5Lqy/x4VfjcMhsYp+VS2carnpGubCNTzI7ItqDZtcH1Vz+/1EWCYZXJ jTof086E4+QanNyUs2ny8OS5yYuTE5Mme33T9cHr4/zRXste23Rt8Jq+tmJeuoP/xb2E/l7Oh7h+ nnPpeUrfw561JfnrcE1G5OtBQZFbPCpfo/WcPOmzGHYzG4NEvdvklTuNYgAuwpRjz/IU9gRMOPYs H1M/tgcUgTVzps3iKUwHuzoSNC9xJ0YY7+L/a7y545wlufH6tDsw7hSybHeKGhiCk6Dl+qC9MZ3x YnK9zXaxvSC5af9OeuSXxA44BkqusVVZyDVBccxd7VXKNTahl7diZ4fVR7GXQcrb5Eqbjct1qA63 dWXAhhcSLHUMoM5+c2UVJGxeJav8mSV2ejIRULjyS+cSrR1yPhGO84nzkR9LHhp1PgqP7J1+LMHf l35KPxam90/rbeGX7YFIH4l0j+4j5eX/oC+I17irvIzu4/kDeoTz+z39bFjnXf1GqO9E129HOq4P hH8sY5G+HunhSF/Vw1b5Dh3wY2XuKX1AP+vnkdDL0SC/xO76qXDXR8JddxJOXe6mt5K5f1bVubnP ZjW4nz1D9v9mScw9OqQzA0ecI0MqM/Ci8+ILJvOCLR52DiNiqGRo09CWIe3Vq9uUzckyqhtlhGpd pGsj7Yp0tbrVropaFV13qjWsgqSFm1Wr3Sx1k2oNW1qK2ppupF9A2TDVFumSSFtUKxm49KpVraoL a9aourCFMlUa9hFDrb8k0uLIX6RKw75b5aT8PAyU6yh35DXUnh9XI/1cToQ6KT+1LcsTcji8Hpav hEH0ijweXh+Xx0L9GWr9L0f6UqQ/lccCxiq8mfJRUQIpyEIOuiFPPhb8m+6qj23quuL3vvecEMex k4DBwQ0xtvNBXpoEE5K+EsAfMVPJuqZA1bi0AtpASSfWSn6ptK2MQDFkQrSEkH5AWsrG9g8ae3lG zCkkQYNVSNukTev6TzeJrpU2sa5Nu/+GNPY7912Co6mWz/2de++5X+edc+65Y5rOElXKIbYRRFb4 PDsBugZSlU6lQ8SMtUoHYkY5olcHrLUDftEBv+iAH3Qwl7Je6cab484VpRuhbY0Ss6N6MNGjxHDI a6LsQNkLMkHDIAvkYu9J7jPQHRASOJQh0ADoJdFyR6GMcAClCboEUiG1gh0GnVcoyTqv0N2yBGUP aAB0GKTxz/m/KLTy9+1RTS/wgo2DTvFf8Iv4fAh6+/PRRkMg4sGOGT5IFkolgtILdrDWmOZ7+F46 PN/Ln3ZcZ8ReVoOc+PvaPuEW+7V9Tvs++8F2A/n869qg8IdRIGK3dgJIgkeA5Js5px9+8t28x4sM QxvMRxodxC4QDLQscuCsSAP3IDXcI1Lxy/kHwoYv4dYuofkSUzRLuyjnuWh7fEbCq30gPfU6kHYw I/EqHFFs8S3hmPwx3m279LppvlkcN414st7OxeooFK+za52UYJ2N9IeYh+xkWjBd95jOPJj4rHIZ A1dxkUPzJt5oa6TSxjyyDEJ7RRj3SWM8AL/+zQ1F/y1UfwoUP9ncYpwcU/XC3Wv50YFBQ2DmGQcf fYLwV6OJR4zRMTfJxKNjazuNsXGuvzbu0ifedulngG+D3gS9BXoDRIPHkfHQAO94a5sRH29tR4FD JNzqO+qE8L4zQPLG0+qE8F+vOq6OCb89BaSekxJH1THhp2H1W+omMiF1k5oSc6Ql9gBJMqmmxAwJ iXGJGyVuUFM2F9EmpraIaLNabRE97UCaoU1iq8QHgbSiLrFZbaHdTt2dA1OFvEANqDVCcplaI76s WpNfvsJQEtVqmVoqdrcISBIlEl2yXVNL6VzTytcyvHylzOHDIYWYs1dGjERY+QLxhjp+rpwTcedn QKqfl/hTIHal/ETiexLPSvl3lXMUbzDjuXwXpRbKbkp6XpxVBtjrIAuk4mb/qx1posyEf5T3+Y3o LP+IbQN9BlL5H5V6BJNo4gGlHt5cD/+uFz4fFbdqGPlUWFzHISQ6IXDlKKOgwyCVf6yshMLaC/wv lJCWI/P8E13b/PdsAKSwj/nvEKMY/y/rYnX8n/w23GH4Kr+NhPQ2U1DNKQgWyuWcqt/5BIbKZ+xX qWXa6bhiH4DB8Sl7v0snf3jFfvJJw2E2f0cy6zdIpq1dMuGIZMiv+BB/DlaBkPOs8MFnRch5Lo+Q A9/ZmW/SjR0JL98pLnyUfIA/TdrnzwChZQSjnEtPuPnjfAvlkHwD72YD9CziD9vf7hMrPWwnUpJZ HRNMt/3oVsmkHnGYfPNqIz6j4F3CwzwiYmUkn6NrmwfoASQQeZLApjaBdqxbDHbbfX2SifXA1935 o269MuHjZSLPpzLES1HO8hKUddyFVTT7gJuUG49L7Z79N/871PpLVD8B3r3Bf31d1W9d55+i5QPQ 7LRbnwFN59z68WNu/cegY7lS4fLDG3tE3BhGEkt4qEtiapMIBd871NRqHDqo6Qex6jDoR6D9oAOY YATLHcVZD+c0/VVMHs8hdA3neDzHg13+QKffv9Zf3eH3rfF7Yv6y1f6Sdr/a5met/oZGb1Ojr1n3 tui+cMQbjfhW1HlDdT4VZ/+a+fkc/4r5+Bf8S+YF3sLJb+GjqfxW3q/+x59Yx5/i25mXb+NPMK9m akPay8yj7db2aM/jQdqm7UY2Nqwd1A6xCu0H2g+1V4CntTP0gNROQ5E+ZVaWfpQzWLCSV2GpNl7J HgPtAM2CNO7lPrEF6vPG2xSs7qus8ngqvJ4yd7mnpHSRR9VcHjiD58UoD4X/EFbi4b7wtfCt8FzY RQqMhGEEDWqjXgLyqV+qSpDXVgRKl1f4K5dVVGtLKvrWcKu6l/VuS1qLOXBr0lqj9xbU0BYrpvda i/q2909y/loGrZYyUoAfWtpIQQFUp57a3l/gNdSdCyI75Mzq3Zk7nplUWNLiI1Zkaz9B/PF+KzRS qGTb+icVngxa2vFMJmN19fb1k2RGr7UGeiE6XJuxYsScqM0wHb8skUmlUxP1rOy4D/hNNjWkreb0 LqslvbNHL/pxM6t/w0/OJ+bMZs359qFiGdOh4p8pBjijxBz4p/qvIgM6Rx6DsAk/E+EzGBFoVy+l 5w6YyipDrABlCbkWR25FnZRbTN2Z4sVS/RBVS/NruyACbFjloH+5cWYKdwKn/QcdGSzzZ9FmyjlS /cFEg7pKDYtrq0lio1ovrq8GifWyPSIxKnGlxJDEOjU8yYu2lrm3v0q1Jd+22qgsAMNRB3EUQntR mThx8H12lG5PM7PgYPwgpUw4UIoGHpnClUsHEudJ0RzUZYdCRrFWMBJvxzEbSYLDhFYacsyYXe03 5jeGzgm7NSakJvKhKM02YfsDtKNgopKdQjZxHnRJZBdU3gB9KGohSC5eaujmEM3GvsmGiuwlO29o 2SK+yI50aWlkbOaQY35kQKn+WdjOBei4R5QhJPxhYTkX7lnOBbIcYiZtvPuEEcKGqJ5fLmznQr65 xUHHli5IW1poTI5W5vCEia01HCZSb4iv8yHeN/e/jiPWaeuthsOsCIH5HEwgKFuqljgflpTbabc5 Wu6kHMRhqgILbDnVP61uxvuNU8aL9xuupCnBiCXA5AM1xpErkHiDXoVCf8FEGSvB24+LkYocCUtz Rq6MSmZJjeNV84tlyUdN3ZyvFn+JoflWx4nF13FY+ir8XkBw0BTDs+aUdlabSO8taG+mB3f1CCho 76QHrfixXVZ8Z0F7N9KTlZ9XLlAcebLSAuCR2KUVsNoRZ7HlrJT8v4BmDg3pMrYstCWnxkQQ0nlB vYlNqTcjPQvj1gKD5fPr4TwsS2ek0syaPAvOHMqSAkwTDSanzcwbKxVMVDGGhphMF7HSRN3Up7Q+ rY/W/0f6hV20FagG8tiXiNqQwHpSgUNirvvHQCekplwRVwAzuLxCrQQFl+++Wl3hSI8YNKTTzkkv 9yagzZt00qy+IEBni8/ORTVb5ICmzsT+izVKZ2PzMqKLzd86nPTgVM35b8HENUADJ8voluzbksRV uUVcl9byCCo3UelExUOVgS2WKyLuVbQj8JVoLDlZypJTzE1cOUsG+SRjSysnN7GXJtmmDQXtb2lW 0D5NW+W65cbQ8kiSbdwY0Cu7+cttDwVKPFYJWksjycz/2K9jlAaCKAzA/8ZsdkXRJGCVKohYRrER YmFh7xH0Ch5A8Ap2XsFSvICFYJXKXmwFWxEU0VnIHWy+x3zzZnhv2mEm5cVbPqpNBin3VpPJ8VpT 9avUK6v9tMOXRRmZHSxmi/296Wg62ilTVZq/rup8dzllsYwTAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/lGVPL1XF9nNddbTyzDbmScbr4Pz1KVa6p3D8e/D2ebRRyZturg7ve11+X7+fPn59vM4 3mpvyrZdnsifAAMA7ImczwplbmRzdHJlYW0NZW5kb2JqDTY3IDAgb2JqDTw8IA0vVHlwZSAvRXh0 R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTY4 IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9PUCBmYWxzZSANL29wIGZh bHNlIA0vT1BNIDAgDS9CRzIgL0RlZmF1bHQgDS9VQ1IyIC9EZWZhdWx0IA0vVFIyIC9EZWZhdWx0 IA0vSFQgL0RlZmF1bHQgDS9DQSAxIA0vY2EgMSANL1NNYXNrIC9Ob25lIA0vQUlTIGZhbHNlIA0v Qk0gL05vcm1hbCANL1RLIHRydWUgDT4+IA1lbmRvYmoNNjkgMCBvYmoNPDwgDS9UeXBlIC9Gb250 RGVzY3JpcHRvciANL0FzY2VudCAxMDY4IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yNzAgDS9G bGFncyA0IA0vRm9udEJCb3ggWyAtMTAxMSAtMjc5IDIyNjAgMTA3NCBdIA0vRm9udE5hbWUgL05O SEVHTytBcmlhbFVuaWNvZGVNUyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vRm9udEZpbGUy IDY2IDAgUiANPj4gDWVuZG9iag03MCAwIG9iag08PCAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJH QiAvTGVuZ3RoIDI1NzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImclnlUU3cW x39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10Rk9FnS6uY60O1n3q 0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsAjdagz0qMxRYVFGKk CQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0AQBk4ByiUtXKcO3Gu qjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX1xmVOCOpOHfVqZX1 OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuUDQbTpSTVuka9WlVu wNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHBwUJ/H9E7hfqvm79Q pt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2++M59+KZ5KTcYdGG+ vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSEPx3iXx3483l4 ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDytwsA5dIAUrQN 34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqACJuABK2APnIE7EAJ/ EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyDj8EJ8EdwHnwJroFb YBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH6oeGoR3Qbuj3 0FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj8D74MHwCPg9f gyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuUiHJRDBWi4WgSmovK 0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCGcI0wTXhKJBL5RAEx hJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZNE16TqaRHcj+5ARy IVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g5lArqO3UIep+6hnq beoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2EwGG6MaEYhw8BYx9jN OMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXGkrBkrFbWCOso6wZr ls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3mkfkCXhSXgWvh/db 3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovLFs8sbSyjLZWW3ZYH LK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvbetpm2TbbfmB7wXbW zt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSdxmYcbR2THI2OOxwn HF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r+sxN4Jbvtspt3O2+ wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5qr61el7wJ3qHeWu9R 7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzqEB0Tfefv6S/3H/G/ GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8cYa4V/x5KCE0 NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJKMcoWdRo1DfR ztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/TnBKUCXsTZhJDEps TjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21Mu73QdaF24Xg6SJem b0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK8nbnPcuPy+/P n1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2kmFksKz5UQijJ L9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPqQXlU+WD5I7VEPaz+ tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOpZkafot9ZC9UuqT1i 4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xxbGlvmVoWs2xHK9Ra 2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXvurEqfNX21ehq9eqJ NQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt2NXP7m/qv7sxbePh AWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5A nq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+r Aqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfg uFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvF yMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG 1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi 2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/ 8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t//8CDAD3hPP7 CmVuZHN0cmVhbQ1lbmRvYmoNNzEgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvQ0lE Rm9udFR5cGUyIA0vQmFzZUZvbnQgL05OSEVHTytBcmlhbFVuaWNvZGVNUyANL0ZvbnREZXNjcmlw dG9yIDY5IDAgUiANL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkvT3JkZXJpbmcg KElkZW50aXR5KS9TdXBwbGVtZW50IDAgPj4gDS9EVyAxMDAwIA0vVyBbIDMgWyAyNzcgXSBdIA0+ PiANZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM5IDAgUiANL1Jlc291 cmNlcyA8PCAvQ29sb3JTcGFjZSA8PCAvQ1MwIDQ4IDAgUiAvQ1MxIDQ5IDAgUiA+PiAvRXh0R1N0 YXRlIDw8IC9HUzAgNjcgMCBSIC9HUzEgNjggMCBSID4+IA0vRm9udCA8PCAvVFQwIDQ1IDAgUiA+ PiAvUHJvY1NldCBbIC9QREYgL1RleHQgXSA+PiANL0NvbnRlbnRzIDIgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANL1N0 cnVjdFBhcmVudHMgMSANPj4gDWVuZG9iag0yIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMyAwIFIgPj4gDXN0cmVhbQ0KSIl0VE1v2zAMvftX8CgNjSPZjj+AosCaZsUGZCta 39YdHFtJ3KZWJjUN+u9H0k6bohmCyBJJPeqRTxrfwPn5eD79fgUKLi4ur6bBeHqnoPa4ph/4ugs0 tBCMb82mem5fzNRurGufzLNra3BtML7GDSsfXJbBuCwVaCiXwUiFSqkcyhpUmKiigHIPWoWTlGH7 WaEgm+RhkqsYyqfgt8hDkFqLr3KUCi8jAc78JcNOjrRoZSKcjIVpYPEqI/SiVYtvMtLCUoCbzu5o x44izZPUqTDdM84ZquoagoKlq3rXXqbDvsczoLA1LQwyprj1AMAeDgO/25Jnax3ZoDP0YRT3yNDy T/ljYJ72zJWOiLiCkQ6TLEOaV0iTkauuWr0fciKABms3OHquwkaOMiQ9EY8G7n5SSeZSJ+JGxjGe ZW13FNpw6MJATStTOfr01dk643tow4VqgMA6pkLWge7WWc5cc+q+AdeU7VZmh4wEtyZH5clAe15o SYANwzTHkEd1GBSg4qQ4UQhfv5V5aGljltS9jocVVOC5ymCXfLA5V61vJA2/6KALyvpAPa859p6O Hfe+e4mKgUPBacvqWBm9x3iPqP5IfBv0sSTsbrVmM/XZwLpi3gY6LBruPKKq9UA1p+bvofyCBBuz JSjL5LhIbzKjqfF8iKV17552EOwZ7Kl1sDCEwJLG3Aot7XC4QQQJdhYFsOQp/Y8uR207T+F9k5xp zjiZLLSYYntncoTJ+quhBPBVOti4lruqB0Ul9qiVIzFFH7R+IM6zTz1m0YHtDKCGJwQfk8pG0UQN KLMymM3x4Xl/i/TwFn14UhSn+c87kub4zGSFpncEYcuHE6jRKdRTWGkS5llefML6J8AA2JhBGQ1l bmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNNjU1IA1lbmRvYmoNNCAwIG9iag08PCANL1RleHRCb3gg L0RpdiANL0ZyYW1lIC9EaXYgDS9Gb290bm90ZSAvTm90ZSANL0VuZG5vdGUgL05vdGUgDS9TaGFw ZSAvRmlndXJlIA0vSW5saW5lU2hhcGUgL0ZpZ3VyZSANL1RPQSAvVE9DIA0vVE9BSSAvVE9DSSAN L1RPRiAvVE9DIA0vVE9GSSAvVE9DSSANL1N1cGVyc2NyaXB0IC9TcGFuIA0vU3Vic2NyaXB0IC9T cGFuIA0vU3RyaWtlb3V0IC9TcGFuIA0vVW5kZXJsaW5lIC9TcGFuIA0vRHJvcENhcCAvRmlndXJl IA0vI0U2I0FEI0EzI0U2Izk2Izg3IC9QIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9TIC8jRTYj QUQjQTMjRTYjOTYjODcgDS9BIFsgNiAwIFIgXSANL0MgLyNFNiNBRCNBMyNFNiM5NiM4NyANL1Bn IDQzIDAgUiANL0sgMCANL1AgMzEgMCBSIA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgDS9PIC9MYXlv dXQgDS9UZXh0QWxpZ24gL1N0YXJ0IA0+PiANZW5kb2JqDTcgMCBvYmoNPDwgDS8jRTYjQUQjQTMj RTYjOTYjODcgOCAwIFIgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL08gL0xheW91dCANL1dyaXRp bmdNb2RlIC9MclRiIA0vU3RhcnRJbmRlbnQgMCANL0VuZEluZGVudCAwIA0vVGV4dEFsaWduIC9K dXN0aWZ5IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJbmRlbnQgMCANPj4g DWVuZG9iag05IDAgb2JqDTw8IA0vUyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vQSBbIDEwIDAgUiBd IA0vQyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vUGcgNDMgMCBSIA0vSyAxIA0vUCAzMSAwIFIgDT4+ IA1lbmRvYmoNMTAgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL1N0YXJ0IA0+PiAN ZW5kb2JqDTExIDAgb2JqDTw8IA0vUyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vQSBbIDEyIDAgUiBd IA0vQyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vUGcgNDMgMCBSIA0vSyAyIA0vUCAzMSAwIFIgDT4+ IA1lbmRvYmoNMTIgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9UZXh0QWxpZ24gL1N0YXJ0IA0+PiAN ZW5kb2JqDTEzIDAgb2JqDTw8IA0vUyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vQyAvI0U2I0FEI0Ez I0U2Izk2Izg3IA0vUGcgNDMgMCBSIA0vSyAzIA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMTQgMCBv YmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9Q ZyA0MyAwIFIgDS9LIDQgDS9QIDMxIDAgUiANPj4gDWVuZG9iag0xNSAwIG9iag08PCANL1MgLyNF NiNBRCNBMyNFNiM5NiM4NyANL0MgLyNFNiNBRCNBMyNFNiM5NiM4NyANL1BnIDQzIDAgUiANL0sg NSANL1AgMzEgMCBSIA0+PiANZW5kb2JqDTE2IDAgb2JqDTw8IA0vUyAvI0U2I0FEI0EzI0U2Izk2 Izg3IA0vQyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vUGcgNDMgMCBSIA0vSyA2IA0vUCAzMSAwIFIg DT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYj QUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDcgDS9QIDMxIDAgUiANPj4gDWVuZG9iag0x OCAwIG9iag08PCANL1MgLyNFNiNBRCNBMyNFNiM5NiM4NyANL0MgLyNFNiNBRCNBMyNFNiM5NiM4 NyANL1BnIDQzIDAgUiANL0sgOCANL1AgMzEgMCBSIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0v UyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vQyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vUGcgNDMgMCBS IA0vSyA5IA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMj RTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDEwIA0vUCAz MSAwIFIgDT4+IA1lbmRvYmoNMjEgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9D IC8jRTYjQUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDExIA0vUCAzMSAwIFIgDT4+IA1l bmRvYmoNMjIgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMj RTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDEyIA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMjMgMCBv YmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9Q ZyA0MyAwIFIgDS9LIDEzIA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgDS9TIC8j RTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9L IDE0IA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYj OTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDE1IA0vUCAzMSAw IFIgDT4+IA1lbmRvYmoNMjYgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8j RTYjQUQjQTMjRTYjOTYjODcgDS9QZyA0MyAwIFIgDS9LIDE2IA0vUCAzMSAwIFIgDT4+IA1lbmRv YmoNMjcgMCBvYmoNPDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYj OTYjODcgDS9QZyA0MyAwIFIgDS9LIDE3IA0vUCAzMSAwIFIgDT4+IA1lbmRvYmoNMjggMCBvYmoN PDwgDS9TIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9DIC8jRTYjQUQjQTMjRTYjOTYjODcgDS9QZyAx IDAgUiANL0sgMCANL1AgMzEgMCBSIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUyAvI0U2I0FE I0EzI0U2Izk2Izg3IA0vQyAvI0U2I0FEI0EzI0U2Izk2Izg3IA0vUGcgMSAwIFIgDS9LIDEgDS9Q IDMxIDAgUiANPj4gDWVuZG9iag0zMCAwIG9iag08PCANL1MgLyNFNiNBRCNBMyNFNiM5NiM4NyAN L0MgLyNFNiNBRCNBMyNFNiM5NiM4NyANL1BnIDEgMCBSIA0vSyAyIA0vUCAzMSAwIFIgDT4+IA1l bmRvYmoNMzEgMCBvYmoNPDwgDS9TIC9TZWN0IA0vUCA0MiAwIFIgDS9MYW5nIChFTi1HQikNL0sg WyA1IDAgUiA5IDAgUiAxMSAwIFIgMTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE3IDAgUiAx OCAwIFIgMTkgMCBSIA0yMCAwIFIgMjEgMCBSIDIyIDAgUiAyMyAwIFIgMjQgMCBSIDI1IDAgUiAy NiAwIFIgMjcgMCBSIDI4IDAgUiAyOSAwIFIgDTMwIDAgUiBdIA0+PiANZW5kb2JqDTMyIDAgb2Jq DTw8IA0vTnVtcyBbIDAgMzMgMCBSIDEgMzQgMCBSIF0gDT4+IA1lbmRvYmoNMzMgMCBvYmoNWyAN NSAwIFIgOSAwIFIgMTEgMCBSIDEzIDAgUiAxNCAwIFIgMTUgMCBSIDE2IDAgUiAxNyAwIFIgMTgg MCBSIDE5IDAgUiANMjAgMCBSIDIxIDAgUiAyMiAwIFIgMjMgMCBSIDI0IDAgUiAyNSAwIFIgMjYg MCBSIDI3IDAgUiANXQ1lbmRvYmoNMzQgMCBvYmoNWyANMjggMCBSIDI5IDAgUiAzMCAwIFIgDV0N ZW5kb2JqDTM1IDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0zNiAwIG9iag08PCANL051bXMg WyAwIDM1IDAgUiBdIA0+PiANZW5kb2JqDTM3IDAgb2JqDTw8IA0vUHJvZHVjZXIgKEFjcm9iYXQg RGlzdGlsbGVyIDUuMC41IFwoV2luZG93c1wpKQ0vQXV0aG9yIChXd20pDS9DcmVhdG9yIChBY3Jv YmF0IFBERk1ha2VyIDUuMCBmb3IgV29yZCkNL01vZERhdGUgKEQ6MjAwNDAzMDUyMjA4MTArMDgn MDAnKQ0vVGl0bGUgKEFwYXJ0IGZyb20gdGhlIGRldGFpbGVkIHJlc3VsdHMgd2UgcHJlc2VudGVk IHRvIElFVEYgbWVldGluZywgd2UgYWxzbyBoYVwNdmUgc29tZSAgZXhwZXJpZW5jZXMgd2l0aCBH Uk1QIGR1cmluZyB0aGUgaW1wbGVtZW50YXRpKQ0vQ3JlYXRpb25EYXRlIChEOjIwMDQwMzA1MjIw ODA4KzA4JzAwJykNPj4gDWVuZG9iag0zOCAwIG9iag08PCAvVHlwZSAvTWV0YWRhdGEgL1N1YnR5 cGUgL1hNTCAvTGVuZ3RoIDE0MTAgPj4gDXN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPScnIGlkPSdX NU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnIGJ5dGVzPScxNDA5Jz8+PHJkZjpSREYgeG1sbnM6cmRm PSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0n aHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHht bG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpDcmVhdGlvbkRhdGU9JzIwMDQtMDMtMDVUMTQ6MDg6MDha JyBwZGY6TW9kRGF0ZT0nMjAwNC0wMy0wNVQxNDowODowOFonIHBkZjpQcm9kdWNlcj0nQWNyb2Jh dCBEaXN0aWxsZXIgNS4wLjUgKFdpbmRvd3MpJyBwZGY6QXV0aG9yPSdXd20nIHBkZjpDcmVhdG9y PSdBY3JvYmF0IFBERk1ha2VyIDUuMCBmb3IgV29yZCc+PHBkZjpUaXRsZT5BcGFydCBmcm9tIHRo ZSBkZXRhaWxlZCByZXN1bHRzIHdlIHByZXNlbnRlZCB0byBJRVRGIG1lZXRpbmcsIHdlIGFsc28g aGF2ZSBzb21lICBleHBlcmllbmNlcyB3aXRoIEdSTVAgZHVyaW5nIHRoZSBpbXBsZW1lbnRhdGk8 L3BkZjpUaXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4 bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdodHRwOi8vbnMu YWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwNC0wMy0wNVQxNDowODowOFon IHhhcDpNb2RpZnlEYXRlPScyMDA0LTAzLTA1VDE0OjA4OjA4WicgeGFwOkF1dGhvcj0nV3dtJyB4 YXA6TWV0YWRhdGFEYXRlPScyMDA0LTAzLTA1VDE0OjA4OjA4Wic+PHhhcDpUaXRsZT48cmRmOkFs dD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkFwYXJ0IGZyb20gdGhlIGRldGFpbGVkIHJl c3VsdHMgd2UgcHJlc2VudGVkIHRvIElFVEYgbWVldGluZywgd2UgYWxzbyBoYXZlIHNvbWUgIGV4 cGVyaWVuY2VzIHdpdGggR1JNUCBkdXJpbmcgdGhlIGltcGxlbWVudGF0aTwvcmRmOmxpPjwvcmRm OkFsdD48L3hhcDpUaXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiBhYm91 dD0nJyB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIHhtbG5zOmRjPSdo dHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Y3JlYXRvcj0nV3dtJz48ZGM6dGl0 bGU+QXBhcnQgZnJvbSB0aGUgZGV0YWlsZWQgcmVzdWx0cyB3ZSBwcmVzZW50ZWQgdG8gSUVURiBt ZWV0aW5nLCB3ZSBhbHNvIGhhdmUgc29tZSAgZXhwZXJpZW5jZXMgd2l0aCBHUk1QIGR1cmluZyB0 aGUgaW1wbGVtZW50YXRpPC9kYzp0aXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPjw/ eHBhY2tldCBlbmQ9J3InPz4KZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9iag08PCANL1R5cGUgL1Bh Z2VzIA0vS2lkcyBbIDQzIDAgUiAxIDAgUiBdIA0vQ291bnQgMiANPj4gDWVuZG9iag14cmVmDTAg NDAgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA3MzY1NCAwMDAwMCBuDQowMDAwMDczOTU1IDAw MDAwIG4NCjAwMDAwNzQ2ODYgMDAwMDAgbg0KMDAwMDA3NDcwNiAwMDAwMCBuDQowMDAwMDc0OTky IDAwMDAwIG4NCjAwMDAwNzUxMDYgMDAwMDAgbg0KMDAwMDA3NTE2MCAwMDAwMCBuDQowMDAwMDc1 MjEwIDAwMDAwIG4NCjAwMDAwNzUzNjIgMDAwMDAgbg0KMDAwMDA3NTQ3NyAwMDAwMCBuDQowMDAw MDc1NTMyIDAwMDAwIG4NCjAwMDAwNzU2NDggMDAwMDAgbg0KMDAwMDA3NTcwMyAwMDAwMCBuDQow MDAwMDc1ODA0IDAwMDAwIG4NCjAwMDAwNzU5MDUgMDAwMDAgbg0KMDAwMDA3NjAwNiAwMDAwMCBu DQowMDAwMDc2MTA3IDAwMDAwIG4NCjAwMDAwNzYyMDggMDAwMDAgbg0KMDAwMDA3NjMwOSAwMDAw MCBuDQowMDAwMDc2NDEwIDAwMDAwIG4NCjAwMDAwNzY1MTIgMDAwMDAgbg0KMDAwMDA3NjYxNCAw MDAwMCBuDQowMDAwMDc2NzE2IDAwMDAwIG4NCjAwMDAwNzY4MTggMDAwMDAgbg0KMDAwMDA3Njky MCAwMDAwMCBuDQowMDAwMDc3MDIyIDAwMDAwIG4NCjAwMDAwNzcxMjQgMDAwMDAgbg0KMDAwMDA3 NzIyNiAwMDAwMCBuDQowMDAwMDc3MzI2IDAwMDAwIG4NCjAwMDAwNzc0MjYgMDAwMDAgbg0KMDAw MDA3NzUyNiAwMDAwMCBuDQowMDAwMDc3NzQwIDAwMDAwIG4NCjAwMDAwNzc3OTMgMDAwMDAgbg0K MDAwMDA3Nzk0MCAwMDAwMCBuDQowMDAwMDc3OTgzIDAwMDAwIG4NCjAwMDAwNzgwMTQgMDAwMDAg bg0KMDAwMDA3ODA1OCAwMDAwMCBuDQowMDAwMDc4Mzk4IDAwMDAwIG4NCjAwMDAwNzk4OTIgMDAw MDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA0MA0vSURbPGMxNDA5NDRkYjFhYTQ5YjBlNWM0ZTg1ZDJh MzAyZjYyPjwzMDI4NGFiNzg1ZWMxN2JjYzkyY2Y0MzhjN2FjMjBlMT5dDT4+DXN0YXJ0eHJlZg0x NzMNJSVFT0YN ------=_NextPart_000_05A8_01C402FF.92CB4E90-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 14:38:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24869 for ; Fri, 5 Mar 2004 14:38:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL8o-000602-AH for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 14:37:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Jboxi023051 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 14:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL8n-0005zi-Uo for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 14:37:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24836 for ; Fri, 5 Mar 2004 14:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL8j-0004iI-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL6v-0004F2-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:35:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzL5C-0003f9-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:34:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzL5E-00067O-Fv for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:34:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL58-00058h-Nn; Fri, 05 Mar 2004 14:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL4t-00058D-Mo for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 14:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24482 for ; Fri, 5 Mar 2004 14:33:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL4p-0003Ug-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:33:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL3A-00034Z-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:32:02 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzL1V-0002Tv-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:30:17 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030511305600:62973 ; Fri, 5 Mar 2004 11:30:56 -0800 Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis Design TeamAdministrivia From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243EDB9@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B00243EDB9@orsmsx410.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078515013.1037.48.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 03/05/2004 11:30:56 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 11:30:58 AM, Serialize complete at 03/05/2004 11:30:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 14:30:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Thu, 2004-03-04 at 21:11, Khosravi, Hormuzd M wrote: [..] > > The ForCES protocol should have separate channels/connections/(any > other > > terminology ?) for data and control messages. By data messages we mean > > control protocol packets such as OSPF, RIP packets, etc. which need to > > be redirected from FE to CE or forwarded from CE to FE. By control > > messages we mean all other control/capability/configuration messages. > > Is there a good reason for such separation? > > [HK] Yes there are several good reasons. One is reliability, the second > is robustness against DoS attacks, yet another one pointed out by Steve > was efficient delivery into CE's networking stack. I thought we had a > common understanding on this, I think we do - but i am getting confused by some of the messages i see from Weiming. Why dont you put some text around this and lets settle on it; Note, my confusion is the nature of the beast: I would take it if you have two channels/sockets/connections then they must differ somehow. Is the difference in priority, reliability, availability, bandwidth, or what? This is what needs to be clarified so we reach a conclusion of some sort. Note in our case, the separation of the socket connection was based on a) cost: It is cheaper to reach more FEs with a single message to a multicast channel. b) reliability: Retransmissions go out on unicast TCP connections. In other words it was not the packets that were important, it was "which channel should i use to achieve a goal?". To reiterate the issues (and hopefully add discipline to the discussion so we can settle quickly), the above would be issue 2). The others are: 0) ID on the header. 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 15:01:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26489 for ; Fri, 5 Mar 2004 15:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLV3-0001YQ-Vv for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 15:00:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25K0nqE005969 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 15:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLV3-0001Y2-MJ for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 15:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26445 for ; Fri, 5 Mar 2004 15:00:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLUy-0001s3-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:00:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLU3-0001gW-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:59:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzLTF-0001Vk-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 14:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLTJ-0008G6-Cc; Fri, 05 Mar 2004 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLSO-0008Ca-EQ for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 14:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26266 for ; Fri, 5 Mar 2004 14:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLSJ-0001Jk-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:57:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLRN-00017z-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:57:02 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzLQU-0000wh-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 14:56:06 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030511563835:62994 ; Fri, 5 Mar 2004 11:56:38 -0800 Subject: Re: [Forces-protocol] Comments from chat with ADs From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Wang,Weiming" , "Putzolu, David" , forces-protocol@ietf.org In-Reply-To: <4048A7EB.2030808@alcatel.com> References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> <4048A7EB.2030808@alcatel.com> Organization: ZNYX Networks Message-Id: <1078516549.1035.75.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 03/05/2004 11:56:38 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 11:56:47 AM, Serialize complete at 03/05/2004 11:56:47 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 14:55:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think theres a lot of implementation details being tossed around as opposed to what the protocol needs. Weiming, i apologize for not having paid close scrutiny to GRMPs issue of DOS in you draft; however looking at the slides Ligang presented it seems to me the issue maybe implementation. I thought David did a good job explaining the link aspect of things. I actually agree with you that a single link may be insufficient to prevent a DOS. In particular this issue gets exaceberated if the DOS is infact filling the pipe. The suggestion was if you could prioritize before the packets hit the OS, such as via different DMA channels, things will improve (because the DOS is limited to attacking the physical link). This is of course only true until someone starts DOSing with high priority packets and filling that high prio DMA channel. The problem is not solvable if all DMA channels regardless of priority are being DOSed. This also applies to the dual (physical) links. i.e you cant protect if all physical links are being attacked. The solution is to have a trusted vs non trusted link. And if you have trusted sources, then can do a very good job addressing that issue with the multiple DMA channels. Once the packet hits the OS, you need not only to protect against bandwidth, but also against CPU(thorugh thread prioritization alex is suggesting) and RAM abuse. i.e you need to protect all those three resources by providing QOS for them. Some OSes help you more than others to achieve this. So far all the above is an implementation issue. Nobody will teach you these tricks, but if you want to have a robust implementation, you will need to do the above. This is regardless of the protocol (OSPF, BGP etc). i.e has nothing to do with Forces. The only protocol/header semantic that is valuable is prioritization bit which are specific to Forces. Is this what you are refering to? I believe (I could be mistaken) all three proposals have this. This is valuable. However, this should probably be optional. Its easier to use whatever the underlying mechanism provides (802.1p, diffserv etc) To quote from netlink2 draft: " Prioritization is an orthogonal mechanism to reliability. When a node runs out of resources, a message sent with a higher priority will get preferential treatment. For instance, if a FE has only enough memory to allocate one message in response to a message from the CE and it has to choose between one of two messages to respond to, then it will use that memory for the request which was sent with the higher priority. This also applies to other resources such as computing cycles " cheers, jamal On Fri, 2004-03-05 at 11:16, Alex Audu wrote: > Hello Weiming, > > I still believe that the result you got from your experiment could be > much more > improved if you allocated two separate queues, one for C and the other > for D > data. Then create two separate threads to process the queues (one for each). > Give both threads equal priority and you should be fine. If you want to skew > things in favor of the C, then you can adjust priority accordingly. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 15:23:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28333 for ; Fri, 5 Mar 2004 15:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLqU-0003cj-6c for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 15:22:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25KMwqA013921 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 15:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLqT-0003cS-Ud for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 15:22:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28324 for ; Fri, 5 Mar 2004 15:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLqS-00068u-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:22:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLpT-0005xz-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:21:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzLob-0005ns-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:21:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzLoe-000729-9T for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLoa-0003JA-JX; Fri, 05 Mar 2004 15:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLoT-0003CG-CW for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 15:20:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28269 for ; Fri, 5 Mar 2004 15:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLoS-0005mq-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:20:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLnb-0005dF-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:20:01 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzLml-0005Ib-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:19:07 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25KKbxv016399; Fri, 5 Mar 2004 20:20:37 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25KKKqs016023; Fri, 5 Mar 2004 20:20:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030512183306678 ; Fri, 05 Mar 2004 12:18:33 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 12:18: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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243F189@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCLs7nL03OZJM+QgqTRTug7WuVqwAIJBbgACeKFoA= From: "Deleganes, Ellen M" To: "Khosravi, Hormuzd M" , Cc: X-OriginalArrivalTime: 05 Mar 2004 20:18:33.0990 (UTC) FILETIME=[08B78260:01C402EF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 12:18:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is that even if Multicast is optional, those procedures that noted in Hormudz's email should be described in the ForCES protocol spec. That is, if a ForCES protocol implementation supports multicast, then it MUST implement it in the manner described in the ForCES protocol specification. Otherwise, ForCES implementations using multicast will probably not interoperate. Whether or not implementing multicast for transports that support multicast is a requirement is a separate question.=20 Regards, Ellen -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Thursday, March 04, 2004 6:12 PM To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs Hi Alex, In general, I prefer using language such as MUST so that there is no confusion or interop issues in the protocol implementations. However, you raise a reasonable point and let me tell you my thoughts on this. We will definitely need Unicast between FEs and CEs at the minimum in the protocol. In addition, if the interconnect technology supports Multicast and there is a case where it is useful to the application (such as downloading IPv4 routes) we must allow it as well without breaking interop. In order to do that, we will need specific procedures in the protocol that will allow the CE and FE to negotiate on using multicast dynamically at run-time (say during the binding or joining phase between the CE and FE) and also associate different multicast groups with LFBs. We will also need to define how Reliability/CC etc. will be provided for multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, then applications will be able to use both unicast and multicast without any interop issues. Let me know what you guys think about this. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 1:22 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs Hormuzd, Why should multicast be "mandated for certain cases where it will be=20 useful" if there is a simpler, more robust way to do the same thing? I'll say we don't=20 mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: >Hi David > >Your summary below of the discussion with Ads on the different issues >seems like very reasonable approaches to me. > >I agree that it will be a good idea to present transport alternatives at >IP and non-IP level for the ForCES protocol. We can mandate one or more >transport for IP and one or more transport for non-IP, this way the >interoperability requirements are met and at the same time, the in-box, >out of box scenarios are met. > >Also, agree with having multiple channels/connections to differentiate C >& D traffic between CEs and FEs. On the unicast/multicast topic, dual >mandatory approach again seems a good idea to support interoperability. >The one thing that I would like to point out is that for any ForCES >protocol implementation to work, unicast will definitely be required at >the minimum. One could also mandate using multicast for certain cases >where it will be useful (e.g. IPv4/config table download), if it is >supported by the interconnect as you stated. But just multicast without >unicast will not work, atleast not efficiently. > >Regards >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >Sent: Tuesday, March 02, 2004 5:06 AM >To: forces-protocol@ietf.org >Subject: [Forces-protocol] Comments from chat with ADs > >Patrick and I spent about 90 minutes last night >chatting with Bill and Alex about ForCES, with >maybe half of the time on the protocol. In >the conversations with them, along with some >follow-up chats I had with Allison Mankin, the >following topics where covered: multiple=20 >channels, multicast/unicast, and congestion=20 >control. Below is what I recall from memory=20 >(Patrick please correct me/elaborate as needed :) > > > >Multiple channels: =20 > >I discussed the interference issue that=20 >was identified by the GRMP team. Bill & >Alex agreed that many OS implementations can have >an interference property (i.e. where two different >connections will have queuing interference lower in >the networking stack in the OS). So it is necessary >to make sure when implementing a FE (or CE probably >as well) that this is taken into account. Methods >of doing that include: >* Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) >* Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. >However, it was also mentioned that intra-FE=20 >interference is only one kind of interference. Good >FE implementation (e.g. by manually queuing above the >OS) helps to fix intra-FE interference, but it does >not solve inter-FE interference. That is, if all >(C & D) packets are always on the same connection, >that makes it impossible on the wire to differentiate >them from one another. Imagine you have a bunch of >FEs with some of them being subject to DOS attack for >D packets, and you want to query one of the FEs for >statistics. It would be good to have some way of >ensuring the C packets (or any high priority packets - >OSPF HELLO maybe) get through. Separate channels >(as Jamal indicated, don't even have to be C & D) >makes this possible. Putting everything on one >channel makes it impossible to deal with inter-FE >interference in a differentiated fashion.=20 > > >Multicast & Unicast: =20 > >The discussion on this started out with a discussion >of the IETF protocol design BKM that options can ruin >compatibility. That is, if there are four ways to >implement something, all optional, then you can have >client 1 implement A & B, and client 2 implement C & D, >and even though both clients are 100% compliant, they >cannot talk to one another. Better to say all clients >must implement A and make B, C, and D optional, so that >way you know that all implementations will be able to=20 >at least talk. > >Patrick & I pushed on this a bit, explaining that we >actually had potentially (at least) two different >environments - very close environments where multicast >support could be present in the interconnect, and=20 >not-as-close environments (and some close >environments as well) where multicast was not available. > >Bill & Alex indicated that if there really are two >quite different cases, then it is possible to have a >"dual mandatory" approach. I.e.: > >If your underlying interconnect supports multicast, >then you MUST implement the following (multicast) >method of communication. > >If your underlying interconnect supports unicast, then >you MUST implement the following (unicast) method >of communication. > >This will guarantee interop, although at a potential >extra cost (cost being having to potentially support >both when both are present). While this isn't optimal, >it does at least give some flexibility. > > > >Congestion control: > >Several times over the whole conversation the topic >of congestion control came up. Also, as part of some >TIPC discussions, I ended up spending some time talking >to Allison Mankin (transport AD) about congestion control >as well. All the ADs I talked to where consistent on=20 >the following: > >If you are running over IP, you MUST act in a RFC2914 >compliant fashion (i.e. respond to congestion like TCP >or SCTP or RMT does). Two reasons where put forth for >this: >1) Any time you define an IP-based protocol you cannot >guarantee that it will not go out over the Internet. As >such, the IESG will NOT standardize IP protocols with >"bad" (non-2914) behaviors. >2) Lots of implementation experience showing that other >congestion control mechanisms don't work (congestion >collapse etc). > >They where very firm on the above and my impression was >that convincing them otherwise would be very difficult. > >That being said, a second alternative did arise: If >you are not implementing on top of IP (e.g. running on >Infiniband, ATM, Ethernet) then you could rely on mechanisms >for congestion control built into what you are relying on, >or even consider building your own congestion control >mechanisms (ala TIPC). This makes it possible to define >(for example) a multicast transport for forces without >having to go all the way and implementing RMT - as long >as it is clear that it isn't over IP. The ADs went as >far as saying that the IETF could even accept standards- >track drafts that say nothing about IP (e.g. define an >Ethernet-only transport for ForCES), if it is necessary=20 >for ForCES. GSMP and (some other group I forgot) was >given as an example. > >Cheers, >David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:01:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29559 for ; Fri, 5 Mar 2004 16:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMRJ-0007Np-1d for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:01:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25L1138028378 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMRI-0007Nd-BY for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:01:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29549 for ; Fri, 5 Mar 2004 16:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMRG-0004iR-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMQM-0004YC-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:00:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMPM-0004NM-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 15:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMPM-0007CK-PY; Fri, 05 Mar 2004 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMPL-0007C3-KX for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 15:58:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29478 for ; Fri, 5 Mar 2004 15:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMPJ-0004Mt-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMOR-0004CS-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:58:03 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzMNU-0003qv-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:57:04 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25Kwbxv004400; Fri, 5 Mar 2004 20:58:37 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25Kw9r2001443; Fri, 5 Mar 2004 20:58:19 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030512563110998 ; Fri, 05 Mar 2004 12:56:31 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 12:56:31 -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 Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis DesignTeamAdministrivia Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243F1DA@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] RE: ForCES Protocol Analysis DesignTeamAdministrivia Thread-Index: AcQC6E7qvNAUKSANTsKOSl9pZsH4eAAC3dIw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 Mar 2004 20:56:31.0284 (UTC) FILETIME=[5616FF40:01C402F4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 12:56:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, On Thu, 2004-03-04 at 21:11, Khosravi, Hormuzd M wrote: [..] >=20 > Is there a good reason for such separation? >=20 > [HK] Yes there are several good reasons. One is reliability, the second > is robustness against DoS attacks, yet another one pointed out by Steve > was efficient delivery into CE's networking stack. I thought we had a > common understanding on this,=20 I think we do - but i am getting confused by some of the messages i see from Weiming. Why dont you put some text around this and lets settle on it;=20 [HK] Alright I will do this. I will respond to the issues in the order You have presented them below over the weekend. Regards Hormuzd ------------- To reiterate the issues (and hopefully add discipline to the discussion so we can settle quickly), the above would be issue 2). The others are: 0) ID on the header. 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast=20 { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC}=20 4) Congestion control 5) Reliability 6) Security 7) High availability _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:03:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29617 for ; Fri, 5 Mar 2004 16:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMT5-0007Tf-Ue for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:02:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25L2p1H028734 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:02:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMT5-0007TM-Mm for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29599 for ; Fri, 5 Mar 2004 16:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMT4-00053n-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:02:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMS9-0004t4-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:01:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMRI-0004ip-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMRJ-0007OC-KB; Fri, 05 Mar 2004 16:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMRH-0007NY-Jw for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:00:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29544 for ; Fri, 5 Mar 2004 16:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMRF-0004iH-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:00:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMQK-0004Y4-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:00:02 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzMPM-0004D5-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 15:59:00 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25L0Txv005402; Fri, 5 Mar 2004 21:00:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25L05qs002440; Fri, 5 Mar 2004 21:00:10 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030512581911232 ; Fri, 05 Mar 2004 12:58:19 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 12:58: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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCLs7nL03OZJM+QgqTRTug7WuVqwAIJBbgACeKFoAAAbd+8A== From: "Khosravi, Hormuzd M" To: "Deleganes, Ellen M" , Cc: X-OriginalArrivalTime: 05 Mar 2004 20:58:18.0818 (UTC) FILETIME=[962F6220:01C402F4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 12:58:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes Ellen, that was my intent. Thanks for the clarification, Hormuzd -----Original Message----- From: Deleganes, Ellen M=20 Sent: Friday, March 05, 2004 12:19 PM To: Khosravi, Hormuzd M; alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is that even if Multicast is optional, those procedures that noted in Hormudz's email should be described in the ForCES protocol spec. That is, if a ForCES protocol implementation supports multicast, then it MUST implement it in the manner described in the ForCES protocol specification. Otherwise, ForCES implementations using multicast will probably not interoperate. Whether or not implementing multicast for transports that support multicast is a requirement is a separate question.=20 Regards, Ellen -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Thursday, March 04, 2004 6:12 PM To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs Hi Alex, In general, I prefer using language such as MUST so that there is no confusion or interop issues in the protocol implementations. However, you raise a reasonable point and let me tell you my thoughts on this. We will definitely need Unicast between FEs and CEs at the minimum in the protocol. In addition, if the interconnect technology supports Multicast and there is a case where it is useful to the application (such as downloading IPv4 routes) we must allow it as well without breaking interop. In order to do that, we will need specific procedures in the protocol that will allow the CE and FE to negotiate on using multicast dynamically at run-time (say during the binding or joining phase between the CE and FE) and also associate different multicast groups with LFBs. We will also need to define how Reliability/CC etc. will be provided for multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, then applications will be able to use both unicast and multicast without any interop issues. Let me know what you guys think about this. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 1:22 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs Hormuzd, Why should multicast be "mandated for certain cases where it will be=20 useful" if there is a simpler, more robust way to do the same thing? I'll say we don't=20 mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: >Hi David > >Your summary below of the discussion with Ads on the different issues >seems like very reasonable approaches to me. > >I agree that it will be a good idea to present transport alternatives at >IP and non-IP level for the ForCES protocol. We can mandate one or more >transport for IP and one or more transport for non-IP, this way the >interoperability requirements are met and at the same time, the in-box, >out of box scenarios are met. > >Also, agree with having multiple channels/connections to differentiate C >& D traffic between CEs and FEs. On the unicast/multicast topic, dual >mandatory approach again seems a good idea to support interoperability. >The one thing that I would like to point out is that for any ForCES >protocol implementation to work, unicast will definitely be required at >the minimum. One could also mandate using multicast for certain cases >where it will be useful (e.g. IPv4/config table download), if it is >supported by the interconnect as you stated. But just multicast without >unicast will not work, atleast not efficiently. > >Regards >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >Sent: Tuesday, March 02, 2004 5:06 AM >To: forces-protocol@ietf.org >Subject: [Forces-protocol] Comments from chat with ADs > >Patrick and I spent about 90 minutes last night >chatting with Bill and Alex about ForCES, with >maybe half of the time on the protocol. In >the conversations with them, along with some >follow-up chats I had with Allison Mankin, the >following topics where covered: multiple=20 >channels, multicast/unicast, and congestion=20 >control. Below is what I recall from memory=20 >(Patrick please correct me/elaborate as needed :) > > > >Multiple channels: =20 > >I discussed the interference issue that=20 >was identified by the GRMP team. Bill & >Alex agreed that many OS implementations can have >an interference property (i.e. where two different >connections will have queuing interference lower in >the networking stack in the OS). So it is necessary >to make sure when implementing a FE (or CE probably >as well) that this is taken into account. Methods >of doing that include: >* Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) >* Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. >However, it was also mentioned that intra-FE=20 >interference is only one kind of interference. Good >FE implementation (e.g. by manually queuing above the >OS) helps to fix intra-FE interference, but it does >not solve inter-FE interference. That is, if all >(C & D) packets are always on the same connection, >that makes it impossible on the wire to differentiate >them from one another. Imagine you have a bunch of >FEs with some of them being subject to DOS attack for >D packets, and you want to query one of the FEs for >statistics. It would be good to have some way of >ensuring the C packets (or any high priority packets - >OSPF HELLO maybe) get through. Separate channels >(as Jamal indicated, don't even have to be C & D) >makes this possible. Putting everything on one >channel makes it impossible to deal with inter-FE >interference in a differentiated fashion.=20 > > >Multicast & Unicast: =20 > >The discussion on this started out with a discussion >of the IETF protocol design BKM that options can ruin >compatibility. That is, if there are four ways to >implement something, all optional, then you can have >client 1 implement A & B, and client 2 implement C & D, >and even though both clients are 100% compliant, they >cannot talk to one another. Better to say all clients >must implement A and make B, C, and D optional, so that >way you know that all implementations will be able to=20 >at least talk. > >Patrick & I pushed on this a bit, explaining that we >actually had potentially (at least) two different >environments - very close environments where multicast >support could be present in the interconnect, and=20 >not-as-close environments (and some close >environments as well) where multicast was not available. > >Bill & Alex indicated that if there really are two >quite different cases, then it is possible to have a >"dual mandatory" approach. I.e.: > >If your underlying interconnect supports multicast, >then you MUST implement the following (multicast) >method of communication. > >If your underlying interconnect supports unicast, then >you MUST implement the following (unicast) method >of communication. > >This will guarantee interop, although at a potential >extra cost (cost being having to potentially support >both when both are present). While this isn't optimal, >it does at least give some flexibility. > > > >Congestion control: > >Several times over the whole conversation the topic >of congestion control came up. Also, as part of some >TIPC discussions, I ended up spending some time talking >to Allison Mankin (transport AD) about congestion control >as well. All the ADs I talked to where consistent on=20 >the following: > >If you are running over IP, you MUST act in a RFC2914 >compliant fashion (i.e. respond to congestion like TCP >or SCTP or RMT does). Two reasons where put forth for >this: >1) Any time you define an IP-based protocol you cannot >guarantee that it will not go out over the Internet. As >such, the IESG will NOT standardize IP protocols with >"bad" (non-2914) behaviors. >2) Lots of implementation experience showing that other >congestion control mechanisms don't work (congestion >collapse etc). > >They where very firm on the above and my impression was >that convincing them otherwise would be very difficult. > >That being said, a second alternative did arise: If >you are not implementing on top of IP (e.g. running on >Infiniband, ATM, Ethernet) then you could rely on mechanisms >for congestion control built into what you are relying on, >or even consider building your own congestion control >mechanisms (ala TIPC). This makes it possible to define >(for example) a multicast transport for forces without >having to go all the way and implementing RMT - as long >as it is clear that it isn't over IP. The ADs went as >far as saying that the IETF could even accept standards- >track drafts that say nothing about IP (e.g. define an >Ethernet-only transport for ForCES), if it is necessary=20 >for ForCES. GSMP and (some other group I forgot) was >given as an example. > >Cheers, >David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:08:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29863 for ; Fri, 5 Mar 2004 16:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMXy-0008Er-EJ for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:07:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25L7sBV031652 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:07:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMXx-0008ER-RT for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:07:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29822 for ; Fri, 5 Mar 2004 16:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMXw-00061n-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:07:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMX5-0005r7-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:07:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMW8-0005fq-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMWA-0007tc-2B; Fri, 05 Mar 2004 16:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMW7-0007t5-07 for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29737 for ; Fri, 5 Mar 2004 16:05:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMW5-0005fI-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMVB-0005UK-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:05:02 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzMUO-00056s-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:04:12 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25L3fTN028919; Fri, 5 Mar 2004 15:03:41 -0600 (CST) Message-ID: <4048EB2C.9090104@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia References: <9CB758BBEE58754F8F33234D75B9F4B00243EAD0@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243EAD0@orsmsx410.jf.intel.com> Content-Type: multipart/alternative; boundary="------------090402070008010009090406" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 15:03:40 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090402070008010009090406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Hormuzd, If ForCES run directly over L2, we are suggesting it acts like the network (OSI) or Internet layer (IP). That means it validates, routes, and demultiplexes amongst various transports/applications (amongst other functions). Is that what we want here? Regards, Alex. Khosravi, Hormuzd M wrote: >I believe layer 2 protocol is the same in both models (internet and >OSI). >Common example is Ethernet. May be the use of the word "interconnect" >was confusing. >What I mean is that the ForCES protocol should be able to run directly >over layer 2 >protocols like ethernet. This might be useful in some in-box scenarios. > >Let me know if you have any other questions. > >Regards >Hormuzd > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, March 04, 2004 12:56 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team >Administrivia > > >Hormuzd, > >I don't understand this requirement (reproduced below): > >------------------------------------------------------------------------ >The ForCES protocol will run directly over layer 2 interconnects. It can >either use additional TLVs or encapsulation headers or transports such >as TIPC to provide the missing functionality such as reliability, >fragmentation, etc. >------------------------------------------------------------------------ > >Can you explain this? Which L2 are you refering to? (Internet Protocol >layer 2 or OSI layer2). > >Regards, >Alex. > > > > >Khosravi, Hormuzd M wrote: > > > >>Here is a starter list of common high level ideas/features/principles >>that I believe we all agree on... >> >>All ForCES protocol messages should consist of a fixed size header and >>variable size payload fields. Further, the protocol header is made up >> >> >of > > >>CE ID, FE ID fields in addition to other fields (TBD) >> >>All ForCES protocol messages should be 32-bit aligned. >> >>The ForCES protocol payload consists of a number of variable size TLVs >>i.e. all ForCES messages must use TLV encoding. >> >>The FE ID field in the protocol header is assigned or allocated by the >>CE. >> >>The ForCES protocol/model must support the discovery of static >>capabilities of an FE. The protocol/model may also support dynamic >>capabilities when they are supported by the FEs. >> >>The ForCES protocol should support logical addressing for multicast in >>addition to unicast. The FE ID, CE ID fields in the header will be used >>for addressing FEs, CEs. >> >>The ForCES protocol should have separate channels/connections/(any >> >> >other > > >>terminology ?) for data and control messages. By data messages we mean >>control protocol packets such as OSPF, RIP packets, etc. which need to >>be redirected from FE to CE or forwarded from CE to FE. By control >>messages we mean all other control/capability/configuration messages. >> >>The ForCES protocol will mandate a minimum set of transports for data >>and control connections/channels for interoperability reasons. >> >>The ForCES protocol will take advantage of underlying transports/ >>interconnects to provide features such as reliability, security to keep >>the protocol design itself simple. >> >>The ForCES protocol will run directly over layer 2 interconnects. It >> >> >can > > >>either use additional TLVs or encapsulation headers or transports such >>as TIPC to provide the missing functionality such as reliability, >>fragmentation, etc. >> >>This is just a starting list, we should continue adding to this one as >>we discuss more ideas. >>Pls feel free to give comments or make any changes to the text above. >> >> >>BTW note to the list-admin, gyf@htrdc.com address is not working. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: Khosravi, Hormuzd M >>Sent: Tuesday, March 02, 2004 4:55 PM >>To: 'hadi@znyx.com' >>Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; >>spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; >>ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; >>jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; >>zsolt.haraszti@ericsson.com; forces-protocol@ietf.org >>Subject: RE: ForCES Protocol Analysis Design Team Administrivia >> >>Hi Jamal, All >> >>I briefly chatted with David, Patrick regarding our deliverables by >>March 20th and I got a feeling that they are looking for whether we can >>merge the protocols and what are the high level design features that we >>all agree on. >>I think most of us already agree that we can achieve a merge if we work >>towards it. I would suggest that we first try to get all the high level >>features list out and agree on it, then proceed to the details. >> >>So in that spirit I would suggest to postpone getting into details such >>as length of bits in the header, what the format is, etc for now and >>quickly come up with a list of common ideas. Some of the items below >>that we all seem to agree on may be a good start. >> >> >>regards >>Hormuzd >> >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > > --------------090402070008010009090406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,

If ForCES run directly over L2, we are suggesting it acts like the network (OSI) or
Internet layer (IP). That means it validates, routes, and demultiplexes amongst various
transports/applications  (amongst other functions). Is that what we want here?

Regards,
Alex.


Khosravi, Hormuzd M wrote:
I believe layer 2 protocol is the same in both models (internet and
OSI).
Common example is Ethernet. May be the use of the word "interconnect"
was confusing.
What I mean is that the ForCES protocol should be able to run directly
over layer 2
protocols like ethernet. This might be useful in some in-box scenarios.

Let me know if you have any other questions.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Thursday, March 04, 2004 12:56 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team
Administrivia


Hormuzd,

I don't understand this requirement (reproduced below):

------------------------------------------------------------------------
The ForCES protocol will run directly over layer 2 interconnects. It can
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.
------------------------------------------------------------------------

Can you explain this?  Which L2 are you refering to? (Internet Protocol
layer 2 or OSI layer2). 

Regards,
Alex.




Khosravi, Hormuzd M wrote:

  
Here is a starter list of common high level ideas/features/principles
that I believe we all agree on...

All ForCES protocol messages should consist of a fixed size header and
variable size payload fields. Further, the protocol header is made up
    
of
  
CE ID, FE ID fields in addition to other fields (TBD)

All ForCES protocol messages should be 32-bit aligned.

The ForCES protocol payload consists of a number of variable size TLVs
i.e. all ForCES messages must use TLV encoding.

The FE ID field in the protocol header is assigned or allocated by the
CE.

The ForCES protocol/model must support the discovery of static
capabilities of an FE. The protocol/model may also support dynamic
capabilities when they are supported by the FEs.

The ForCES protocol should support logical addressing for multicast in
addition to unicast. The FE ID, CE ID fields in the header will be used
for addressing FEs, CEs.

The ForCES protocol should have separate channels/connections/(any
    
other
  
terminology ?) for data and control messages. By data messages we mean
control protocol packets such as OSPF, RIP packets, etc. which need to
be redirected from FE to CE or forwarded from CE to FE. By control
messages we mean all other control/capability/configuration messages.

The ForCES protocol will mandate a minimum set of transports for data
and control connections/channels for interoperability reasons.

The ForCES protocol will take advantage of underlying transports/
interconnects to provide features such as reliability, security to keep
the protocol design itself simple.

The ForCES protocol will run directly over layer 2 interconnects. It
    
can
  
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.

This is just a starting list, we should continue adding to this one as
we discuss more ideas.
Pls feel free to give comments or make any changes to the text above.


BTW note to the list-admin, gyf@htrdc.com address is not working.

Regards
Hormuzd

-----Original Message-----
From: Khosravi, Hormuzd M 
Sent: Tuesday, March 02, 2004 4:55 PM
To: 'hadi@znyx.com'
Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn;
spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas;
ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz;
jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com;
zsolt.haraszti@ericsson.com; forces-protocol@ietf.org
Subject: RE: ForCES Protocol Analysis Design Team Administrivia

Hi Jamal, All

I briefly chatted with David, Patrick regarding our deliverables by
March 20th and I got a feeling that they are looking for whether we can
merge the protocols and what are the high level design features that we
all agree on.
I think most of us already agree that we can achieve a merge if we work
towards it. I would suggest that we first try to get all the high level
features list out and agree on it, then proceed to the details.

So in that spirit I would suggest to postpone getting into details such
as length of bits in the header, what the format is, etc for now and
quickly come up with a list of common ideas. Some of the items below
that we all seem to agree on may be a good start.


regards
Hormuzd



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------090402070008010009090406-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:14:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00039 for ; Fri, 5 Mar 2004 16:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMdi-0000Es-KP for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:13:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LDo13000912 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMdi-0000Ec-CW for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:13:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00032 for ; Fri, 5 Mar 2004 16:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMdg-0006z8-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:13:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMcm-0006qA-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:12:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMbu-0006gk-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMbv-0008Vm-Ng; Fri, 05 Mar 2004 16:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMbo-0008VG-Fc for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:11:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29981 for ; Fri, 5 Mar 2004 16:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMbm-0006fh-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMaw-0006W7-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:11:00 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzMaO-0006MF-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:10:24 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25LBmxv011992; Fri, 5 Mar 2004 21:11:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25L3x6T015744; Fri, 5 Mar 2004 21:04:11 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030513094428903 ; Fri, 05 Mar 2004 13:09:44 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 13:09:44 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243F209@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCtsuE1jgYr6d7RT+Wyv6quGwybQAPilmg From: "Khosravi, Hormuzd M" To: "jeff pickering" Cc: , X-OriginalArrivalTime: 05 Mar 2004 21:09:44.0695 (UTC) FILETIME=[2EFFE870:01C402F6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 13:09:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jeff, Just wanted to clarify one comment below. I think some sort of negotiation will be necessary even if we mandate multicast for certain cases in order to have an easy interop. In general, the more specific we are about all the details in the protocol, the stronger language we use, the easier it will be for us to interop. The question that you have asked below is a very valid question and will need to be answered in the protocol spec explicitly. My gut feeling for the answer is that there will be a mix traffic, if the other FEs support multicast and the CE would like to use it or is using it already. Regards Hormuzd -----Original Message----- From: jeff pickering [mailto:jpickering@creeksidenet.com]=20 Sent: Friday, March 05, 2004 5:36 AM To: Khosravi, Hormuzd M Cc: alex.audu@alcatel.com; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs All, Given that I dont believe we can scale well without multicast, I would=20 like to see it as a MUST. But thats just due to a focus on larger systems. For=20 lightweight implementations, one could envision unicast being sufficient. I agree with Hormuzd that=20 some negotiation is necessary if we make this a SHOULD. Then the question would become=20 what happens when 1 FE says it can only unicast. Does all traffic revert to unicast,=20 or can there be a mix? Jeff Khosravi, Hormuzd M wrote: >Hi Alex, > >In general, I prefer using language such as MUST so that there is no >confusion or interop issues in the protocol implementations. However, >you raise a reasonable point and let me tell you my thoughts on this. We >will definitely need Unicast between FEs and CEs at the minimum in the >protocol. In addition, if the interconnect technology supports Multicast >and there is a case where it is useful to the application (such as >downloading IPv4 routes) we must allow it as well without breaking >interop. In order to do that, we will need specific procedures in the >protocol that will allow the CE and FE to negotiate on using multicast >dynamically at run-time (say during the binding or joining phase between >the CE and FE) and also associate different multicast groups with LFBs. >We will also need to define how Reliability/CC etc. will be provided for >multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >then applications will be able to use both unicast and multicast without >any interop issues. > >Let me know what you guys think about this. > >Regards >Hormuzd > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com]=20 >Sent: Thursday, March 04, 2004 1:22 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Comments from chat with ADs > > >Hormuzd, > >Why should multicast be "mandated for certain cases where it will be=20 >useful" if there >is a simpler, more robust way to do the same thing? I'll say we don't=20 >mandate this. >We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >and make MULTICAST optional. Any issues with this? > >Regards, >Alex. > > >Khosravi, Hormuzd M wrote: > > =20 > >>Hi David >> >>Your summary below of the discussion with Ads on the different issues >>seems like very reasonable approaches to me. >> >>I agree that it will be a good idea to present transport alternatives >> =20 >> >at > =20 > >>IP and non-IP level for the ForCES protocol. We can mandate one or more >>transport for IP and one or more transport for non-IP, this way the >>interoperability requirements are met and at the same time, the in-box, >>out of box scenarios are met. >> >>Also, agree with having multiple channels/connections to differentiate >> =20 >> >C > =20 > >>& D traffic between CEs and FEs. On the unicast/multicast topic, dual >>mandatory approach again seems a good idea to support interoperability. >>The one thing that I would like to point out is that for any ForCES >>protocol implementation to work, unicast will definitely be required at >>the minimum. One could also mandate using multicast for certain cases >>where it will be useful (e.g. IPv4/config table download), if it is >>supported by the interconnect as you stated. But just multicast without >>unicast will not work, atleast not efficiently. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>Sent: Tuesday, March 02, 2004 5:06 AM >>To: forces-protocol@ietf.org >>Subject: [Forces-protocol] Comments from chat with ADs >> >>Patrick and I spent about 90 minutes last night >>chatting with Bill and Alex about ForCES, with >>maybe half of the time on the protocol. In >>the conversations with them, along with some >>follow-up chats I had with Allison Mankin, the >>following topics where covered: multiple=20 >>channels, multicast/unicast, and congestion=20 >>control. Below is what I recall from memory=20 >>(Patrick please correct me/elaborate as needed :) >> >> >> >>Multiple channels: =20 >> >>I discussed the interference issue that=20 >>was identified by the GRMP team. Bill & >>Alex agreed that many OS implementations can have >>an interference property (i.e. where two different >>connections will have queuing interference lower in >>the networking stack in the OS). So it is necessary >>to make sure when implementing a FE (or CE probably >>as well) that this is taken into account. Methods >>of doing that include: >>* Manually queuing packets (i.e. feed OS few enough >> packets that it cannot get into trouble - although >> you pay a performance price for that, in that fine >> grained scheduling takes cycles) >>* Indicating to the OS to treat flows differently -=20 >> some real-time OS will let you do this, that is they >> are implemented to internally retain QoS between >> flows. >>However, it was also mentioned that intra-FE=20 >>interference is only one kind of interference. Good >>FE implementation (e.g. by manually queuing above the >>OS) helps to fix intra-FE interference, but it does >>not solve inter-FE interference. That is, if all >>(C & D) packets are always on the same connection, >>that makes it impossible on the wire to differentiate >>them from one another. Imagine you have a bunch of >>FEs with some of them being subject to DOS attack for >>D packets, and you want to query one of the FEs for >>statistics. It would be good to have some way of >>ensuring the C packets (or any high priority packets - >>OSPF HELLO maybe) get through. Separate channels >>(as Jamal indicated, don't even have to be C & D) >>makes this possible. Putting everything on one >>channel makes it impossible to deal with inter-FE >>interference in a differentiated fashion.=20 >> >> >>Multicast & Unicast: =20 >> >>The discussion on this started out with a discussion >>of the IETF protocol design BKM that options can ruin >>compatibility. That is, if there are four ways to >>implement something, all optional, then you can have >>client 1 implement A & B, and client 2 implement C & D, >>and even though both clients are 100% compliant, they >>cannot talk to one another. Better to say all clients >>must implement A and make B, C, and D optional, so that >>way you know that all implementations will be able to=20 >>at least talk. >> >>Patrick & I pushed on this a bit, explaining that we >>actually had potentially (at least) two different >>environments - very close environments where multicast >>support could be present in the interconnect, and=20 >>not-as-close environments (and some close >>environments as well) where multicast was not available. >> >>Bill & Alex indicated that if there really are two >>quite different cases, then it is possible to have a >>"dual mandatory" approach. I.e.: >> >>If your underlying interconnect supports multicast, >>then you MUST implement the following (multicast) >>method of communication. >> >>If your underlying interconnect supports unicast, then >>you MUST implement the following (unicast) method >>of communication. >> >>This will guarantee interop, although at a potential >>extra cost (cost being having to potentially support >>both when both are present). While this isn't optimal, >>it does at least give some flexibility. >> >> >> >>Congestion control: >> >>Several times over the whole conversation the topic >>of congestion control came up. Also, as part of some >>TIPC discussions, I ended up spending some time talking >>to Allison Mankin (transport AD) about congestion control >>as well. All the ADs I talked to where consistent on=20 >>the following: >> >>If you are running over IP, you MUST act in a RFC2914 >>compliant fashion (i.e. respond to congestion like TCP >>or SCTP or RMT does). Two reasons where put forth for >>this: >>1) Any time you define an IP-based protocol you cannot >>guarantee that it will not go out over the Internet. As >>such, the IESG will NOT standardize IP protocols with >>"bad" (non-2914) behaviors. >>2) Lots of implementation experience showing that other >>congestion control mechanisms don't work (congestion >>collapse etc). >> >>They where very firm on the above and my impression was >>that convincing them otherwise would be very difficult. >> >>That being said, a second alternative did arise: If >>you are not implementing on top of IP (e.g. running on >>Infiniband, ATM, Ethernet) then you could rely on mechanisms >>for congestion control built into what you are relying on, >>or even consider building your own congestion control >>mechanisms (ala TIPC). This makes it possible to define >>(for example) a multicast transport for forces without >>having to go all the way and implementing RMT - as long >>as it is clear that it isn't over IP. The ADs went as >>far as saying that the IETF could even accept standards- >>track drafts that say nothing about IP (e.g. define an >>Ethernet-only transport for ForCES), if it is necessary=20 >>for ForCES. GSMP and (some other group I forgot) was >>given as an example. >> >>Cheers, >>David >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >>=20 >> >> =20 >> > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00717 for ; Fri, 5 Mar 2004 16:28:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMrR-0001Q1-T2 for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LS1uc005442 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMrR-0001Pe-KS for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00687 for ; Fri, 5 Mar 2004 16:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMrP-0001h6-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:27:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMqb-0001W5-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:27:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMpU-0001LA-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMpU-0001Mz-TP; Fri, 05 Mar 2004 16:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMpL-0001Mh-4c for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00542 for ; Fri, 5 Mar 2004 16:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMpJ-0001KF-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:25:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMoK-0001BD-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:24:50 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzMnN-0000to-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:23:49 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25LPIxv019323; Fri, 5 Mar 2004 21:25:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25LH96h021392; Fri, 5 Mar 2004 21:17:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030513231530719 ; Fri, 05 Mar 2004 13:23:15 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 13:23:15 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C402F8.11DE40A2" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00243F228@orsmsx410.jf.intel.com> Thread-Topic: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Thread-Index: AcQC9WypKecxHjPCTse933whgzAmpAAAQV6Q From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 Mar 2004 21:23:15.0169 (UTC) FILETIME=[12146D10:01C402F8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 13:23:14 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C402F8.11DE40A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, =20 We will need some of the stuff below to run ForCES directly over L2 including reliability/CC, etc. But that doesn't mean all this complexity has to necessarily be implemented by the ForCES protocol. See David's email on this issue, we might land up using TIPC to provide some of this functionality over L2. This still needs to be discussed. =20 Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Friday, March 05, 2004 1:04 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Hi Hormuzd, If ForCES run directly over L2, we are suggesting it acts like the network (OSI) or=20 Internet layer (IP). That means it validates, routes, and demultiplexes amongst various transports/applications (amongst other functions). Is that what we want here? Regards, Alex. Khosravi, Hormuzd M wrote: I believe layer 2 protocol is the same in both models (internet and OSI). Common example is Ethernet. May be the use of the word "interconnect" was confusing. What I mean is that the ForCES protocol should be able to run directly over layer 2 protocols like ethernet. This might be useful in some in-box scenarios. Let me know if you have any other questions. Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 12:56 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team Administrivia Hormuzd, I don't understand this requirement (reproduced below): ------------------------------------------------------------------------ The ForCES protocol will run directly over layer 2 interconnects. It can either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. ------------------------------------------------------------------------ Can you explain this? Which L2 are you refering to? (Internet Protocol layer 2 or OSI layer2).=20 Regards, Alex. Khosravi, Hormuzd M wrote: =20 Here is a starter list of common high level ideas/features/principles that I believe we all agree on... All ForCES protocol messages should consist of a fixed size header and variable size payload fields. Further, the protocol header is made up =20 of =20 CE ID, FE ID fields in addition to other fields (TBD) All ForCES protocol messages should be 32-bit aligned. The ForCES protocol payload consists of a number of variable size TLVs i.e. all ForCES messages must use TLV encoding. The FE ID field in the protocol header is assigned or allocated by the CE. The ForCES protocol/model must support the discovery of static capabilities of an FE. The protocol/model may also support dynamic capabilities when they are supported by the FEs. The ForCES protocol should support logical addressing for multicast in addition to unicast. The FE ID, CE ID fields in the header will be used for addressing FEs, CEs. The ForCES protocol should have separate channels/connections/(any =20 other =20 terminology ?) for data and control messages. By data messages we mean control protocol packets such as OSPF, RIP packets, etc. which need to be redirected from FE to CE or forwarded from CE to FE. By control messages we mean all other control/capability/configuration messages. The ForCES protocol will mandate a minimum set of transports for data and control connections/channels for interoperability reasons. The ForCES protocol will take advantage of underlying transports/ interconnects to provide features such as reliability, security to keep the protocol design itself simple. The ForCES protocol will run directly over layer 2 interconnects. It =20 can =20 either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. This is just a starting list, we should continue adding to this one as we discuss more ideas. Pls feel free to give comments or make any changes to the text above. BTW note to the list-admin, gyf@htrdc.com address is not working. Regards Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Tuesday, March 02, 2004 4:55 PM To: 'hadi@znyx.com' Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn; spyros.denazis@hitachi-eu.com; Steve Blake; Robert Haas; ram.gopal@nokia.com; alex.audu@alcatel.com; Wang,Weiming; Patrick Droz; jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com; zsolt.haraszti@ericsson.com; forces-protocol@ietf.org Subject: RE: ForCES Protocol Analysis Design Team Administrivia Hi Jamal, All I briefly chatted with David, Patrick regarding our deliverables by March 20th and I got a feeling that they are looking for whether we can merge the protocols and what are the high level design features that we all agree on. I think most of us already agree that we can achieve a merge if we work towards it. I would suggest that we first try to get all the high level features list out and agree on it, then proceed to the details. So in that spirit I would suggest to postpone getting into details such as length of bits in the header, what the format is, etc for now and quickly come up with a list of common ideas. Some of the items below that we all seem to agree on may be a good start. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 =20 ------_=_NextPart_001_01C402F8.11DE40A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Alex,
 
We=20 will need some of the stuff below to run ForCES directly over L2 = including=20 reliability/CC, etc.
But=20 that doesn't mean all this complexity has to necessarily be implemented = by the=20 ForCES protocol.
See=20 David's email on this issue, we might land up using TIPC to provide some = of this=20 functionality over L2.
This=20 still needs to be discussed.
 
Regards
Hormuzd
-----Original Message-----
From: Alex = Audu=20 [mailto:alex.audu@alcatel.com]
Sent: Friday, March 05, 2004 = 1:04=20 PM
To: Khosravi, Hormuzd M
Cc:=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: = ForCES=20 Protocol Analysis Design Team Administrivia

Hi=20 Hormuzd,

If ForCES run directly over L2, we are suggesting it = acts like=20 the network (OSI) or
Internet layer (IP). That means it validates, = routes,=20 and demultiplexes amongst various
transports/applications  = (amongst=20 other functions). Is that what we want=20 here?

Regards,
Alex.


Khosravi, Hormuzd M = wrote:
I believe layer 2 protocol is the same in =
both models (internet and
OSI).
Common example is Ethernet. May be the use of the word "interconnect"
was confusing.
What I mean is that the ForCES protocol should be able to run directly
over layer 2
protocols like ethernet. This might be useful in some in-box scenarios.

Let me know if you have any other questions.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com]=20
Sent: Thursday, March 04, 2004 12:56 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team
Administrivia


Hormuzd,

I don't understand this requirement (reproduced below):

------------------------------------------------------------------------
The ForCES protocol will run directly over layer 2 interconnects. It can
either use additional TLVs or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.
------------------------------------------------------------------------

Can you explain this?  Which L2 are you refering to? (Internet Protocol
layer 2 or OSI layer2).=20

Regards,
Alex.




Khosravi, Hormuzd M wrote:

  
Here is a starter list of =
common high level ideas/features/principles
that I believe we all agree on...

All ForCES protocol messages should consist of a fixed size header and
variable size payload fields. Further, the protocol header is made up
    
of
  
CE ID, FE ID fields in =
addition to other fields (TBD)

All ForCES protocol messages should be 32-bit aligned.

The ForCES protocol payload consists of a number of variable size TLVs
i.e. all ForCES messages must use TLV encoding.

The FE ID field in the protocol header is assigned or allocated by the
CE.

The ForCES protocol/model must support the discovery of static
capabilities of an FE. The protocol/model may also support dynamic
capabilities when they are supported by the FEs.

The ForCES protocol should support logical addressing for multicast in
addition to unicast. The FE ID, CE ID fields in the header will be used
for addressing FEs, CEs.

The ForCES protocol should have separate channels/connections/(any
    
other
  
terminology ?) for data and =
control messages. By data messages we mean
control protocol packets such as OSPF, RIP packets, etc. which need to
be redirected from FE to CE or forwarded from CE to FE. By control
messages we mean all other control/capability/configuration messages.

The ForCES protocol will mandate a minimum set of transports for data
and control connections/channels for interoperability reasons.

The ForCES protocol will take advantage of underlying transports/
interconnects to provide features such as reliability, security to keep
the protocol design itself simple.

The ForCES protocol will run directly over layer 2 interconnects. It
    
can
  
either use additional TLVs =
or encapsulation headers or transports such
as TIPC to provide the missing functionality such as reliability,
fragmentation, etc.

This is just a starting list, we should continue adding to this one as
we discuss more ideas.
Pls feel free to give comments or make any changes to the text above.


BTW note to the list-admin, gyf@htrdc.com address is not working.

Regards
Hormuzd

-----Original Message-----
From: Khosravi, Hormuzd M=20
Sent: Tuesday, March 02, 2004 4:55 PM
To: 'hadi@znyx.com'
Cc: Putzolu, David; gmwang@mail.hzic.edu.cn; donglg@mail.hzic.edu.cn;
spyros.denazis@hitachi-eu.c=
om; Steve Blake; Robert Haas;
ram.gopal@nokia.com; alex.audu@alcatel.com; =
Wang,Weiming; Patrick Droz;
jeff pickering; avri@acm.org; Deleganes, Ellen M; gyf@htrdc.com;
zsolt.haraszti@ericsson.com; forces-protocol@ietf.org
Subject: RE: ForCES Protocol Analysis Design Team Administrivia

Hi Jamal, All

I briefly chatted with David, Patrick regarding our deliverables by
March 20th and I got a feeling that they are looking for whether we can
merge the protocols and what are the high level design features that we
all agree on.
I think most of us already agree that we can achieve a merge if we work
towards it. I would suggest that we first try to get all the high level
features list out and agree on it, then proceed to the details.

So in that spirit I would suggest to postpone getting into details such
as length of bits in the header, what the format is, etc for now and
quickly come up with a list of common ideas. Some of the items below
that we all seem to agree on may be a good start.


regards
Hormuzd



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
=20
------_=_NextPart_001_01C402F8.11DE40A2-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:31:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00826 for ; Fri, 5 Mar 2004 16:31:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMuE-0001XV-Rz for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:30:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LUsq1005911 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMuD-0001XG-Vs for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:30:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00818 for ; Fri, 5 Mar 2004 16:30:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMuC-0002EL-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:30:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMtI-00023t-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:29:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMsN-0001sQ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMsO-0001RO-EL; Fri, 05 Mar 2004 16:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMrV-0001QD-7E for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00692 for ; Fri, 5 Mar 2004 16:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMrT-0001hl-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMqh-0001XE-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:27:17 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzMq6-0001LE-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:26:38 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25LQ7TN002742; Fri, 5 Mar 2004 15:26:07 -0600 (CST) Message-ID: <4048F06E.8020809@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> Content-Type: multipart/alternative; boundary="------------030102090104000904020609" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 15:26:06 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030102090104000904020609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I still maintain that MULTICAST is best left at SHOULD implement strength. Why? A lot of issues are still unresolved concerning multicast reliabililty, security, etc., unless we want to define an application-layer method to resolve issues like synchronization, packet-loss, ACK/NACK implosion, etc. Alex. Khosravi, Hormuzd M wrote: >Yes Ellen, that was my intent. > >Thanks for the clarification, >Hormuzd > >-----Original Message----- >From: Deleganes, Ellen M >Sent: Friday, March 05, 2004 12:19 PM >To: Khosravi, Hormuzd M; alex.audu@alcatel.com >Cc: forces-protocol@ietf.org >Subject: RE: [Forces-protocol] Comments from chat with ADs > > >I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is >that even if Multicast is optional, those procedures that noted in >Hormudz's email should be described in the ForCES protocol spec. That >is, if a ForCES protocol implementation supports multicast, then it MUST >implement it in the manner described in the ForCES protocol >specification. Otherwise, ForCES implementations using multicast will >probably not interoperate. > >Whether or not implementing multicast for transports that support >multicast is a requirement is a separate question. > >Regards, >Ellen > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M >Sent: Thursday, March 04, 2004 6:12 PM >To: alex.audu@alcatel.com >Cc: forces-protocol@ietf.org >Subject: RE: [Forces-protocol] Comments from chat with ADs > >Hi Alex, > >In general, I prefer using language such as MUST so that there is no >confusion or interop issues in the protocol implementations. However, >you raise a reasonable point and let me tell you my thoughts on this. We >will definitely need Unicast between FEs and CEs at the minimum in the >protocol. In addition, if the interconnect technology supports Multicast >and there is a case where it is useful to the application (such as >downloading IPv4 routes) we must allow it as well without breaking >interop. In order to do that, we will need specific procedures in the >protocol that will allow the CE and FE to negotiate on using multicast >dynamically at run-time (say during the binding or joining phase between >the CE and FE) and also associate different multicast groups with LFBs. >We will also need to define how Reliability/CC etc. will be provided for >multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >then applications will be able to use both unicast and multicast without >any interop issues. > >Let me know what you guys think about this. > >Regards >Hormuzd > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Thursday, March 04, 2004 1:22 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Comments from chat with ADs > > >Hormuzd, > >Why should multicast be "mandated for certain cases where it will be >useful" if there >is a simpler, more robust way to do the same thing? I'll say we don't >mandate this. >We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >and make MULTICAST optional. Any issues with this? > >Regards, >Alex. > > >Khosravi, Hormuzd M wrote: > > > >>Hi David >> >>Your summary below of the discussion with Ads on the different issues >>seems like very reasonable approaches to me. >> >>I agree that it will be a good idea to present transport alternatives >> >> >at > > >>IP and non-IP level for the ForCES protocol. We can mandate one or more >>transport for IP and one or more transport for non-IP, this way the >>interoperability requirements are met and at the same time, the in-box, >>out of box scenarios are met. >> >>Also, agree with having multiple channels/connections to differentiate >> >> >C > > >>& D traffic between CEs and FEs. On the unicast/multicast topic, dual >>mandatory approach again seems a good idea to support interoperability. >>The one thing that I would like to point out is that for any ForCES >>protocol implementation to work, unicast will definitely be required at >>the minimum. One could also mandate using multicast for certain cases >>where it will be useful (e.g. IPv4/config table download), if it is >>supported by the interconnect as you stated. But just multicast without >>unicast will not work, atleast not efficiently. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>Sent: Tuesday, March 02, 2004 5:06 AM >>To: forces-protocol@ietf.org >>Subject: [Forces-protocol] Comments from chat with ADs >> >>Patrick and I spent about 90 minutes last night >>chatting with Bill and Alex about ForCES, with >>maybe half of the time on the protocol. In >>the conversations with them, along with some >>follow-up chats I had with Allison Mankin, the >>following topics where covered: multiple >>channels, multicast/unicast, and congestion >>control. Below is what I recall from memory >>(Patrick please correct me/elaborate as needed :) >> >> >> >>Multiple channels: >> >>I discussed the interference issue that >>was identified by the GRMP team. Bill & >>Alex agreed that many OS implementations can have >>an interference property (i.e. where two different >>connections will have queuing interference lower in >>the networking stack in the OS). So it is necessary >>to make sure when implementing a FE (or CE probably >>as well) that this is taken into account. Methods >>of doing that include: >>* Manually queuing packets (i.e. feed OS few enough >> packets that it cannot get into trouble - although >> you pay a performance price for that, in that fine >> grained scheduling takes cycles) >>* Indicating to the OS to treat flows differently - >> some real-time OS will let you do this, that is they >> are implemented to internally retain QoS between >> flows. >>However, it was also mentioned that intra-FE >>interference is only one kind of interference. Good >>FE implementation (e.g. by manually queuing above the >>OS) helps to fix intra-FE interference, but it does >>not solve inter-FE interference. That is, if all >>(C & D) packets are always on the same connection, >>that makes it impossible on the wire to differentiate >>them from one another. Imagine you have a bunch of >>FEs with some of them being subject to DOS attack for >>D packets, and you want to query one of the FEs for >>statistics. It would be good to have some way of >>ensuring the C packets (or any high priority packets - >>OSPF HELLO maybe) get through. Separate channels >>(as Jamal indicated, don't even have to be C & D) >>makes this possible. Putting everything on one >>channel makes it impossible to deal with inter-FE >>interference in a differentiated fashion. >> >> >>Multicast & Unicast: >> >>The discussion on this started out with a discussion >>of the IETF protocol design BKM that options can ruin >>compatibility. That is, if there are four ways to >>implement something, all optional, then you can have >>client 1 implement A & B, and client 2 implement C & D, >>and even though both clients are 100% compliant, they >>cannot talk to one another. Better to say all clients >>must implement A and make B, C, and D optional, so that >>way you know that all implementations will be able to >>at least talk. >> >>Patrick & I pushed on this a bit, explaining that we >>actually had potentially (at least) two different >>environments - very close environments where multicast >>support could be present in the interconnect, and >>not-as-close environments (and some close >>environments as well) where multicast was not available. >> >>Bill & Alex indicated that if there really are two >>quite different cases, then it is possible to have a >>"dual mandatory" approach. I.e.: >> >>If your underlying interconnect supports multicast, >>then you MUST implement the following (multicast) >>method of communication. >> >>If your underlying interconnect supports unicast, then >>you MUST implement the following (unicast) method >>of communication. >> >>This will guarantee interop, although at a potential >>extra cost (cost being having to potentially support >>both when both are present). While this isn't optimal, >>it does at least give some flexibility. >> >> >> >>Congestion control: >> >>Several times over the whole conversation the topic >>of congestion control came up. Also, as part of some >>TIPC discussions, I ended up spending some time talking >>to Allison Mankin (transport AD) about congestion control >>as well. All the ADs I talked to where consistent on >>the following: >> >>If you are running over IP, you MUST act in a RFC2914 >>compliant fashion (i.e. respond to congestion like TCP >>or SCTP or RMT does). Two reasons where put forth for >>this: >>1) Any time you define an IP-based protocol you cannot >>guarantee that it will not go out over the Internet. As >>such, the IESG will NOT standardize IP protocols with >>"bad" (non-2914) behaviors. >>2) Lots of implementation experience showing that other >>congestion control mechanisms don't work (congestion >>collapse etc). >> >>They where very firm on the above and my impression was >>that convincing them otherwise would be very difficult. >> >>That being said, a second alternative did arise: If >>you are not implementing on top of IP (e.g. running on >>Infiniband, ATM, Ethernet) then you could rely on mechanisms >>for congestion control built into what you are relying on, >>or even consider building your own congestion control >>mechanisms (ala TIPC). This makes it possible to define >>(for example) a multicast transport for forces without >>having to go all the way and implementing RMT - as long >>as it is clear that it isn't over IP. The ADs went as >>far as saying that the IETF could even accept standards- >>track drafts that say nothing about IP (e.g. define an >>Ethernet-only transport for ForCES), if it is necessary >>for ForCES. GSMP and (some other group I forgot) was >>given as an example. >> >>Cheers, >>David >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------030102090104000904020609 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I still maintain that MULTICAST is best left at SHOULD implement strength.  Why?
A lot of issues are still unresolved concerning multicast reliabililty, security, etc., unless
we want to define an application-layer method to resolve issues like  synchronization,
packet-loss, ACK/NACK implosion, etc. 

Alex.

Khosravi, Hormuzd M wrote:
Yes Ellen, that was my intent.

Thanks for the clarification,
Hormuzd

-----Original Message-----
From: Deleganes, Ellen M 
Sent: Friday, March 05, 2004 12:19 PM
To: Khosravi, Hormuzd M; alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs


I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is
that even if Multicast is optional, those procedures that noted in
Hormudz's email should be described in the ForCES protocol spec. That
is, if a ForCES protocol implementation supports multicast, then it MUST
implement it in the manner described in the ForCES protocol
specification. Otherwise, ForCES implementations using multicast will
probably not interoperate.

Whether or not implementing multicast for transports that support
multicast is a requirement is a separate question. 

Regards,
Ellen

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M
Sent: Thursday, March 04, 2004 6:12 PM
To: alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs

Hi Alex,

In general, I prefer using language such as MUST so that there is no
confusion or interop issues in the protocol implementations. However,
you raise a reasonable point and let me tell you my thoughts on this. We
will definitely need Unicast between FEs and CEs at the minimum in the
protocol. In addition, if the interconnect technology supports Multicast
and there is a case where it is useful to the application (such as
downloading IPv4 routes) we must allow it as well without breaking
interop. In order to do that, we will need specific procedures in the
protocol that will allow the CE and FE to negotiate on using multicast
dynamically at run-time (say during the binding or joining phase between
the CE and FE) and also associate different multicast groups with LFBs.
We will also need to define how Reliability/CC etc. will be provided for
multicast...may be using RMT, TIPC, etc. (?) If we do this correctly,
then applications will be able to use both unicast and multicast without
any interop issues.

Let me know what you guys think about this.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Thursday, March 04, 2004 1:22 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from chat with ADs


Hormuzd,

Why should multicast be "mandated for certain cases where it will be 
useful" if there
is a simpler, more robust way to do the same thing?  I'll say we don't 
mandate this.
We can make it a "SHOULD" strength, not a "MUST".  We mandate UNICAST
and make MULTICAST optional.  Any issues with this?

Regards,
Alex.


Khosravi, Hormuzd M wrote:

  
Hi David

Your summary below of the discussion with Ads on the different issues
seems like very reasonable approaches to me.

I agree that it will be a good idea to present transport alternatives
    
at
  
IP and non-IP level for the ForCES protocol. We can mandate one or more
transport for IP and one or more transport for non-IP, this way the
interoperability requirements are met and at the same time, the in-box,
out of box scenarios are met.

Also, agree with having multiple channels/connections to differentiate
    
C
  
& D traffic between CEs and FEs. On the unicast/multicast topic, dual
mandatory approach again seems a good idea to support interoperability.
The one thing that I would like to point out is that for any ForCES
protocol implementation to work, unicast will definitely be required at
the minimum. One could also mandate using multicast for certain cases
where it will be useful (e.g. IPv4/config table download), if it is
supported by the interconnect as you stated. But just multicast without
unicast will not work, atleast not efficiently.

Regards
Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David
Sent: Tuesday, March 02, 2004 5:06 AM
To: forces-protocol@ietf.org
Subject: [Forces-protocol] Comments from chat with ADs

Patrick and I spent about 90 minutes last night
chatting with Bill and Alex about ForCES, with
maybe half of the time on the protocol.  In
the conversations with them, along with some
follow-up chats I had with Allison Mankin, the
following topics where covered:  multiple 
channels, multicast/unicast, and congestion 
control.  Below is what I recall from memory 
(Patrick please correct me/elaborate as needed :)



Multiple channels:  

I discussed the interference issue that 
was identified by the GRMP team.  Bill &
Alex agreed that many OS implementations can have
an interference property (i.e. where two different
connections will have queuing interference lower in
the networking stack in the OS).  So it is necessary
to make sure when implementing a FE (or CE probably
as well) that this is taken into account.  Methods
of doing that include:
* Manually queuing packets (i.e. feed OS few enough
 packets that it cannot get into trouble - although
 you pay a performance price for that, in that fine
 grained scheduling takes cycles)
* Indicating to the OS to treat flows differently - 
 some real-time OS will let you do this, that is they
 are implemented to internally retain QoS between
 flows.
However, it was also mentioned that intra-FE 
interference is only one kind of interference.  Good
FE implementation (e.g. by manually queuing above the
OS) helps to fix intra-FE interference, but it does
not solve inter-FE interference.  That is, if all
(C & D) packets are always on the same connection,
that makes it impossible on the wire to differentiate
them from one another.  Imagine you have a bunch of
FEs with some of them being subject to DOS attack for
D packets, and you want to query one of the FEs for
statistics.  It would be good to have some way of
ensuring the C packets (or any high priority packets -
OSPF HELLO maybe) get through.  Separate channels
(as Jamal indicated, don't even have to be C & D)
makes this possible.   Putting everything on one
channel makes it impossible to deal with inter-FE
interference in a differentiated fashion. 


Multicast & Unicast:  

The discussion on this started out with a discussion
of the IETF protocol design BKM that options can ruin
compatibility.  That is, if there are four ways to
implement something, all optional, then you can have
client 1 implement A & B, and client 2 implement C & D,
and even though both clients are 100% compliant, they
cannot talk to one another. Better to say all clients
must implement A and make B, C, and D optional, so that
way you know that all implementations will be able to 
at least talk.

Patrick & I pushed on this a bit, explaining that we
actually had potentially (at least) two different
environments - very close environments where multicast
support could be present in the interconnect,  and 
not-as-close environments (and some close
environments as well) where multicast was not available.

Bill & Alex indicated that if there really are two
quite different cases, then it is possible to have a
"dual mandatory" approach.  I.e.:

If your underlying interconnect supports multicast,
then you MUST implement the following (multicast)
method of communication.

If your underlying interconnect supports unicast, then
you MUST implement the following (unicast) method
of communication.

This will guarantee interop, although at a potential
extra cost (cost being having to potentially support
both when both are present).  While this isn't optimal,
it does at least give some flexibility.



Congestion control:

Several times over the whole conversation the topic
of congestion control came up.  Also, as part of some
TIPC discussions, I ended up spending some time talking
to Allison Mankin (transport AD) about congestion control
as well.  All the ADs I talked to where consistent on 
the following:

If you are running over IP, you MUST act in a RFC2914
compliant fashion (i.e. respond to congestion like TCP
or SCTP or RMT does).  Two reasons where put forth for
this:
1) Any time you define an IP-based protocol you cannot
guarantee that it will not go out over the Internet. As
such, the IESG will NOT standardize IP protocols with
"bad" (non-2914) behaviors.
2) Lots of implementation experience showing that other
congestion control mechanisms don't work (congestion
collapse etc).

They where very firm on the above and my impression was
that convincing them otherwise would be very difficult.

That being said, a second alternative did arise:  If
you are not implementing on top of IP (e.g. running on
Infiniband, ATM, Ethernet) then you could rely on mechanisms
for congestion control built into what you are relying on,
or even consider building your own congestion control
mechanisms (ala TIPC).  This makes it possible to define
(for example) a multicast transport for forces without
having to go all the way and implementing RMT - as long
as it is clear that it isn't over IP.  The ADs went as
far as saying that the IETF could even accept standards-
track drafts that say nothing about IP (e.g. define an
Ethernet-only transport for ForCES), if it is necessary 
for ForCES. GSMP and (some other group I forgot) was
given as an example.

Cheers,
David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
 

    


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------030102090104000904020609-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:36:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01059 for ; Fri, 5 Mar 2004 16:36:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMz1-0001eH-FW for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:35:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LZplf006331 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:35:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMz1-0001e2-7g for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:35:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01009 for ; Fri, 5 Mar 2004 16:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMyz-00031i-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:35:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMy6-0002sS-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:34:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzMxE-0002j7-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMxF-0001be-Fd; Fri, 05 Mar 2004 16:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzMx9-0001bD-7H for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00890 for ; Fri, 5 Mar 2004 16:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzMx7-0002hv-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:33:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzMwA-0002YM-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:32:55 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzMvJ-0002Oi-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:32:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030513324037:63095 ; Fri, 5 Mar 2004 13:32:40 -0800 Subject: RE: [Forces-protocol] Comments from chat with ADs From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: jeff pickering , alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00243F209@orsmsx410.jf.intel.com> References: <9CB758BBEE58754F8F33234D75B9F4B00243F209@orsmsx410.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078522316.1040.104.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 03/05/2004 01:32:40 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 01:32:42 PM, Serialize complete at 03/05/2004 01:32:42 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 16:31:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Is this negotiation for transport going to happen at the FEM/CEM plane? In toher words i would think this is more of a configuration/bootstrapping issue, no? And those typically belong to the FEM/CEM plane. My opinion is that typically a single NE will be controlled by a single admin; therefore selection of transport can be enforced within that domain - such a static setup will simplify things a great deal. BTW, we should add capability exchange as something else that needs discussion. cheers, jamal On Fri, 2004-03-05 at 16:09, Khosravi, Hormuzd M wrote: > Hi Jeff, > > Just wanted to clarify one comment below. I think some sort of > negotiation will be necessary even if we mandate multicast for certain > cases in order to have an easy interop. In general, the more specific we > are about all the details in the protocol, the stronger language we use, > the easier it will be for us to interop. The question that you have > asked below is a very valid question and will need to be answered in the > protocol spec explicitly. My gut feeling for the answer is that there > will be a mix traffic, if the other FEs support multicast and the CE > would like to use it or is using it already. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 16:43:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01329 for ; Fri, 5 Mar 2004 16:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzN5q-0002GK-3z for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 16:42:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LgsxV008690 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 16:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzN5p-0002G4-NN for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01318 for ; Fri, 5 Mar 2004 16:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzN5n-0004FH-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzN4s-00044v-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzN40-0003uT-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 16:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzN41-00028C-7T; Fri, 05 Mar 2004 16:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzN3t-00027Z-KX for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 16:40:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01234 for ; Fri, 5 Mar 2004 16:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzN3r-0003sz-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:40:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzN2u-0003hf-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:39:53 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzN24-0003Xo-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:39:00 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030513394028:63102 ; Fri, 5 Mar 2004 13:39:40 -0800 Subject: Re: [Forces-protocol] Comments from chat with ADs From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Khosravi, Hormuzd M" , "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <4048F06E.8020809@alcatel.com> References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> Organization: ZNYX Networks Message-Id: <1078522737.1040.111.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 03/05/2004 01:39:40 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 01:39:41 PM, Serialize complete at 03/05/2004 01:39:41 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 16:38:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Lets just follow the discussion in order of issues, to make faster progress. One issue at a time. At the end if it is shown that multicast has all these problems you say it does, we should probably throw it out totaly. All the issues you address are listed below. I sent text on issue 0 yesterday. Hormuzd is sending something on at least 2. Maybe i should send on 1. These three are the easisest to resolve. Here are the issues again (with two new additions at the end): If you ahve any that are missing here, please make suggestions. 0) ID on the header. 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability 8) Capability exchange 9) The FEM/CEM interface cheers, jamal On Fri, 2004-03-05 at 16:26, Alex Audu wrote: > I still maintain that MULTICAST is best left at SHOULD implement > strength. Why? > A lot of issues are still unresolved concerning multicast > reliabililty, security, etc., unless > we want to define an application-layer method to resolve issues like > synchronization, > packet-loss, ACK/NACK implosion, etc. > > Alex. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 17:05:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02315 for ; Fri, 5 Mar 2004 17:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNRE-0003u0-KL for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 17:05:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25M50EB014999 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 17:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNRE-0003tq-GZ for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 17:05:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02300 for ; Fri, 5 Mar 2004 17:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNRC-0000BT-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:04:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNQ7-00000x-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:03:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzNPH-0007dJ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNPJ-0003l9-8C; Fri, 05 Mar 2004 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNOo-0003gK-7A for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02001 for ; Fri, 5 Mar 2004 17:02:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNOm-0007RC-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:02:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNNB-00079B-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:00:50 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzNMH-0006w4-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 16:59:53 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030514002770:63123 ; Fri, 5 Mar 2004 14:00:27 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1078523986.1036.116.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 03/05/2004 02:00:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 02:00:34 PM, Serialize complete at 03/05/2004 02:00:34 PM Content-Type: multipart/mixed; boundary="=-eE1vUC0StIsmYXWwnAps" Subject: [Forces-protocol] issue 1: packet encoding Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 16:59:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-eE1vUC0StIsmYXWwnAps Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached is text for stimulating discussion on issue 1. cheers, jamal --=-eE1vUC0StIsmYXWwnAps Content-Disposition: attachment; filename=issue1.txt Content-Type: text/plain; name=issue1.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Packet encoding suggestion. Binary encoding to be used to be able to pack as much as possible within an allowed MTU. TLVs to be used to map the various attributes. TLVs within TLVs were used to encode complex attributes such as lists or compound structures. The layout below is to get a discussion going. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Forces message header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Forces Attributes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Forces Message Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | typeid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The xIDs are being discussed in issue 0. The command would be of the sort of ADD, DEL, GET. The xID will address the entity being targeted. [A command from a CE -> FE is for querying or configuration, whereas one from FE -> CE is a response or event]. The typeid identifies further the type of target by looking at typeid. [ for example, in our implementation we extended the popular tcpdump sniffer to look decode the packet for protocol debugging purposes. Length: length of the message including the attributes + header. XML encoding: XML encoding may be useful in capabilities definition (i.e slow path) but not in the configuration of data path tables. This is because of its nature to require higher bandwith and CPU computational needs. TLVs: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | variable TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Value (Data of size TLV length) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is possible to extend the data in the TLV to contain another TLV to build complex structures (such as the ones described in XML by the model draft or lists susch as those defined by GRMP). Example: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer TLV Type | Outer TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner TLV1 Type | Inner TLV1 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~~~~~~~~~~~~~~ VALUE1 ~~~~~~~~~~~~~~~~~~~~~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner TLV2 Type | Inner TLV2 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~~~~~~~~~~~~~~ VALUE2 ~~~~~~~~~~~~~~~~~~~~~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Which could be used to represent the following layout : +-+-+-+-+-+-+-+-+-+-+-+ .-~-~-~-~-~-~-. | TLV1 | ------>| param 1 | +-+-+-+-+-+-+-+-+-+-+-+ -~-~-~-~-~-~- | TLV2 | --->--+ +-+-+-+-+-+-+-+-+-+-+-+ | V | / +-----------+ | V .-~-~-~-~-~-~-. | +--->| param2_1 | +-+-+-+-+-+-+-+-+-+-+-+ | -~-~-~-~-~-~- | TLV2_1 | --->-+ .-~-~-~-~-~-~-. +-+-+-+-+-+-+-+-+-+-+-+ +--->| param2_2 | | TLV2_2 | --->----+ -~-~-~-~-~-~- +-+-+-+-+-+-+-+-+-+-+-+ It is thought that TLVs and nested TLVs will generally constitute slightly higher requirements for compute and bandwdith than encodings based on fixed layouts (XML is many more factors demanding). The added advantage with TLV usage of course is ability to add new TLVs easily without redefining the packet or the protocol. In addition, being able to optionally leave a TLV out during communication (the message example would have been perfectly decoded if TLV1 was never encoded). A small challenge that needs to be overcome for TLVs is to detect where failures happen (when you have a list or other compound structure). This is mostly useful/needed for batching or configuring a list of elements. If we were to use our implementation as a sample space: we had the "all upto failed one applied" scheme, in which case a NACK with the failed TLV Type is sent back. An interesting idea is to encode an 8 bit sequence number in the type to find precisely which TLV failed. --=-eE1vUC0StIsmYXWwnAps-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 17:40:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03308 for ; Fri, 5 Mar 2004 17:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzH-0007um-CQ for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 17:40:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25MeAhY030405 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 17:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzG-0007uK-2d for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 17:40:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03192 for ; Fri, 5 Mar 2004 17:40:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNzD-0005xY-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:40:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNy3-0005eY-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:38:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzNxB-0005VG-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:38:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzNvI-00011I-SY for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNvG-0007R3-6z; Fri, 05 Mar 2004 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNvA-0007Qo-Ab for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:35:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03152 for ; Fri, 5 Mar 2004 17:35:52 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNv7-0005CT-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:35:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNu9-00053t-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:34:54 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AzNtF-0004vE-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:33:57 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MXsZ19206; Sat, 6 Mar 2004 00:33:54 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 00:33:50 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i25MXoce000464; Sat, 6 Mar 2004 00:33:50 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00yF63px; Sat, 06 Mar 2004 00:33:49 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MXm717735; Sat, 6 Mar 2004 00:33:48 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:33:46 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQAVxdbpPHWaZ5SSA2tld74bEVMgABXv0/wAFLMA7A= To: , X-OriginalArrivalTime: 05 Mar 2004 22:33:46.0369 (UTC) FILETIME=[EC124F10:01C40301] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 17:33:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hormuzd, Comments are line. =20 >=20 > Your summary below of the discussion with Ads on the different issues > seems like very reasonable approaches to me. >=20 > I agree that it will be a good idea to present transport=20 > alternatives at > IP and non-IP level for the ForCES protocol. We can mandate=20 > one or more > transport for IP and one or more transport for non-IP, this way the > interoperability requirements are met and at the same time,=20 > the in-box, > out of box scenarios are met. Ok. >=20 > Also, agree with having multiple channels/connections to=20 > differentiate C > & D traffic between CEs and FEs. On the unicast/multicast topic, dual > mandatory approach again seems a good idea to support=20 > interoperability. =20 > The one thing that I would like to point out is that for any ForCES > protocol implementation to work, unicast will definitely be=20 > required at > the minimum.=20 > One could also mandate using multicast for certain cases > where it will be useful (e.g. IPv4/config table download), if it is > supported by the interconnect as you stated. But just=20 > multicast without > unicast will not work, atleast not efficiently. >=20 Mandate one and make option depending upon the operating environment=20 and availability of interconnect. But for single box solution, it will = be less of multicast and its mostly broadcast... For close proximity its responsibility of = the operator to ensure=20 what type of interconnect can be used..... Regards Ramg > Regards > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David > Sent: Tuesday, March 02, 2004 5:06 AM > To: forces-protocol@ietf.org > Subject: [Forces-protocol] Comments from chat with ADs >=20 > Patrick and I spent about 90 minutes last night > chatting with Bill and Alex about ForCES, with > maybe half of the time on the protocol. In > the conversations with them, along with some > follow-up chats I had with Allison Mankin, the > following topics where covered: multiple=20 > channels, multicast/unicast, and congestion=20 > control. Below is what I recall from memory=20 > (Patrick please correct me/elaborate as needed :) >=20 >=20 >=20 > Multiple channels: =20 >=20 > I discussed the interference issue that=20 > was identified by the GRMP team. Bill & > Alex agreed that many OS implementations can have > an interference property (i.e. where two different > connections will have queuing interference lower in > the networking stack in the OS). So it is necessary > to make sure when implementing a FE (or CE probably > as well) that this is taken into account. Methods > of doing that include: > * Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) > * Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. > However, it was also mentioned that intra-FE=20 > interference is only one kind of interference. Good > FE implementation (e.g. by manually queuing above the > OS) helps to fix intra-FE interference, but it does > not solve inter-FE interference. That is, if all > (C & D) packets are always on the same connection, > that makes it impossible on the wire to differentiate > them from one another. Imagine you have a bunch of > FEs with some of them being subject to DOS attack for > D packets, and you want to query one of the FEs for > statistics. It would be good to have some way of > ensuring the C packets (or any high priority packets - > OSPF HELLO maybe) get through. Separate channels > (as Jamal indicated, don't even have to be C & D) > makes this possible. Putting everything on one > channel makes it impossible to deal with inter-FE > interference in a differentiated fashion.=20 >=20 >=20 > Multicast & Unicast: =20 >=20 > The discussion on this started out with a discussion > of the IETF protocol design BKM that options can ruin > compatibility. That is, if there are four ways to > implement something, all optional, then you can have > client 1 implement A & B, and client 2 implement C & D, > and even though both clients are 100% compliant, they > cannot talk to one another. Better to say all clients > must implement A and make B, C, and D optional, so that > way you know that all implementations will be able to=20 > at least talk. >=20 > Patrick & I pushed on this a bit, explaining that we > actually had potentially (at least) two different > environments - very close environments where multicast > support could be present in the interconnect, and=20 > not-as-close environments (and some close > environments as well) where multicast was not available. >=20 > Bill & Alex indicated that if there really are two > quite different cases, then it is possible to have a > "dual mandatory" approach. I.e.: >=20 > If your underlying interconnect supports multicast, > then you MUST implement the following (multicast) > method of communication. >=20 > If your underlying interconnect supports unicast, then > you MUST implement the following (unicast) method > of communication. >=20 > This will guarantee interop, although at a potential > extra cost (cost being having to potentially support > both when both are present). While this isn't optimal, > it does at least give some flexibility. >=20 >=20 >=20 > Congestion control: >=20 > Several times over the whole conversation the topic > of congestion control came up. Also, as part of some > TIPC discussions, I ended up spending some time talking > to Allison Mankin (transport AD) about congestion control > as well. All the ADs I talked to where consistent on=20 > the following: >=20 > If you are running over IP, you MUST act in a RFC2914 > compliant fashion (i.e. respond to congestion like TCP > or SCTP or RMT does). Two reasons where put forth for > this: > 1) Any time you define an IP-based protocol you cannot > guarantee that it will not go out over the Internet. As > such, the IESG will NOT standardize IP protocols with > "bad" (non-2914) behaviors. > 2) Lots of implementation experience showing that other > congestion control mechanisms don't work (congestion > collapse etc). >=20 > They where very firm on the above and my impression was > that convincing them otherwise would be very difficult. >=20 > That being said, a second alternative did arise: If > you are not implementing on top of IP (e.g. running on > Infiniband, ATM, Ethernet) then you could rely on mechanisms > for congestion control built into what you are relying on, > or even consider building your own congestion control > mechanisms (ala TIPC). This makes it possible to define > (for example) a multicast transport for forces without > having to go all the way and implementing RMT - as long > as it is clear that it isn't over IP. The ADs went as > far as saying that the IETF could even accept standards- > track drafts that say nothing about IP (e.g. define an > Ethernet-only transport for ForCES), if it is necessary=20 > for ForCES. GSMP and (some other group I forgot) was > given as an example. >=20 > Cheers, > David >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 17:40:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03368 for ; Fri, 5 Mar 2004 17:40:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzR-0007vw-6H for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 17:40:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25MeLqe030490 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 17:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzR-0007vh-1c for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 17:40:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03224 for ; Fri, 5 Mar 2004 17:40:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNzO-0005yx-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:40:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNyH-0005gk-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:39:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzNxL-0005VQ-01 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:38:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzNqS-0000w3-VE for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNqQ-0006we-3P; Fri, 05 Mar 2004 17:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNqG-0006wD-QE for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:30:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03075 for ; Fri, 5 Mar 2004 17:30:49 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNqE-0004SZ-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:30:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNpF-0004K4-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:29:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AzNoF-00044K-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:28:47 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MShC07061; Sat, 6 Mar 2004 00:28:43 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 00:28:42 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i25MSguc028742; Sat, 6 Mar 2004 00:28:42 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00URaRRq; Sat, 06 Mar 2004 00:28:40 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MSdO28873; Sat, 6 Mar 2004 00:28:39 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:28:39 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: Comments from chat with ADs Thread-Index: AcQAVxdbpPHWaZ5SSA2tld74bEVMgACpnlmA To: , X-OriginalArrivalTime: 05 Mar 2004 22:28:39.0026 (UTC) FILETIME=[34E17D20:01C40301] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 17:28:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, I just came back after a break due to some personal work. I have to = catch up with all other email threads. I agree to the summary and below are my comments. =20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Putzolu, David > Sent: Tuesday, March 02, 2004 8:06 AM > To: forces-protocol@ietf.org > Subject: [Forces-protocol] Comments from chat with ADs >=20 >=20 > Patrick and I spent about 90 minutes last night > chatting with Bill and Alex about ForCES, with > maybe half of the time on the protocol. In > the conversations with them, along with some > follow-up chats I had with Allison Mankin, the > following topics where covered: multiple=20 > channels, multicast/unicast, and congestion=20 > control. Below is what I recall from memory=20 > (Patrick please correct me/elaborate as needed :) >=20 >=20 >=20 > Multiple channels: =20 >=20 > I discussed the interference issue that=20 > was identified by the GRMP team. =20 Not sure how GRMP has experienced this - may be more detail if possible. > Bill & > Alex agreed that many OS implementations can have > an interference property (i.e. where two different > connections will have queuing interference lower in > the networking stack in the OS). So it is necessary > to make sure when implementing a FE (or CE probably > as well) that this is taken into account. Methods > of doing that include: > * Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) > * Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. I agree. We have implemented this using earlier version of FACT with = multiple stack implementation on QNX (RTOS) and FreeBSD platforms. FreeBSD implementation is available publicly at = http://www.tel.fer.hr/zec/papers/zec-03.pdf and people have used this = and tweaked such multiple stacks to resist against DoS attack (logical channel separation for various C = and D types of packets with different rate limiter values )=20 =20 > However, it was also mentioned that intra-FE=20 > interference is only one kind of interference. Good > FE implementation (e.g. by manually queuing above the > OS) helps to fix intra-FE interference, but it does > not solve inter-FE interference. That is, if all > (C & D) packets are always on the same connection, > that makes it impossible on the wire to differentiate > them from one another. Imagine you have a bunch of > FEs with some of them being subject to DOS attack for > D packets, and you want to query one of the FEs for > statistics. =20 If the query is from CE -> FE with the support of different rate control = mechanism, and always allowing CE -> FE message to get processed FE as = that is more important, we can achieve this.=20 But there is a limit to which we can control or defend against DoS = scenario. > It would be good to have some way of > ensuring the C packets (or any high priority packets - > OSPF HELLO maybe) get through. Separate channels > (as Jamal indicated, don't even have to be C & D) > makes this possible. Putting everything on one > channel makes it impossible to deal with inter-FE > interference in a differentiated fashion.=20 >=20 >=20 currently there are various solutions exists that uses same physical = channel, and tries to provide resist to DoS attacks... - Multiple stack implementation - Rate control (Asymmetric rate control) - Perflow queuing=20 and many other solutions.. =20 > Multicast & Unicast: =20 >=20 > The discussion on this started out with a discussion > of the IETF protocol design BKM that options can ruin > compatibility. That is, if there are four ways to > implement something, all optional, then you can have > client 1 implement A & B, and client 2 implement C & D, > and even though both clients are 100% compliant, they > cannot talk to one another. Better to say all clients > must implement A and make B, C, and D optional, so that > way you know that all implementations will be able to=20 > at least talk. >=20 I agree, too much option and generaliazation will run into problems. We have systems implementing unicast both for single box and also for = muliple-hops.=20 I don't remember exactly even systems on Point-Of-Presence uses unicast = as they want reliability. =20 > Patrick & I pushed on this a bit, explaining that we > actually had potentially (at least) two different > environments - very close environments where multicast > support could be present in the interconnect, and=20 > not-as-close environments (and some close > environments as well) where multicast was not available. is the interconnect refers to layer-2 or layer-3 support?=20 =20 >=20 > Bill & Alex indicated that if there really are two > quite different cases, then it is possible to have a > "dual mandatory" approach. I.e.: >=20 > If your underlying interconnect supports multicast, > then you MUST implement the following (multicast) > method of communication. >=20 > If your underlying interconnect supports unicast, then > you MUST implement the following (unicast) method > of communication. First unicast - this look like a default case. =20 I'm not aware of the case where we have multicast and not unicast? To accommodate multicast then if the underlying mechanism supports then = its more like=20 a configuration options. >=20 > This will guarantee interop, although at a potential > extra cost (cost being having to potentially support > both when both are present). While this isn't optimal, > it does at least give some flexibility. >=20 Mandate unicast and mulicast when layer-2 or layer -3 is supported may = little bit easier. For example in OSPF if the routers are on shared LAN then multicasting = takes place or else its unicasting for hub-and-spoke topology.... Regards Ramg=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 17:56:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03741 for ; Fri, 5 Mar 2004 17:56:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOEU-0000Xy-3q for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 17:55:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25MtswX002096 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 17:55:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOET-0000Xj-TE for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 17:55:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03734 for ; Fri, 5 Mar 2004 17:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOER-0000qO-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:55:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzODV-0000h6-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:54:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOCd-0000YH-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOCe-0000Jl-Mj; Fri, 05 Mar 2004 17:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOBh-0000GZ-Q1 for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03701 for ; Fri, 5 Mar 2004 17:52:57 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOBe-0000NS-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOAh-0000DZ-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:52:00 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AzO9z-00003p-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:51:15 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25Mp4h05308; Sat, 6 Mar 2004 00:51:06 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 00:50:57 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i25MovvT021613; Sat, 6 Mar 2004 00:50:57 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00vpUV1e; Sat, 06 Mar 2004 00:50:56 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MotO04243; Sat, 6 Mar 2004 00:50:55 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:50:55 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCeAEgUFGzt/YiSAWh7UdpGgJxmwAim91A To: , , X-OriginalArrivalTime: 05 Mar 2004 22:50:55.0029 (UTC) FILETIME=[51335E50:01C40304] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 17:50:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Weiming, Alex as already answered to this - just to add more to his question my = comments are line. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Wang,Weiming > Sent: Friday, March 05, 2004 12:35 AM > To: Putzolu, David; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Comments from chat with ADs >=20 >=20 > Hi David, >=20 > Some more comments on the multi-channels from your last email=20 > as below: >=20 > I agree that multiple FEs sharing the same physical link=20 > makes problems more complicated. To make things more clear, I=20 > want state GRMP's ideas > again here, for I think there might be some misunderstanding on it: >=20 > 1. GRMP presents that pure separation of C/D in the same=20 > physical link is of no use to DoS protection. DoS protection=20 > can only be achieved by inside FE mechanisms except a=20 > separate physical link is used by C/D. This also applies to=20 > multi-FEs sharing the same physical links as you mentioned=20 > above. Actually I can not see such separation has solved the=20 > DoS problem for multi-FE case from the above txt. =20 >=20 > 2. We do not oppose to have such separation if it's proven=20 > useful for others. Actually the key GRMP has defined for DoS=20 > and congestion control is the FE attribute for DoS protection=20 > policy, which has no limitation with multi transport layer=20 > channels. If it's proven separation of C/D channels are=20 > useful, GRMP can easily adapt it. But what we need more=20 > discussion is trying to see more reasons for such separations.=20 >=20 > 3. A combined control of C and D is useful for DoS protection=20 > as well as for congestion.=20 > I have to note that the scheme proposed by FACT and also=20 > mentioned in the proposed basic merge principles only assume=20 > to provide a Data channel control mechanism ( a rate limit).=20 > We just argue that this is not enough. Actually what you=20 > mentioned above is also to ask for such a control combination=20 > for multi-FEs cases. GRMP scheme can supply this very well by=20 > using a FE attribute to specify DoS protection policy in=20 > which C packets with higher priorities can be ensured. I=20 > don't think other protocols have provided this mechanism=20 > (Note that this priority is different from that in ForCES=20 > message headers, which actually does not take effect for this=20 > purpose). =20 May be your understand is not complete on FACT. In FACT we proposed two rate limiter value one for C and another one for = D in adddition the rate from CE -> FE is different and from FE -> CE. FE after processing the = packet discrimiates the C and D and accordingly=20 act on it. We have mentioned in our draft that rate limiting can be = done based on even various traffic (C and D) types. FE endpoint has intelligence to perform such operation. Hope this = helps. =20 =20 =20 End of comments Regards Ramg =20 >=20 > To summarize, we just argue that a DoS protection policy like=20 > that presented by GRMP should be included in final ForCES=20 > protocol other than just by separation of C/D channels so as=20 > to effectively avoid DoS attack and also to manage the=20 > congestion. I think this idea is quite the same as what you=20 > presented in another email as some QoS hints transmitted from=20 > CE to FE for DoS protection and congestion control.=20 >=20 > Yours, > Weiming >=20 > ----- Original Message -----=20 > From: "Putzolu, David" > To: > Sent: Tuesday, March 02, 2004 9:06 PM > Subject: [Forces-protocol] Comments from chat with ADs >=20 >=20 > Patrick and I spent about 90 minutes last night > chatting with Bill and Alex about ForCES, with > maybe half of the time on the protocol. In > the conversations with them, along with some > follow-up chats I had with Allison Mankin, the > following topics where covered: multiple=20 > channels, multicast/unicast, and congestion=20 > control. Below is what I recall from memory=20 > (Patrick please correct me/elaborate as needed :) >=20 >=20 >=20 > Multiple channels: =20 >=20 > I discussed the interference issue that=20 > was identified by the GRMP team. Bill & > Alex agreed that many OS implementations can have > an interference property (i.e. where two different > connections will have queuing interference lower in > the networking stack in the OS). So it is necessary > to make sure when implementing a FE (or CE probably > as well) that this is taken into account. Methods > of doing that include: > * Manually queuing packets (i.e. feed OS few enough > packets that it cannot get into trouble - although > you pay a performance price for that, in that fine > grained scheduling takes cycles) > * Indicating to the OS to treat flows differently -=20 > some real-time OS will let you do this, that is they > are implemented to internally retain QoS between > flows. > However, it was also mentioned that intra-FE=20 > interference is only one kind of interference. Good > FE implementation (e.g. by manually queuing above the > OS) helps to fix intra-FE interference, but it does > not solve inter-FE interference. That is, if all > (C & D) packets are always on the same connection, > that makes it impossible on the wire to differentiate > them from one another. Imagine you have a bunch of > FEs with some of them being subject to DOS attack for > D packets, and you want to query one of the FEs for > statistics. It would be good to have some way of > ensuring the C packets (or any high priority packets - > OSPF HELLO maybe) get through. Separate channels > (as Jamal indicated, don't even have to be C & D) > makes this possible. Putting everything on one > channel makes it impossible to deal with inter-FE > interference in a differentiated fashion.=20 >=20 > [WangRe] >=20 > =20 > =16Sz=CA=A2=DA=A2YSX'X=B4Zq=EB=AE=FF=0C> = =D6'~S=FEf-f=FEX=B6)=A3=F7=AD=C7=A6=BA=A1=CA >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:01:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03854 for ; Fri, 5 Mar 2004 18:01:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOJK-0001iV-Pa for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:00:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25N0stM006590 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOJK-0001i0-77 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:00:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03844 for ; Fri, 5 Mar 2004 18:00:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOJH-0001b8-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:00:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOIK-0001SR-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:59:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOHS-0001KB-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOHU-00017N-HI; Fri, 05 Mar 2004 17:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOHQ-000174-N8 for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:58:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03801 for ; Fri, 5 Mar 2004 17:58:52 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOHN-0001Jk-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOGU-0001B2-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:58:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AzOFZ-00011R-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:57:01 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25MusZ03881; Sat, 6 Mar 2004 00:56:54 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 00:56:49 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i25Mun3j031720; Sat, 6 Mar 2004 00:56:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00hfuPJV; Sat, 06 Mar 2004 00:56:46 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25Mui727361; Sat, 6 Mar 2004 00:56:45 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 16:56:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40305.1FA87EC8" Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQC+OiJkV+P/AufQKyrFJ0IeBWJswAC/vcQ To: , Cc: , X-OriginalArrivalTime: 05 Mar 2004 22:56:42.0525 (UTC) FILETIME=[20530CD0:01C40305] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 17:56:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TITLE_EMPTY,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40305.1FA87EC8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex,=20 =20 I share your concern.=20 =20 May be we need to make it a point that if underlying infrastructure = supports such capabilities like reliable multicast, multicast security = etc. then its responsibility of the operator to choose. =20 Does that work fine? =20 Regards Ramg -----Original Message----- From: forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Alex Audu Sent: Friday, March 05, 2004 4:26 PM To: Khosravi, Hormuzd M Cc: Deleganes, Ellen M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs I still maintain that MULTICAST is best left at SHOULD implement = strength. Why? A lot of issues are still unresolved concerning multicast reliabililty, = security, etc., unless we want to define an application-layer method to resolve issues like = synchronization, packet-loss, ACK/NACK implosion, etc. =20 Alex. Khosravi, Hormuzd M wrote: Yes Ellen, that was my intent. Thanks for the clarification, Hormuzd -----Original Message----- From: Deleganes, Ellen M=20 Sent: Friday, March 05, 2004 12:19 PM To: Khosravi, Hormuzd M; alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is that even if Multicast is optional, those procedures that noted in Hormudz's email should be described in the ForCES protocol spec. That is, if a ForCES protocol implementation supports multicast, then it MUST implement it in the manner described in the ForCES protocol specification. Otherwise, ForCES implementations using multicast will probably not interoperate. Whether or not implementing multicast for transports that support multicast is a requirement is a separate question.=20 Regards, Ellen -----Original Message----- From: forces-protocol-admin@ietf.org [ mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd = M Sent: Thursday, March 04, 2004 6:12 PM To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs Hi Alex, In general, I prefer using language such as MUST so that there is no confusion or interop issues in the protocol implementations. However, you raise a reasonable point and let me tell you my thoughts on this. We will definitely need Unicast between FEs and CEs at the minimum in the protocol. In addition, if the interconnect technology supports Multicast and there is a case where it is useful to the application (such as downloading IPv4 routes) we must allow it as well without breaking interop. In order to do that, we will need specific procedures in the protocol that will allow the CE and FE to negotiate on using multicast dynamically at run-time (say during the binding or joining phase between the CE and FE) and also associate different multicast groups with LFBs. We will also need to define how Reliability/CC etc. will be provided for multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, then applications will be able to use both unicast and multicast without any interop issues. Let me know what you guys think about this. Regards Hormuzd -----Original Message----- From: Alex Audu [ mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 1:22 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs Hormuzd, Why should multicast be "mandated for certain cases where it will be=20 useful" if there is a simpler, more robust way to do the same thing? I'll say we don't=20 mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? Regards, Alex. Khosravi, Hormuzd M wrote: =20 Hi David Your summary below of the discussion with Ads on the different issues seems like very reasonable approaches to me. I agree that it will be a good idea to present transport alternatives =20 at =20 IP and non-IP level for the ForCES protocol. We can mandate one or more transport for IP and one or more transport for non-IP, this way the interoperability requirements are met and at the same time, the in-box, out of box scenarios are met. Also, agree with having multiple channels/connections to differentiate =20 C =20 & D traffic between CEs and FEs. On the unicast/multicast topic, dual mandatory approach again seems a good idea to support interoperability. The one thing that I would like to point out is that for any ForCES protocol implementation to work, unicast will definitely be required at the minimum. One could also mandate using multicast for certain cases where it will be useful (e.g. IPv4/config table download), if it is supported by the interconnect as you stated. But just multicast without unicast will not work, atleast not efficiently. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [ mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Tuesday, March 02, 2004 5:06 AM To: forces-protocol@ietf.org Subject: [Forces-protocol] Comments from chat with ADs Patrick and I spent about 90 minutes last night chatting with Bill and Alex about ForCES, with maybe half of the time on the protocol. In the conversations with them, along with some follow-up chats I had with Allison Mankin, the following topics where covered: multiple=20 channels, multicast/unicast, and congestion=20 control. Below is what I recall from memory=20 (Patrick please correct me/elaborate as needed :) Multiple channels: =20 I discussed the interference issue that=20 was identified by the GRMP team. Bill & Alex agreed that many OS implementations can have an interference property (i.e. where two different connections will have queuing interference lower in the networking stack in the OS). So it is necessary to make sure when implementing a FE (or CE probably as well) that this is taken into account. Methods of doing that include: * Manually queuing packets (i.e. feed OS few enough packets that it cannot get into trouble - although you pay a performance price for that, in that fine grained scheduling takes cycles) * Indicating to the OS to treat flows differently -=20 some real-time OS will let you do this, that is they are implemented to internally retain QoS between flows. However, it was also mentioned that intra-FE=20 interference is only one kind of interference. Good FE implementation (e.g. by manually queuing above the OS) helps to fix intra-FE interference, but it does not solve inter-FE interference. That is, if all (C & D) packets are always on the same connection, that makes it impossible on the wire to differentiate them from one another. Imagine you have a bunch of FEs with some of them being subject to DOS attack for D packets, and you want to query one of the FEs for statistics. It would be good to have some way of ensuring the C packets (or any high priority packets - OSPF HELLO maybe) get through. Separate channels (as Jamal indicated, don't even have to be C & D) makes this possible. Putting everything on one channel makes it impossible to deal with inter-FE interference in a differentiated fashion.=20 Multicast & Unicast: =20 The discussion on this started out with a discussion of the IETF protocol design BKM that options can ruin compatibility. That is, if there are four ways to implement something, all optional, then you can have client 1 implement A & B, and client 2 implement C & D, and even though both clients are 100% compliant, they cannot talk to one another. Better to say all clients must implement A and make B, C, and D optional, so that way you know that all implementations will be able to=20 at least talk. Patrick & I pushed on this a bit, explaining that we actually had potentially (at least) two different environments - very close environments where multicast support could be present in the interconnect, and=20 not-as-close environments (and some close environments as well) where multicast was not available. Bill & Alex indicated that if there really are two quite different cases, then it is possible to have a "dual mandatory" approach. I.e.: If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. Congestion control: Several times over the whole conversation the topic of congestion control came up. Also, as part of some TIPC discussions, I ended up spending some time talking to Allison Mankin (transport AD) about congestion control as well. All the ADs I talked to where consistent on=20 the following: If you are running over IP, you MUST act in a RFC2914 compliant fashion (i.e. respond to congestion like TCP or SCTP or RMT does). Two reasons where put forth for this: 1) Any time you define an IP-based protocol you cannot guarantee that it will not go out over the Internet. As such, the IESG will NOT standardize IP protocols with "bad" (non-2914) behaviors. 2) Lots of implementation experience showing that other congestion control mechanisms don't work (congestion collapse etc). They where very firm on the above and my impression was that convincing them otherwise would be very difficult. That being said, a second alternative did arise: If you are not implementing on top of IP (e.g. running on Infiniband, ATM, Ethernet) then you could rely on mechanisms for congestion control built into what you are relying on, or even consider building your own congestion control mechanisms (ala TIPC). This makes it possible to define (for example) a multicast transport for forces without having to go all the way and implementing RMT - as long as it is clear that it isn't over IP. The ADs went as far as saying that the IETF could even accept standards- track drafts that say nothing about IP (e.g. define an Ethernet-only transport for ForCES), if it is necessary=20 for ForCES. GSMP and (some other group I forgot) was given as an example. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 ------_=_NextPart_001_01C40305.1FA87EC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Alex,=20
 
I=20 share your concern.
 
May be=20 we need to make it a point that if underlying infrastructure supports = such=20 capabilities like reliable multicast, multicast security etc. then its=20 responsibility of the operator to choose.
 
Does=20 that work fine?
 
Regards
Ramg
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On=20 Behalf Of ext Alex Audu
Sent: Friday, March 05, 2004 = 4:26=20 PM
To: Khosravi, Hormuzd M
Cc: Deleganes, Ellen M; = forces-protocol@ietf.org
Subject: Re: [Forces-protocol] = Comments=20 from chat with ADs

I still maintain that MULTICAST = is best=20 left at SHOULD implement strength.  Why?
A lot of issues are = still=20 unresolved concerning multicast reliabililty, security, etc., = unless
we=20 want to define an application-layer method to resolve issues = like =20 synchronization,
packet-loss, ACK/NACK implosion, etc. =20

Alex.

Khosravi, Hormuzd M wrote:
Yes Ellen, that was my intent.

Thanks for the clarification,
Hormuzd

-----Original Message-----
From: Deleganes, Ellen M=20
Sent: Friday, March 05, 2004 12:19 PM
To: Khosravi, Hormuzd M; alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs


I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is
that even if Multicast is optional, those procedures that noted in
Hormudz's email should be described in the ForCES protocol spec. That
is, if a ForCES protocol implementation supports multicast, then it MUST
implement it in the manner described in the ForCES protocol
specification. Otherwise, ForCES implementations using multicast will
probably not interoperate.

Whether or not implementing multicast for transports that support
multicast is a requirement is a separate question.=20

Regards,
Ellen

-----Original Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org] On Behalf Of Khosravi, Hormuzd M
Sent: Thursday, March 04, 2004 6:12 PM
To: alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs

Hi Alex,

In general, I prefer using language such as MUST so that there is no
confusion or interop issues in the protocol implementations. However,
you raise a reasonable point and let me tell you my thoughts on this. We
will definitely need Unicast between FEs and CEs at the minimum in the
protocol. In addition, if the interconnect technology supports Multicast
and there is a case where it is useful to the application (such as
downloading IPv4 routes) we must allow it as well without breaking
interop. In order to do that, we will need specific procedures in the
protocol that will allow the CE and FE to negotiate on using multicast
dynamically at run-time (say during the binding or joining phase between
the CE and FE) and also associate different multicast groups with LFBs.
We will also need to define how Reliability/CC etc. will be provided for
multicast...may be using RMT, TIPC, etc. (?) If we do this correctly,
then applications will be able to use both unicast and multicast without
any interop issues.

Let me know what you guys think about this.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com]=20
Sent: Thursday, March 04, 2004 1:22 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from chat with ADs


Hormuzd,

Why should multicast be "mandated for certain cases where it will be=20
useful" if there
is a simpler, more robust way to do the same thing?  I'll say we don't=20
mandate this.
We can make it a "SHOULD" strength, not a "MUST".  We mandate UNICAST
and make MULTICAST optional.  Any issues with this?

Regards,
Alex.


Khosravi, Hormuzd M wrote:

  
Hi David

Your summary below of the discussion with Ads on the different issues
seems like very reasonable approaches to me.

I agree that it will be a good idea to present transport alternatives
    
at
  
IP and non-IP level for the =
ForCES protocol. We can mandate one or more
transport for IP and one or more transport for non-IP, this way the
interoperability requirements are met and at the same time, the in-box,
out of box scenarios are met.

Also, agree with having multiple channels/connections to differentiate
    
C
  
& D traffic between CEs =
and FEs. On the unicast/multicast topic, dual
mandatory approach again seems a good idea to support interoperability.
The one thing that I would like to point out is that for any ForCES
protocol implementation to work, unicast will definitely be required at
the minimum. One could also mandate using multicast for certain cases
where it will be useful (e.g. IPv4/config table download), if it is
supported by the interconnect as you stated. But just multicast without
unicast will not work, atleast not efficiently.

Regards
Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org] On Behalf Of Putzolu, David
Sent: Tuesday, March 02, 2004 5:06 AM
To: forces-protocol@ietf.org
Subject: [Forces-protocol] Comments from chat with ADs

Patrick and I spent about 90 minutes last night
chatting with Bill and Alex about ForCES, with
maybe half of the time on the protocol.  In
the conversations with them, along with some
follow-up chats I had with Allison Mankin, the
following topics where covered:  multiple=20
channels, multicast/unicast, and congestion=20
control.  Below is what I recall from memory=20
(Patrick please correct me/elaborate as needed :)



Multiple channels: =20

I discussed the interference issue that=20
was identified by the GRMP team.  Bill &
Alex agreed that many OS implementations can have
an interference property (i.e. where two different
connections will have queuing interference lower in
the networking stack in the OS).  So it is necessary
to make sure when implementing a FE (or CE probably
as well) that this is taken into account.  Methods
of doing that include:
* Manually queuing packets (i.e. feed OS few enough
 packets that it cannot get into trouble - although
 you pay a performance price for that, in that fine
 grained scheduling takes cycles)
* Indicating to the OS to treat flows differently -=20
 some real-time OS will let you do this, that is they
 are implemented to internally retain QoS between
 flows.
However, it was also mentioned that intra-FE=20
interference is only one kind of interference.  Good
FE implementation (e.g. by manually queuing above the
OS) helps to fix intra-FE interference, but it does
not solve inter-FE interference.  That is, if all
(C & D) packets are always on the same connection,
that makes it impossible on the wire to differentiate
them from one another.  Imagine you have a bunch of
FEs with some of them being subject to DOS attack for
D packets, and you want to query one of the FEs for
statistics.  It would be good to have some way of
ensuring the C packets (or any high priority packets -
OSPF HELLO maybe) get through.  Separate channels
(as Jamal indicated, don't even have to be C & D)
makes this possible.   Putting everything on one
channel makes it impossible to deal with inter-FE
interference in a differentiated fashion.=20


Multicast & Unicast: =20

The discussion on this started out with a discussion
of the IETF protocol design BKM that options can ruin
compatibility.  That is, if there are four ways to
implement something, all optional, then you can have
client 1 implement A & B, and client 2 implement C & D,
and even though both clients are 100% compliant, they
cannot talk to one another. Better to say all clients
must implement A and make B, C, and D optional, so that
way you know that all implementations will be able to=20
at least talk.

Patrick & I pushed on this a bit, explaining that we
actually had potentially (at least) two different
environments - very close environments where multicast
support could be present in the interconnect,  and=20
not-as-close environments (and some close
environments as well) where multicast was not available.

Bill & Alex indicated that if there really are two
quite different cases, then it is possible to have a
"dual mandatory" approach.  I.e.:

If your underlying interconnect supports multicast,
then you MUST implement the following (multicast)
method of communication.

If your underlying interconnect supports unicast, then
you MUST implement the following (unicast) method
of communication.

This will guarantee interop, although at a potential
extra cost (cost being having to potentially support
both when both are present).  While this isn't optimal,
it does at least give some flexibility.



Congestion control:

Several times over the whole conversation the topic
of congestion control came up.  Also, as part of some
TIPC discussions, I ended up spending some time talking
to Allison Mankin (transport AD) about congestion control
as well.  All the ADs I talked to where consistent on=20
the following:

If you are running over IP, you MUST act in a RFC2914
compliant fashion (i.e. respond to congestion like TCP
or SCTP or RMT does).  Two reasons where put forth for
this:
1) Any time you define an IP-based protocol you cannot
guarantee that it will not go out over the Internet. As
such, the IESG will NOT standardize IP protocols with
"bad" (non-2914) behaviors.
2) Lots of implementation experience showing that other
congestion control mechanisms don't work (congestion
collapse etc).

They where very firm on the above and my impression was
that convincing them otherwise would be very difficult.

That being said, a second alternative did arise:  If
you are not implementing on top of IP (e.g. running on
Infiniband, ATM, Ethernet) then you could rely on mechanisms
for congestion control built into what you are relying on,
or even consider building your own congestion control
mechanisms (ala TIPC).  This makes it possible to define
(for example) a multicast transport for forces without
having to go all the way and implementing RMT - as long
as it is clear that it isn't over IP.  The ADs went as
far as saying that the IETF could even accept standards-
track drafts that say nothing about IP (e.g. define an
Ethernet-only transport for ForCES), if it is necessary=20
for ForCES. GSMP and (some other group I forgot) was
given as an example.

Cheers,
David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
=20

    


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
------_=_NextPart_001_01C40305.1FA87EC8-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:17:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05205 for ; Fri, 5 Mar 2004 18:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOYp-00088C-Gf for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:16:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25NGtjU031242 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:16:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOYp-000871-4v for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:16:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05155 for ; Fri, 5 Mar 2004 18:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOYm-0004Gn-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:16:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOXp-00047h-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:15:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOWx-0003yp-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:14:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOWz-0007OL-0n; Fri, 05 Mar 2004 18:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOWt-0007NI-SA for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 18:14:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04963 for ; Fri, 5 Mar 2004 18:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOWq-0003xu-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOVr-0003nQ-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:13:54 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzOUt-0003UI-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:12:51 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25NCKTN019855; Fri, 5 Mar 2004 17:12:20 -0600 (CST) Message-ID: <40490954.6020402@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: hormuzd.m.khosravi@intel.com, ellen.m.deleganes@intel.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060001010000030203070002" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 17:12:20 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060001010000030203070002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Ram, Good to have you back. Yes,..that will be fine. All I am saying is we leave it at a SHOULD implement strength. We can't mandate implementation (i.e. make it a MUST) of what hasn't been fully defined. Regards, Alex. ram.gopal@nokia.com wrote: > Alex, > > I share your concern. > > May be we need to make it a point that if underlying infrastructure > supports such capabilities like reliable multicast, multicast security > etc. then its responsibility of the operator to choose. > > Does that work fine? > > Regards > Ramg > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Alex Audu > Sent: Friday, March 05, 2004 4:26 PM > To: Khosravi, Hormuzd M > Cc: Deleganes, Ellen M; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Comments from chat with ADs > > I still maintain that MULTICAST is best left at SHOULD implement > strength. Why? > A lot of issues are still unresolved concerning multicast > reliabililty, security, etc., unless > we want to define an application-layer method to resolve issues > like synchronization, > packet-loss, ACK/NACK implosion, etc. > > Alex. > > Khosravi, Hormuzd M wrote: > >>Yes Ellen, that was my intent. >> >>Thanks for the clarification, >>Hormuzd >> >>-----Original Message----- >>From: Deleganes, Ellen M >>Sent: Friday, March 05, 2004 12:19 PM >>To: Khosravi, Hormuzd M; alex.audu@alcatel.com >>Cc: forces-protocol@ietf.org >>Subject: RE: [Forces-protocol] Comments from chat with ADs >> >> >>I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is >>that even if Multicast is optional, those procedures that noted in >>Hormudz's email should be described in the ForCES protocol spec. That >>is, if a ForCES protocol implementation supports multicast, then it MUST >>implement it in the manner described in the ForCES protocol >>specification. Otherwise, ForCES implementations using multicast will >>probably not interoperate. >> >>Whether or not implementing multicast for transports that support >>multicast is a requirement is a separate question. >> >>Regards, >>Ellen >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M >>Sent: Thursday, March 04, 2004 6:12 PM >>To: alex.audu@alcatel.com >>Cc: forces-protocol@ietf.org >>Subject: RE: [Forces-protocol] Comments from chat with ADs >> >>Hi Alex, >> >>In general, I prefer using language such as MUST so that there is no >>confusion or interop issues in the protocol implementations. However, >>you raise a reasonable point and let me tell you my thoughts on this. We >>will definitely need Unicast between FEs and CEs at the minimum in the >>protocol. In addition, if the interconnect technology supports Multicast >>and there is a case where it is useful to the application (such as >>downloading IPv4 routes) we must allow it as well without breaking >>interop. In order to do that, we will need specific procedures in the >>protocol that will allow the CE and FE to negotiate on using multicast >>dynamically at run-time (say during the binding or joining phase between >>the CE and FE) and also associate different multicast groups with LFBs. >>We will also need to define how Reliability/CC etc. will be provided for >>multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, >>then applications will be able to use both unicast and multicast without >>any interop issues. >> >>Let me know what you guys think about this. >> >>Regards >>Hormuzd >> >>-----Original Message----- >>From: Alex Audu [mailto:alex.audu@alcatel.com] >>Sent: Thursday, March 04, 2004 1:22 PM >>To: Khosravi, Hormuzd M >>Cc: forces-protocol@ietf.org >>Subject: Re: [Forces-protocol] Comments from chat with ADs >> >> >>Hormuzd, >> >>Why should multicast be "mandated for certain cases where it will be >>useful" if there >>is a simpler, more robust way to do the same thing? I'll say we don't >>mandate this. >>We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST >>and make MULTICAST optional. Any issues with this? >> >>Regards, >>Alex. >> >> >>Khosravi, Hormuzd M wrote: >> >> >> >>>Hi David >>> >>>Your summary below of the discussion with Ads on the different issues >>>seems like very reasonable approaches to me. >>> >>>I agree that it will be a good idea to present transport alternatives >>> >>> >>at >> >> >>>IP and non-IP level for the ForCES protocol. We can mandate one or more >>>transport for IP and one or more transport for non-IP, this way the >>>interoperability requirements are met and at the same time, the in-box, >>>out of box scenarios are met. >>> >>>Also, agree with having multiple channels/connections to differentiate >>> >>> >>C >> >> >>>& D traffic between CEs and FEs. On the unicast/multicast topic, dual >>>mandatory approach again seems a good idea to support interoperability. >>>The one thing that I would like to point out is that for any ForCES >>>protocol implementation to work, unicast will definitely be required at >>>the minimum. One could also mandate using multicast for certain cases >>>where it will be useful (e.g. IPv4/config table download), if it is >>>supported by the interconnect as you stated. But just multicast without >>>unicast will not work, atleast not efficiently. >>> >>>Regards >>>Hormuzd >>> >>>-----Original Message----- >>>From: forces-protocol-admin@ietf.org >>>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >>>Sent: Tuesday, March 02, 2004 5:06 AM >>>To: forces-protocol@ietf.org >>>Subject: [Forces-protocol] Comments from chat with ADs >>> >>>Patrick and I spent about 90 minutes last night >>>chatting with Bill and Alex about ForCES, with >>>maybe half of the time on the protocol. In >>>the conversations with them, along with some >>>follow-up chats I had with Allison Mankin, the >>>following topics where covered: multiple >>>channels, multicast/unicast, and congestion >>>control. Below is what I recall from memory >>>(Patrick please correct me/elaborate as needed :) >>> >>> >>> >>>Multiple channels: >>> >>>I discussed the interference issue that >>>was identified by the GRMP team. Bill & >>>Alex agreed that many OS implementations can have >>>an interference property (i.e. where two different >>>connections will have queuing interference lower in >>>the networking stack in the OS). So it is necessary >>>to make sure when implementing a FE (or CE probably >>>as well) that this is taken into account. Methods >>>of doing that include: >>>* Manually queuing packets (i.e. feed OS few enough >>> packets that it cannot get into trouble - although >>> you pay a performance price for that, in that fine >>> grained scheduling takes cycles) >>>* Indicating to the OS to treat flows differently - >>> some real-time OS will let you do this, that is they >>> are implemented to internally retain QoS between >>> flows. >>>However, it was also mentioned that intra-FE >>>interference is only one kind of interference. Good >>>FE implementation (e.g. by manually queuing above the >>>OS) helps to fix intra-FE interference, but it does >>>not solve inter-FE interference. That is, if all >>>(C & D) packets are always on the same connection, >>>that makes it impossible on the wire to differentiate >>>them from one another. Imagine you have a bunch of >>>FEs with some of them being subject to DOS attack for >>>D packets, and you want to query one of the FEs for >>>statistics. It would be good to have some way of >>>ensuring the C packets (or any high priority packets - >>>OSPF HELLO maybe) get through. Separate channels >>>(as Jamal indicated, don't even have to be C & D) >>>makes this possible. Putting everything on one >>>channel makes it impossible to deal with inter-FE >>>interference in a differentiated fashion. >>> >>> >>>Multicast & Unicast: >>> >>>The discussion on this started out with a discussion >>>of the IETF protocol design BKM that options can ruin >>>compatibility. That is, if there are four ways to >>>implement something, all optional, then you can have >>>client 1 implement A & B, and client 2 implement C & D, >>>and even though both clients are 100% compliant, they >>>cannot talk to one another. Better to say all clients >>>must implement A and make B, C, and D optional, so that >>>way you know that all implementations will be able to >>>at least talk. >>> >>>Patrick & I pushed on this a bit, explaining that we >>>actually had potentially (at least) two different >>>environments - very close environments where multicast >>>support could be present in the interconnect, and >>>not-as-close environments (and some close >>>environments as well) where multicast was not available. >>> >>>Bill & Alex indicated that if there really are two >>>quite different cases, then it is possible to have a >>>"dual mandatory" approach. I.e.: >>> >>>If your underlying interconnect supports multicast, >>>then you MUST implement the following (multicast) >>>method of communication. >>> >>>If your underlying interconnect supports unicast, then >>>you MUST implement the following (unicast) method >>>of communication. >>> >>>This will guarantee interop, although at a potential >>>extra cost (cost being having to potentially support >>>both when both are present). While this isn't optimal, >>>it does at least give some flexibility. >>> >>> >>> >>>Congestion control: >>> >>>Several times over the whole conversation the topic >>>of congestion control came up. Also, as part of some >>>TIPC discussions, I ended up spending some time talking >>>to Allison Mankin (transport AD) about congestion control >>>as well. All the ADs I talked to where consistent on >>>the following: >>> >>>If you are running over IP, you MUST act in a RFC2914 >>>compliant fashion (i.e. respond to congestion like TCP >>>or SCTP or RMT does). Two reasons where put forth for >>>this: >>>1) Any time you define an IP-based protocol you cannot >>>guarantee that it will not go out over the Internet. As >>>such, the IESG will NOT standardize IP protocols with >>>"bad" (non-2914) behaviors. >>>2) Lots of implementation experience showing that other >>>congestion control mechanisms don't work (congestion >>>collapse etc). >>> >>>They where very firm on the above and my impression was >>>that convincing them otherwise would be very difficult. >>> >>>That being said, a second alternative did arise: If >>>you are not implementing on top of IP (e.g. running on >>>Infiniband, ATM, Ethernet) then you could rely on mechanisms >>>for congestion control built into what you are relying on, >>>or even consider building your own congestion control >>>mechanisms (ala TIPC). This makes it possible to define >>>(for example) a multicast transport for forces without >>>having to go all the way and implementing RMT - as long >>>as it is clear that it isn't over IP. The ADs went as >>>far as saying that the IETF could even accept standards- >>>track drafts that say nothing about IP (e.g. define an >>>Ethernet-only transport for ForCES), if it is necessary >>>for ForCES. GSMP and (some other group I forgot) was >>>given as an example. >>> >>>Cheers, >>>David >>> >>>_______________________________________________ >>>Forces-protocol mailing list >>>Forces-protocol@ietf.org >>>https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> >>>_______________________________________________ >>>Forces-protocol mailing list >>>Forces-protocol@ietf.org >>>https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> >>> >>> >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> --------------060001010000030203070002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Ram,

Good to have you back.  Yes,..that will be fine.  All I am saying is  we leave it
at a SHOULD implement strength.  We can't mandate implementation (i.e. make it
a MUST) of what hasn't been fully defined. 

Regards,
Alex.


ram.gopal@nokia.com wrote:
Alex,
 
I share your concern.
 
May be we need to make it a point that if underlying infrastructure supports such capabilities like reliable multicast, multicast security etc. then its responsibility of the operator to choose.
 
Does that work fine?
 
Regards
Ramg
-----Original Message-----
From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Alex Audu
Sent: Friday, March 05, 2004 4:26 PM
To: Khosravi, Hormuzd M
Cc: Deleganes, Ellen M; forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from chat with ADs

I still maintain that MULTICAST is best left at SHOULD implement strength.  Why?
A lot of issues are still unresolved concerning multicast reliabililty, security, etc., unless
we want to define an application-layer method to resolve issues like  synchronization,
packet-loss, ACK/NACK implosion, etc. 

Alex.

Khosravi, Hormuzd M wrote:
Yes Ellen, that was my intent.

Thanks for the clarification,
Hormuzd

-----Original Message-----
From: Deleganes, Ellen M 
Sent: Friday, March 05, 2004 12:19 PM
To: Khosravi, Hormuzd M; alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs


I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is
that even if Multicast is optional, those procedures that noted in
Hormudz's email should be described in the ForCES protocol spec. That
is, if a ForCES protocol implementation supports multicast, then it MUST
implement it in the manner described in the ForCES protocol
specification. Otherwise, ForCES implementations using multicast will
probably not interoperate.

Whether or not implementing multicast for transports that support
multicast is a requirement is a separate question. 

Regards,
Ellen

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M
Sent: Thursday, March 04, 2004 6:12 PM
To: alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from chat with ADs

Hi Alex,

In general, I prefer using language such as MUST so that there is no
confusion or interop issues in the protocol implementations. However,
you raise a reasonable point and let me tell you my thoughts on this. We
will definitely need Unicast between FEs and CEs at the minimum in the
protocol. In addition, if the interconnect technology supports Multicast
and there is a case where it is useful to the application (such as
downloading IPv4 routes) we must allow it as well without breaking
interop. In order to do that, we will need specific procedures in the
protocol that will allow the CE and FE to negotiate on using multicast
dynamically at run-time (say during the binding or joining phase between
the CE and FE) and also associate different multicast groups with LFBs.
We will also need to define how Reliability/CC etc. will be provided for
multicast...may be using RMT, TIPC, etc. (?) If we do this correctly,
then applications will be able to use both unicast and multicast without
any interop issues.

Let me know what you guys think about this.

Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Thursday, March 04, 2004 1:22 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from chat with ADs


Hormuzd,

Why should multicast be "mandated for certain cases where it will be 
useful" if there
is a simpler, more robust way to do the same thing?  I'll say we don't 
mandate this.
We can make it a "SHOULD" strength, not a "MUST".  We mandate UNICAST
and make MULTICAST optional.  Any issues with this?

Regards,
Alex.


Khosravi, Hormuzd M wrote:

  
Hi David

Your summary below of the discussion with Ads on the different issues
seems like very reasonable approaches to me.

I agree that it will be a good idea to present transport alternatives
    
at
  
IP and non-IP level for the ForCES protocol. We can mandate one or more
transport for IP and one or more transport for non-IP, this way the
interoperability requirements are met and at the same time, the in-box,
out of box scenarios are met.

Also, agree with having multiple channels/connections to differentiate
    
C
  
& D traffic between CEs and FEs. On the unicast/multicast topic, dual
mandatory approach again seems a good idea to support interoperability.
The one thing that I would like to point out is that for any ForCES
protocol implementation to work, unicast will definitely be required at
the minimum. One could also mandate using multicast for certain cases
where it will be useful (e.g. IPv4/config table download), if it is
supported by the interconnect as you stated. But just multicast without
unicast will not work, atleast not efficiently.

Regards
Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David
Sent: Tuesday, March 02, 2004 5:06 AM
To: forces-protocol@ietf.org
Subject: [Forces-protocol] Comments from chat with ADs

Patrick and I spent about 90 minutes last night
chatting with Bill and Alex about ForCES, with
maybe half of the time on the protocol.  In
the conversations with them, along with some
follow-up chats I had with Allison Mankin, the
following topics where covered:  multiple 
channels, multicast/unicast, and congestion 
control.  Below is what I recall from memory 
(Patrick please correct me/elaborate as needed :)



Multiple channels:  

I discussed the interference issue that 
was identified by the GRMP team.  Bill &
Alex agreed that many OS implementations can have
an interference property (i.e. where two different
connections will have queuing interference lower in
the networking stack in the OS).  So it is necessary
to make sure when implementing a FE (or CE probably
as well) that this is taken into account.  Methods
of doing that include:
* Manually queuing packets (i.e. feed OS few enough
 packets that it cannot get into trouble - although
 you pay a performance price for that, in that fine
 grained scheduling takes cycles)
* Indicating to the OS to treat flows differently - 
 some real-time OS will let you do this, that is they
 are implemented to internally retain QoS between
 flows.
However, it was also mentioned that intra-FE 
interference is only one kind of interference.  Good
FE implementation (e.g. by manually queuing above the
OS) helps to fix intra-FE interference, but it does
not solve inter-FE interference.  That is, if all
(C & D) packets are always on the same connection,
that makes it impossible on the wire to differentiate
them from one another.  Imagine you have a bunch of
FEs with some of them being subject to DOS attack for
D packets, and you want to query one of the FEs for
statistics.  It would be good to have some way of
ensuring the C packets (or any high priority packets -
OSPF HELLO maybe) get through.  Separate channels
(as Jamal indicated, don't even have to be C & D)
makes this possible.   Putting everything on one
channel makes it impossible to deal with inter-FE
interference in a differentiated fashion. 


Multicast & Unicast:  

The discussion on this started out with a discussion
of the IETF protocol design BKM that options can ruin
compatibility.  That is, if there are four ways to
implement something, all optional, then you can have
client 1 implement A & B, and client 2 implement C & D,
and even though both clients are 100% compliant, they
cannot talk to one another. Better to say all clients
must implement A and make B, C, and D optional, so that
way you know that all implementations will be able to 
at least talk.

Patrick & I pushed on this a bit, explaining that we
actually had potentially (at least) two different
environments - very close environments where multicast
support could be present in the interconnect,  and 
not-as-close environments (and some close
environments as well) where multicast was not available.

Bill & Alex indicated that if there really are two
quite different cases, then it is possible to have a
"dual mandatory" approach.  I.e.:

If your underlying interconnect supports multicast,
then you MUST implement the following (multicast)
method of communication.

If your underlying interconnect supports unicast, then
you MUST implement the following (unicast) method
of communication.

This will guarantee interop, although at a potential
extra cost (cost being having to potentially support
both when both are present).  While this isn't optimal,
it does at least give some flexibility.



Congestion control:

Several times over the whole conversation the topic
of congestion control came up.  Also, as part of some
TIPC discussions, I ended up spending some time talking
to Allison Mankin (transport AD) about congestion control
as well.  All the ADs I talked to where consistent on 
the following:

If you are running over IP, you MUST act in a RFC2914
compliant fashion (i.e. respond to congestion like TCP
or SCTP or RMT does).  Two reasons where put forth for
this:
1) Any time you define an IP-based protocol you cannot
guarantee that it will not go out over the Internet. As
such, the IESG will NOT standardize IP protocols with
"bad" (non-2914) behaviors.
2) Lots of implementation experience showing that other
congestion control mechanisms don't work (congestion
collapse etc).

They where very firm on the above and my impression was
that convincing them otherwise would be very difficult.

That being said, a second alternative did arise:  If
you are not implementing on top of IP (e.g. running on
Infiniband, ATM, Ethernet) then you could rely on mechanisms
for congestion control built into what you are relying on,
or even consider building your own congestion control
mechanisms (ala TIPC).  This makes it possible to define
(for example) a multicast transport for forces without
having to go all the way and implementing RMT - as long
as it is clear that it isn't over IP.  The ADs went as
far as saying that the IETF could even accept standards-
track drafts that say nothing about IP (e.g. define an
Ethernet-only transport for ForCES), if it is necessary 
for ForCES. GSMP and (some other group I forgot) was
given as an example.

Cheers,
David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
 

    


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------060001010000030203070002-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:18:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05299 for ; Fri, 5 Mar 2004 18:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOZp-0008RD-D4 for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:17:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25NHvU4032429 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOZp-0008Qi-2q for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:17:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05268 for ; Fri, 5 Mar 2004 18:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOZm-0004Qv-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:17:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOYp-0004HH-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:16:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOXv-00048U-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOXx-0007tg-3l; Fri, 05 Mar 2004 18:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOX2-0007Pj-VF for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 18:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04995 for ; Fri, 5 Mar 2004 18:15:00 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOX0-0003zA-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:15:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOW7-0003pi-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:14:08 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AzOVZ-0003fU-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:13:33 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25NDDS15910; Sat, 6 Mar 2004 01:13:13 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 01:13:11 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i25NDBvc014411; Sat, 6 Mar 2004 01:13:11 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00mS8rzK; Sat, 06 Mar 2004 01:13:09 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25ND8O10058; Sat, 6 Mar 2004 01:13:08 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 17:13:07 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQC+sEl7fc7gmfZQL2W+F2rOXoszQADFPdg To: , Cc: , , X-OriginalArrivalTime: 05 Mar 2004 23:13:07.0893 (UTC) FILETIME=[6BA64650:01C40307] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 18:13:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Jamal, FEM/CEM interface and message description is outside the scope of the = ForCES framework. I'm not sure why we to deal now within our scope? The initial configuration like FE and CE endpoint and other vital = information are pre-configuration and is outside the scope how we do it either thro' CLI or SNMP or ????.=20 Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > Hadi Salim > Sent: Friday, March 05, 2004 4:39 PM > To: alex.audu@alcatel.com > Cc: Khosravi, Hormuzd M; Deleganes, Ellen M; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Comments from chat with ADs >=20 >=20 > Alex, >=20 > Lets just follow the discussion in order of issues, to make faster > progress. > One issue at a time. At the end if it is shown that multicast > has all these problems you say it does, we should probably throw it > out totaly. All the issues you address are listed below. > I sent text on issue 0 yesterday. Hormuzd is sending something > on at least 2. Maybe i should send on 1.=20 > These three are the easisest to resolve. >=20 > Here are the issues again (with two new additions at the end): > If you ahve any that are missing here, please make suggestions. >=20 > 0) ID on the header. > 1) Encoding > 2) Multiple channels/connections > 3) Transport: unicast/multicast/broadcast=20 > { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary=20 > backplanes, TIPC}=20 > 4) Congestion control > 5) Reliability > 6) Security > 7) High availability > 8) Capability exchange > 9) The FEM/CEM interface >=20 > cheers, > jamal >=20 > On Fri, 2004-03-05 at 16:26, Alex Audu wrote: > > I still maintain that MULTICAST is best left at SHOULD implement > > strength. Why? > > A lot of issues are still unresolved concerning multicast > > reliabililty, security, etc., unless > > we want to define an application-layer method to resolve=20 > issues like=20 > > synchronization, > > packet-loss, ACK/NACK implosion, etc. =20 > >=20 > > Alex. > >=20 >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:30:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03307 for ; Fri, 5 Mar 2004 17:40:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzG-0007ui-Uj for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 17:40:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25MeAY4030398 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 17:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNzF-0007uD-Cl for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 17:40:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03189 for ; Fri, 5 Mar 2004 17:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNzC-0005xT-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:40:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNy2-0005eQ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:38:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzNx9-0005VJ-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 17:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNxB-0007no-Bk; Fri, 05 Mar 2004 17:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNx4-0007lD-Dl for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 17:37:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03165 for ; Fri, 5 Mar 2004 17:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNx1-0005Ua-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:37:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNw6-0005Lh-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:36:55 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AzNvT-00054D-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 17:36:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i25MZiTN014518; Fri, 5 Mar 2004 16:35:45 -0600 (CST) Message-ID: <404900BF.6030305@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] issue 1: packet encoding References: <1078523986.1036.116.camel@jzny.localdomain> In-Reply-To: <1078523986.1036.116.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------060901030707050506070908" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 05 Mar 2004 16:35:43 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060901030707050506070908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamal, After a quick glance, we don't need OuterTLV / IinnerTLV to be explicitly called out. As far as I know, this is an inherent TLV encoding property. I'll take a look at the rest and comment later. Regards, Alex. Jamal Hadi Salim wrote: >Attached is text for stimulating discussion on issue 1. > >cheers, >jamal > > >------------------------------------------------------------------------ > >Packet encoding suggestion. > >Binary encoding to be used to be able to pack as much as possible >within an allowed MTU. >TLVs to be used to map the various attributes. >TLVs within TLVs were used to encode complex attributes such as >lists or compound structures. > >The layout below is to get a discussion going. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Forces message header | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Forces Attributes | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >The Forces Message Header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Command | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flags | typeid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >The xIDs are being discussed in issue 0. > >The command would be of the sort of ADD, DEL, GET. >The xID will address the entity being targeted. >[A command from a CE -> FE is for querying or configuration, whereas one >from FE -> CE is a response or event]. > >The typeid identifies further the type of target by looking at >typeid. >[ for example, in our implementation we extended the popular tcpdump >sniffer to look decode the packet for protocol debugging purposes. > >Length: length of the message including the attributes + header. > >XML encoding: >XML encoding may be useful in capabilities definition >(i.e slow path) but not in the configuration of data path tables. >This is because of its nature to require higher bandwith and >CPU computational needs. > >TLVs: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Type | variable TLV Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > | Value (Data of size TLV length) | > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >It is possible to extend the data in the TLV to contain another >TLV to build complex structures (such as the ones described in >XML by the model draft or lists susch as those defined by GRMP). > >Example: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Outer TLV Type | Outer TLV Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner TLV1 Type | Inner TLV1 Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ~~~~~~~~~~~~~~ VALUE1 ~~~~~~~~~~~~~~~~~~~~~~ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Inner TLV2 Type | Inner TLV2 Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ~~~~~~~~~~~~~~ VALUE2 ~~~~~~~~~~~~~~~~~~~~~~ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Which could be used to represent the following layout : > > +-+-+-+-+-+-+-+-+-+-+-+ .-~-~-~-~-~-~-. > | TLV1 | ------>| param 1 | > +-+-+-+-+-+-+-+-+-+-+-+ -~-~-~-~-~-~- > | TLV2 | --->--+ > +-+-+-+-+-+-+-+-+-+-+-+ | > V > | > / > +-----------+ > | > V .-~-~-~-~-~-~-. > | +--->| param2_1 | > +-+-+-+-+-+-+-+-+-+-+-+ | -~-~-~-~-~-~- > | TLV2_1 | --->-+ .-~-~-~-~-~-~-. > +-+-+-+-+-+-+-+-+-+-+-+ +--->| param2_2 | > | TLV2_2 | --->----+ -~-~-~-~-~-~- > +-+-+-+-+-+-+-+-+-+-+-+ > > >It is thought that TLVs and nested TLVs will generally constitute >slightly higher requirements for compute and bandwdith than encodings >based on fixed layouts (XML is many more factors demanding). >The added advantage with TLV usage of course is ability to add new >TLVs easily without redefining the packet or the protocol. >In addition, being able to optionally leave a TLV out during communication >(the message example would have been perfectly decoded if TLV1 was >never encoded). > >A small challenge that needs to be overcome for TLVs is to detect >where failures happen (when you have a list or other compound structure). >This is mostly useful/needed for batching or configuring a list of elements. >If we were to use our implementation as a sample space: we had the "all >upto failed one applied" scheme, in which case a NACK with the failed >TLV Type is sent back. > >An interesting idea is to encode an 8 bit sequence number in the >type to find precisely which TLV failed. > > > > --------------060901030707050506070908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal,

After a quick glance, we don't need  OuterTLV / IinnerTLV to be explicitly called out.
As far as I know, this is an inherent TLV encoding property.

I'll take a look at the rest and comment later.

Regards,
Alex.

Jamal Hadi Salim wrote:
Attached is text for stimulating discussion on issue 1.

cheers,
jamal
  

Packet encoding suggestion. 

Binary encoding to be used to be able to pack as much as possible
within an allowed MTU. 
TLVs to be used to map the various attributes.
TLVs within TLVs were used to encode complex attributes such as
lists or compound structures.

The layout below is to get a discussion going.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Forces message header                       |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Forces  Attributes                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



The Forces Message Header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     0               1               2             3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Command         |               Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Source xID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Destination xID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             flags           |             typeid              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The xIDs are being discussed in issue 0.

The command would be of the sort of ADD, DEL, GET.
The xID will address the entity being targeted.
[A command from a CE -> FE is for querying or configuration, whereas one
from FE -> CE is a response or event].

The typeid identifies further the type of target by looking at
typeid.
[ for example, in our implementation we extended the popular tcpdump 
sniffer to look decode the packet for protocol debugging purposes.

Length: length of the message including the attributes + header.

XML encoding:
XML encoding may be useful in capabilities definition
(i.e slow path) but not in the configuration of data path tables.
This is because of its nature to require higher bandwith and
CPU computational needs.

TLVs:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type                    | variable TLV Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |            Value (Data of size TLV length)                    |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It is possible to extend the data in the TLV to contain another
TLV to build complex structures (such as the ones described in
XML by the model draft or lists susch as those defined by GRMP).

Example:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outer TLV Type              |    Outer TLV Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner TLV1 Type             |   Inner TLV1 Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ~~~~~~~~~~~~~~           VALUE1    ~~~~~~~~~~~~~~~~~~~~~~     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner TLV2 Type             |   Inner TLV2 Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ~~~~~~~~~~~~~~           VALUE2    ~~~~~~~~~~~~~~~~~~~~~~     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Which could be used to represent the following layout :

  +-+-+-+-+-+-+-+-+-+-+-+        .-~-~-~-~-~-~-.
  |  TLV1               | ------>|   param 1   |
  +-+-+-+-+-+-+-+-+-+-+-+         -~-~-~-~-~-~-
  |  TLV2               | --->--+
  +-+-+-+-+-+-+-+-+-+-+-+       |
                                V
                                |
                               /
                  +-----------+
                  |           
                  V                 .-~-~-~-~-~-~-.
                  |            +--->|  param2_1   | 
  +-+-+-+-+-+-+-+-+-+-+-+      |     -~-~-~-~-~-~- 
  |  TLV2_1             | --->-+       .-~-~-~-~-~-~-.
  +-+-+-+-+-+-+-+-+-+-+-+         +--->| param2_2    |
  |  TLV2_2             | --->----+     -~-~-~-~-~-~- 
  +-+-+-+-+-+-+-+-+-+-+-+  


It is thought that TLVs and nested TLVs will generally constitute
slightly higher requirements for compute and bandwdith than encodings 
based on fixed layouts (XML is many more factors demanding). 
The added advantage with TLV usage of course is ability to add new 
TLVs easily without redefining the packet or the protocol.
In addition, being able to optionally leave a TLV out during communication
(the message example would have been perfectly decoded if TLV1 was
never encoded).

A small challenge that needs to be overcome for TLVs is to detect
where failures happen (when you have a list or other compound structure). 
This is mostly useful/needed for batching or configuring a list of elements. 
If we were to use our implementation as a sample space: we had the "all 
upto failed one applied" scheme, in which case a NACK with the failed 
TLV Type is sent back.

An interesting idea is to encode an 8 bit sequence number in the 
type to find precisely which TLV failed.
--------------060901030707050506070908-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:31:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05711 for ; Fri, 5 Mar 2004 18:31:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOmU-0001Yq-Ms for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25NV2TU005994 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOmT-0001YW-RK for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05701 for ; Fri, 5 Mar 2004 18:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOmQ-0006UR-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOlR-0006K2-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:29:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOkV-00069u-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOkX-0001Fs-61; Fri, 05 Mar 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOjb-000136-17 for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 18:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05547 for ; Fri, 5 Mar 2004 18:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOjY-0005zd-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOib-0005px-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:27:02 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzOi1-0005fZ-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:26:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i25NTWkh013739; Fri, 5 Mar 2004 23:29:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i25NKI6N027972; Fri, 5 Mar 2004 23:20:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030515255219092 ; Fri, 05 Mar 2004 15:25:52 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 15:25: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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: <52D13A805349A249960B9943E5590BD802928613@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQC+sEl7fc7gmfZQL2W+F2rOXoszQADFPdgAABoIeA= From: "Putzolu, David" To: , Cc: X-OriginalArrivalTime: 05 Mar 2004 23:25:52.0872 (UTC) FILETIME=[339CCE80:01C40309] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 15:25:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Nice to have you back Ram! I agree that _defining_ the FEM/CEM interface & associated FEM/CEM messages is outside our scope. That being said, the protocol could assert that certain functions will be done in the FEM/CEM interface (as opposed to by the protocol itself). I.e. "We do not do (foo) here - we assert that it has already been done. (Foo) is expected to be done during by the FEM/CEM and the mechanisms=20 for doing (Foo) in FEM/CEM are beyond the scope of this=20 document." Cheers, David > -----Original Message----- > From: forces-protocol-admin@ietf.org=20 > [mailto:forces-protocol-admin@ietf.org] On Behalf Of=20 > ram.gopal@nokia.com > Sent: Friday, March 05, 2004 3:13 PM > To: hadi@znyx.com; alex.audu@alcatel.com > Cc: Khosravi, Hormuzd M; Deleganes, Ellen M; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Comments from chat with ADs >=20 > Hello Jamal, >=20 > FEM/CEM interface and message description is outside the=20 > scope of the ForCES framework. I'm not sure why we to deal=20 > now within our scope? >=20 > The initial configuration like FE and CE endpoint and other=20 > vital information are pre-configuration and is outside the scope > how we do it either thro' CLI or SNMP or ????.=20 >=20 >=20 > Regards > Ramg >=20 >=20 > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > > Hadi Salim > > Sent: Friday, March 05, 2004 4:39 PM > > To: alex.audu@alcatel.com > > Cc: Khosravi, Hormuzd M; Deleganes, Ellen M;=20 > forces-protocol@ietf.org > > Subject: Re: [Forces-protocol] Comments from chat with ADs > >=20 > >=20 > > Alex, > >=20 > > Lets just follow the discussion in order of issues, to make faster > > progress. > > One issue at a time. At the end if it is shown that multicast > > has all these problems you say it does, we should probably throw it > > out totaly. All the issues you address are listed below. > > I sent text on issue 0 yesterday. Hormuzd is sending something > > on at least 2. Maybe i should send on 1.=20 > > These three are the easisest to resolve. > >=20 > > Here are the issues again (with two new additions at the end): > > If you ahve any that are missing here, please make suggestions. > >=20 > > 0) ID on the header. > > 1) Encoding > > 2) Multiple channels/connections > > 3) Transport: unicast/multicast/broadcast=20 > > { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary=20 > > backplanes, TIPC}=20 > > 4) Congestion control > > 5) Reliability > > 6) Security > > 7) High availability > > 8) Capability exchange > > 9) The FEM/CEM interface > >=20 > > cheers, > > jamal > >=20 > > On Fri, 2004-03-05 at 16:26, Alex Audu wrote: > > > I still maintain that MULTICAST is best left at SHOULD implement > > > strength. Why? > > > A lot of issues are still unresolved concerning multicast > > > reliabililty, security, etc., unless > > > we want to define an application-layer method to resolve=20 > > issues like=20 > > > synchronization, > > > packet-loss, ACK/NACK implosion, etc. =20 > > >=20 > > > Alex. > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:35:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05824 for ; Fri, 5 Mar 2004 18:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOqO-0006yz-8V for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25NZ4CY026833 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOqM-0006yU-Pd for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:35:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05812 for ; Fri, 5 Mar 2004 18:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOqJ-0007A1-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:34:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOpT-0006zz-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:34:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOog-0006q7-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:33:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOoc-00054I-HE; Fri, 05 Mar 2004 18:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOnX-0001Zw-Ef for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 18:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05749 for ; Fri, 5 Mar 2004 18:32:03 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOnU-0006f9-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:32:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOmX-0006VY-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:31:06 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzOm1-0006LS-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:30:34 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 6 Mar 2004 07:41:40 +0800 Received: from 219.82.182.143 ( [219.82.182.143]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 6 Mar 2004 07:41:40 +0800 Message-ID: <1078530100.4049103fdc6dc@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> <4048A7EB.2030808@alcatel.com> In-Reply-To: <4048A7EB.2030808@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA05750 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 07:41:40 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alex, Because we have several experiment cases, could you tell more which one = you=20 are addressing and what is the result you think should be? I strongly suggest the same experiments be done by more guys here so tha= t we=20 can share to analyze the results. Cheers, Weiming Quoting Alex Audu : > Hello Weiming, >=20 > I still believe that the result you got from your experiment could be=20 > much more > improved if you allocated two separate queues, one for C and the other=20 > for D > data. Then create two separate threads to process the queues (one for e= ach). > Give both threads equal priority and you should be fine. If you want to= skew > things in favor of the C, then you can adjust priority accordingly. >=20 > Regards, > Alex. >=20 > Wang,Weiming wrote: >=20 > >Hi David, > > > >Some more comments on the multi-channels from your last email as below= : > > > >I agree that multiple FEs sharing the same physical link makes problem= s more > complicated. To make things more clear, I want state GRMP's ideas > >again here, for I think there might be some misunderstanding on it: > > > >1. GRMP presents that pure separation of C/D in the same physical link= is of > no use to DoS protection. DoS protection can only be achieved by inside= FE > mechanisms except a separate physical link is used by C/D. This also a= pplies > to multi-FEs sharing the same physical links as you mentioned above. Ac= tually > I can not see such separation has solved the DoS problem for multi-FE c= ase > from the above txt. =20 > > > >2. We do not oppose to have such separation if it's proven useful for > others. Actually the key GRMP has defined for DoS and congestion contro= l is > the FE attribute for DoS protection policy, which has no limitation wit= h > multi transport layer channels. If it's proven separation of C/D channe= ls are > useful, GRMP can easily adapt it. But what we need more discussion is t= rying > to see more reasons for such separations.=20 > > > >3. A combined control of C and D is useful for DoS protection as well = as for > congestion.=20 > >I have to note that the scheme proposed by FACT and also mentioned in = the > proposed basic merge principles only assume to provide a Data channel > control mechanism ( a rate limit). We just argue that this is not enoug= h. > Actually what you mentioned above is also to ask for such a control > combination for multi-FEs cases. GRMP scheme can supply this very well = by > using a FE attribute to specify DoS protection policy in which C packet= s with > higher priorities can be ensured. I don't think other protocols have pr= ovided > this mechanism (Note that this priority is different from that in ForCE= S > message headers, which actually does not take effect for this purpose).= =20 > > > >To summarize, we just argue that a DoS protection policy like that pre= sented > by GRMP should be included in final ForCES protocol other than just by > separation of C/D channels so as to effectively avoid DoS attack and al= so to > manage the congestion. I think this idea is quite the same as what you > presented in another email as some QoS hints transmitted from CE to FE = for > DoS protection and congestion control.=20 > > > >Yours, > >Weiming > > > >----- Original Message -----=20 > >From: "Putzolu, David" > >To: > >Sent: Tuesday, March 02, 2004 9:06 PM > >Subject: [Forces-protocol] Comments from chat with ADs > > > > > >Patrick and I spent about 90 minutes last night > >chatting with Bill and Alex about ForCES, with > >maybe half of the time on the protocol. In > >the conversations with them, along with some > >follow-up chats I had with Allison Mankin, the > >following topics where covered: multiple=20 > >channels, multicast/unicast, and congestion=20 > >control. Below is what I recall from memory=20 > >(Patrick please correct me/elaborate as needed :) > > > > > > > >Multiple channels: =20 > > > >I discussed the interference issue that=20 > >was identified by the GRMP team. Bill & > >Alex agreed that many OS implementations can have > >an interference property (i.e. where two different > >connections will have queuing interference lower in > >the networking stack in the OS). So it is necessary > >to make sure when implementing a FE (or CE probably > >as well) that this is taken into account. Methods > >of doing that include: > >* Manually queuing packets (i.e. feed OS few enough > > packets that it cannot get into trouble - although > > you pay a performance price for that, in that fine > > grained scheduling takes cycles) > >* Indicating to the OS to treat flows differently -=20 > > some real-time OS will let you do this, that is they > > are implemented to internally retain QoS between > > flows. > >However, it was also mentioned that intra-FE=20 > >interference is only one kind of interference. Good > >FE implementation (e.g. by manually queuing above the > >OS) helps to fix intra-FE interference, but it does > >not solve inter-FE interference. That is, if all > >(C & D) packets are always on the same connection, > >that makes it impossible on the wire to differentiate > >them from one another. Imagine you have a bunch of > >FEs with some of them being subject to DOS attack for > >D packets, and you want to query one of the FEs for > >statistics. It would be good to have some way of > >ensuring the C packets (or any high priority packets - > >OSPF HELLO maybe) get through. Separate channels > >(as Jamal indicated, don't even have to be C & D) > >makes this possible. Putting everything on one > >channel makes it impossible to deal with inter-FE > >interference in a differentiated fashion.=20 > > > >[WangRe] > > > >=20 > >=16=8A=DCz=CAk=A2=DA=1C=A2Y=9A=8AX=A7=82X=AC=B4Z+q=EB)=AE=8Bhr=89bz=D7= =E8=AE=08m=B6=9B?=FF=0C0=D6'=AD~=8A=E0=FEf=A2=96f=A7=FEX=AC=B6)=DF=A3=F7=E8= =AD=C7=AC=A6=BA-=A1=CA% > > >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 18:38:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05909 for ; Fri, 5 Mar 2004 18:38:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOtF-0007JC-IJ for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 18:38:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Nc1cw028080 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 18:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOtF-0007Ip-53 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 18:38:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05903 for ; Fri, 5 Mar 2004 18:37:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOtC-0007ce-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:37:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOsF-0007TC-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:37:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzOrH-0007Jx-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 18:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOrK-00070F-0P; Fri, 05 Mar 2004 18:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzOqQ-0006z0-Fx for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 18:35:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05818 for ; Fri, 5 Mar 2004 18:35:02 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzOqN-0007AR-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzOpa-00070v-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:34:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AzOp7-0006qR-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 18:33:45 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25NXZC26947; Sat, 6 Mar 2004 01:33:35 +0200 (EET) X-Scanned: Sat, 6 Mar 2004 01:33:19 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i25NXJnN015216; Sat, 6 Mar 2004 01:33:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 001uaEsD; Sat, 06 Mar 2004 01:33:18 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i25NXH713766; Sat, 6 Mar 2004 01:33:17 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Mar 2004 17:33:09 -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 Subject: RE: [Forces-protocol] Comments from chat with ADs Message-ID: Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQCeAEgUFGzt/YiSAWh7UdpGgJxmwAim91AAAHr2MA= To: , , X-OriginalArrivalTime: 05 Mar 2004 23:33:09.0348 (UTC) FILETIME=[37C5C240:01C4030A] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 18:33:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello weiming, Just one clarification to avoid confusion on my text. (see my text = below). > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext > ram.gopal@nokia.com > Sent: Friday, March 05, 2004 5:51 PM > To: wmwang@mail.hzic.edu.cn; david.putzolu@intel.com; > forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Comments from chat with ADs >=20 >=20 >=20 > Hello Weiming, >=20 > Alex as already answered to this - just to add more to his=20 > question my comments are line. >=20 > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Wang,Weiming > > Sent: Friday, March 05, 2004 12:35 AM > > To: Putzolu, David; forces-protocol@ietf.org > > Subject: Re: [Forces-protocol] Comments from chat with ADs > >=20 > >=20 > > Hi David, > >=20 > > Some more comments on the multi-channels from your last email=20 > > as below: > >=20 > > I agree that multiple FEs sharing the same physical link=20 > > makes problems more complicated. To make things more clear, I=20 > > want state GRMP's ideas > > again here, for I think there might be some misunderstanding on it: > >=20 > > 1. GRMP presents that pure separation of C/D in the same=20 > > physical link is of no use to DoS protection. DoS protection=20 > > can only be achieved by inside FE mechanisms except a=20 > > separate physical link is used by C/D. This also applies to=20 > > multi-FEs sharing the same physical links as you mentioned=20 > > above. Actually I can not see such separation has solved the=20 > > DoS problem for multi-FE case from the above txt. =20 > >=20 > > 2. We do not oppose to have such separation if it's proven=20 > > useful for others. Actually the key GRMP has defined for DoS=20 > > and congestion control is the FE attribute for DoS protection=20 > > policy, which has no limitation with multi transport layer=20 > > channels. If it's proven separation of C/D channels are=20 > > useful, GRMP can easily adapt it. But what we need more=20 > > discussion is trying to see more reasons for such separations.=20 > >=20 > > 3. A combined control of C and D is useful for DoS protection=20 > > as well as for congestion.=20 > > I have to note that the scheme proposed by FACT and also=20 > > mentioned in the proposed basic merge principles only assume=20 > > to provide a Data channel control mechanism ( a rate limit).=20 > > We just argue that this is not enough. Actually what you=20 > > mentioned above is also to ask for such a control combination=20 > > for multi-FEs cases. GRMP scheme can supply this very well by=20 > > using a FE attribute to specify DoS protection policy in=20 > > which C packets with higher priorities can be ensured. I=20 > > don't think other protocols have provided this mechanism=20 > > (Note that this priority is different from that in ForCES=20 > > message headers, which actually does not take effect for this=20 > > purpose). =20 >=20 > May be your understand is not complete on FACT. >=20 > In FACT we proposed two rate limiter value one for C and=20 > another one for D in adddition the rate from > CE -> FE is different and from FE -> CE. FE after processing=20 > the packet discrimiates the C and D and accordingly=20 > act on it. We have mentioned in our draft that rate=20 > limiting can be done based on even various traffic (C and D) types. > FE endpoint has intelligence to perform such operation. Hope=20 > this helps. =20 >=20 > =20 Please note that there is a "rate limiter" LFB block and it is part of = FE model and FACT will use those to acheive this. FACT doesn't implement the rate limiter as part of the protocol. Regards Ramg=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 21:05:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11700 for ; Fri, 5 Mar 2004 21:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRBW-0001rR-Pz for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 21:05:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26252uu007146 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 21:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRBW-0001r1-5J for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 21:05:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11663 for ; Fri, 5 Mar 2004 21:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzRBT-0002DX-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:04:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzRAX-00022k-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:04:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzR9X-0001rw-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzR9Z-0001aX-1W; Fri, 05 Mar 2004 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzR8b-0001ZQ-3z for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 21:02:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11516 for ; Fri, 5 Mar 2004 21:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzR8Y-0001gn-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzR7a-0001Ue-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:00:59 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzR6g-0001HM-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:00:02 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030518004149:63300 ; Fri, 5 Mar 2004 18:00:41 -0800 Subject: Re: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org In-Reply-To: <404900BF.6030305@alcatel.com> References: <1078523986.1036.116.camel@jzny.localdomain> <404900BF.6030305@alcatel.com> Organization: ZNYX Networks Message-Id: <1078538399.1037.120.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 03/05/2004 06:00:41 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 06:00:43 PM, Serialize complete at 03/05/2004 06:00:43 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 21:00:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-05 at 17:35, Alex Audu wrote: > Jamal, > > After a quick glance, we don't need OuterTLV / IinnerTLV to be > explicitly called out. > As far as I know, this is an inherent TLV encoding property. Alex, nod cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 5 21:28:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12530 for ; Fri, 5 Mar 2004 21:28:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRY1-0003qw-16 for forces-protocol-archive@odin.ietf.org; Fri, 05 Mar 2004 21:28:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i262SGYg014804 for forces-protocol-archive@odin.ietf.org; Fri, 5 Mar 2004 21:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRY0-0003qh-J6 for forces-protocol-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 21:28:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12457 for ; Fri, 5 Mar 2004 21:28:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzRXy-00065b-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:28:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzRWx-0005pP-00 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:27:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzRVn-0005Ro-02 for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:25:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzRJI-0008QQ-Mn for forces-protocol-web-archive@ietf.org; Fri, 05 Mar 2004 21:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRJF-0002ux-3o; Fri, 05 Mar 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzRId-0002ss-3X for forces-protocol@optimus.ietf.org; Fri, 05 Mar 2004 21:12:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12086 for ; Fri, 5 Mar 2004 21:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzRIa-0003Wp-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzRHf-0003LC-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:11:24 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzRH5-00039m-00 for forces-protocol@ietf.org; Fri, 05 Mar 2004 21:10:47 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030518112686:63303 ; Fri, 5 Mar 2004 18:11:26 -0800 Subject: RE: [Forces-protocol] Comments from chat with ADs From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: alex.audu@alcatel.com, hormuzd.m.khosravi@intel.com, ellen.m.deleganes@intel.com, forces-protocol@ietf.org In-Reply-To: References: Organization: ZNYX Networks Message-Id: <1078539044.1038.132.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 03/05/2004 06:11:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/05/2004 06:11:29 PM, Serialize complete at 03/05/2004 06:11:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 05 Mar 2004 21:10:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ram, WB. David beat me to the answer. I added that because it seems that some of the issues we are discussing belong there. For example: It seems to me like it is easier to just select via config if multicast or unicast should be supported. And if it says "config" then it means FEM/CEM. That is not to say that FEM or CEM has to be static; there could be a dynamic protocol (we implemented something proprietary that works with SLP) - in which case the selection/negotiation for multicast/unicast etc is done more intellegentelly. Yes, this is outside the scope. By moving it out of the protocol it makes it simpler imo. In any case, since you are recharged from vacation, can we follow through that list? My opinion is we can progress faster this way. I put out some text issue 0 and issue 1. We should probably beat one issue at a time. But we should be able to attack several at a time. I feel it is easier to have each topic on a separate email thread. cheers, jamal On Fri, 2004-03-05 at 18:13, ram.gopal@nokia.com wrote: > Hello Jamal, > > FEM/CEM interface and message description is outside the scope of the ForCES framework. I'm not sure why we to deal now within our scope? > > The initial configuration like FE and CE endpoint and other vital information are pre-configuration and is outside the scope > how we do it either thro' CLI or SNMP or ????. > > > Regards > Ramg _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 09:04:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17537 for ; Sat, 6 Mar 2004 09:04:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzcOs-0005Nz-Dh for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 09:03:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26E3YbQ020697 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 09:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzcOs-0005Nk-9S for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 09:03:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17534 for ; Sat, 6 Mar 2004 09:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzcOq-00023i-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 09:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzcNw-0001vQ-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 09:02:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzcNN-0001my-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzcNO-0005M6-4I; Sat, 06 Mar 2004 09:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzcMz-0005LP-NH for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 09:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17490 for ; Sat, 6 Mar 2004 09:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzcMy-0001lt-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 09:01:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzcM2-0001ck-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 09:00:38 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzcLT-0001U5-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 09:00:04 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sat, 6 Mar 2004 22:11:21 +0800 Message-ID: <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: base64 Subject: [Forces-protocol] Issue 100: On the issue play Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 21:58:04 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpIaSBKYW1hbCBhbmQgYWxsLCANCg0KSSByZWFsbHkgZW5qb3kgeW91ciBwcm9wb3NhbCB0byBz ZXQgaW5kaXZpZHVhbCBkaXNjdXNzaW5nIGl0ZW1zIGFzIElzc3VlIFggYW5kIHRvIA0Kc2V0IGEg c3BlY2lmaWMgZW1haWwgdG8gZGlzY3VzcyBpdC4gTW9yZW92ZXIsIEkgaGF2ZSBzb21lIHN1Z2dl c3Rpb25zIGZvciBzdWNoIHBsYXk6DQoNCjEuIFRoZSBpc3N1ZSBudW1iZXIgaXMgZ2l2ZW4gYWNj b3JkaW5nIHRvIHRoZSBhY3NlbmQgb3JkZXIgd2hlbiBpdCBpcyBhcHBlYXJlZCBhcyANCmEgc3Bl Y2lmaWMgZW1haWwuIElzc3VlIDAtOTkgYXJlIHJlc2VydmVkIGZvciBkaXNjdXNzaW9uIHJlbGF0 ZWQgdG8gdGhlIHByb3RvY29sIHRlY2huaXF1ZXMsDQphbmQgSXNzdWUgMTAwLTE5OSBhcmUgcmVz ZXJ2ZWQgZm9yIG90aGVyIGlzc3VlcywganVzdCBsaWtlIEkgYm9sZGx5IHB1dCB0aGlzIGVtYWls IGFzIElzc3VlIDEwMC4gDQpJbiB0aGUgZW5kLCB3ZSBqdXN0IG5lZWQgdG8gcGljayB1cCB0aGUg cmVzdWx0cyBmcm9tIHRoZSBJc3N1ZSAwLTk5IGFzIGRlbGl2YXJhYmxlcyB0byBzdWJtaXQgdG8g DQpXRy4gVGhlIHBvc3NpYmxlIHJlc3VsdHMgbWF5IGJlIGEgcG9zaXRpdmUgYWdyZWVtZW50LCBh IG5lZ2F0aXZlIGFncmVlbWVudCAobGlrZSAiY2FuIG5vdCByZWFjaCANCmFncmVlbWVudCIsICJu b3QgY29tcHJvbWlzZWQiLCAibm90IGNvbXByb21pc2VkIHlldCBidXQgbWF5IGluIHRoZSBmdXR1 cmUiLCAibm90IGltcG9ydGFudCIsIA0KImRvbid0IGNhcmUiLCBhbnl3YXksIGFueXRoaW5nLiBJ biB0aGlzIHdheSwgYSByZXN1bHQgd2l0aG91dCBhbnkgb2JqZWN0aW9uIGNhbiBzdXJlbHkgYmUg bWFkZS4gDQoNCjIuIFRoZSBlbWFpbCBzdWJqZWN0IGlzIG1hcmtlZCBhcyBJc3N1ZTxudW1iZXI+ OiA8aXNzdWUgc3RhdGVtZW50Pi4gSW4gdGhpcyB3YXksIG90aGVycyBhcmUgZWFzaWVyDQp0byBm b2xsb3cgdGhlIGRpc2N1c3Npb24uIFdlIG1heSBhbHNvIHVzZSB0aGUgbnVtYmVyIGFzIHRoZSB3 YXkgSmFtbCBkb2VzIHRvIGxpc3QgdGhlbSBpbiBhZHZhbmNlLCBJIGFtIGp1c3QNCmEgbGl0dGxl IHdvcnJ5IGl0IG1heSBiZSBoYXJkIHRvIGZpbmQgdGhlIGlzc3VlIG51bWJlciB3aGVuIGl0IGhh cyBub3QgYmUgcG9zdGVkIGFzIGFuIGluZGlwZW5kYW50IGVtYWlsLg0KDQozLiBJbiBvcmRlciB0 byBzcGVlZCB0aGUgcHJvY2VzcywgaW5kaXZpZHVhbCBjYW5kaWRhdGUgcHJvdG9jb2wgdGVhbSBp cyByZWNvbW1lbmRlZCANCnRvIHNwZWFrIGluIHRoZSBzYW1lIHZvaWNlIHNvIHRoYXQgb3RoZXJz IGNhbiBlYXNpbHkgdW5kZXJzdGFuZCBhbmQgaGF2ZSBsZXNzIGNvbmZ1c2lvbiANCm9uIHRoZSB0 ZWFtIGF0dGl0dXRlLiBEaXNjdXNzaW9ucyBpbnNpZGUgYSB0ZWFtIGFyZSBzdXBwb3NlZCB0byBi ZSBtYWRlIHByaXZhdGVseS4gQnkgcGxheWluZyBpbiB0aGlzIHdheSwgDQp3ZSBqdXN0IGFzc3Vt ZSB0aGF0IGhvdyBjYW4gYSBjb21wcm9taXNlIGJlIG1hZGUgaWYgdGhlIHRlYW0gaW5zaWRlIGNh biBub3QgbWFrZSBhIGNvbXByb21pc2UgZmlyc3QuDQpPZiBjb3Vyc2UsIHRoaXMgZG9lcyBub3Qg YXQgYWxsIG1lYW4gdG8gZXhjbHVkZSBpbmRpdmlkdWFscyAoaW5jbHVkaW5nIGluZGl2aWR1YWxz IGluIHNvbWUgdGVhbSkgdG8gcHJvdmlkZSBjb21tZW50cw0Kb24gdGhlIGlzc3Vlcy4gSXQganVz dCBtZWFucyB0byB0cnkgYmVzdC4gDQoNCg0KWW91cnMsDQpXZWltaW5nDQoNCihQLlMuIEkgc3Vw cG9zZSB0aGUgbWFpbGluZyBsaXN0IG5vdyBydW5zIGluIG9yZGVyLCBpbmRpdmlkdWFsIGFkZHJl c3NlcyBuZWVkbid0IGJlIGFkZGl0aW9uYWxseSBhZGRlZA0KaWYgYSByZXBseSBpcyB0byBwdWJs aWMgYW5kIHRoZSBhZGRpdGlvbmFscyBhcmUgYWxyZWFkeSBpbiB0aGUgbGlzdCwgdG8gbWFrZSBs ZXNzIGR1cGxpY2F0ZXMpLg0KDQoNCg== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 11:00:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24005 for ; Sat, 6 Mar 2004 11:00:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzeDP-00025W-7u for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 10:59:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26Fxpja008022 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 10:59:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzeDO-00025E-KF for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 10:59:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23978 for ; Sat, 6 Mar 2004 10:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzeDM-0007MM-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 10:59:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzeCM-0007DH-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 10:58:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzeBa-00073o-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 10:57:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzeBc-000212-Ku; Sat, 06 Mar 2004 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzeBE-0001xA-FO for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 10:57:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23910 for ; Sat, 6 Mar 2004 10:57:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzeBB-00070k-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 10:57:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzeAD-0006o8-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 10:56:34 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Aze9K-0006cX-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 10:55:38 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030607561614:63565 ; Sat, 6 Mar 2004 07:56:16 -0800 Subject: Re: [Forces-protocol] Issue 100: On the issue play From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078588533.1040.149.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 03/06/2004 07:56:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/06/2004 07:56:18 AM, Serialize complete at 03/06/2004 07:56:18 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2004 10:55:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, On Sat, 2004-03-06 at 08:58, Wang,Weiming wrote: > Hi Jamal and all, > > I really enjoy your proposal to set individual discussing items as Issue X and to > set a specific email to discuss it. Moreover, I have some suggestions for such play: > > 1. The issue number is given according to the acsend order when it is appeared as > a specific email. Issue 0-99 are reserved for discussion related to the protocol techniques, > and Issue 100-199 are reserved for other issues, just like I boldly put this email as Issue 100. > In the end, we just need to pick up the results from the Issue 0-99 as delivarables to submit to > WG. The possible results may be a positive agreement, a negative agreement (like "can not reach > agreement", "not compromised", "not compromised yet but may in the future", "not important", > "don't care", anyway, anything. In this way, a result without any objection can surely be made. I dont think we have be very rigorous in the numbering of the issues. I agree with you on the formating for the March 20th report. The list i presented is a suggestion - i dont think it is totaly complete. Your suggestion on how the results get tagged is fine. I dont think in the final report we have to say exactly how the "congestion control" is met rather what we should say is "reached agreement". The how goes on the protocol draft. > 2. The email subject is marked as Issue: . In this way, others are easier > to follow the discussion. We may also use the number as the way Jaml does to list them in advance, I am just > a little worry it may be hard to find the issue number when it has not be posted as an indipendant email. I agree with this (and made the same suggestion in my other email). Lets have issues with on separate emails. Your subject suggestion is good. If i may add to this suggestion: We propbably should not have more than 3-4 subjects being disscussed concurently. I am pretty sure we can nail the first 3 very quickly. > 3. In order to speed the process, individual candidate protocol team is recommended > to speak in the same voice so that others can easily understand and have less confusion > on the team attitute. Discussions inside a team are supposed to be made privately. By playing in this way, > we just assume that how can a compromise be made if the team inside can not make a compromise first. > Of course, this does not at all mean to exclude individuals (including individuals in some team) to provide comments > on the issues. It just means to try best. The way i look at it is we are now going towards a new protocol. Lets share experiences/opinions etc so we can move faster. Weiming, why dont you the following so we could move faster: 1) add any missing items to that list or format whichever way you prefer. 2) Start responding to the issues posted. Issue 0 (ID semantics) and issue 1 (packet encoding). Hormuzd is planning to post on the recent subject discussion as issue 2. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 13:33:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29556 for ; Sat, 6 Mar 2004 13:33:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgbR-0002Cq-0G for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 13:32:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26IWmWn008479 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 13:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgbQ-0002Cg-QX for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 13:32:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29550 for ; Sat, 6 Mar 2004 13:32:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzgbO-0001Et-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzgaR-00016A-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:31:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzgZh-0000yC-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgZj-0002AW-BX; Sat, 06 Mar 2004 13:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgZO-00026R-Lf for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 13:30:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29512 for ; Sat, 6 Mar 2004 13:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzgZM-0000wa-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:30:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzgYP-0000o7-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:29:42 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzgXS-0000cX-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:28:42 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 7 Mar 2004 02:39:58 +0800 Message-ID: <075b01c403a8$92550150$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> <1078588533.1040.149.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 100: On the issue play MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 02:26:41 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpIaSBKYW1hbCwNCg0KUGxzIGFsbG93IG1lIGp1c3QgcmVwbHkgdG8gbWFpbGluZyBsaXN0IHRv IHJlcGx5IHRvIHlvdSBhcyB3ZWxsLiBJIHdpc2ggeW91IG1heSBvbmx5IG5lZWQgdG8gcmVwbHkg dG8gbWUNCmJ5IHJlcGx5aW5nIHRvIHRoZSBsaXN0LCBmb3IgaXQgcHJvZHVjZXMgZHVwbGljYXRp b25zIDopDQogIA0KPiA+IEkgcmVhbGx5IGVuam95IHlvdXIgcHJvcG9zYWwgdG8gc2V0IGluZGl2 aWR1YWwgZGlzY3Vzc2luZyBpdGVtcyBhcyBJc3N1ZSBYIGFuZCB0byANCj4gPiBzZXQgYSBzcGVj aWZpYyBlbWFpbCB0byBkaXNjdXNzIGl0LiBNb3Jlb3ZlciwgSSBoYXZlIHNvbWUgc3VnZ2VzdGlv bnMgZm9yIHN1Y2ggcGxheToNCj4gPiANCj4gPiAxLiBUaGUgaXNzdWUgbnVtYmVyIGlzIGdpdmVu IGFjY29yZGluZyB0byB0aGUgYWNzZW5kIG9yZGVyIHdoZW4gaXQgaXMgYXBwZWFyZWQgYXMgDQo+ ID4gYSBzcGVjaWZpYyBlbWFpbC4gSXNzdWUgMC05OSBhcmUgcmVzZXJ2ZWQgZm9yIGRpc2N1c3Np b24gcmVsYXRlZCB0byB0aGUgcHJvdG9jb2wgdGVjaG5pcXVlcywNCj4gPiBhbmQgSXNzdWUgMTAw LTE5OSBhcmUgcmVzZXJ2ZWQgZm9yIG90aGVyIGlzc3VlcywganVzdCBsaWtlIEkgYm9sZGx5IHB1 dCB0aGlzIGVtYWlsIGFzIElzc3VlIDEwMC4gDQo+ID4gSW4gdGhlIGVuZCwgd2UganVzdCBuZWVk IHRvIHBpY2sgdXAgdGhlIHJlc3VsdHMgZnJvbSB0aGUgSXNzdWUgMC05OSBhcyBkZWxpdmFyYWJs ZXMgdG8gc3VibWl0IHRvIA0KPiA+IFdHLiBUaGUgcG9zc2libGUgcmVzdWx0cyBtYXkgYmUgYSBw b3NpdGl2ZSBhZ3JlZW1lbnQsIGEgbmVnYXRpdmUgYWdyZWVtZW50IChsaWtlICJjYW4gbm90IHJl YWNoIA0KPiA+IGFncmVlbWVudCIsICJub3QgY29tcHJvbWlzZWQiLCAibm90IGNvbXByb21pc2Vk IHlldCBidXQgbWF5IGluIHRoZSBmdXR1cmUiLCAibm90IGltcG9ydGFudCIsIA0KPiA+ICJkb24n dCBjYXJlIiwgYW55d2F5LCBhbnl0aGluZy4gSW4gdGhpcyB3YXksIGEgcmVzdWx0IHdpdGhvdXQg YW55IG9iamVjdGlvbiBjYW4gc3VyZWx5IGJlIG1hZGUuIA0KDQo+W0phbWFsIFJlXQ0KPiBJIGRv bnQgdGhpbmsgd2UgaGF2ZSBiZSB2ZXJ5IHJpZ29yb3VzIGluIHRoZSBudW1iZXJpbmcgb2YgdGhl IGlzc3Vlcy4gSQ0KPiBhZ3JlZSB3aXRoIHlvdSBvbiB0aGUgZm9ybWF0aW5nIGZvciB0aGUgTWFy Y2ggMjB0aCByZXBvcnQuIFRoZSBsaXN0IGkNCj4gcHJlc2VudGVkIGlzIGEgc3VnZ2VzdGlvbiAt IGkgZG9udCB0aGluayBpdCBpcyB0b3RhbHkgY29tcGxldGUuIFlvdXINCj4gc3VnZ2VzdGlvbiBv biBob3cgdGhlIHJlc3VsdHMgZ2V0IHRhZ2dlZCBpcyBmaW5lLiBJIGRvbnQgdGhpbmsgaW4gdGhl DQo+IGZpbmFsIHJlcG9ydCB3ZSBoYXZlIHRvIHNheSBleGFjdGx5IGhvdyB0aGUgImNvbmdlc3Rp b24gIGNvbnRyb2wiIGlzIG1ldA0KPiByYXRoZXIgd2hhdCB3ZSBzaG91bGQgc2F5IGlzICJyZWFj aGVkIGFncmVlbWVudCIuIFRoZSBob3cgZ29lcyBvbiB0aGUNCj4gcHJvdG9jb2wgZHJhZnQuDQo+ IFsvSmFtYWwgUmVdDQo+DQo+ID4gMi4gVGhlIGVtYWlsIHN1YmplY3QgaXMgbWFya2VkIGFzIElz c3VlPG51bWJlcj46IDxpc3N1ZSBzdGF0ZW1lbnQ+LiBJbiB0aGlzIHdheSwgb3RoZXJzIGFyZSBl YXNpZXINCj4gPiB0byBmb2xsb3cgdGhlIGRpc2N1c3Npb24uIFdlIG1heSBhbHNvIHVzZSB0aGUg bnVtYmVyIGFzIHRoZSB3YXkgSmFtbCBkb2VzIHRvIGxpc3QgdGhlbSBpbiBhZHZhbmNlLCBJIGFt IGp1c3QNCj4gPiBhIGxpdHRsZSB3b3JyeSBpdCBtYXkgYmUgaGFyZCB0byBmaW5kIHRoZSBpc3N1 ZSBudW1iZXIgd2hlbiBpdCBoYXMgbm90IGJlIHBvc3RlZCBhcyBhbiBpbmRpcGVuZGFudCBlbWFp bC4NCj4NCj5bSmFtYWwgUmVdIA0KPiBJIGFncmVlIHdpdGggdGhpcyAoYW5kIG1hZGUgdGhlIHNh bWUgc3VnZ2VzdGlvbiBpbiBteSBvdGhlciBlbWFpbCkuIA0KPiBMZXRzIGhhdmUgaXNzdWVzIHdp dGggb24gc2VwYXJhdGUgZW1haWxzLiBZb3VyIHN1YmplY3Qgc3VnZ2VzdGlvbiBpcw0KPiBnb29k Lg0KPiBJZiBpIG1heSBhZGQgdG8gdGhpcyBzdWdnZXN0aW9uOiBXZSBwcm9wYmFibHkgc2hvdWxk IG5vdCBoYXZlIG1vcmUgdGhhbg0KPiAzLTQgc3ViamVjdHMgYmVpbmcgZGlzc2N1c3NlZCBjb25j dXJlbnRseS4gSSBhbSBwcmV0dHkgc3VyZSB3ZSBjYW4gbmFpbA0KPiB0aGUgZmlyc3QgMyB2ZXJ5 IHF1aWNrbHkuDQo+IFsvSmFtYWwgUmVdDQo+IA0KW1dlaW1pbmcgUmVdDQpUaGF0J3MgZmluZSwg YnV0IEkganVzdCB3YW50IHBvc3QgdGhlICJEb1MgcHJvdGVjdGlvbiBhbmQgY29uZ2VzdGlvbiBj b250cm9sIG1lY2hhbmlzbSIgdmVyeSBzb29uLCBmb3IgSSBoYXZlIA0KYWxyZWFkeSBmaW5pc2hl ZCB0aGUgZW1haWwuDQoNCkkgYWxzbyBjYW1lIHVwIHdpdGggYW4gaWRlYSB0aGF0IGEgc3ViLWlz c3VlIG1heSBiZSBvcGVuZWQgd2hlbiBzb21lIGlzc3VlIGRpc2N1c3Npb24gDQpoYXMgbGVhZCB0 byB0b28gY29tcGxleCBzdGF0ZSBvciBzb21lIHByb2JsZW0gaW4gdGhlIGlzc3VlIGlzIHJlbGF0 aXZlbHkgaW5kZXBlbmRlbnQuIA0KSSdtIGFmcmFpZCB0aGlzIG1heSBoYXBwZW4gd2hlbiBzb21l IHRvcGljcyBhcmUgcXVpdGUgd2lkZSBzcHJlYWQuIFRoZSBpc3N1ZSBtYXkgYmUgDQptYXJrZWQg YXMgSXNzdWUgWC5ZIC4NClsvV2VpbWluZyBSZV0NCg0KPiA+IDMuIEluIG9yZGVyIHRvIHNwZWVk IHRoZSBwcm9jZXNzLCBpbmRpdmlkdWFsIGNhbmRpZGF0ZSBwcm90b2NvbCB0ZWFtIGlzIHJlY29t bWVuZGVkIA0KPiA+IHRvIHNwZWFrIGluIHRoZSBzYW1lIHZvaWNlIHNvIHRoYXQgb3RoZXJzIGNh biBlYXNpbHkgdW5kZXJzdGFuZCBhbmQgaGF2ZSBsZXNzIGNvbmZ1c2lvbiANCj4gPiBvbiB0aGUg dGVhbSBhdHRpdHV0ZS4gRGlzY3Vzc2lvbnMgaW5zaWRlIGEgdGVhbSBhcmUgc3VwcG9zZWQgdG8g YmUgbWFkZSBwcml2YXRlbHkuIEJ5IHBsYXlpbmcgaW4gdGhpcyB3YXksIA0KPiA+IHdlIGp1c3Qg YXNzdW1lIHRoYXQgaG93IGNhbiBhIGNvbXByb21pc2UgYmUgbWFkZSBpZiB0aGUgdGVhbSBpbnNp ZGUgY2FuIG5vdCBtYWtlIGEgY29tcHJvbWlzZSBmaXJzdC4NCj4gPiBPZiBjb3Vyc2UsIHRoaXMg ZG9lcyBub3QgYXQgYWxsIG1lYW4gdG8gZXhjbHVkZSBpbmRpdmlkdWFscyAoaW5jbHVkaW5nIGlu ZGl2aWR1YWxzIGluIHNvbWUgdGVhbSkgdG8gcHJvdmlkZSBjb21tZW50cw0KPiA+IG9uIHRoZSBp c3N1ZXMuIEl0IGp1c3QgbWVhbnMgdG8gdHJ5IGJlc3QuIA0KPg0KPiBbSmFtYWwgUmVdIA0KPiBU aGUgd2F5IGkgbG9vayBhdCBpdCBpcyB3ZSBhcmUgbm93IGdvaW5nIHRvd2FyZHMgYSBuZXcgcHJv dG9jb2wuIA0KPiBMZXRzIHNoYXJlIGV4cGVyaWVuY2VzL29waW5pb25zIGV0YyBzbyB3ZSBjYW4g bW92ZSBmYXN0ZXIuDQo+IA0KPiBXZWltaW5nLCB3aHkgZG9udCB5b3UgdGhlIGZvbGxvd2luZyBz byB3ZSBjb3VsZCBtb3ZlIGZhc3RlcjoNCj4gMSkgYWRkIGFueSBtaXNzaW5nIGl0ZW1zIHRvIHRo YXQgbGlzdCBvciBmb3JtYXQgd2hpY2hldmVyIHdheSB5b3UNCj4gcHJlZmVyLg0KPiAyKSBTdGFy dCByZXNwb25kaW5nIHRvIHRoZSBpc3N1ZXMgcG9zdGVkLiBJc3N1ZSAwIChJRCBzZW1hbnRpY3Mp IGFuZA0KPiBpc3N1ZSAxIChwYWNrZXQgZW5jb2RpbmcpLiBIb3JtdXpkIGlzIHBsYW5uaW5nIHRv IHBvc3Qgb24gdGhlIHJlY2VudA0KPiBzdWJqZWN0IGRpc2N1c3Npb24gYXMgaXNzdWUgMi4NCj5b L0phbWFsIFJlXQ0KDQpbV2VpbWluZyBSZV0NCkkgYWJzb2x1dGVseSBkbyBub3QgbWVhbiB0byBw dXQgYW55IGxpbWl0IHRvIG9waW5pb24gc2hhcmluZy4gSSdtIHNvcnJ5IHRvIGhhdmUgbWlzZXhw cmVzc2VkIGl0Lg0KV2hhdCBteSBvcmlnaW5hbCB0aG91Z2h0IGlzIGp1c3QgSSB0aG91Z2h0IGEg dHJlZSBzdHJ1Y3R1cmUgbWF5IGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gYSBsaW5lYXIgc3RydWN0 dXJlLg0KDQpZZXMsIEknbSBnbGFkIHRvIGFkZCBzb21lIG1vcmUgaXRlbXMgdG8gZm9sbG93IHRo ZSBsaXN0IGFzOg0KDQoxMCkgSW4tcHJvdG9jb2wgbWVjaGFuaXNtIGZvciByZWxpYWJpbGl0eQ0K MTEpIFN1cHBvcnQgZm9yIHZlbmRvciBmdW5jdGlvbnMNCjEyKSBTdXBwb3J0IGZvciBuZXR3b3Jr IG1hbmFnZW1lbnQgdG9vbHMNCjEzKSBNZXNzYWdlIG9yZ2FuaXppbmcNCjE0KSBDb25mbGljdCBj aGVjayB3aXRoIGN1cnJlbnQgRkUgbW9kZWwNCg0KRm9yIHRoZSBJc3N1ZSAxMCwgSSdtIGp1c3Qg bm90IHN1cmUgaWYgdGhlIHJlbGlhYmlsaXR5IGlzc3VlIChJc3N1ZSA1KSB5b3UgbGlzdGVkIGlu Y2x1ZGUgdGhpcy4gDQpJdCdzIGFsc28gZmluZSB0byBoYXZlIHRoaXMgYXMgYSBzdWItaXNzdWUs IGJ1dCBhbnl3YXkgc2hvdWxkIGJlIHNwZWNpYWxseSBhZGRyZXNzZWQgYmVjYXVzZSBpdCBpcyBh IGJpZyBpc3N1ZS4gDQoNCkknZCBsaWtlIHRvIGFkZCBzb21lIG1vcmUsIGJ1dCBJJ20gYWZyYWlk IEkgaGF2ZSB0byBnbyB0byBiZWQgbm93LCBpdCdzIGFscmVhZHkgMidjbG9jayBpbiB0aGUgbW9y bmluZy4gfm9+IA0KWy9XZWltaW5nIFJlXQ0KDQpDaGVlcnMsDQpXZWltaW5nDQoNCg== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 13:34:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29620 for ; Sat, 6 Mar 2004 13:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgcQ-0002Gv-Fh for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 13:33:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26IXorq008727 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 13:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgcQ-0002Gg-Bl for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 13:33:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29610 for ; Sat, 6 Mar 2004 13:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzgcO-0001ON-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:33:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzgbV-0001G5-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:32:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azgae-00016k-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 13:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azgaf-0002BY-QO; Sat, 06 Mar 2004 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzgaS-0002BD-04 for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 13:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29540 for ; Sat, 6 Mar 2004 13:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzgaQ-00015o-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzgZW-0000y0-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:30:51 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzgYt-0000pm-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 13:30:11 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 7 Mar 2004 02:41:30 +0800 Message-ID: <075c01c403a8$c8b3eb80$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> <4048A7EB.2030808@alcatel.com> <1078516549.1035.75.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: base64 Subject: [Forces-protocol] Issue 4: DoS protection and congestion control mechanism Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 02:28:12 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpIaSBKYW1hbCwgYW5kIEFsZXgsICANCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBr aW5kIHN1Z2dlc3Rpb24gZm9yIHRoZSBpbXBsZW1lbnRhdGlvbi4gDQpCdXQgd2hhdCBJIHNob3Vs ZCBjbGFyaWZ5IGlzIHRoYXQgdGhlIGV4cGVyaW1lbnQgd2UgZG8gYXJlIGFsbCANCmluIGEgc2l0 dWF0aW9uIHRoYXQgaXQgZm9sbG93cyB0aGUgRm9yQ0VTIHByb3RvY29sLiBUaGlzIG1lYW5zLCBl Lm0uLCANCmZvciB0aGUgVURQIGFuZCBUQ1Agc2VwYXJhdGlvbiBjaGFubmVsIGV4cGVyaW1lbnRz LCB3ZSBqdXN0IGFzc3VtZSB0aGF0DQpGb3JDRVMgdXNlIHRoZSBzZXBhcmF0ZSBjaGFubmVsIGFu ZCB0aGVuIHdlIGFjdHVhbGx5IHByb2R1Y2UgcmVkaXJlY3Rpb24gDQpwYWNrZXRzIGZyb20gb3V0 c2lkZSBvZiB0aGUgRkUgYW5kIHRoZSBGRSBpdHNlbGYgcHJvZHVjZXMgQ29udHJvbCBwYWNrZXRz DQp0byBwYXNzIHRocm91Z2ggaXQuIEl0J3MgdHJ1ZSB3ZSBkbyBub3QgZ28gZGVlcCBpbnRvIHRo ZSB0aHJlYWQgc2NoZWR1bGluZw0Kb3IgZXZlbiBETUEgY2hhbm5lbCBtYW5hZ2VtZW50IGluc3Rl YWQgd2UganVzdCB1c2UgZGVmYXVsdCBzdHJhdGVneSB3aXRoIA0KZXF1YWwgcHJpb3JpdHkgZm9y IHRoZSB0d28gdGhyZWFkcywgYmVjYXVzZSB3ZSB0aGluayBldmVuIGlmIHdlIG5lZWQgdG8gZG8N CnRoaXMsIGl0IHNob3VsZCBiZSBjb250cm9sbGVkIGJ5IEZvckNFUyBDRSB2aWEgc2V0dGluZyBz b21lIEZFIGF0dHJpYnV0ZSAobGlrZQ0KRGF2aWQgc2FpZCBzb21lIFFvUyBoaW50cykgdG8gdGhl IEZFLiBUaGlzIGhhcyBhbHNvIHByb3ZlbiB0aGF0IGEga2luZCBvZiBtZWNoYW5pc20NCmxpa2Ug RkUgYXR0cmlidXRlIGZvciBEb1MgcHJvdGVjdGlvbiBwb2xpY3kgc2hvdWQgYmUgaW5jbHVkZWQg aW4gRm9yQ0VTIHByb3RvY29sLiANCg0KSSBiYXNpY2FsbHkgZm9sbG93cyBKYW1hbCdzIGlzc3Vl IGxpc3Qgb24gdGhlIGNvbmdlc3Rpb24gY29udHJvbCBpc3N1ZSwgYnV0IGhhdmUgdXNlZA0KdGhp cyAiRG9TIHByb3RlY3Rpb24gY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMiIGFzIHRoZSBu YW1lLCBJIHRoaW5rIHRoZXNlIHR3byBpc3N1ZXMNCmhhdmUgYmVlbiBxdWl0ZSB0aWdodGx5IGNv bm5lY3RlZC4gDQoNClRvIGVhc2UgdGhlIGRpc2N1c3Npb24sIEkganVzdCB3YW50IHRvIHN1bW1h cml6ZSBvdXIgdGhvdWdocyB0b3dhcmRzIHRoZSBpc3N1ZSBiYXNlZCBvbiANCnJlY2VudCBkaXNj dXNzaW9ucyBhcyB3ZWxsIGFzIG9uIGV4cGVyaW1lbnRzIGFzIGJlbG93Og0KDQoxLiBBZ3JlZSB0 byB0aGUgaWRlYSB0byBkaXN0aW5ndWlzaCBwYWNrZXRzIGJ5IERhdGEgcGFja2V0cyBhbmQgQ29u dHJvbCBwYWNrZXRzLCB3aGVyZSANCkRhdGEgcGFja2V0cyBhcmUgYWN0dWFsbHkgcmVkaXJlY3Rl ZCBwYWNrZXRzIGJ5IEZFIHRvIENFLCBhbmQgdGhlIENvbnRyb2wgcGFja2V0cyBhcmUgYWN0dWFs bHkgRm9yQ0VTIHByb3RvY29sDQptZXNzYWdlcyBnZW5lcmF0ZWQgYnkgRkUgYW5kIHNob3VsZCBi ZSB0cmFuc3BvcnRlZCB0byBDRS4NCg0KMi4gVG8gcHJvdGVjdCBEb1MgYW5kIGNvbnRyb2wgY29u Z2VzdGlvbiBiZXR0ZXIsIGFuIEZFIGF0dHJpYnV0ZXMgYXMgRkUgRG9TIHByb3RlY3Rpb24gYW5k IGNvbmdlc3Rpb24NCmNvbnRyb2wgcG9saWN5IHNob3VsZCBiZSBpbmNsdWRlZCBpbiBGb3JDRVMg cHJvdG9jb2wuIFRoaXMgYWxzbyBtZWFucyBzb21lIGtpbmQgb2Ygc2NoZWR1bGluZyBzdHJhdGVn aWVzDQpzaG91bGQgYmUgYXBwbGllZCB0byBGRSBhcyB3ZWxsIGFzIHJhdGUgbGltaXRlcnMgdG8g cHJldmVudCBEb1MgYW5kIGNvbnRyb2wgY29uZ2VzdGlvbi4gDQoNCjMuIFdoZXRoZXIgc3VjaCBj b250cm9sIHNob3VsZCBiZSBpbXBsZW1lbnRlZCBhdCBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIgb3Ig YXQgT1MgbGF5ZXIsIHRoZSBpbmRpdmlkdWFsIHByb3MgYW5kIGNvbnMNCnNob3VsZCBiZSBmdXJ0 aGVyIGRpc2N1c3NlZC4NCg0KNC4gQSBzZXBhcmF0aW9uIGFwcGxpZWQgYXQgdHJhbnNwb3J0IGxh eWVyIHRvIHRoZSB0d28ga2luZHMgb2YgcGFja2V0cyBoYXMgbGl0dGxlIGVmZmVjdCB0byBwcm90 ZWN0IERvUy4NCldoZXRoZXIgdG8gYXBwbHkgaXQgc2hvdWxkIG1haW5seSBkZXBlbmRzIG9uIG90 aGVyIHJlYXNvbmFibGUgcmVhc29ucy4gSWYgdGhlIHJlYXNvbnMgYXJlIGVub3VnaCwgd2UgYXJl IGdsYWQNCnRvIHNlZSBpdCBpbiB0aGUgcHJvdG9jb2wuIFRoaXMgaXRlbSBtYXkgc3BlY2lmaWNh bGx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgbXVsdGljaGFubmVsIGlzc3VlIChJc3N1ZSAyKS4gDQoN CjUuIEEgY2FzZSBpbiB3aGljaCB0aGUgRGF0YSBwYWNrZXRzIG1heSBiZSBibG9ja2VkIGJ5IENv bnRyb2wgcGFja2V0cyBvd2luZyB0byBpbXByb3BlciBjb25nZXN0aW9uIGNvbnRyb2wNCnNldHVw LCBhbmQgdGhlIGhhcm0gb2Ygc3VjaCBjYXNlIChkZWxheXMgdGhlIHBhY2t0ZXMgZGVsaXZlcnkp IG1heSBiZSBhZGRyZXNzZWQgaW4gdGhlIHByb3RvY29sLiANCg0KT3RoZXIgaXRlbXMgZm9yIHdo aWNoIHdlIGp1c3Qgd2FudCB0byByYWlzZSBkaXNjdXNzaW9uIGluIHRoaXMgSXNzdWUgNCBhcmUg YXM6DQoNCjYuIFRoZSBEb1MgYWxlcnQgd2F5LiBBY3R1YWxseSBHUk1QIGhhcyB1c2VkIGFuIEZF IGF0dHJpYnV0ZSBhcyAiRkUgRG9TIGFsZXJ0IHBvbGljeSIgYW5kIEZFIGV2ZW50IGFzICJGRSBE b1MgYWxlcnQgZXZlbnQiDQpmb3IgdGhpcyBwdXJwb3NlLiBXZSBqdXN0IHN1Z2dlc3QgdG8gdXNl IHRoaXMgdXNlZnVsIG1lY2hhbmlzbS4NCg0KNy4gUmF0ZSBjb250cm9sIGZvciBDb250cm9sIHBh Y2tldHMgYXMgZGVmaW5lZCBhYm92ZSBtYXkgY2FuIG9ubHkgYmUgbWFuaXB1bGF0ZWQgYnkgRm9y Q0VTIHByb3RvY29scyBpbnN0ZWFkIGJ5IExGQnMNCmRlZmluZWQgYnkgRkUgbW9kZWxzLCBmb3Ig aXQgc2VlbXMgYmUgb3V0IG9mIHRoZSBzY29wZSBvZiBGRSBtb2RlbHMgYmVjYXVzZSB0aGUgcGFj a3RlcyBwYXNzIGl0IGFyZSBGb3JDRVMgcHJvdG9jb2wgDQptZXNzYWdlcyBhbmQgaXQgc2hvdWxk IGJlIGxhdW5jaGVkIGJlZm9yZSB0aGUgRkUgbW9kZWwgbWVjaGFuaXNtIGNhbiB3b3JrLg0KDQpU aGUgcHJpb3JpdGl6YXRpb24gYW5kIGFzc29jaWF0ZWQgcHJpb3JpdHkgZGVmaW5pdGlvbiBpbiBG b3JDRVMgcHJvdG9jb2wgc2VlbXMgaGF2ZSBhIGxvdCBvZiBjb25mdXNpb25zIGFtb25nIHRoZSB0 aHJlZQ0KY2FuZGlkYXRlcyBhbmQgYW1vbmcgdGhlIGRpc2N1c3Npb25zLiBJIHdvdWxkIHN1Z2dl c3QgdG8gaGF2ZSB0aGlzIGFzIGFub3RoZXIgc3BlY2lhbCBpc3N1ZSBmb3IgbW9yZSBkaXNjdXNz aW9uLiANCg0KWW91cnMsDQpXZWltaW5nDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4NClRvOiA8YWxleC5h dWR1QGFsY2F0ZWwuY29tPg0KQ2M6ICJXYW5nLFdlaW1pbmciIDx3bXdhbmdAbWFpbC5oemljLmVk dS5jbj47ICJQdXR6b2x1LCBEYXZpZCIgPGRhdmlkLnB1dHpvbHVAaW50ZWwuY29tPjsgPGZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwNiwgMjAwNCAzOjU1 IEFNDQpTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gQ29tbWVudHMgZnJvbSBjaGF0IHdp dGggQURzDQoNCg0KPiANCj4gSSB0aGluayB0aGVyZXMgYSBsb3Qgb2YgaW1wbGVtZW50YXRpb24g ZGV0YWlscyBiZWluZyB0b3NzZWQgYXJvdW5kDQo+IGFzIG9wcG9zZWQgdG8gd2hhdCB0aGUgcHJv dG9jb2wgbmVlZHMuIA0KPiBXZWltaW5nLCBpIGFwb2xvZ2l6ZSBmb3Igbm90IGhhdmluZyBwYWlk IGNsb3NlIHNjcnV0aW55IHRvIEdSTVBzIGlzc3VlDQo+IG9mIERPUyBpbiB5b3UgZHJhZnQ7IGhv d2V2ZXIgbG9va2luZyBhdCB0aGUgc2xpZGVzIExpZ2FuZyBwcmVzZW50ZWQgaXQNCj4gc2VlbXMg dG8gbWUgdGhlIGlzc3VlIG1heWJlIGltcGxlbWVudGF0aW9uLiBJIHRob3VnaHQgRGF2aWQgZGlk IGEgZ29vZA0KPiBqb2IgZXhwbGFpbmluZyB0aGUgbGluayBhc3BlY3Qgb2YgdGhpbmdzLiBJIGFj dHVhbGx5IGFncmVlIHdpdGggeW91IHRoYXQNCj4gYSBzaW5nbGUgbGluayBtYXkgYmUgaW5zdWZm aWNpZW50IHRvIHByZXZlbnQgYSBET1MuIEluIHBhcnRpY3VsYXIgdGhpcw0KPiBpc3N1ZSBnZXRz IGV4YWNlYmVyYXRlZCBpZiB0aGUgRE9TIGlzIGluZmFjdCBmaWxsaW5nIHRoZSBwaXBlLiANCj4g VGhlIHN1Z2dlc3Rpb24gd2FzIGlmIHlvdSBjb3VsZCBwcmlvcml0aXplIGJlZm9yZSB0aGUgcGFj a2V0cyBoaXQgdGhlDQo+IE9TLCBzdWNoIGFzIHZpYSBkaWZmZXJlbnQgRE1BIGNoYW5uZWxzLCB0 aGluZ3Mgd2lsbCBpbXByb3ZlIChiZWNhdXNlIHRoZQ0KPiBET1MgaXMgbGltaXRlZCB0byBhdHRh Y2tpbmcgdGhlIHBoeXNpY2FsIGxpbmspLiBUaGlzIGlzIG9mIGNvdXJzZSBvbmx5DQo+IHRydWUg dW50aWwgc29tZW9uZSBzdGFydHMgRE9TaW5nIHdpdGggaGlnaCBwcmlvcml0eSBwYWNrZXRzIGFu ZCBmaWxsaW5nDQo+IHRoYXQgaGlnaCBwcmlvIERNQSBjaGFubmVsLiBUaGUgcHJvYmxlbSBpcyBu b3Qgc29sdmFibGUgaWYgYWxsIERNQQ0KPiBjaGFubmVscyByZWdhcmRsZXNzIG9mIHByaW9yaXR5 IGFyZSBiZWluZyBET1NlZC4gVGhpcyBhbHNvIGFwcGxpZXMgdG8NCj4gdGhlIGR1YWwgKHBoeXNp Y2FsKSBsaW5rcy4gaS5lIHlvdSBjYW50IHByb3RlY3QgaWYgYWxsIHBoeXNpY2FsIGxpbmtzDQo+ IGFyZSBiZWluZyBhdHRhY2tlZC4gVGhlIHNvbHV0aW9uIGlzIHRvIGhhdmUgYSB0cnVzdGVkIHZz IG5vbiB0cnVzdGVkDQo+IGxpbmsuDQo+IEFuZCBpZiB5b3UgaGF2ZSB0cnVzdGVkIHNvdXJjZXMs IHRoZW4gY2FuIGRvIGEgdmVyeSBnb29kIGpvYiBhZGRyZXNzaW5nDQo+IHRoYXQgaXNzdWUgd2l0 aCB0aGUgbXVsdGlwbGUgRE1BIGNoYW5uZWxzLg0KPiANCj4gT25jZSB0aGUgcGFja2V0IGhpdHMg dGhlIE9TLCB5b3UgbmVlZCBub3Qgb25seSB0byBwcm90ZWN0IGFnYWluc3QNCj4gYmFuZHdpZHRo LCBidXQgYWxzbyBhZ2FpbnN0IENQVSh0aG9ydWdoIHRocmVhZCBwcmlvcml0aXphdGlvbiBhbGV4 IGlzDQo+IHN1Z2dlc3RpbmcpIGFuZCBSQU0gYWJ1c2UuIGkuZSB5b3UgbmVlZCB0byBwcm90ZWN0 IGFsbCB0aG9zZSB0aHJlZQ0KPiByZXNvdXJjZXMgYnkgcHJvdmlkaW5nIFFPUyBmb3IgdGhlbS4g U29tZSBPU2VzIGhlbHAgeW91IG1vcmUgdGhhbiBvdGhlcnMNCj4gdG8gYWNoaWV2ZSB0aGlzLg0K PiANCj4gU28gZmFyIGFsbCB0aGUgYWJvdmUgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUuIE5v Ym9keSB3aWxsIHRlYWNoIHlvdQ0KPiB0aGVzZSB0cmlja3MsIGJ1dCBpZiB5b3Ugd2FudCB0byBo YXZlIGEgcm9idXN0IGltcGxlbWVudGF0aW9uLCB5b3Ugd2lsbA0KPiBuZWVkIHRvIGRvIHRoZSBh Ym92ZS4gVGhpcyBpcyByZWdhcmRsZXNzIG9mIHRoZSBwcm90b2NvbCAoT1NQRiwgQkdQDQo+IGV0 YykuIGkuZSBoYXMgbm90aGluZyB0byBkbyB3aXRoIEZvcmNlcy4NCj4gDQo+IFRoZSBvbmx5IHBy b3RvY29sL2hlYWRlciBzZW1hbnRpYyB0aGF0IGlzIHZhbHVhYmxlIGlzIHByaW9yaXRpemF0aW9u DQo+IGJpdCB3aGljaCBhcmUgc3BlY2lmaWMgdG8gRm9yY2VzLiBJcyB0aGlzIHdoYXQgeW91IGFy ZSByZWZlcmluZyB0bz8NCj4gSSBiZWxpZXZlIChJIGNvdWxkIGJlIG1pc3Rha2VuKSBhbGwgdGhy ZWUgcHJvcG9zYWxzIGhhdmUgdGhpcy4gVGhpcyBpcw0KPiB2YWx1YWJsZS4gSG93ZXZlciwgdGhp cyBzaG91bGQgcHJvYmFibHkgYmUgb3B0aW9uYWwuIEl0cyBlYXNpZXINCj4gdG8gdXNlIHdoYXRl dmVyIHRoZSB1bmRlcmx5aW5nIG1lY2hhbmlzbSBwcm92aWRlcyAoODAyLjFwLCBkaWZmc2VydiBl dGMpDQo+IFRvIHF1b3RlIGZyb20gbmV0bGluazIgZHJhZnQ6DQo+IA0KPiAiICBQcmlvcml0aXph dGlvbiBpcyBhbiBvcnRob2dvbmFsIG1lY2hhbmlzbSB0byByZWxpYWJpbGl0eS4gIFdoZW4gYQ0K PiAgICBub2RlIHJ1bnMgb3V0IG9mIHJlc291cmNlcywgYSBtZXNzYWdlIHNlbnQgd2l0aCBhIGhp Z2hlciBwcmlvcml0eQ0KPiAgICB3aWxsIGdldCBwcmVmZXJlbnRpYWwgdHJlYXRtZW50LiAgRm9y IGluc3RhbmNlLCBpZiBhIEZFIGhhcyBvbmx5DQo+ICAgIGVub3VnaCBtZW1vcnkgdG8gYWxsb2Nh dGUgb25lIG1lc3NhZ2UgaW4gcmVzcG9uc2UgdG8gYSBtZXNzYWdlIGZyb20NCj4gICAgdGhlIENF IGFuZCBpdCBoYXMgdG8gY2hvb3NlIGJldHdlZW4gb25lIG9mIHR3byBtZXNzYWdlcyB0byByZXNw b25kDQo+ICAgIHRvLCB0aGVuIGl0IHdpbGwgdXNlIHRoYXQgbWVtb3J5IGZvciB0aGUgcmVxdWVz dCB3aGljaCB3YXMgc2VudCB3aXRoDQo+ICAgIHRoZSBoaWdoZXIgcHJpb3JpdHkuICBUaGlzIGFs c28gYXBwbGllcyB0byBvdGhlciByZXNvdXJjZXMgc3VjaCBhcw0KPiAgICBjb21wdXRpbmcgY3lj bGVzIA0KPiAiDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA0KPiBPbiBGcmksIDIwMDQtMDMt MDUgYXQgMTE6MTYsIEFsZXggQXVkdSB3cm90ZToNCj4gPiBIZWxsbyBXZWltaW5nLA0KPiA+IA0K PiA+IEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoZSByZXN1bHQgeW91IGdvdCBmcm9tIHlvdXIgZXhw ZXJpbWVudCBjb3VsZCBiZSANCj4gPiBtdWNoIG1vcmUNCj4gPiBpbXByb3ZlZCBpZiB5b3UgYWxs b2NhdGVkIHR3byBzZXBhcmF0ZSBxdWV1ZXMsIG9uZSBmb3IgQyBhbmQgdGhlIG90aGVyIA0KPiA+ IGZvciBEDQo+ID4gZGF0YS4gVGhlbiBjcmVhdGUgdHdvIHNlcGFyYXRlIHRocmVhZHMgdG8gcHJv Y2VzcyB0aGUgcXVldWVzIChvbmUgZm9yIGVhY2gpLg0KPiA+IEdpdmUgYm90aCB0aHJlYWRzIGVx dWFsIHByaW9yaXR5IGFuZCB5b3Ugc2hvdWxkIGJlIGZpbmUuIElmIHlvdSB3YW50IHRvIHNrZXcN Cj4gPiB0aGluZ3MgaW4gZmF2b3Igb2YgdGhlIEMsIHRoZW4geW91IGNhbiBhZGp1c3QgcHJpb3Jp dHkgYWNjb3JkaW5nbHkuDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 16:42:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06301 for ; Sat, 6 Mar 2004 16:42:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjYP-0006EM-OA for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 16:41:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26LfrKd023946 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 16:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjYP-0006E9-Hx for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 16:41:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06287 for ; Sat, 6 Mar 2004 16:41:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzjYN-0005Oz-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 16:41:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzjXV-0005GP-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 16:40:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzjWb-00057E-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 16:40:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjWc-0006C4-Os; Sat, 06 Mar 2004 16:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjWS-0006BF-Fx for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 16:39:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06175 for ; Sat, 6 Mar 2004 16:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzjWQ-00055J-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 16:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzjVS-0004wr-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 16:38:50 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzjUX-0004h2-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 16:37:53 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i26LdQAp032337; Sat, 6 Mar 2004 21:39:26 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i26Ld80i015717; Sat, 6 Mar 2004 21:39:09 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030613372121699 ; Sat, 06 Mar 2004 13:37:21 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 13: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> Thread-Topic: Issue 0: Application addressing Thread-Index: AcQCMliMCmKVNweTREi0SbSJJd5RLQBjmX7g From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 06 Mar 2004 21:37:21.0549 (UTC) FILETIME=[34F983D0:01C403C3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: Issue 0: Application addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 13:37:20 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alright, here are my views on this issue/topic... Terminology: Src ID, Dest ID vs CEID, FEID I don't like to get stuck up on terminology, so I will go with whatever the majority likes on this as long as we agree on the semantics. Semantics: This is where we differ a bit. As our terminology suggests, these can be individual FE, group of FE, all FEs and same applies for CEs. However, this field does not represent LFBs. LFB ID is something which has to be assigned by FEs for representing static topologies, and may be assigned by FEs for dynamic topologies (I think this is also what the Model team concluded on this issue, but not 100% sure). In contrast, FE IDs is something assigned by the CE as Jamal suggested. Moreover LFB ID is not something which is needed in all ForCES messages, hence does not need to be in the common header. It will be part of the TLV defined for carrying configuration/control/event messages. Length: Acc to the scalability requirements, we need to support hundreds of FEs (<=3D1000) and even much less no of CEs (<=3D100). So 10 bits = would be enough for FEID/Dest ID and 7 bits for CEID/ Src ID. However, in order to accommodate even higher requirements and have the fields 32-bit aligned we used 16 bits for FEID, CEID. If there is a good technical reason for requiring 32-bits I would be willing to compromise on this. However, one thing to keep in mind is that this is the common header so every byte we add to it will be added to all the messages, so it would be a good design principle to be a bit stingy here. If it was part of an optional TLV, we wouldn't care as much. Let me know what other views are on this topic. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, March 04, 2004 1:48 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Issue 0: Application addressing Hormuzd, heres some text for application addressing ---- Source and Destination IDs: These are application level identifiers. They could be used to address the following: - an LFB on the FE, - a set of LFBs on an FE - a set of LFBs on different FEs=20 - proxies for LFBs, - proxies for control application in the form on the CEs,=20 - the FE, - a set of FEs - all FEs - the CE. - a set of CEs - all CEs The above shows need for having the ID being able to be IDed as unicast, broadcast or multicast. For clarity, i could create a diagram of what we used. I will post the header i posted earlier next. Or maybe we should=20 stick to resolving this first. Hopefully we can get to a good way to beat the several issues, i am doing this to hopefuly come to a style that we can use to beat the issues. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 17:43:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07994 for ; Sat, 6 Mar 2004 17:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkVT-0001Uz-3w for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 17:42:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26MgtJe005755 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 17:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkVS-0001Uj-UT for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 17:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07980 for ; Sat, 6 Mar 2004 17:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzkVQ-0006fD-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzkUT-0006WR-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzkTa-0006NQ-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkTc-0001Pf-Oy; Sat, 06 Mar 2004 17:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkT9-0001Ni-1j for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 17:40:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07877 for ; Sat, 6 Mar 2004 17:40:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzkT6-0006Et-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzkSE-00061B-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:39:35 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzkRC-0005ez-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:38:31 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i26Me4Ap014964; Sat, 6 Mar 2004 22:40:04 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i26MWFj3015487; Sat, 6 Mar 2004 22:32:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030614375724604 ; Sat, 06 Mar 2004 14:37:57 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 14:37:57 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] issue 1: packet encoding X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQC/aSnyVTMFJXrQJSONhAioUGtMgAxcRZQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 06 Mar 2004 22:37:57.0475 (UTC) FILETIME=[AC27CB30:01C403CB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 14:37:57 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, Before I give my comments, I would like to say that I appreciate the fact that you did not copy/paste the netlink header from your draft over here! That is a very positive sign to me, lets try to stick to the best technical solution rather than pushing our own protocol implementations. That's the best way to make progress on this merger!! =20 Here are my views on this issue, particularly the common header: Command: Agree this is needed. We think 8-12 bits will be more than sufficient for this depending on whether it is subdivided. We have sub-divided this field into Class/type...this is an OO approach, seemed pretty neat. However, I am personally fine with having a single field for this, no problem with that. Length: Agree needed and agree with size. xIDs: Agree this is needed. More detailed comments on length, semantics in my previous email. Sequence No: Agree needed and agree with size. Flags/Priority: We need 2-3 bits for priority in every message. I don't think we need any other flags in all messages. Typeid: This is one field I don't think is needed in all messages. I am not sure why this is needed at all cause, we will be using the Model and LFB IDs to address processing functional blocks on the FEs. Missing field: Version (2-4 bits): This is present in all protocols, and is generally included in most IETF protocols. Its usually the 1st field. General comment: Lets try to be stingy on the size of the header and its fields since this will be included in all ForCES messages. Jamal's text....... The Forces Message Header:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | typeid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ XML encoding: XML encoding may be useful in capabilities definition (i.e slow path) but not in the configuration of data path tables. This is because of its nature to require higher bandwith and CPU computational needs. HK Comment: I think we should stick with a single encoding type, namely TLV. This is also what some of the model team folks have mentioned before for the protocol. Is there a reason why capabilities cannot be expressed using TLVs? Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Friday, March 05, 2004 2:00 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] issue 1: packet encoding Attached is text for stimulating discussion on issue 1. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 17:44:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08029 for ; Sat, 6 Mar 2004 17:44:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkWS-0001W1-QD for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 17:43:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26MhuJP005819 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 17:43:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkWS-0001Vm-Fw for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 17:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08016 for ; Sat, 6 Mar 2004 17:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzkWQ-0006np-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:43:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzkVT-0006fk-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:43:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzkUZ-0006XC-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 17:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkUb-0001SN-CU; Sat, 06 Mar 2004 17:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzkUV-0001S7-Ke for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 17:41:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07954 for ; Sat, 6 Mar 2004 17:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzkUS-0006WM-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:41:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzkTY-0006NL-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:41:00 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzkSd-00060C-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 17:39:59 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i26MfLAp015244; Sat, 6 Mar 2004 22:41:21 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i26MXcix015770; Sat, 6 Mar 2004 22:33:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030614391524655 ; Sat, 06 Mar 2004 14:39:15 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 14:39:16 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C403CB.DADEE900" Subject: RE: [Forces-protocol] Comments from chat with ADs X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E054214@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQC+I5BOuQqHbX/Ss23wKMcf638eAAJOAvQ From: "Khosravi, Hormuzd M" To: Cc: "Deleganes, Ellen M" , X-OriginalArrivalTime: 06 Mar 2004 22:39:16.0127 (UTC) FILETIME=[DB0922F0:01C403CB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 14:39:15 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C403CB.DADEE900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand your concern and definitely agree that we will have to resolve the issues of reliability/CC, security (may be) for multicast before deciding to use it. I was assuming this will be done. How we acheive this is a separate discussion... using RMT, TIPC, others, etc...we can have that discussion after resolving the other topics that Jamal has raised. =20 Regards Hormuzd -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Friday, March 05, 2004 1:26 PM To: Khosravi, Hormuzd M Cc: Deleganes, Ellen M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs I still maintain that MULTICAST is best left at SHOULD implement strength. Why? A lot of issues are still unresolved concerning multicast reliabililty, security, etc., unless we want to define an application-layer method to resolve issues like synchronization, packet-loss, ACK/NACK implosion, etc. =20 Alex. Khosravi, Hormuzd M wrote: Yes Ellen, that was my intent. =20 Thanks for the clarification, Hormuzd =20 -----Original Message----- From: Deleganes, Ellen M=20 Sent: Friday, March 05, 2004 12:19 PM To: Khosravi, Hormuzd M; alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs =20 =20 I think what Hormuzd is saying (Hormudz can correct me if I am wrong) is that even if Multicast is optional, those procedures that noted in Hormudz's email should be described in the ForCES protocol spec. That is, if a ForCES protocol implementation supports multicast, then it MUST implement it in the manner described in the ForCES protocol specification. Otherwise, ForCES implementations using multicast will probably not interoperate. =20 Whether or not implementing multicast for transports that support multicast is a requirement is a separate question.=20 =20 Regards, Ellen =20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Thursday, March 04, 2004 6:12 PM To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs =20 Hi Alex, =20 In general, I prefer using language such as MUST so that there is no confusion or interop issues in the protocol implementations. However, you raise a reasonable point and let me tell you my thoughts on this. We will definitely need Unicast between FEs and CEs at the minimum in the protocol. In addition, if the interconnect technology supports Multicast and there is a case where it is useful to the application (such as downloading IPv4 routes) we must allow it as well without breaking interop. In order to do that, we will need specific procedures in the protocol that will allow the CE and FE to negotiate on using multicast dynamically at run-time (say during the binding or joining phase between the CE and FE) and also associate different multicast groups with LFBs. We will also need to define how Reliability/CC etc. will be provided for multicast...may be using RMT, TIPC, etc. (?) If we do this correctly, then applications will be able to use both unicast and multicast without any interop issues. =20 Let me know what you guys think about this. =20 Regards Hormuzd =20 -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Thursday, March 04, 2004 1:22 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs =20 =20 Hormuzd, =20 Why should multicast be "mandated for certain cases where it will be=20 useful" if there is a simpler, more robust way to do the same thing? I'll say we don't=20 mandate this. We can make it a "SHOULD" strength, not a "MUST". We mandate UNICAST and make MULTICAST optional. Any issues with this? =20 Regards, Alex. =20 =20 Khosravi, Hormuzd M wrote: =20 =20 Hi David =20 Your summary below of the discussion with Ads on the different issues seems like very reasonable approaches to me. =20 I agree that it will be a good idea to present transport alternatives =20 at =20 IP and non-IP level for the ForCES protocol. We can mandate one or more transport for IP and one or more transport for non-IP, this way the interoperability requirements are met and at the same time, the in-box, out of box scenarios are met. =20 Also, agree with having multiple channels/connections to differentiate =20 C =20 & D traffic between CEs and FEs. On the unicast/multicast topic, dual mandatory approach again seems a good idea to support interoperability. The one thing that I would like to point out is that for any ForCES protocol implementation to work, unicast will definitely be required at the minimum. One could also mandate using multicast for certain cases where it will be useful (e.g. IPv4/config table download), if it is supported by the interconnect as you stated. But just multicast without unicast will not work, atleast not efficiently. =20 Regards Hormuzd =20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Tuesday, March 02, 2004 5:06 AM To: forces-protocol@ietf.org Subject: [Forces-protocol] Comments from chat with ADs =20 Patrick and I spent about 90 minutes last night chatting with Bill and Alex about ForCES, with maybe half of the time on the protocol. In the conversations with them, along with some follow-up chats I had with Allison Mankin, the following topics where covered: multiple=20 channels, multicast/unicast, and congestion=20 control. Below is what I recall from memory=20 (Patrick please correct me/elaborate as needed :) =20 =20 =20 Multiple channels: =20 =20 I discussed the interference issue that=20 was identified by the GRMP team. Bill & Alex agreed that many OS implementations can have an interference property (i.e. where two different connections will have queuing interference lower in the networking stack in the OS). So it is necessary to make sure when implementing a FE (or CE probably as well) that this is taken into account. Methods of doing that include: * Manually queuing packets (i.e. feed OS few enough packets that it cannot get into trouble - although you pay a performance price for that, in that fine grained scheduling takes cycles) * Indicating to the OS to treat flows differently -=20 some real-time OS will let you do this, that is they are implemented to internally retain QoS between flows. However, it was also mentioned that intra-FE=20 interference is only one kind of interference. Good FE implementation (e.g. by manually queuing above the OS) helps to fix intra-FE interference, but it does not solve inter-FE interference. That is, if all (C & D) packets are always on the same connection, that makes it impossible on the wire to differentiate them from one another. Imagine you have a bunch of FEs with some of them being subject to DOS attack for D packets, and you want to query one of the FEs for statistics. It would be good to have some way of ensuring the C packets (or any high priority packets - OSPF HELLO maybe) get through. Separate channels (as Jamal indicated, don't even have to be C & D) makes this possible. Putting everything on one channel makes it impossible to deal with inter-FE interference in a differentiated fashion.=20 =20 =20 Multicast & Unicast: =20 =20 The discussion on this started out with a discussion of the IETF protocol design BKM that options can ruin compatibility. That is, if there are four ways to implement something, all optional, then you can have client 1 implement A & B, and client 2 implement C & D, and even though both clients are 100% compliant, they cannot talk to one another. Better to say all clients must implement A and make B, C, and D optional, so that way you know that all implementations will be able to=20 at least talk. =20 Patrick & I pushed on this a bit, explaining that we actually had potentially (at least) two different environments - very close environments where multicast support could be present in the interconnect, and=20 not-as-close environments (and some close environments as well) where multicast was not available. =20 Bill & Alex indicated that if there really are two quite different cases, then it is possible to have a "dual mandatory" approach. I.e.: =20 If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. =20 If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. =20 This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. =20 =20 =20 Congestion control: =20 Several times over the whole conversation the topic of congestion control came up. Also, as part of some TIPC discussions, I ended up spending some time talking to Allison Mankin (transport AD) about congestion control as well. All the ADs I talked to where consistent on=20 the following: =20 If you are running over IP, you MUST act in a RFC2914 compliant fashion (i.e. respond to congestion like TCP or SCTP or RMT does). Two reasons where put forth for this: 1) Any time you define an IP-based protocol you cannot guarantee that it will not go out over the Internet. As such, the IESG will NOT standardize IP protocols with "bad" (non-2914) behaviors. 2) Lots of implementation experience showing that other congestion control mechanisms don't work (congestion collapse etc). =20 They where very firm on the above and my impression was that convincing them otherwise would be very difficult. =20 That being said, a second alternative did arise: If you are not implementing on top of IP (e.g. running on Infiniband, ATM, Ethernet) then you could rely on mechanisms for congestion control built into what you are relying on, or even consider building your own congestion control mechanisms (ala TIPC). This makes it possible to define (for example) a multicast transport for forces without having to go all the way and implementing RMT - as long as it is clear that it isn't over IP. The ADs went as far as saying that the IETF could even accept standards- track drafts that say nothing about IP (e.g. define an Ethernet-only transport for ForCES), if it is necessary=20 for ForCES. GSMP and (some other group I forgot) was given as an example. =20 Cheers, David =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 =20 =20 =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 ------_=_NextPart_001_01C403CB.DADEE900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I understand your concern and = definitely agree that we will have to resolve the issues of reliability/CC, = security (may be)

for multicast before deciding to = use it. I was assuming this will be done. How we acheive this is a separate = discussion...

using RMT, TIPC, others, etc...we = can have that discussion after resolving the other topics that Jamal has = raised.

 

Regards

Hormuzd

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com]
Sent: Friday, March 05, = 2004 1:26 PM
To: Khosravi, Hormuzd = M
Cc: Deleganes, Ellen M; forces-protocol@ietf.org
Subject: Re: = [Forces-protocol] Comments from chat with ADs

I still maintain that MULTICAST is best left = at SHOULD implement strength.  Why?
A lot of issues are still unresolved concerning multicast reliabililty, security, etc., unless
we want to define an application-layer method to resolve issues = like  synchronization,
packet-loss, ACK/NACK implosion, etc. 

Alex.

Khosravi, Hormuzd M wrote:

Yes Ellen, that was my =
intent.
 
Thanks for the =
clarification,
Hormuzd
 
-----Original =
Message-----
From: Deleganes, Ellen M =

Sent: Friday, March 05, 2004 12:19 =
PM
To: Khosravi, Hormuzd M; alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from =
chat with ADs
 
 
I think what Hormuzd is saying (Hormudz can =
correct me if I am wrong) is
that even if Multicast is optional, those =
procedures that noted in
Hormudz's email should be described in the =
ForCES protocol spec. That
is, if a ForCES protocol implementation =
supports multicast, then it MUST
implement it in the manner described in the =
ForCES protocol
specification. Otherwise, ForCES =
implementations using multicast will
probably not =
interoperate.
 
Whether or not implementing multicast for =
transports that support
multicast is a requirement is a separate =
question. 
 
Regards,
Ellen
 
-----Original =
Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org] On Behalf Of Khosravi, Hormuzd =
M
Sent: Thursday, March 04, 2004 6:12 =
PM
To: alex.audu@alcatel.com
Cc: forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Comments from =
chat with ADs
 
Hi Alex,
 
In general, I prefer using language such as =
MUST so that there is no
confusion or interop issues in the protocol =
implementations. However,
you raise a reasonable point and let me tell =
you my thoughts on this. We
will definitely need Unicast between FEs and =
CEs at the minimum in the
protocol. In addition, if the interconnect =
technology supports Multicast
and there is a case where it is useful to the =
application (such as
downloading IPv4 routes) we must allow it as =
well without breaking
interop. In order to do that, we will need =
specific procedures in the
protocol that will allow the CE and FE to =
negotiate on using multicast
dynamically at run-time (say during the =
binding or joining phase between
the CE and FE) and also associate different =
multicast groups with LFBs.
We will also need to define how =
Reliability/CC etc. will be provided for
multicast...may be using RMT, TIPC, etc. (?) =
If we do this correctly,
then applications will be able to use both =
unicast and multicast without
any interop =
issues.
 
Let me know what you guys think about =
this.
 
Regards
Hormuzd
 
-----Original =
Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] =

Sent: Thursday, March 04, 2004 1:22 =
PM
To: Khosravi, Hormuzd =
M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Comments from =
chat with ADs
 
 
Hormuzd,
 
Why should multicast be "mandated for =
certain cases where it will be 
useful" if =
there
is a simpler, more robust way to do the same =
thing?  I'll say we don't 
mandate this.
We can make it a "SHOULD" strength, =
not a "MUST".  We mandate =
UNICAST
and make MULTICAST optional.  Any issues =
with this?
 
Regards,
Alex.
 
 
Khosravi, Hormuzd M =
wrote:
 
  
Hi David
 
Your summary below of the discussion with Ads =
on the different issues
seems like very reasonable approaches to =
me.
 
I agree that it will be a good idea to =
present transport alternatives
    =

at
  =

IP and non-IP level for the ForCES protocol. =
We can mandate one or more
transport for IP and one or more transport =
for non-IP, this way the
interoperability requirements are met and at =
the same time, the in-box,
out of box scenarios are =
met.
 
Also, agree with having multiple =
channels/connections to differentiate
    =

C
  =

& D traffic between CEs and FEs. On the =
unicast/multicast topic, dual
mandatory approach again seems a good idea to =
support interoperability.
The one thing that I would like to point out =
is that for any ForCES
protocol implementation to work, unicast will =
definitely be required at
the minimum. One could also mandate using =
multicast for certain cases
where it will be useful (e.g. IPv4/config =
table download), if it is
supported by the interconnect as you stated. =
But just multicast without
unicast will not work, atleast not =
efficiently.
 
Regards
Hormuzd
 
-----Original =
Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org] On Behalf Of Putzolu, =
David
Sent: Tuesday, March 02, 2004 5:06 =
AM
To: forces-protocol@ietf.org
Subject: [Forces-protocol] Comments from chat =
with ADs
 
Patrick and I spent about 90 minutes last =
night
chatting with Bill and Alex about ForCES, =
with
maybe half of the time on the protocol.  =
In
the conversations with them, along with =
some
follow-up chats I had with Allison Mankin, =
the
following topics where covered:  =
multiple 
channels, multicast/unicast, and congestion =

control.  Below is what I recall from =
memory 
(Patrick please correct me/elaborate as =
needed :)
 
 
 
Multiple channels:  =

 
I discussed the interference issue that =

was identified by the GRMP team.  Bill =
&
Alex agreed that many OS implementations can =
have
an interference property (i.e. where two =
different
connections will have queuing interference =
lower in
the networking stack in the OS).  So it =
is necessary
to make sure when implementing a FE (or CE =
probably
as well) that this is taken into =
account.  Methods
of doing that =
include:
* Manually queuing packets (i.e. feed OS few =
enough
 packets that it cannot get into trouble - =
although
 you pay a performance price for that, in =
that fine
 grained scheduling takes =
cycles)
* Indicating to the OS to treat flows =
differently - 
 some real-time OS will let you do this, =
that is they
 are implemented to internally retain QoS =
between
 flows.
However, it was also mentioned that intra-FE =

interference is only one kind of =
interference.  Good
FE implementation (e.g. by manually queuing =
above the
OS) helps to fix intra-FE interference, but =
it does
not solve inter-FE interference.  That =
is, if all
(C & D) packets are always on the same =
connection,
that makes it impossible on the wire to =
differentiate
them from one another.  Imagine you have =
a bunch of
FEs with some of them being subject to DOS =
attack for
D packets, and you want to query one of the =
FEs for
statistics.  It would be good to have =
some way of
ensuring the C packets (or any high priority =
packets -
OSPF HELLO maybe) get through.  Separate =
channels
(as Jamal indicated, don't even have to be C =
& D)
makes this possible.   Putting =
everything on one
channel makes it impossible to deal with =
inter-FE
interference in a differentiated fashion. =

 
 
Multicast & Unicast:  =

 
The discussion on this started out with a =
discussion
of the IETF protocol design BKM that options =
can ruin
compatibility.  That is, if there are =
four ways to
implement something, all optional, then you =
can have
client 1 implement A & B, and client 2 =
implement C & D,
and even though both clients are 100% =
compliant, they
cannot talk to one another. Better to say all =
clients
must implement A and make B, C, and D =
optional, so that
way you know that all implementations will be =
able to 
at least talk.
 
Patrick & I pushed on this a bit, =
explaining that we
actually had potentially (at least) two =
different
environments - very close environments where =
multicast
support could be present in the =
interconnect,  and 
not-as-close environments (and some =
close
environments as well) where multicast was not =
available.
 
Bill & Alex indicated that if there =
really are two
quite different cases, then it is possible to =
have a
"dual mandatory" approach.  =
I.e.:
 
If your underlying interconnect supports =
multicast,
then you MUST implement the following =
(multicast)
method of =
communication.
 
If your underlying interconnect supports =
unicast, then
you MUST implement the following (unicast) =
method
of =
communication.
 
This will guarantee interop, although at a =
potential
extra cost (cost being having to potentially =
support
both when both are present).  While this =
isn't optimal,
it does at least give some =
flexibility.
 
 
 
Congestion =
control:
 
Several times over the whole conversation the =
topic
of congestion control came up.  Also, as =
part of some
TIPC discussions, I ended up spending some =
time talking
to Allison Mankin (transport AD) about =
congestion control
as well.  All the ADs I talked to where =
consistent on 
the following:
 
If you are running over IP, you MUST act in a =
RFC2914
compliant fashion (i.e. respond to congestion =
like TCP
or SCTP or RMT does).  Two reasons where =
put forth for
this:
1) Any time you define an IP-based protocol =
you cannot
guarantee that it will not go out over the =
Internet. As
such, the IESG will NOT standardize IP =
protocols with
"bad" (non-2914) =
behaviors.
2) Lots of implementation experience showing =
that other
congestion control mechanisms don't work =
(congestion
collapse etc).
 
They where very firm on the above and my =
impression was
that convincing them otherwise would be very =
difficult.
 
That being said, a second alternative did =
arise:  If
you are not implementing on top of IP (e.g. =
running on
Infiniband, ATM, Ethernet) then you could =
rely on mechanisms
for congestion control built into what you =
are relying on,
or even consider building your own congestion =
control
mechanisms (ala TIPC).  This makes it =
possible to define
(for example) a multicast transport for =
forces without
having to go all the way and implementing RMT =
- as long
as it is clear that it isn't over IP.  =
The ADs went as
far as saying that the IETF could even accept =
standards-
track drafts that say nothing about IP (e.g. =
define an
Ethernet-only transport for ForCES), if it is =
necessary 
for ForCES. GSMP and (some other group I =
forgot) was
given as an =
example.
 
Cheers,
David
 
______________________________________________=
_
Forces-protocol mailing =
list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
 
 
______________________________________________=
_
Forces-protocol mailing =
list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
 
    =

 
 
______________________________________________=
_
Forces-protocol mailing =
list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
 
------_=_NextPart_001_01C403CB.DADEE900-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 18:35:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10758 for ; Sat, 6 Mar 2004 18:35:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzlJu-0002B0-HR for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 18:35:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26NZ2P4008365 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 18:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzlJt-0002Ad-FC for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 18:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10751 for ; Sat, 6 Mar 2004 18:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzlJq-00069D-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 18:34:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzlIr-00061J-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 18:33:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzlHu-0005ta-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 18:32:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzlHx-0001zX-8t; Sat, 06 Mar 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzlHu-0001z5-Rg for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 18:32:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10714 for ; Sat, 6 Mar 2004 18:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzlHr-0005sy-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 18:32:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzlH0-0005kt-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 18:32:03 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AzlGl-0005d4-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 18:31:47 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i26NXLAp029050; Sat, 6 Mar 2004 23:33:21 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i26NX30i009519; Sat, 6 Mar 2004 23:33:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030615311615166 ; Sat, 06 Mar 2004 15:31:16 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 15:31:16 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Comments from chat with ADs X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E05421D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Comments from chat with ADs Thread-Index: AcQC+VIm6Jq65INFSkK74ydlaA8u0gA2K0Tg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 06 Mar 2004 23:31:16.0339 (UTC) FILETIME=[1ED3B430:01C403D3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 15:31:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal My thinking on this is a little different. I think this should be part of the protocol phase call it binding phase during which after the initial unicast connection (say TCP) is set up, other multicast connections can be negotiated and setup. Also, an unreliable D channel/connection will be setup during this phase. This is reduce our dependence on FEM/CEM interface and also help with interop. This approach is similar in basics to approach used by say FTP (for setting up data connections) or more sophisticated approach used by iSCSI to setup multiple TCP connections for performance reasons.=20 Anyways, lets discuss this issue later otherwise it will be very confusing. Lets get the header resolved first, Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, March 05, 2004 1:32 PM To: Khosravi, Hormuzd M Cc: jeff pickering; alex.audu@alcatel.com; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Comments from chat with ADs Is this negotiation for transport going to happen at the FEM/CEM plane? In toher words i would think this is more of a configuration/bootstrapping issue, no? And those typically belong to the FEM/CEM plane. My opinion is that typically a single NE will be controlled by a single admin; therefore selection of transport can be enforced within that domain - such a static setup will simplify things a great deal. BTW, we should add capability exchange as something else that needs discussion. cheers, jamal On Fri, 2004-03-05 at 16:09, Khosravi, Hormuzd M wrote: > Hi Jeff, >=20 > Just wanted to clarify one comment below. I think some sort of > negotiation will be necessary even if we mandate multicast for certain > cases in order to have an easy interop. In general, the more specific we > are about all the details in the protocol, the stronger language we use, > the easier it will be for us to interop. The question that you have > asked below is a very valid question and will need to be answered in the > protocol spec explicitly. My gut feeling for the answer is that there > will be a mix traffic, if the other FEs support multicast and the CE > would like to use it or is using it already. >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 21:55:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16543 for ; Sat, 6 Mar 2004 21:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoRU-0005ih-DC for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 21:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i272t4ov021981 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 21:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoRU-0005iS-5o for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 21:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16532 for ; Sat, 6 Mar 2004 21:55:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzoRR-0003NI-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 21:55:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzoQR-0003G9-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 21:54:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzoPS-00036g-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 21:52:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoPV-0005Tq-BG; Sat, 06 Mar 2004 21:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoOk-0005R6-Oz for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 21:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16514 for ; Sat, 6 Mar 2004 21:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzoOh-00031e-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 21:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzoNg-0002uB-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 21:51:08 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzoNQ-0002md-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 21:50:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030618512698:63788 ; Sat, 6 Mar 2004 18:51:26 -0800 Subject: Re: [Forces-protocol] Issue 100: On the issue play From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <075b01c403a8$92550150$845c21d2@Necom.hzic.edu.cn> References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> <1078588533.1040.149.camel@jzny.localdomain> <075b01c403a8$92550150$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078627840.1036.220.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 03/06/2004 06:51:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/06/2004 06:51:33 PM, Serialize complete at 03/06/2004 06:51:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2004 21:50:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, On Sat, 2004-03-06 at 13:26, Wang,Weiming wrote: > Hi Jamal, > > Pls allow me just reply to mailing list to reply to you as well. I wish you may only need to reply to me > by replying to the list, for it produces duplications :) I have been bitten on many lists where i send a message and it never makes it. CCing the original poster always helps for redundancy purposes. So bear with my emails because in the worst case you will receive two;-> > [Weiming Re] > That's fine, but I just want post the "DoS protection and congestion control mechanism" very soon, for I have > already finished the email. I saw that email. Can we ignore it for now if you dont mind until we address 0-2? I am not gonna respond to your other emails so we can have some order to any chaos. > I also came up with an idea that a sub-issue may be opened when some issue discussion > has lead to too complex state or some problem in the issue is relatively independent. > I'm afraid this may happen when some topics are quite wide spread. The issue may be > marked as Issue X.Y . > [/Weiming Re] I agree. If it is something that can be obviously identified then by all means go ahead and propose the sub-topics; otherwise the subtopics will come up as we hit each topic. > [Weiming Re] > I absolutely do not mean to put any limit to opinion sharing. I'm sorry to have misexpressed it. > What my original thought is just I thought a tree structure may be more efficient than a linear structure. > > Yes, I'm glad to add some more items to follow the list as: > > 10) In-protocol mechanism for reliability Should be part of issue 5. > 11) Support for vendor functions Not sure if i see this as anything speacial right now; but lets add it to the list. > 12) Support for network management tools Not sure i follow this. This can always be resolved later. > 13) Message organizing Is this different from issue 1? > 14) Conflict check with current FE model This is not a contetious issue - it can be resolved later. I actually havent read the latest incarnation of the model draft. what did you have in mind? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 22:11:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16989 for ; Sat, 6 Mar 2004 22:11:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoh1-0006Xu-QF for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 22:11:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i273B7cj025156 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 22:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoh1-0006Xf-HK for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 22:11:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16953 for ; Sat, 6 Mar 2004 22:11:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azogy-0005dB-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:11:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azofw-0005TR-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:10:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azoex-0005G0-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoez-0006Rv-Fa; Sat, 06 Mar 2004 22:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoeS-0006Qy-5S for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 22:08:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16842 for ; Sat, 6 Mar 2004 22:08:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzoeP-0005B7-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:08:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzodK-00050b-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:07:19 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzocX-0004rJ-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:06:30 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030619065968:63793 ; Sat, 6 Mar 2004 19:06:59 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078628768.1037.251.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 03/06/2004 07:07:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/06/2004 07:07:10 PM, Serialize complete at 03/06/2004 07:07:10 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] RE: Issue 0: Application addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2004 22:06:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 16:37, Khosravi, Hormuzd M wrote: > Alright, here are my views on this issue/topic... > > Terminology: Src ID, Dest ID vs CEID, FEID > I don't like to get stuck up on terminology, so I will go with whatever > the majority likes on this as long as we agree on the semantics. Same here. > Semantics: This is where we differ a bit. As our terminology suggests, > these can be individual FE, group of FE, all FEs and same applies for > CEs. However, this field does not represent LFBs. LFB ID is something > which has to be assigned by FEs for representing static topologies, and > may be assigned by FEs for dynamic topologies (I think this is also what > the Model team concluded on this issue, but not 100% sure). In contrast, > FE IDs is something assigned by the CE as Jamal suggested. Moreover LFB > ID is not something which is needed in all ForCES messages, hence does > not need to be in the common header. It will be part of the TLV defined > for carrying configuration/control/event messages. My wording was insufficient. The targeted end point for an ID is not something thats on the datapath (although i have a feeling some of the NPF folks may disagree with me). In otherwords, the ID is that of a Forces application (or OS process or thread) which resides on a CE or FE. If we looked at the entity that is being addressed by this ID as a forces application then we could say that: - the ID is always needed since there maybe more than one such app on a specific endsystem. This is true regardless of the end system being a CE or FE. So lets ignore the LFB part and see if the above is agreeable. > Length: Acc to the scalability requirements, we need to support hundreds > of FEs (<=1000) and even much less no of CEs (<=100). So 10 bits would > be enough for FEID/Dest ID and 7 bits for CEID/ Src ID. However, in > order to accommodate even higher requirements and have the fields 32-bit > > aligned we used 16 bits for FEID, CEID. If there is a good technical > reason for requiring 32-bits I would be willing to compromise on this. 32 bits is not that expensive and it always saves you from famous last words like "nobody will ever need more than 640K of RAM" or "you can give light bulbs IP addresses if you used 32 bit IP addresses". The partitioning of CEID or FEID is a little limiting in my opinion. The end target may not be precisely a CE or FE; it could be an OSPF offloader on an FE. > However, one thing to keep in mind is that this is the common header so > every byte we add to it will be added to all the messages, so it would > be a good design principle to be a bit stingy here. If it was part of an > optional TLV, we wouldn't care as much. Forces is almost middleware; typical middleware abuses a lot of the PID space usually around 128 bits for each direction. Example look at corba or: http://www.rti.com/products/ndds/index.html Note in their case the IDs above are known as UUIDs with one of the Us standing for universal; in our case the universe is the NE so a 32 bit maybe suffice. > > Let me know what other views are on this topic. Well the other issues are in regards to semantics of the ID; To quote what i said earlier: > .. shows need for having the ID being able to be IDed > as unicast, broadcast or multicast. > in other words we should be able to address a single forces app, or several. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 22:15:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17086 for ; Sat, 6 Mar 2004 22:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoks-0006pR-9O for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 22:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i273F6SM026243 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 22:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoks-0006pC-1y for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 22:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17076 for ; Sat, 6 Mar 2004 22:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azoko-000698-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:15:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azojp-00061a-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:14:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azoio-0005pZ-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:12:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azoir-0006ga-BO; Sat, 06 Mar 2004 22:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzoiB-0006bS-2E for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 22:12:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17040 for ; Sat, 6 Mar 2004 22:12:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azoi8-0005n4-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:12:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azoh7-0005eT-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:11:13 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1Azog8-0005Up-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:10:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030619105193:63796 ; Sat, 6 Mar 2004 19:10:51 -0800 Subject: RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078629011.1038.257.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 03/06/2004 07:10:52 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/06/2004 07:10:53 PM, Serialize complete at 03/06/2004 07:10:53 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2004 22:10:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 17:37, Khosravi, Hormuzd M wrote: > Jamal, > > Before I give my comments, I would like to say that I appreciate the > fact that you did not copy/paste the netlink header from your draft over > here! That is a very positive sign to me, lets try to stick to the best > technical solution rather than pushing our own protocol implementations. > That's the best way to make progress on this merger!! We actually have learnt a few things while implementing ;-> The thinking right now is to learn from mistakes (and from good things of course). > Here are my views on this issue, particularly the common header: > > Command: Agree this is needed. We think 8-12 bits will be more than > sufficient for this depending on whether it is subdivided. We have > sub-divided this field into Class/type...this is an OO approach, seemed > pretty neat. However, I am personally fine with having a single field > for this, no problem with that. I think we could resolve this later; i am not seeing a lot of commands. On the outset i can only see ADD/DEL/GET > Sequence No: Agree needed and agree with size. > > Flags/Priority: We need 2-3 bits for priority in every message. I don't > think we need any other flags in all messages. How do you propose we do things like 2 phase commits; atomic transactions etc? Maybe what you called "class" in the command is a flag then? Also in regards to priority; do you see this being used all the time? and would an underlying transport priority be insufficient (example diffserv, 802.1p etc)? > Typeid: This is one field I don't think is needed in all messages. I am > not sure why this is needed at all cause, we will be using the Model and > LFB IDs to address processing functional blocks on the FEs. I am not sure i see this. If you could explain more mayeb it would help. Like i said the only value is in being able to look at the outer header and recognizing for example the target where the message is being sent to (example LFB class). If not for anything else, debugging (via sniffing) is a good reason - this way i could dump the rest of the message by recognizing what the TLVs mean. > Missing field: Version (2-4 bits): This is present in all protocols, and > is generally included in most IETF protocols. Its usually the 1st field. Agreed. 4 bits is what i have seen normally. > General comment: Lets try to be stingy on the size of the header and its > fields since this will be included in all ForCES messages. Agreed - the main thing is that if something needs to be used in all messages then it should go on this header (since its cheaper than a TLV). cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 22:52:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17750 for ; Sat, 6 Mar 2004 22:52:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzpKs-0000Ei-GS for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 22:52:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i273qI8G000901 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 22:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzpKs-0000ES-94 for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 22:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17742 for ; Sat, 6 Mar 2004 22:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzpKo-00033p-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzpJo-0002w9-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:51:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzpJa-0002oK-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 22:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzpJd-0000CL-De; Sat, 06 Mar 2004 22:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzpIu-0000BS-6A for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 22:50:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17699 for ; Sat, 6 Mar 2004 22:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzpIq-0002nU-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:50:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzpHl-0002fM-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:49:06 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1AzpGw-0002Wd-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 22:48:15 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 7 Mar 2004 11:59:29 +0800 Message-ID: <083b01c403f6$bb740ec0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> <1078588533.1040.149.camel@jzny.localdomain> <075b01c403a8$92550150$845c21d2@Necom.hzic.edu.cn> <1078627840.1036.220.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 100: On the issue play MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 11:46:11 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmFtYWwsDQoNCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4NCj4g V2VpbWluZywNCj4gDQo+IE9uIFNhdCwgMjAwNC0wMy0wNiBhdCAxMzoyNiwgV2FuZyxXZWltaW5n IHdyb3RlOg0KPiA+IEhpIEphbWFsLA0KPiA+IA0KPiA+IFBscyBhbGxvdyBtZSBqdXN0IHJlcGx5 IHRvIG1haWxpbmcgbGlzdCB0byByZXBseSB0byB5b3UgYXMgd2VsbC4gSSB3aXNoIHlvdSBtYXkg b25seSBuZWVkIHRvIHJlcGx5IHRvIG1lDQo+ID4gYnkgcmVwbHlpbmcgdG8gdGhlIGxpc3QsIGZv ciBpdCBwcm9kdWNlcyBkdXBsaWNhdGlvbnMgOikNCj4gDQo+IEkgaGF2ZSBiZWVuIGJpdHRlbiBv biBtYW55IGxpc3RzIHdoZXJlIGkgc2VuZCBhIG1lc3NhZ2UgYW5kIGl0IG5ldmVyDQo+IG1ha2Vz IGl0LiBDQ2luZyB0aGUgb3JpZ2luYWwgcG9zdGVyIGFsd2F5cyBoZWxwcyBmb3IgcmVkdW5kYW5j eQ0KPiBwdXJwb3Nlcy4gU28gYmVhciB3aXRoIG15IGVtYWlscyBiZWNhdXNlIGluIHRoZSB3b3Jz dCBjYXNlIHlvdSB3aWxsDQo+IHJlY2VpdmUgdHdvOy0+DQo+IA0KPiANCj4gDQo+ID4gW1dlaW1p bmcgUmVdDQo+ID4gVGhhdCdzIGZpbmUsIGJ1dCBJIGp1c3Qgd2FudCBwb3N0IHRoZSAiRG9TIHBy b3RlY3Rpb24gYW5kIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc20iIHZlcnkgc29vbiwgZm9y IEkgaGF2ZSANCj4gPiBhbHJlYWR5IGZpbmlzaGVkIHRoZSBlbWFpbC4NCj4gDQo+IEkgc2F3IHRo YXQgZW1haWwuIENhbiB3ZSBpZ25vcmUgaXQgZm9yIG5vdyBpZiB5b3UgZG9udCBtaW5kIHVudGls IHdlDQo+IGFkZHJlc3MgMC0yPyBJIGFtIG5vdCBnb25uYSByZXNwb25kIHRvIHlvdXIgb3RoZXIg ZW1haWxzIHNvIHdlIGNhbiBoYXZlDQo+IHNvbWUgb3JkZXIgdG8gYW55IGNoYW9zLg0KDQpbV2Vp bWluZyBSZV0NClRoZSBtdWx0aWNoYW5uZWwgaXNzdWUgaXMgcXVpdGUgcmVsYXRlZCB0byB0aGUg Y29uZ2VzdGlvbiBjb250cm9sIGlzc3VlLCB0aGVyZWZvcmUsIGlmIHdlIHdhbnQgdG8gYmUgbW9y ZSBmb2N1cywgSSBzdWdnZXN0DQpqdXN0IHRvIGJpZ2luIHdpdGggMCwxIG9ubHksIGxlYXZpbmcy LDMsNCBhcyB0aGUgZm9sbG93aW5nIGdyb3VwLiBPciBlbHNlLCBJIHRoaW5rIGl0J3MgcmVhc29u YWJsZSB0byBzdGFydCB3aXRoIDAtNC4gQWN0dWFsbHkgd2UNCmFscmVhZHkgaGFkIG1hbnkgZGlz Y3Vzc2lvbnMgb24gdGhlc2UuIEl0IHNlZW1zIG5vdCB2ZXJ5IHdlbGwgdG8gc3RvcCB0aGVzZSBk aXNjdXNzaW9ucyBhbGwgb2YgYSBzdWRkZW4uIE1vcmVvdmVyLCBpc3N1ZSAxIGlzIA0KcXVpdGUg YSBiaWcgaXNzdWUsIEkgZG9uJ3QgdGhpbmsgaXQgY2FuIGJlIGNsb3NlZCB3aXRoaW4gb25lIHdl ZWsuIFRoZW4sIHdlIGNhbiBjb3VudCBob3cgbXVjaCB0aW1lIGlzIGxlZnQuIFRoZXJlZm9yZSwg SSBzdWdnZXN0DQp0byB3b3JrIHdpdGggbW9yZSBwYXJhbGxlbGxpc20uIA0KDQo+IA0KPiA+IEkg YWxzbyBjYW1lIHVwIHdpdGggYW4gaWRlYSB0aGF0IGEgc3ViLWlzc3VlIG1heSBiZSBvcGVuZWQg d2hlbiBzb21lIGlzc3VlIGRpc2N1c3Npb24gDQo+ID4gaGFzIGxlYWQgdG8gdG9vIGNvbXBsZXgg c3RhdGUgb3Igc29tZSBwcm9ibGVtIGluIHRoZSBpc3N1ZSBpcyByZWxhdGl2ZWx5IGluZGVwZW5k ZW50LiANCj4gPiBJJ20gYWZyYWlkIHRoaXMgbWF5IGhhcHBlbiB3aGVuIHNvbWUgdG9waWNzIGFy ZSBxdWl0ZSB3aWRlIHNwcmVhZC4gVGhlIGlzc3VlIG1heSBiZSANCj4gPiBtYXJrZWQgYXMgSXNz dWUgWC5ZIC4NCj4gPiBbL1dlaW1pbmcgUmVdDQo+IA0KPiBJIGFncmVlLiBJZiBpdCBpcyBzb21l dGhpbmcgdGhhdCBjYW4gYmUgb2J2aW91c2x5IGlkZW50aWZpZWQgdGhlbiBieSBhbGwNCj4gbWVh bnMgZ28gYWhlYWQgYW5kIHByb3Bvc2UgdGhlIHN1Yi10b3BpY3M7IG90aGVyd2lzZSB0aGUgc3Vi dG9waWNzIHdpbGwNCj4gY29tZSB1cCBhcyB3ZSBoaXQgZWFjaCB0b3BpYy4NCj4gDQo+ID4gW1dl aW1pbmcgUmVdDQo+ID4gSSBhYnNvbHV0ZWx5IGRvIG5vdCBtZWFuIHRvIHB1dCBhbnkgbGltaXQg dG8gb3BpbmlvbiBzaGFyaW5nLiBJJ20gc29ycnkgdG8gaGF2ZSBtaXNleHByZXNzZWQgaXQuDQo+ ID4gV2hhdCBteSBvcmlnaW5hbCB0aG91Z2h0IGlzIGp1c3QgSSB0aG91Z2h0IGEgdHJlZSBzdHJ1 Y3R1cmUgbWF5IGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gYSBsaW5lYXIgc3RydWN0dXJlLg0KPiA+ IA0KPiA+IFllcywgSSdtIGdsYWQgdG8gYWRkIHNvbWUgbW9yZSBpdGVtcyB0byBmb2xsb3cgdGhl IGxpc3QgYXM6DQo+ID4gDQo+ID4gMTApIEluLXByb3RvY29sIG1lY2hhbmlzbSBmb3IgcmVsaWFi aWxpdHkNCj4gDQo+IFNob3VsZCBiZSBwYXJ0IG9mIGlzc3VlIDUuDQo+IA0KPiA+IDExKSBTdXBw b3J0IGZvciB2ZW5kb3IgZnVuY3Rpb25zDQo+IA0KPiBOb3Qgc3VyZSBpZiBpIHNlZSB0aGlzIGFz IGFueXRoaW5nIHNwZWFjaWFsIHJpZ2h0IG5vdzsNCj4gYnV0IGxldHMgYWRkIGl0IHRvIHRoZSBs aXN0Lg0KPiANCj4gPiAxMikgU3VwcG9ydCBmb3IgbmV0d29yayBtYW5hZ2VtZW50IHRvb2xzDQo+ IA0KPiBOb3Qgc3VyZSBpIGZvbGxvdyB0aGlzLiBUaGlzIGNhbiBhbHdheXMgYmUgcmVzb2x2ZWQg bGF0ZXIuDQoNCltXYW5nIFJlXQ0KSSdtIG5vdCBzdXJlIHRoZSBsYXRlciBtZWFucy4gSSBzdXBw b3NlIHdlIGFyZSBqdXN0IHByZXNlbnRpbmcgc29tZSB0b3BpY3MgZm9yIGxhdGVyIGRpc2N1c3Np b24sIHJpZ2h0Pw0KPiANCj4gPiAxMykgTWVzc2FnZSBvcmdhbml6aW5nDQo+IA0KPiBJcyB0aGlz IGRpZmZlcmVudCBmcm9tIGlzc3VlIDE/DQoNCltXZWltaW5nIFJlXQ0KSXNzdWUgMSBpcyBhYm91 dCBwYWNrZXQgZW5jb2RpbmcgZm9ybWF0LCB0aGlzIGlzc3VlIGlzIGFib3V0IG1lc3NhZ2Ugb3Jn YW5pemluZyB3YXksIHN1Y2ggYXMgd2hhdCBraW5kIG9mIEZvckNFUyBtZXNzYWdlcw0Kd2UgbmVl ZCBhbmQgaG93IHRoZXkgYXJlIG9yZ2FuaXplZC4gRGlmZmVyZW50Pw0KIA0KPiA+IDE0KSBDb25m bGljdCBjaGVjayB3aXRoIGN1cnJlbnQgRkUgbW9kZWwNCj4gDQo+IFRoaXMgaXMgbm90IGEgY29u dGV0aW91cyBpc3N1ZSAtIGl0IGNhbiBiZSByZXNvbHZlZA0KPiBsYXRlci4gSSBhY3R1YWxseSBo YXZlbnQgcmVhZCB0aGUgbGF0ZXN0IGluY2FybmF0aW9uDQo+IG9mIHRoZSBtb2RlbCBkcmFmdC4g d2hhdCBkaWQgeW91IGhhdmUgaW4gbWluZD8NCg0KW1dlaW1pbmcgUmVdDQpNYXliZSBJIHNob3Vs ZCBub3QgdXNlICdjb25mbGljdCcsIGluc3RlYWQgc2hvdWxkIGJlIGEgY29oZXJlcmVudCBjaGVj ay4gRm9yIGluc3RhbmNlLCBuZXcgRkUgbW9kZWwgc3VwcG9zZSB0byB1c2UgDQpBU0NJSSBic2Vk IExGQiBuYW1lcyBsaWtlICJJUHY0IExQRiIuIEknbSBzdXJlIGFuIExGQiBJRCB3aWxsIGFwcGVh ciBpbiBGb3JDRVMgcHJvdG9jb2wsIHRoZW4gaG93IHRoZXkgYXJlIGNvbnNpc3RlbnQgd2l0aA0K ZWFjaCBvdGhlci4gT3RoZXJzIGxpa2Ugc29tZXRoaW5nIG5vdCBzdXJlZCB3aG8gd2lsbCBkZWZp bmUgdGhlbSwgYW5kIGF0IHdoYXQgbGV2ZWwsIGV0Yy4NCg0KQ2hlZXJzLA0KV2VpbWluZw0KDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 6 23:20:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18468 for ; Sat, 6 Mar 2004 23:20:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azplt-0001sv-AI for forces-protocol-archive@odin.ietf.org; Sat, 06 Mar 2004 23:20:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i274KDn5007239 for forces-protocol-archive@odin.ietf.org; Sat, 6 Mar 2004 23:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azplt-0001sg-3Z for forces-protocol-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 23:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18462 for ; Sat, 6 Mar 2004 23:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azplr-0006vt-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 23:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azpkw-0006oN-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 23:19:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azpkh-0006ga-00 for forces-protocol-web-archive@ietf.org; Sat, 06 Mar 2004 23:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azpkj-0001fv-3v; Sat, 06 Mar 2004 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azpjx-0001au-FV for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 23:18:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18425 for ; Sat, 6 Mar 2004 23:18:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azpjv-0006gN-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 23:18:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azpj6-0006YI-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 23:17:21 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1AzpiX-0006Q1-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 23:16:45 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030620172420:63820 ; Sat, 6 Mar 2004 20:17:24 -0800 Subject: Re: [Forces-protocol] Issue 100: On the issue play From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <083b01c403f6$bb740ec0$845c21d2@Necom.hzic.edu.cn> References: <9CB758BBEE58754F8F33234D75B9F4B00243F1E5@orsmsx410.jf.intel.com> <4048F06E.8020809@alcatel.com> <1078522737.1040.111.camel@jzny.localdomain> <06f101c40383$0bdeb3c0$845c21d2@Necom.hzic.edu.cn> <1078588533.1040.149.camel@jzny.localdomain> <075b01c403a8$92550150$845c21d2@Necom.hzic.edu.cn> <1078627840.1036.220.camel@jzny.localdomain> <083b01c403f6$bb740ec0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078633003.1037.280.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 03/06/2004 08:17:24 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/06/2004 08:17:26 PM, Serialize complete at 03/06/2004 08:17:26 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Mar 2004 23:16:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 22:46, Wang,Weiming wrote: > > I saw that email. Can we ignore it for now if you dont mind until we > > address 0-2? I am not gonna respond to your other emails so we can have > > some order to any chaos. > > [Weiming Re] > The multichannel issue is quite related to the congestion control issue, therefore, if we want to be more focus, I suggest > just to bigin with 0,1 only, leaving2,3,4 as the following group. Or else, I think it's reasonable to start with 0-4. Actually we > already had many discussions on these. It seems not very well to stop these discussions all of a sudden. Moreover, issue 1 is > quite a big issue, I don't think it can be closed within one week. Then, we can count how much time is left. Therefore, I suggest > to work with more parallellism. > The idea is not to agree on the "how"; rather on what of the merger i.e that we can narrow any differences into a small tight area. Thats what needs to be reported back by the 20th. So it should not take many emails to address issue 1 in that scope. As far as i can see from the discussion this should be soon closed. On issue 2 Hormuzd was putting some text around it. Why not wait until he does so? I know its hot for you - but it would help to have a starting point. In the meantime i think it would be useful if you address issue 0 and 1. We are going to talk about every issue that is bothering you, not to worry; lets just do it sequentially. > > > 12) Support for network management tools > > > > Not sure i follow this. This can always be resolved later. > > [Wang Re] > I'm not sure the later means. I suppose we are just presenting some topics for later discussion, right? We are trying to reach a general idea that the issues are resolvable. "Later" is when the protocol is being written. I dont see network management tools as something either imposing on the protocol or contentious to the merging. > > > > > 13) Message organizing > > > > Is this different from issue 1? > > [Weiming Re] > Issue 1 is about packet encoding format, this issue is about message organizing way, such as what kind of ForCES messages > we need and how they are organized. Different? Repsond to issue 1 with examples and maybe it could be a separate topic. I dont see it as different but cant tell without seeing your text. > > > 14) Conflict check with current FE model > > > > This is not a contetious issue - it can be resolved > > later. I actually havent read the latest incarnation > > of the model draft. what did you have in mind? > > [Weiming Re] > Maybe I should not use 'conflict', instead should be a cohererent check. For instance, new FE model suppose to use > ASCII bsed LFB names like "IPv4 LPF". I'm sure an LFB ID will appear in ForCES protocol, then how they are consistent with > each other. Others like something not sured who will define them, and at what level, etc. Ok you can add this. I would recommend the model draft doesnt get approved to final call incase we have issues with it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 7 20:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16794 for ; Sun, 7 Mar 2004 20:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B09IM-0004uj-3e for forces-protocol-archive@odin.ietf.org; Sun, 07 Mar 2004 20:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i281B1qm018870 for forces-protocol-archive@odin.ietf.org; Sun, 7 Mar 2004 20:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B09IL-0004tx-7a for forces-protocol-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 20:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16664 for ; Sun, 7 Mar 2004 20:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B09IJ-0004mf-00 for forces-protocol-web-archive@ietf.org; Sun, 07 Mar 2004 20:10:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B09FQ-0003yG-00 for forces-protocol-web-archive@ietf.org; Sun, 07 Mar 2004 20:08:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B09Du-0003gB-00 for forces-protocol-web-archive@ietf.org; Sun, 07 Mar 2004 20:06:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B094o-00051M-9N for forces-protocol-web-archive@ietf.org; Sun, 07 Mar 2004 19:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B094n-00042T-89; Sun, 07 Mar 2004 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzUGL-0007OX-Q3 for forces-protocol@optimus.ietf.org; Sat, 06 Mar 2004 00:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18309 for ; Sat, 6 Mar 2004 00:22:10 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzUGJ-0003mq-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 00:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzUFN-0003e0-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 00:21:13 -0500 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx with esmtp (Exim 4.12) id 1AzUF4-0003V4-00 for forces-protocol@ietf.org; Sat, 06 Mar 2004 00:20:54 -0500 Received: from Aaudu2000@aol.com by imo-d20.mx.aol.com (mail_out_v37.4.) id l.53.6f125fc (24895) for ; Sat, 6 Mar 2004 00:20:18 -0500 (EST) Message-ID: <53.6f125fc.2d7ab992@aol.com> To: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1078550418" X-Mailer: 9.0 for Windows sub 5003 Subject: [Forces-protocol] subscribe Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 6 Mar 2004 00:20:18 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_50_60,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1078550418 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit subscribe -------------------------------1078550418 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable subscribe -------------------------------1078550418-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 00:13:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26107 for ; Mon, 8 Mar 2004 00:13:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0D4j-0002LG-8Y for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 00:13:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i285DDjS008996 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 00:13:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0D4i-0002L1-Ve for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 00:13:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26104 for ; Mon, 8 Mar 2004 00:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0D4g-0000kd-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 00:13:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0D3k-0000dD-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 00:12:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0D3X-0000Vn-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 00:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0D3Z-00029w-9L; Mon, 08 Mar 2004 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0D2j-00028K-SF for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 00:11:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26072 for ; Mon, 8 Mar 2004 00:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0D2h-0000Uz-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 00:11:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0D1z-0000NU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 00:10:24 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0D10-0000Dp-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 00:09:23 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Mon, 8 Mar 2004 13:20:41 +0800 Message-ID: <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 13:07:19 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpIaSBIb3JtdXpkLCBKYW1hbCwgYW5kIGFsbCwNCg0KUGxlYXNlIGxldCBtZSAgZmlyc3QgcHV0 IG91ciBvcmlnaW5hbCB0aG91Z2h0cyBvbiB0aGUgd2F5IHRvIGFkZHJlc3MgZW50aXRpZXMgZGVm aW5lZCBieSBGb3JDRVMgZnJhbWV3b3JrIGF0IEZvckNFUyBwcm90b2NvbCBsYXllciwgDQpzbyB0 aGF0IHdlIGNhbiBnZXQgdG8gdW5kZXJzdGFuZCBlYWNoIG90aGVyIG1vcmUgZWFzaWx5LiANCg0K V2UgdGhpbmsgYSBsYXllci1iYXNlZCB0cmVlIHN0cnVjdHVyZSBhY2NvcmRpbmcgdG8gdGhlIEZv ckNFUyBhcmNoaXRlY3R1cmUgaXMgZWZmaWNpZW50IHRvIGRvIHN1Y2ggYWRkcmVzc2luZy4gSWYg d2UgYWRkcmVzcyBlbnRpdGllcyBhdA0KdGhlIEZFIGNvYXJzZSBsYXllciAoIHRvIHRha2UgdGhl IEZFIGFzIGEgd2hvbGUgZW50aXR5LCB3aGljaCBpZGVhIGlzIGFsc28gdXNlZCBieSBuZXcgdmVy c2lvbiBvZiBGRSBtb2RlbCApLCB3ZSBvbmx5IG5lZWQgdG8gDQpoYXZlIGEgRkUgSUQuICBJZiB3 ZSBhZGRyZXNzIGVudGl0aWVzIGF0IExGQiBsYXllciwgd2UgdXNlIEZFIElEIGFsb25nIHdpdGgg YSBMRkIgSW5zdGFuY2UgSUQgdG8gc3VwcG9ydCBtdWx0aS1pbnN0YW5jZXMuICBUbyBhZGRyZXNz IA0KQ0VzLCB3ZSB1c2UgQ0UgSUQuICBCeSBkZWZpbmluZyBJRHMgZm9yIEZFIGJyb2FkY2FzdCwg TEZCIGJyb2FkY2FzdCwgTEZCIEluc3RhbmNlIGJyb2FkY2FzdCwgYW5kIENFIGJyb2FkY2FzdCwg Zm9sbG93aW5nIGFkZHJlc3NpbmcgY2FuIGJlIA0KaW1wbGVtZW50ZWQ6DQoNCi0gYW55IEZFIG9y IGFsbCBGRXMNCi0gYW55IENFIG9yIGFsbCBDRXMNCi0gYW55IExGQiBvciBhbGwgTEZCcyB3aXRo IHRoZSBzYW1lIHR5cGUgaW4gYW55IEZFIG9yIGFsbCBGRXMgDQotIGFueSBMRkJzIHdpdGggZGlm ZmVyZW50IHR5cGVzIGluIGFueSBGRSBvciBhbGwgRkVzDQoNCkkgdGhpbmsgdGhpcyBpZGVhIGlz IHF1aXRlIGlkZW50aWNhbCB3aXRoIEhvcm11emQncywgYnV0IGRpZmZlcmVudCBmcm9tIEphbWFs J3MuIExldCdzIHRha2UgYW4gZXhhbXBsZSB0byBzaG93IHRoZSBkaWZmZXJlbmNlLiBTYXkgd2Ug aGF2ZSBzZXZlcmFsDQpyb29tcyB3aXRoIG1hbnkgZGlmZmVyZW50IGNoYWlycyBhbmQgdGFibGVz IGluIGV2ZXJ5IHJvb20sIHdlIHRoZW4gbmVlZCB0byBmaW5kIHRoZSBlbnRpdGllcyBpbnNpZGUg dGhlIHJvb21zIGFzIHdlbGwgYXMgdGhlIHJvb21zIHRoZW1zZWx2ZXMuIA0KV2UgcHJvcG9zZSB0 aGF0IHRvIGZpbmQgYSByb29tLCBqdXN0IHVzZSByb29tIG51bWJlciwgdG8gZmluZCBhIGNoYWly IGluIHRoZSByb29tLCB3ZSBuZWVkIHRvIGZpcnN0IGZpbmQgdGhlIHJvb20gdGhlbiB0byBmaW5k IHRoZSBjaGFpciBpbiBpdC4gDQpJIHN1cHBvc2UgSmFtYWwncyBpZGVhIGlzIHRvIHVzZSBhIHVu aWZvcm0gSUQgdG8gZmluZCB0aGUgY2hhaXIgZGlyZWN0bHkgKCBKYW1hbCwgcGxlYXNlIGV4Y3Vz ZSBtZSBpZiBpdCdzIG5vdCByaWdodCkuIA0KDQpBcyBhIHJlc3VsdCwgd2UgbWF5IG5lZWQgdG8g aGF2ZSBzb21lIGRpc2N1c3Npb24gb24gd2hpY2ggaXMgbW9yZSBmZWFzaWJsZSwgZWZmaWNpZW50 IGFuZCBlYXNpZXIgdG8gdXNlLg0KDQpTb21lIG1vcmUgY29tbWVudHMgcHV0IGlubGluZXMgZm9y IGJvdGggeW91ciBlbWFpbCBhcyBiZWxvdy4gDQoNCkNoZWVycywNCldlaW1pbmcNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJLaG9zcmF2aSwgSG9ybXV6ZCBNIiA8aG9y bXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbT4NClRvOiA8aGFkaUB6bnl4LmNvbT4NCkNjOiA8Zm9y Y2VzLXByb3RvY29sQGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBNYXJjaCAwNywgMjAwNCA1OjM3 IEFNDQpTdWJqZWN0OiBbRm9yY2VzLXByb3RvY29sXSBSRTogSXNzdWUgMDogQXBwbGljYXRpb24g YWRkcmVzc2luZw0KDQoNCkFscmlnaHQsIGhlcmUgYXJlIG15IHZpZXdzIG9uIHRoaXMgaXNzdWUv dG9waWMuLi4NCg0KVGVybWlub2xvZ3k6IFNyYyBJRCwgRGVzdCBJRCB2cyBDRUlELCBGRUlEDQpJ IGRvbid0IGxpa2UgdG8gZ2V0IHN0dWNrIHVwIG9uIHRlcm1pbm9sb2d5LCBzbyBJIHdpbGwgZ28g d2l0aCB3aGF0ZXZlcg0KdGhlIG1ham9yaXR5IGxpa2VzIG9uIHRoaXMgYXMgbG9uZyBhcyB3ZSBh Z3JlZSBvbiB0aGUgc2VtYW50aWNzLg0KDQpbV2FuZyBSZV0NClBlcnNvbmFsbHkgSSBwcmVmZXIg RkUgSUQgYW5kIENFIElEIGFzIHRoZSBuYW1lcy4gSW4gb3RoZXIgd29yZHMsIEkgd291bGQgbGlr ZSB0byB0ZWxsIGFuIGVuZ2luZWVyIA0KIiBwbGVhc2UgaGVscCB0byBmaXQgRkUgSUQgeHh4Iiwg cmF0aGVyIHRoYW4gInRvIGZpdCBEZXN0IElEIHh4eCIuICBCdXQgSSdtIGFmcmFpZCBpbiBmYWN0 IHRoZSBTcmMuSUQgYW5kIERlc3QgSUQNCmhlcmUgYXJlIG5vdCBqdXN0IGZvciBGRXMgYW5kIENF cy4gDQpbL1dhbmcgUmVdDQoNClNlbWFudGljczogVGhpcyBpcyB3aGVyZSB3ZSBkaWZmZXIgYSBi aXQuIEFzIG91ciB0ZXJtaW5vbG9neSBzdWdnZXN0cywNCnRoZXNlIGNhbiBiZSBpbmRpdmlkdWFs IEZFLCBncm91cCBvZiBGRSwgYWxsIEZFcyBhbmQgc2FtZSBhcHBsaWVzIGZvcg0KQ0VzLiBIb3dl dmVyLCB0aGlzIGZpZWxkIGRvZXMgbm90IHJlcHJlc2VudCBMRkJzLiBMRkIgSUQgaXMgc29tZXRo aW5nDQp3aGljaCBoYXMgdG8gYmUgYXNzaWduZWQgYnkgRkVzIGZvciByZXByZXNlbnRpbmcgc3Rh dGljIHRvcG9sb2dpZXMsIGFuZA0KbWF5IGJlIGFzc2lnbmVkIGJ5IEZFcyBmb3IgZHluYW1pYyB0 b3BvbG9naWVzIChJIHRoaW5rIHRoaXMgaXMgYWxzbyB3aGF0DQp0aGUgTW9kZWwgdGVhbSBjb25j bHVkZWQgb24gdGhpcyBpc3N1ZSwgYnV0IG5vdCAxMDAlIHN1cmUpLiBJbiBjb250cmFzdCwNCkZF IElEcyBpcyBzb21ldGhpbmcgYXNzaWduZWQgYnkgdGhlIENFIGFzIEphbWFsIHN1Z2dlc3RlZC4g TW9yZW92ZXIgTEZCDQpJRCBpcyBub3Qgc29tZXRoaW5nIHdoaWNoIGlzIG5lZWRlZCBpbiBhbGwg Rm9yQ0VTIG1lc3NhZ2VzLCBoZW5jZSBkb2VzDQpub3QgbmVlZCB0byBiZSBpbiB0aGUgY29tbW9u IGhlYWRlci4gSXQgd2lsbCBiZSBwYXJ0IG9mIHRoZSBUTFYgZGVmaW5lZA0KZm9yIGNhcnJ5aW5n IGNvbmZpZ3VyYXRpb24vY29udHJvbC9ldmVudCBtZXNzYWdlcy4NCg0KW1dhbmcgUmU6IEFncmVl XSANCg0KTGVuZ3RoOiBBY2MgdG8gdGhlIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cywgd2UgbmVl ZCB0byBzdXBwb3J0IGh1bmRyZWRzDQpvZiBGRXMgKDw9MTAwMCkgYW5kIGV2ZW4gbXVjaCBsZXNz IG5vIG9mIENFcyAoPD0xMDApLiBTbyAxMCBiaXRzIHdvdWxkDQpiZSBlbm91Z2ggZm9yIEZFSUQv RGVzdCBJRCBhbmQgNyBiaXRzIGZvciBDRUlELyBTcmMgSUQuIEhvd2V2ZXIsIGluDQpvcmRlciB0 byBhY2NvbW1vZGF0ZSBldmVuIGhpZ2hlciByZXF1aXJlbWVudHMgYW5kIGhhdmUgdGhlIGZpZWxk cyAzMi1iaXQNCmFsaWduZWQgd2UgdXNlZCAxNiBiaXRzIGZvciBGRUlELCBDRUlELiBJZiB0aGVy ZSBpcyBhIGdvb2QgdGVjaG5pY2FsDQpyZWFzb24gZm9yIHJlcXVpcmluZyAzMi1iaXRzIEkgd291 bGQgYmUgd2lsbGluZyB0byBjb21wcm9taXNlIG9uIHRoaXMuDQpIb3dldmVyLCBvbmUgdGhpbmcg dG8ga2VlcCBpbiBtaW5kIGlzIHRoYXQgdGhpcyBpcyB0aGUgY29tbW9uIGhlYWRlciBzbw0KZXZl cnkgYnl0ZSB3ZSBhZGQgdG8gaXQgd2lsbCBiZSBhZGRlZCB0byBhbGwgdGhlIG1lc3NhZ2VzLCBz byBpdCB3b3VsZA0KYmUgYSBnb29kIGRlc2lnbiBwcmluY2lwbGUgdG8gYmUgYSBiaXQgc3Rpbmd5 IGhlcmUuIElmIGl0IHdhcyBwYXJ0IG9mIGFuDQpvcHRpb25hbCBUTFYsIHdlIHdvdWxkbid0IGNh cmUgYXMgbXVjaC4NCg0KW1dhbmcgUmU6IEFncmVlXQ0KDQpMZXQgbWUga25vdyB3aGF0IG90aGVy IHZpZXdzIGFyZSBvbiB0aGlzIHRvcGljLg0KDQpUaGFua3MNCkhvcm11emQNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEphbWFsIEhhZGkgU2FsaW0gW21haWx0bzpoYWRpQHpu eXguY29tXSANClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwNCwgMjAwNCAxOjQ4IFBNDQpUbzogS2hv c3JhdmksIEhvcm11emQgTQ0KQ2M6IGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KU3ViamVjdDog SXNzdWUgMDogQXBwbGljYXRpb24gYWRkcmVzc2luZw0KDQpIb3JtdXpkLA0KaGVyZXMgc29tZSB0 ZXh0IGZvciBhcHBsaWNhdGlvbiBhZGRyZXNzaW5nDQoNCi0tLS0NClNvdXJjZSBhbmQgRGVzdGlu YXRpb24gSURzOg0KDQpUaGVzZSBhcmUgYXBwbGljYXRpb24gbGV2ZWwgaWRlbnRpZmllcnMuIFRo ZXkgY291bGQgYmUgdXNlZA0KdG8gYWRkcmVzcyB0aGUgZm9sbG93aW5nOg0KLSBhbiBMRkIgb24g dGhlIEZFLA0KLSBhIHNldCBvZiBMRkJzIG9uIGFuIEZFDQotIGEgc2V0IG9mIExGQnMgb24gZGlm ZmVyZW50IEZFcyANCg0KDQpbV2FuZyBSZTogQXJlIHRoZSBzZXQgb2YgTEZCcyBvZiB0aGUgc2Ft ZSB0eXBlP10NCg0KLSBwcm94aWVzIGZvciBMRkJzLA0KLSBwcm94aWVzIGZvciBjb250cm9sIGFw cGxpY2F0aW9uIGluIHRoZSBmb3JtIG9uIHRoZSBDRXMsIA0KDQpbV2FuZyBSZTogIElmIGV2ZXIg d2UgaGF2ZSB0aGVzZSBwcm94aWVzLCBhcmUgdGhleSBuZWVkIHRvIGJlIHNlZW4gYXQgdGhlIHBy b3RvY29sIGxheWVyPyANCk1vcmVvdmVyLCBob3cgYWJvdXQgRkUgcHJveGllcyB0aGVuP10NCg0K LSB0aGUgRkUsDQotIGEgc2V0IG9mIEZFcw0KLSBhbGwgRkVzDQotIHRoZSBDRS4NCi0gYSBzZXQg b2YgQ0VzDQotIGFsbCBDRXMNCg0KVGhlIGFib3ZlIHNob3dzIG5lZWQgZm9yIGhhdmluZyB0aGUg SUQgYmVpbmcgYWJsZSB0byBiZSBJRGVkDQphcyB1bmljYXN0LCBicm9hZGNhc3Qgb3IgbXVsdGlj YXN0Lg0KDQpGb3IgY2xhcml0eSwgaSBjb3VsZCBjcmVhdGUgYSBkaWFncmFtIG9mIHdoYXQgd2Ug dXNlZC4NCg0KSSB3aWxsIHBvc3QgdGhlIGhlYWRlciBpIHBvc3RlZCBlYXJsaWVyIG5leHQuIE9y IG1heWJlIHdlIHNob3VsZCANCnN0aWNrIHRvIHJlc29sdmluZyB0aGlzIGZpcnN0Lg0KSG9wZWZ1 bGx5IHdlIGNhbiBnZXQgdG8gYSBnb29kIHdheSB0byBiZWF0IHRoZSBzZXZlcmFsIGlzc3Vlcywg aSBhbQ0KZG9pbmcgdGhpcyB0byBob3BlZnVseSBjb21lIHRvIGEgc3R5bGUgdGhhdCB3ZSBjYW4g dXNlIHRvIGJlYXQgdGhlDQppc3N1ZXMuDQoNCmNoZWVycywNCmphbWFsDQogDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 01:41:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29133 for ; Mon, 8 Mar 2004 01:41:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ERu-0007sQ-Ef for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 01:41:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i286fEFk030274 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 01:41:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ERu-0007sD-4N for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 01:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29130 for ; Mon, 8 Mar 2004 01:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ERq-0005Lk-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:41:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0EQy-0005F0-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:40:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0EQk-00057Z-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EQn-0007dK-4A; Mon, 08 Mar 2004 01:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EQ1-0007Se-DQ for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 01:39:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29081 for ; Mon, 8 Mar 2004 01:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0EPy-00056q-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:39:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0EP4-0004zQ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:38:19 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0EOl-0004rL-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:37:59 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i286fARi027051; Mon, 8 Mar 2004 06:41:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i286dBvN023257; Mon, 8 Mar 2004 06:39:16 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030722372212289 ; Sun, 07 Mar 2004 22:37:22 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 7 Mar 2004 22:37:22 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E0542EC@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQEy+WDvKF7raT1Sm2p662Hqj1ecAAC67LQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 08 Mar 2004 06:37:22.0819 (UTC) FILETIME=[D00CB530:01C404D7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 22:37:22 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgV2VpbWluZywNCg0KVGhpcyBpcyBnb29kLCB0aGFua3MgZm9yIHNlbmRpbmcgeW91ciBwb2lu dCBvZiB2aWV3LiBJdCBzZWVtcyBsaWtlIHdlIGFyZSBpbiBhZ3JlZW1lbnQgb24gdGhpcyBvbmUu DQoNClRoYW5rcw0KSG9ybXV6ZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Zm9yY2VzLXByb3RvY29sLWFkbWluQGlldGYub3JnIFttYWlsdG86Zm9yY2VzLXByb3RvY29sLWFk bWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2FuZyxXZWltaW5nDQpTZW50OiBTdW5kYXksIE1h cmNoIDA3LCAyMDA0IDk6MDcgUE0NClRvOiBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSBJc3N1ZSAwOiBBcHBsaWNhdGlvbiBhZGRyZXNzaW5n DQoNCg0KSGkgSG9ybXV6ZCwgSmFtYWwsIGFuZCBhbGwsDQoNClBsZWFzZSBsZXQgbWUgIGZpcnN0 IHB1dCBvdXIgb3JpZ2luYWwgdGhvdWdodHMgb24gdGhlIHdheSB0byBhZGRyZXNzIGVudGl0aWVz IGRlZmluZWQgYnkgRm9yQ0VTIGZyYW1ld29yayBhdCBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsIA0K c28gdGhhdCB3ZSBjYW4gZ2V0IHRvIHVuZGVyc3RhbmQgZWFjaCBvdGhlciBtb3JlIGVhc2lseS4g DQoNCldlIHRoaW5rIGEgbGF5ZXItYmFzZWQgdHJlZSBzdHJ1Y3R1cmUgYWNjb3JkaW5nIHRvIHRo ZSBGb3JDRVMgYXJjaGl0ZWN0dXJlIGlzIGVmZmljaWVudCB0byBkbyBzdWNoIGFkZHJlc3Npbmcu IElmIHdlIGFkZHJlc3MgZW50aXRpZXMgYXQNCnRoZSBGRSBjb2Fyc2UgbGF5ZXIgKCB0byB0YWtl IHRoZSBGRSBhcyBhIHdob2xlIGVudGl0eSwgd2hpY2ggaWRlYSBpcyBhbHNvIHVzZWQgYnkgbmV3 IHZlcnNpb24gb2YgRkUgbW9kZWwgKSwgd2Ugb25seSBuZWVkIHRvIA0KaGF2ZSBhIEZFIElELiAg SWYgd2UgYWRkcmVzcyBlbnRpdGllcyBhdCBMRkIgbGF5ZXIsIHdlIHVzZSBGRSBJRCBhbG9uZyB3 aXRoIGEgTEZCIEluc3RhbmNlIElEIHRvIHN1cHBvcnQgbXVsdGktaW5zdGFuY2VzLiAgVG8gYWRk cmVzcyANCkNFcywgd2UgdXNlIENFIElELiAgQnkgZGVmaW5pbmcgSURzIGZvciBGRSBicm9hZGNh c3QsIExGQiBicm9hZGNhc3QsIExGQiBJbnN0YW5jZSBicm9hZGNhc3QsIGFuZCBDRSBicm9hZGNh c3QsIGZvbGxvd2luZyBhZGRyZXNzaW5nIGNhbiBiZSANCmltcGxlbWVudGVkOg0KDQotIGFueSBG RSBvciBhbGwgRkVzDQotIGFueSBDRSBvciBhbGwgQ0VzDQotIGFueSBMRkIgb3IgYWxsIExGQnMg d2l0aCB0aGUgc2FtZSB0eXBlIGluIGFueSBGRSBvciBhbGwgRkVzIA0KLSBhbnkgTEZCcyB3aXRo IGRpZmZlcmVudCB0eXBlcyBpbiBhbnkgRkUgb3IgYWxsIEZFcw0KDQpJIHRoaW5rIHRoaXMgaWRl YSBpcyBxdWl0ZSBpZGVudGljYWwgd2l0aCBIb3JtdXpkJ3MsIGJ1dCBkaWZmZXJlbnQgZnJvbSBK YW1hbCdzLiBMZXQncyB0YWtlIGFuIGV4YW1wbGUgdG8gc2hvdyB0aGUgZGlmZmVyZW5jZS4gU2F5 IHdlIGhhdmUgc2V2ZXJhbA0Kcm9vbXMgd2l0aCBtYW55IGRpZmZlcmVudCBjaGFpcnMgYW5kIHRh YmxlcyBpbiBldmVyeSByb29tLCB3ZSB0aGVuIG5lZWQgdG8gZmluZCB0aGUgZW50aXRpZXMgaW5z aWRlIHRoZSByb29tcyBhcyB3ZWxsIGFzIHRoZSByb29tcyB0aGVtc2VsdmVzLiANCldlIHByb3Bv c2UgdGhhdCB0byBmaW5kIGEgcm9vbSwganVzdCB1c2Ugcm9vbSBudW1iZXIsIHRvIGZpbmQgYSBj aGFpciBpbiB0aGUgcm9vbSwgd2UgbmVlZCB0byBmaXJzdCBmaW5kIHRoZSByb29tIHRoZW4gdG8g ZmluZCB0aGUgY2hhaXIgaW4gaXQuIA0KSSBzdXBwb3NlIEphbWFsJ3MgaWRlYSBpcyB0byB1c2Ug YSB1bmlmb3JtIElEIHRvIGZpbmQgdGhlIGNoYWlyIGRpcmVjdGx5ICggSmFtYWwsIHBsZWFzZSBl eGN1c2UgbWUgaWYgaXQncyBub3QgcmlnaHQpLiANCg0KQXMgYSByZXN1bHQsIHdlIG1heSBuZWVk IHRvIGhhdmUgc29tZSBkaXNjdXNzaW9uIG9uIHdoaWNoIGlzIG1vcmUgZmVhc2libGUsIGVmZmlj aWVudCBhbmQgZWFzaWVyIHRvIHVzZS4NCg0KU29tZSBtb3JlIGNvbW1lbnRzIHB1dCBpbmxpbmVz IGZvciBib3RoIHlvdXIgZW1haWwgYXMgYmVsb3cuIA0KDQpDaGVlcnMsDQpXZWltaW5nDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiS2hvc3JhdmksIEhvcm11emQgTSIg PGhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20+DQpUbzogPGhhZGlAem55eC5jb20+DQpDYzog PGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZz4NClNlbnQ6IFN1bmRheSwgTWFyY2ggMDcsIDIwMDQg NTozNyBBTQ0KU3ViamVjdDogW0ZvcmNlcy1wcm90b2NvbF0gUkU6IElzc3VlIDA6IEFwcGxpY2F0 aW9uIGFkZHJlc3NpbmcNCg0KDQpBbHJpZ2h0LCBoZXJlIGFyZSBteSB2aWV3cyBvbiB0aGlzIGlz c3VlL3RvcGljLi4uDQoNClRlcm1pbm9sb2d5OiBTcmMgSUQsIERlc3QgSUQgdnMgQ0VJRCwgRkVJ RA0KSSBkb24ndCBsaWtlIHRvIGdldCBzdHVjayB1cCBvbiB0ZXJtaW5vbG9neSwgc28gSSB3aWxs IGdvIHdpdGggd2hhdGV2ZXINCnRoZSBtYWpvcml0eSBsaWtlcyBvbiB0aGlzIGFzIGxvbmcgYXMg d2UgYWdyZWUgb24gdGhlIHNlbWFudGljcy4NCg0KW1dhbmcgUmVdDQpQZXJzb25hbGx5IEkgcHJl ZmVyIEZFIElEIGFuZCBDRSBJRCBhcyB0aGUgbmFtZXMuIEluIG90aGVyIHdvcmRzLCBJIHdvdWxk IGxpa2UgdG8gdGVsbCBhbiBlbmdpbmVlciANCiIgcGxlYXNlIGhlbHAgdG8gZml0IEZFIElEIHh4 eCIsIHJhdGhlciB0aGFuICJ0byBmaXQgRGVzdCBJRCB4eHgiLiAgQnV0IEknbSBhZnJhaWQgaW4g ZmFjdCB0aGUgU3JjLklEIGFuZCBEZXN0IElEDQpoZXJlIGFyZSBub3QganVzdCBmb3IgRkVzIGFu ZCBDRXMuIA0KWy9XYW5nIFJlXQ0KDQpTZW1hbnRpY3M6IFRoaXMgaXMgd2hlcmUgd2UgZGlmZmVy IGEgYml0LiBBcyBvdXIgdGVybWlub2xvZ3kgc3VnZ2VzdHMsDQp0aGVzZSBjYW4gYmUgaW5kaXZp ZHVhbCBGRSwgZ3JvdXAgb2YgRkUsIGFsbCBGRXMgYW5kIHNhbWUgYXBwbGllcyBmb3INCkNFcy4g SG93ZXZlciwgdGhpcyBmaWVsZCBkb2VzIG5vdCByZXByZXNlbnQgTEZCcy4gTEZCIElEIGlzIHNv bWV0aGluZw0Kd2hpY2ggaGFzIHRvIGJlIGFzc2lnbmVkIGJ5IEZFcyBmb3IgcmVwcmVzZW50aW5n IHN0YXRpYyB0b3BvbG9naWVzLCBhbmQNCm1heSBiZSBhc3NpZ25lZCBieSBGRXMgZm9yIGR5bmFt aWMgdG9wb2xvZ2llcyAoSSB0aGluayB0aGlzIGlzIGFsc28gd2hhdA0KdGhlIE1vZGVsIHRlYW0g Y29uY2x1ZGVkIG9uIHRoaXMgaXNzdWUsIGJ1dCBub3QgMTAwJSBzdXJlKS4gSW4gY29udHJhc3Qs DQpGRSBJRHMgaXMgc29tZXRoaW5nIGFzc2lnbmVkIGJ5IHRoZSBDRSBhcyBKYW1hbCBzdWdnZXN0 ZWQuIE1vcmVvdmVyIExGQg0KSUQgaXMgbm90IHNvbWV0aGluZyB3aGljaCBpcyBuZWVkZWQgaW4g YWxsIEZvckNFUyBtZXNzYWdlcywgaGVuY2UgZG9lcw0Kbm90IG5lZWQgdG8gYmUgaW4gdGhlIGNv bW1vbiBoZWFkZXIuIEl0IHdpbGwgYmUgcGFydCBvZiB0aGUgVExWIGRlZmluZWQNCmZvciBjYXJy eWluZyBjb25maWd1cmF0aW9uL2NvbnRyb2wvZXZlbnQgbWVzc2FnZXMuDQoNCltXYW5nIFJlOiBB Z3JlZV0gDQoNCkxlbmd0aDogQWNjIHRvIHRoZSBzY2FsYWJpbGl0eSByZXF1aXJlbWVudHMsIHdl IG5lZWQgdG8gc3VwcG9ydCBodW5kcmVkcw0Kb2YgRkVzICg8PTEwMDApIGFuZCBldmVuIG11Y2gg bGVzcyBubyBvZiBDRXMgKDw9MTAwKS4gU28gMTAgYml0cyB3b3VsZA0KYmUgZW5vdWdoIGZvciBG RUlEL0Rlc3QgSUQgYW5kIDcgYml0cyBmb3IgQ0VJRC8gU3JjIElELiBIb3dldmVyLCBpbg0Kb3Jk ZXIgdG8gYWNjb21tb2RhdGUgZXZlbiBoaWdoZXIgcmVxdWlyZW1lbnRzIGFuZCBoYXZlIHRoZSBm aWVsZHMgMzItYml0DQphbGlnbmVkIHdlIHVzZWQgMTYgYml0cyBmb3IgRkVJRCwgQ0VJRC4gSWYg dGhlcmUgaXMgYSBnb29kIHRlY2huaWNhbA0KcmVhc29uIGZvciByZXF1aXJpbmcgMzItYml0cyBJ IHdvdWxkIGJlIHdpbGxpbmcgdG8gY29tcHJvbWlzZSBvbiB0aGlzLg0KSG93ZXZlciwgb25lIHRo aW5nIHRvIGtlZXAgaW4gbWluZCBpcyB0aGF0IHRoaXMgaXMgdGhlIGNvbW1vbiBoZWFkZXIgc28N CmV2ZXJ5IGJ5dGUgd2UgYWRkIHRvIGl0IHdpbGwgYmUgYWRkZWQgdG8gYWxsIHRoZSBtZXNzYWdl cywgc28gaXQgd291bGQNCmJlIGEgZ29vZCBkZXNpZ24gcHJpbmNpcGxlIHRvIGJlIGEgYml0IHN0 aW5neSBoZXJlLiBJZiBpdCB3YXMgcGFydCBvZiBhbg0Kb3B0aW9uYWwgVExWLCB3ZSB3b3VsZG4n dCBjYXJlIGFzIG11Y2guDQoNCltXYW5nIFJlOiBBZ3JlZV0NCg0KTGV0IG1lIGtub3cgd2hhdCBv dGhlciB2aWV3cyBhcmUgb24gdGhpcyB0b3BpYy4NCg0KVGhhbmtzDQpIb3JtdXpkDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1hbCBIYWRpIFNhbGltIFttYWlsdG86aGFk aUB6bnl4LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDQsIDIwMDQgMTo0OCBQTQ0KVG86 IEtob3NyYXZpLCBIb3JtdXpkIE0NCkNjOiBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNClN1Ympl Y3Q6IElzc3VlIDA6IEFwcGxpY2F0aW9uIGFkZHJlc3NpbmcNCg0KSG9ybXV6ZCwNCmhlcmVzIHNv bWUgdGV4dCBmb3IgYXBwbGljYXRpb24gYWRkcmVzc2luZw0KDQotLS0tDQpTb3VyY2UgYW5kIERl c3RpbmF0aW9uIElEczoNCg0KVGhlc2UgYXJlIGFwcGxpY2F0aW9uIGxldmVsIGlkZW50aWZpZXJz LiBUaGV5IGNvdWxkIGJlIHVzZWQNCnRvIGFkZHJlc3MgdGhlIGZvbGxvd2luZzoNCi0gYW4gTEZC IG9uIHRoZSBGRSwNCi0gYSBzZXQgb2YgTEZCcyBvbiBhbiBGRQ0KLSBhIHNldCBvZiBMRkJzIG9u IGRpZmZlcmVudCBGRXMgDQoNCg0KW1dhbmcgUmU6IEFyZSB0aGUgc2V0IG9mIExGQnMgb2YgdGhl IHNhbWUgdHlwZT9dDQoNCi0gcHJveGllcyBmb3IgTEZCcywNCi0gcHJveGllcyBmb3IgY29udHJv bCBhcHBsaWNhdGlvbiBpbiB0aGUgZm9ybSBvbiB0aGUgQ0VzLCANCg0KW1dhbmcgUmU6ICBJZiBl dmVyIHdlIGhhdmUgdGhlc2UgcHJveGllcywgYXJlIHRoZXkgbmVlZCB0byBiZSBzZWVuIGF0IHRo ZSBwcm90b2NvbCBsYXllcj8gDQpNb3Jlb3ZlciwgaG93IGFib3V0IEZFIHByb3hpZXMgdGhlbj9d DQoNCi0gdGhlIEZFLA0KLSBhIHNldCBvZiBGRXMNCi0gYWxsIEZFcw0KLSB0aGUgQ0UuDQotIGEg c2V0IG9mIENFcw0KLSBhbGwgQ0VzDQoNClRoZSBhYm92ZSBzaG93cyBuZWVkIGZvciBoYXZpbmcg dGhlIElEIGJlaW5nIGFibGUgdG8gYmUgSURlZA0KYXMgdW5pY2FzdCwgYnJvYWRjYXN0IG9yIG11 bHRpY2FzdC4NCg0KRm9yIGNsYXJpdHksIGkgY291bGQgY3JlYXRlIGEgZGlhZ3JhbSBvZiB3aGF0 IHdlIHVzZWQuDQoNCkkgd2lsbCBwb3N0IHRoZSBoZWFkZXIgaSBwb3N0ZWQgZWFybGllciBuZXh0 LiBPciBtYXliZSB3ZSBzaG91bGQgDQpzdGljayB0byByZXNvbHZpbmcgdGhpcyBmaXJzdC4NCkhv cGVmdWxseSB3ZSBjYW4gZ2V0IHRvIGEgZ29vZCB3YXkgdG8gYmVhdCB0aGUgc2V2ZXJhbCBpc3N1 ZXMsIGkgYW0NCmRvaW5nIHRoaXMgdG8gaG9wZWZ1bHkgY29tZSB0byBhIHN0eWxlIHRoYXQgd2Ug Y2FuIHVzZSB0byBiZWF0IHRoZQ0KaXNzdWVzLg0KDQpjaGVlcnMsDQpqYW1hbA0KIA0KFsWgesOK wqLDmsKiWcWgWOKAmljCtFpxw6vCruKAuXLigLB6w5fCrgjCtuKAusO/DQrDlid+xaDDvmbigJNm w75YwrYpwqPDt8Ktw4fCpsK6wqHDig0KDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 01:59:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29919 for ; Mon, 8 Mar 2004 01:59:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EjW-0000c8-Bs for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 01:59:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i286xQRG002360 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 01:59:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EjV-0000br-Uw for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 01:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29915 for ; Mon, 8 Mar 2004 01:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0EjS-00007H-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Eid-0007mZ-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:58:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ei8-0007d3-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 01:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EiA-0000Yo-Fd; Mon, 08 Mar 2004 01:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EhS-0000Xe-69 for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 01:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29788 for ; Mon, 8 Mar 2004 01:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0EhO-0007ZX-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Egc-0007RN-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:56:27 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Efg-00079A-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 01:55:29 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i286wfRi001787; Mon, 8 Mar 2004 06:58:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i286uivT030268; Mon, 8 Mar 2004 06:56:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030722545824443 ; Sun, 07 Mar 2004 22:54:58 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 7 Mar 2004 22:54:58 -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 Message-ID: <468F3FDA28AA87429AD807992E22D07E0542F0@orsmsx408.jf.intel.com> Thread-Topic: Issue 0: Application addressing Thread-Index: AcQD8TTIc1IHLhokRP2GNK67z5rLxgA5uWcg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 08 Mar 2004 06:54:58.0465 (UTC) FILETIME=[45438110:01C404DA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: Issue 0: Application addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 22:54:58 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > Terminology: Src ID, Dest ID vs CEID, FEID > I don't like to get stuck up on terminology, so I will go with whatever > the majority likes on this as long as we agree on the semantics. Same here. [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go with that terminology then? > Semantics: This is where we differ a bit. As our terminology suggests, > these can be individual FE, group of FE, all FEs and same applies for > CEs. However, this field does not represent LFBs. LFB ID is something > which has to be assigned by FEs for representing static topologies, and > may be assigned by FEs for dynamic topologies (I think this is also what > the Model team concluded on this issue, but not 100% sure). In contrast, > FE IDs is something assigned by the CE as Jamal suggested. Moreover LFB > ID is not something which is needed in all ForCES messages, hence does > not need to be in the common header. It will be part of the TLV defined > for carrying configuration/control/event messages. My wording was insufficient. The targeted end point for an ID is not something thats on the datapath (although i have a feeling some of the NPF folks may disagree with me). In otherwords, the ID is that of a Forces application (or OS process or thread) which resides on a CE or FE. If we looked at the entity that is being addressed by this ID as a forces application then we could say that: - the ID is always needed since there maybe more than one such app on a specific endsystem. This is true regardless of the end system being a CE or FE.=20 So lets ignore the LFB part and see if the above is agreeable. [HK] I don't see the value of having an App ID in the common header. How is it useful ? May be if you could give a good example of how this can be used, it would help. The ForCES endpoints are CEs and FEs which should be addressed in the common header. LFBs are like knobs on the FEs used to program its functionality. I am sure you know all this very well and I think most folks will agree on this. If we go with a different view, we will probably land up breaking the FE Model as well. Other views on this one ? > Length: Acc to the scalability requirements, we need to support hundreds > of FEs (<=3D1000) and even much less no of CEs (<=3D100). So 10 bits = would > be enough for FEID/Dest ID and 7 bits for CEID/ Src ID. However, in > order to accommodate even higher requirements and have the fields 32-bit >.... 32 bits is not that expensive and it always saves you from famous last words like "nobody will ever need more than 640K of RAM" or=20 "you can give light bulbs IP addresses if you used 32 bit IP addresses". The partitioning of CEID or FEID is a little limiting in my opinion. The end target may not be precisely a CE or FE; it could be an OSPF=20 offloader on an FE.=20 [HK] Could you give me an example of why this is limiting? I would like to know if using 16 bits would break in some scenarios. If this was part of a TLV I wouldn't care as much, but since this is the common header, I am a bit concerned...acting stingy :-)) > However, one thing to keep in mind is that this is the common header so > every byte we add to it will be added to all the messages, so it would > be a good design principle to be a bit stingy here. If it was part of an > optional TLV, we wouldn't care as much. Forces is almost middleware; typical middleware abuses a lot of the PID space usually around 128 bits for each direction. Example look at corba or: http://www.rti.com/products/ndds/index.html Note in their case the IDs above are known as UUIDs with one of the Us standing for universal; in our case the universe is the NE so a 32 bit maybe suffice. [HK] Exactly, ForCES has much limited/specific scope (NE) than general purpose middleware such as Corba. You cannot compare these 2 because of the difference in scope. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 02:17:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13054 for ; Mon, 8 Mar 2004 02:17:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0F0m-0006U6-V6 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 02:17:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i287HGj9024903 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 02:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0F0l-0006TM-09 for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 02:17:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13015 for ; Mon, 8 Mar 2004 02:17:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0F0h-0002Pj-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:17:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ezl-0002J6-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:16:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0EzW-0002CB-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:15:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0EzY-0003CX-T4 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0EzY-00068e-Mm; Mon, 08 Mar 2004 02:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Eyp-0005w7-9B for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 02:15:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12875 for ; Mon, 8 Mar 2004 02:15:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Eyl-0002BD-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:15:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Exo-00023u-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:14:12 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0ExP-0001wG-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:13: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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i287H0Ri009885; Mon, 8 Mar 2004 07:17:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i287F6vN006212; Mon, 8 Mar 2004 07:15:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030723131626630 ; Sun, 07 Mar 2004 23:13:16 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 7 Mar 2004 23:13:16 -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 Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E0542F5@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQD8ho0/Xelh9jEQf2vTOh8dSRJWAA6HSFg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 08 Mar 2004 07:13:16.0934 (UTC) FILETIME=[D4009260:01C404DC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 23:13:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- On Behalf Of Jamal Hadi Salim > Here are my views on this issue, particularly the common header: >=20 > Command: Agree this is needed. We think 8-12 bits will be more than > sufficient for this depending on whether it is subdivided. We have > sub-divided this field into Class/type...this is an OO approach, seemed > pretty neat. However, I am personally fine with having a single field > for this, no problem with that. I think we could resolve this later; i am not seeing a lot of commands. On the outset i can only see ADD/DEL/GET [HK] Ok, we can resolve this later. So I guess you are fine with 8 bits for the command? especially, if you only see a few of them. > Flags/Priority: We need 2-3 bits for priority in every message. I don't > think we need any other flags in all messages. How do you propose we do things like 2 phase commits; atomic transactions etc? [HK] You need flags for this, however this is only for configuration messages, they don't have to be in the common header. They will be part of the config message TLV. As you said below... "Agreed - the main thing is that if something needs to be used in all messages then it should go on this header (since its cheaper than a TLV)." Also in regards to priority; do you see this being used all the time? [HK] Sure, this is definitely needed in all messages. I believe even GRMP has this, infact I had a feeling till today that even netlink had it. and would an underlying transport priority be insufficient (example diffserv, 802.1p etc)? [HK] This is priority at the ForCES level which will eventually be mapped to the underlying transport/interconnect. We definitely need it at the ForCES level as well. > Typeid: This is one field I don't think is needed in all messages. I am > not sure why this is needed at all cause, we will be using the Model and > LFB IDs to address processing functional blocks on the FEs. I am not sure i see this. If you could explain more mayeb it would help. Like i said the only value is in being able to look at the outer header and recognizing for example the target where the message is being sent to (example LFB class). If not for anything else, debugging (via sniffing) is a good reason - this way i could dump the rest of the message by recognizing what the TLVs mean. [HK] Debugging doesn't seem to be a good reason to me to add a field to the common header. It has to be something very useful for the protocol and all messages. What do others think about this one? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 02:42:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14436 for ; Mon, 8 Mar 2004 02:42:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FPB-0002qS-7m for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 02:42:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i287gTFx010935 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 02:42:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FPA-0002q3-Jl for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 02:42:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14428 for ; Mon, 8 Mar 2004 02:42:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0FP6-0005wt-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:42:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FOE-0005oT-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:41:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0FNj-0005eu-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 02:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FNm-0002ls-4j; Mon, 08 Mar 2004 02:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FN9-0002ki-V6 for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 02:40:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14385 for ; Mon, 8 Mar 2004 02:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0FN1-0005e3-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:40:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FM7-0005WE-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:39:19 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0FLN-0005GK-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 02:38:33 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i287e9pk012260; Mon, 8 Mar 2004 07:40:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i287dnvP014700; Mon, 8 Mar 2004 07:39:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030723380316731 ; Sun, 07 Mar 2004 23:38:03 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 7 Mar 2004 23:38: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 Subject: RE: [Forces-protocol] Issue 100: On the issue play Message-ID: <468F3FDA28AA87429AD807992E22D07E0542F8@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 100: On the issue play Thread-Index: AcQD+1QczYXR59skRKGSrjXD1EFhwwA5HWhg From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 08 Mar 2004 07:38:03.0826 (UTC) FILETIME=[4A424920:01C404E0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 7 Mar 2004 23:38:03 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, A request on this one, as Jamal suggested lets go with the issues sequentially. Otherwise it will be impossible for all of us to keep up. ForCES protocol is not my full time job and that is true for most of the folks on this team. So I would request that we give everyone some breading time to understand and comment on all the issues. Thanks a lot for your understanding and patience, The issue on multiple channels will be the next, once we resolve the header. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Saturday, March 06, 2004 8:17 PM To: Wang,Weiming Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 100: On the issue play On Sat, 2004-03-06 at 22:46, Wang,Weiming wrote: > > I saw that email. Can we ignore it for now if you dont mind until we > > address 0-2? I am not gonna respond to your other emails so we can have > > some order to any chaos. >=20 > [Weiming Re] > The multichannel issue is quite related to the congestion control issue, therefore, if we want to be more focus, I suggest > just to bigin with 0,1 only, leaving2,3,4 as the following group. Or else, I think it's reasonable to start with 0-4. Actually we > already had many discussions on these. It seems not very well to stop these discussions all of a sudden. Moreover, issue 1 is=20 > quite a big issue, I don't think it can be closed within one week. Then, we can count how much time is left. Therefore, I suggest > to work with more parallellism.=20 >=20 The idea is not to agree on the "how"; rather on what of the merger i.e=20 that we can narrow any differences into a small tight area. Thats what needs to be reported back by the 20th. So it should not take many emails to address issue 1 in that scope. As far as i can see from the discussion this should be soon closed.=20 On issue 2 Hormuzd was putting some text around it. Why not wait until he does so? I know its hot for you - but it would help to have a starting point. In the meantime i think it would be useful if you address issue 0 and 1. We are going to talk about every issue that is bothering you, not to worry; lets just do it sequentially. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 03:21:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15909 for ; Mon, 8 Mar 2004 03:21:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0G0l-0005xH-NZ for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 03:21:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i288LJv6022888 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 03:21:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0G0l-0005x5-5V for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 03:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15892 for ; Mon, 8 Mar 2004 03:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0G0j-00048C-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 03:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Fzp-0003wl-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 03:20:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0FzW-0003ob-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 03:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FzX-0005re-UW; Mon, 08 Mar 2004 03:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Fz1-0005nU-V6 for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 03:19:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15754 for ; Mon, 8 Mar 2004 03:19:29 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Fyz-0003nu-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 03:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FyB-0003dr-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 03:18:39 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B0FxG-0003Se-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 03:17:42 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i288QMep027612 for ; Mon, 8 Mar 2004 09:26:25 +0100 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] issue 1: packet encoding To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 17:17:37 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have just caught up with the messages on this list. One general comment, I think the way you are all working through the issues is great - fills me with hope. Specifically to the header, and I don't know how this fits into the issue numbering scheme: - I think you should consider adding an error indication to the header. It can either be along the lines included in GRMP or otherwise. I have found having this in the header a very useful thing. - I agree that you need to include version and preferably subversion number. - I also think that 8 bits is enough for message type. best regards a. (avoiding commenting on topics not yet under discussion - i think) On 7 mar 2004, at 07.37, Khosravi, Hormuzd M wrote: > The Forces Message Header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Command | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flags | typeid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 06:36:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26041 for ; Mon, 8 Mar 2004 06:36:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0J3Z-0001tF-3O for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 06:36:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28BaPFg007264 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 06:36:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0J3Y-0001t5-Qa for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 06:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25992 for ; Mon, 8 Mar 2004 06:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0J3U-0004ej-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0J2X-0004Pd-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:35:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0J1V-0004A8-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:34:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0IzJ-0007ND-IM for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0IzJ-0001lG-Ds; Mon, 08 Mar 2004 06:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Iyi-0001iJ-RH for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 06:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25785 for ; Mon, 8 Mar 2004 06:31:20 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Iye-0003vJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ixg-0003oS-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:30:20 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Ix1-0003hf-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:29:39 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i28BcIep027799; Mon, 8 Mar 2004 12:38:20 +0100 In-Reply-To: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Forces-protocol] Comments from chat with ADs To: "Putzolu, David" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 20:29:35 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I definitely recommend this approach. It simplifies all of the documents and leaves the option open foe people to standardized using the protocol over their underlying layer/protocol of choice. a. On 2 mar 2004, at 22.06, Putzolu, David wrote: > The ADs went as > far as saying that the IETF could even accept standards- > track drafts that say nothing about IP (e.g. define an > Ethernet-only transport for ForCES), if it is necessary > for ForCES. GSMP and (some other group I forgot) was > given as an example. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 06:37:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26082 for ; Mon, 8 Mar 2004 06:37:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0J3k-0001to-GJ for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 06:36:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28BaaTf007294 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 06:36:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0J3k-0001tZ-Ar for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 06:36:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26020 for ; Mon, 8 Mar 2004 06:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0J3g-0004gH-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0J2l-0004S3-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:35:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0J1d-0004A8-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:34:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0Iqb-0007D9-8O for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 06:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Iqb-0001SE-36; Mon, 08 Mar 2004 06:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Iq5-0001RN-Pn for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 06:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25600 for ; Mon, 8 Mar 2004 06:22:25 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Iq1-0002px-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ip4-0002gx-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:21:27 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B0IoE-0002WC-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 06:20:34 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i28BTCep027790 for ; Mon, 8 Mar 2004 12:29:15 +0100 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Future question for the discussion Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 20:20:29 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, One of the difference between the protocols is the use of peer-peer model versus the master-slave model. Having worked with the master-slave model in GSMP, I found it to have limitations and think this should also be on the topics for discussion. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:08:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29498 for ; Mon, 8 Mar 2004 08:08:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KTo-00084S-74 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:07:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28D7avF031018 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KTn-00084B-Sf for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29492 for ; Mon, 8 Mar 2004 08:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0KTm-0003XP-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:07:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0KSq-0003PP-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:06:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0KSI-0003H2-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KSJ-0007qR-2N; Mon, 08 Mar 2004 08:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KRu-0007pl-78 for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:05:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29428 for ; Mon, 8 Mar 2004 08:05:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0KRt-0003GY-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:05:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0KQw-000386-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:04:39 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0KQY-0002zS-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:04:14 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030805042112:64463 ; Mon, 8 Mar 2004 05:04:21 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org In-Reply-To: <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078751018.1037.386.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 03/08/2004 05:04:22 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 05:04:53 AM, Serialize complete at 03/08/2004 05:04:53 AM Content-Type: multipart/mixed; boundary="=-A/pUjLH3sI1DiJ86qqip" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 08:03:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-A/pUjLH3sI1DiJ86qqip Content-Type: text/plain Content-Transfer-Encoding: 7bit Hormuzd, Weiming, Apologies for long email; i am attempting to respond to two emails in one. Ok, let me provide an example of an FE (same concept applies at the CE). Heres a diagram that may help to clarify what i have been refering to; note that netlink2 did not start like this, however over time implementation ended being like this; this shows an FE side implementation. I have attached the two diagrams so they dont get mangled. Figure 1. shows the netlink2 manager ( a s/ware daemon) managing two socket connections on the lower side labelled as wire0 and wire1 and entities called FECs on the upper side. Figure2 shows the role of the FEC; it MAY manages one or more LFBs. The communication mechanism used there is again beyond the scope of ForCES. Messages arriving at either of the sockets could end up in two sorts of general classes of destinations: 1) for the FE - in which they are serviced by the netlink2 daemon. 2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes them to those entities. Although i only list two classes, there could be more - but thats beside the point. FECs are OS processes/applications. (How they communicate to the netlink2 daemon is beyond the scope of ForCES; lets say it could be a local OS IPC.) As an example, there may be a FEC which controls several LFBs; Another example is an FEC which sends and receives OSPF hellos. Each FEC has a counterpart which understands it on the CE side. The CE piece of OSPF (call it CEC) sends messages to a specific PID when it wants to talk to the FEC portion (the hello offloader). As you can see this is application talking to another application; this could be looked at as essentially IPC. Therefore the concept of PID is useful. Now to address your emails: On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: Weiming, could you make sure your emails wrap around at 80 characters? It helps when i am trying to respond. > We think a layer-based tree structure according to the ForCES architecture > is efficient to do such addressing. If we address entities at > the FE coarse layer ( to take the FE as a whole entity, which idea is also > used by new version of FE model ), we only need to > have a FE ID. If i am not mistaken what you are talking about is a detail on how the address gets split; i.e you want to have a hierachical addressing - as an example you want to split the address above to FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). If this is the case, i think it is a small detail and we could move on and talk baout it later; if not please look at the diagram and tell me how you would split the ID to configure LFB0. I actually have a feeling your approach to this would be VERY different from Hormuzd ;-> > To address > CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, LFB > Instance broadcast, and CE broadcast, following addressing can be > implemented: I think we all agree on the broadcast or multicast to a specific type of entities. >>- a set of LFBs on an FE > - a set of LFBs on different FEs > > > [Wang Re: Are the set of LFBs of the same type?] Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > - proxies for LFBs, > - proxies for control application in the form on the CEs, > > [Wang Re: If ever we have these proxies, are they need to be seen at the > protocol layer? No, there is nothing speacial needed at the protocol header. The list was an exhaustive example. > Moreover, how about FE proxies then?] They dont need to be addressed by anything speacial in the header. On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go > with that terminology then? Lets talk about what needs to be addressed first before we jump to that. Refer to the two diagrams i sent. > [HK] I don't see the value of having an App ID in the common header. How > is it useful ? May be if you could give a good example of how this can > be used, it would help. The ForCES endpoints are CEs and FEs which > should be addressed in the common header. LFBs are like knobs on the FEs > used to program its functionality. I am sure you know all this very well > and I think most folks will agree on this. If we go with a different > view, we will probably land up breaking the FE Model as well. Other > views on this one ? Refer to the two diagrams i sent for an example, then lets discuss. [HK] Could you give me an example of why this is limiting? I was refering to the fact that you have a single ID to address entities within an FE or CE. In my diagram i am rtying to show theres more than one class of end targets. So calling it CEID or FEID is limiting. > I would like > to know if using 16 bits would break in some scenarios. If this was part > of a TLV I wouldn't care as much, but since this is the common header, I > am a bit concerned...acting stingy :-)) .. [HK] Exactly, ForCES has much limited/specific scope (NE) than general > purpose middleware such as Corba. You cannot compare these 2 because of > the difference in scope. I gave the historical experience of PCs (by quoting a naive bill gates), IPV4(by making a mockery over the famous last words that brought IPV6 to the world) and now i can add the experience of unix which would have been more interesting with 64 bit PIDs. Summary: Nothing would break; however it is useful to learn from history and say lets go with something larger. Again, apologies for long email; hopefully this would group things together. cheers, jamal --=-A/pUjLH3sI1DiJ86qqip Content-Disposition: attachment; filename=FE-apps Content-Type: text/plain; name=FE-apps; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +-----FE0---------------------------------------------+ | | | | | | | /~~~~~\ /~~~~~\ /~~~~~\ | | | FEC0 | | FEC1 | | FECx | | | | | | | ..... | | | | \_____/ \_____/ \_____/ | | | | | | | /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ | | | | | | | Netlink2 Manager | | | | | | | \_______________________________/ | | | | | | | | | +--------------/--------------|-----------------------+ | | | | wire0 --+ + --- wire1 Figure 1. /~~~~~\ | FEC0 | | | \_____/ | Y | netlink, proprietary, NPF API, etc ^ | +-+---------+ datapath | | processed packet ----------> | LFB10 | ----> | | +___________+ Figure 2. --=-A/pUjLH3sI1DiJ86qqip-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:15:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29710 for ; Mon, 8 Mar 2004 08:15:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kag-00009c-9x for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:14:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28DEgOb000586 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:14:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kag-00009N-3X for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:14:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29689 for ; Mon, 8 Mar 2004 08:14:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Kaf-0004Xf-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0KZe-0004Oh-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:13:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0KZ2-0004G0-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KZ2-0008To-VP; Mon, 08 Mar 2004 08:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KYV-0008S9-Kp for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:12:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29606 for ; Mon, 8 Mar 2004 08:12:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0KYU-0004D9-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:12:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0KXW-00043V-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:11:26 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0KWU-0003oZ-00 for Forces-protocol@ietf.org; Mon, 08 Mar 2004 08:10:22 -0500 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Mon, 8 Mar 2004 21:21:40 +0800 Message-ID: <000b01c4050e$6fd83d60$6f01a8c0@dlg> From: "Ligang Dong" To: Cc: References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> Subject: Re: [Forces-protocol] Future question for the discussion 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 21:08:23 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksIA0KSSBjaXRlZCBvbmUgc2VudGVuY2UgZnJvbSB0aGUgRm9yQ0VTIEZyYW1ld29yayBQcm90 b2NvbCwgICJUaGUgRm9yQ0VTIHByb3RvY29sIGlzIGEgbWFzdGVyLXNsYXZlIHByb3RvY29sIGlu IHdoaWNoIEZFcyBhcmUgc2xhdmVzIGFuZCBDRXMgYXJlIG1hc3RlcnMuIiBEbyB5b3UgbWVhbiB0 aGF0IHdlIHNob3VsZCBjaGFuZ2UgdGhpcyBmcmFtZXdvcmsgcHJvdG9jb2w/DQoNCkJlc2lkZXMs IGNhbiB5b3UgZ2l2ZSBtb3JlIGRldGFpbCBhYm91dCB0aGUgbGltaXRhdGlvbiBvZiB0aGUgbWFz dGVyLXNsYXZlIG1vZGVsIGluIEdSTVAuDQp0aGFua3MNCmRvbmcNCg0KDQogICANCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8YXZyaUBhY20ub3JnPg0KVG86IDxmb3JjZXMt cHJvdG9jb2xAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1hcmNoIDA4LCAyMDA0IDc6MjAgUE0N ClN1YmplY3Q6IFtGb3JjZXMtcHJvdG9jb2xdIEZ1dHVyZSBxdWVzdGlvbiBmb3IgdGhlIGRpc2N1 c3Npb24NCg0KDQo+IEhpLA0KPiANCj4gT25lIG9mIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhl IHByb3RvY29scyBpcyB0aGUgdXNlIG9mIHBlZXItcGVlciANCj4gbW9kZWwgdmVyc3VzIHRoZSBt YXN0ZXItc2xhdmUgbW9kZWwuICBIYXZpbmcgd29ya2VkIHdpdGggdGhlIA0KPiBtYXN0ZXItc2xh dmUgbW9kZWwgaW4gR1NNUCwgSSBmb3VuZCBpdCB0byBoYXZlIGxpbWl0YXRpb25zIGFuZCB0aGlu ayANCj4gdGhpcyBzaG91bGQgYWxzbyBiZSBvbiB0aGUgdG9waWNzIGZvciBkaXNjdXNzaW9uLg0K PiANCj4gYS4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQo+IEZvcmNlcy1wcm90 b2NvbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9m b3JjZXMtcHJvdG9jb2wNCj4g _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:32:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00372 for ; Mon, 8 Mar 2004 08:32:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kr3-0000zy-D2 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:31:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28DVbU7003835 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kr3-0000zm-6K for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00360 for ; Mon, 8 Mar 2004 08:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Kr2-0007Il-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:31:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0KqG-0007AX-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:30:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0KpY-00070B-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:30:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0KpZ-0000PW-6E for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KpY-0000xN-2g; Mon, 08 Mar 2004 08:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KpA-0000v7-6O for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00243 for ; Mon, 8 Mar 2004 08:29:37 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Kp9-0006xe-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Koa-0006nu-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:29:05 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Kng-0006ZD-00 for Forces-protocol@ietf.org; Mon, 08 Mar 2004 08:28:08 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i28Daiep027937; Mon, 8 Mar 2004 14:36:46 +0100 In-Reply-To: <000b01c4050e$6fd83d60$6f01a8c0@dlg> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <000b01c4050e$6fd83d60$6f01a8c0@dlg> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6CADDF45-7104-11D8-B109-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Forces-protocol] Future question for the discussion To: "Ligang Dong" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 22:28:02 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 8 mar 2004, at 22.08, Ligang Dong wrote: > hi, > I cited one sentence from the ForCES Framework Protocol, "The ForCES > protocol is a master-slave protocol in which FEs are slaves and CEs > are masters." Do you mean that we should change this framework > protocol? Well, and I don't know if it time for this yet, but we have 2 models being presented. As far as I understand it netlink2 is using a peer to peer model of communications while Fact and GRMP are using a master-slave model of communications. I don't disagree that the FE gets its LFB state etc. from the CE, in this it has a more restricted scope of responsibility. The issues I have with master/slave protocols are not which controls the state of the other, but rather in the protocol messaging and in who can initiate an exchange of info. > > Besides, can you give more detail about the limitation of the > master-slave model in GRMP. I was speaking of limitations I had found working with GSMP, another master-slave protocol, not GRMP. As the information in the so called slave got more complex with optical switching we had the to stretch the notion of what a 'slave' was permitted to do and to communicate or its own initiative. At times it felt awkward. But I really just wanted to put this topic on the table for a later timely discussion. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:35:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00441 for ; Mon, 8 Mar 2004 08:35:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Ktt-00015E-8r for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:34:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28DYXS6004158 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kts-00014z-Ts for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00425 for ; Mon, 8 Mar 2004 08:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ktr-0007ja-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:34:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Kt2-0007bb-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:33:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0KsP-0007TF-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0KsQ-0000S2-4J for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KsO-00011d-V3; Mon, 08 Mar 2004 08:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Krt-00010z-SP for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:32:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00391 for ; Mon, 8 Mar 2004 08:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Krs-0007QJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Kr3-0007J0-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:31:38 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0KqK-0007At-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:30:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030805312980:64472 ; Mon, 8 Mar 2004 05:31:29 -0800 Subject: RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0542F5@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0542F5@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078752642.1036.414.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 03/08/2004 05:31:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 05:31:31 AM, Serialize complete at 03/08/2004 05:31:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 08:30:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-08 at 02:13, Khosravi, Hormuzd M wrote: > -----Original Message----- > On Behalf Of Jamal Hadi Salim > > > Here are my views on this issue, particularly the common header: > > > > Command: Agree this is needed. We think 8-12 bits will be more than > > sufficient for this depending on whether it is subdivided. We have > > sub-divided this field into Class/type...this is an OO approach, > seemed > > pretty neat. However, I am personally fine with having a single field > > for this, no problem with that. > > I think we could resolve this later; i am not seeing a lot of commands. > On the outset i can only see ADD/DEL/GET > > [HK] Ok, we can resolve this later. So I guess you are fine with 8 bits > for the command? especially, if you only see a few of them. I am indifferent 8 bits may be sufficient; lets consider this one closed and revisit it later. > How do you propose we do things like 2 phase commits; atomic > transactions etc? > > [HK] You need flags for this, however this is only for configuration > messages, they don't have to be in the common header. They will be part > of the config message TLV. As you said below... > "Agreed - the main thing is that if something needs to be used in all > messages then it should go on this header (since its cheaper than a > TLV)." I think we shouldnt hurry into getting rid of flags. They are used in all transaction type protocols i have come across. We used them extensively in _every_ message. 16 bit flags should suffice. If we are not in agreement i could go into semantics; > Also in regards to priority; do you see this being used all the time? > > [HK] Sure, this is definitely needed in all messages. I believe even > GRMP has this, infact I had a feeling till today that even netlink had > it. > and would an underlying transport priority be insufficient > (example diffserv, 802.1p etc)? > > [HK] This is priority at the ForCES level which will eventually be > mapped to the underlying transport/interconnect. We definitely need it > at the ForCES level as well. Ok - closed. So how many bits do you see? > I am not sure i see this. If you could explain more mayeb it would help. > Like i said the only value is in being able to look at the outer header > and recognizing for example the target where the message is being sent > to (example LFB class). If not for anything else, debugging (via > sniffing) is a good reason - this way i could dump the rest of the > message by recognizing what the TLVs mean. > > [HK] Debugging doesn't seem to be a good reason to me to add a field to > the common header. It has to be something very useful for the protocol > and all messages. What do others think about this one? > I gave debugging as an example - and btw, it is a _very_ good reason to be able to debug protocols. The general idea is by inspecting the header i want to be able to tell what class of LFB it is going or coming from. If you can look at my earlier diagrams and tell me how you could see me decoding that message and identifying that LFB10 is a IPV4 forwarder then we could move on. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:40:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00557 for ; Mon, 8 Mar 2004 08:40:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kzf-0001fo-Gr for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:40:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28DeVT7006426 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:40:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kzf-0001fZ-CD for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:40:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00553 for ; Mon, 8 Mar 2004 08:40:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Kze-0000i7-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:40:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Kyh-0000al-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:39:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0KyC-0000TU-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:39:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0KyD-0000XF-3u for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0KyC-0001ad-7o; Mon, 08 Mar 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Kxg-0001aC-TS for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:38:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00533 for ; Mon, 8 Mar 2004 08:38:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Kxf-0000Sd-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:38:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Kwj-0000Ks-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:37:30 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Kvo-0000DJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:36:32 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030805370935:64476 ; Mon, 8 Mar 2004 05:37:09 -0800 Subject: Re: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1078752987.1038.419.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 03/08/2004 05:37:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 05:37:10 AM, Serialize complete at 03/08/2004 05:37:10 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 08:36:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Avri, On Mon, 2004-03-08 at 03:17, avri@acm.org wrote: > Specifically to the header, and I don't know how this fits into the > issue numbering scheme: > > - I think you should consider adding an error indication to the header. > It can either be along the lines included in GRMP or otherwise. I > have found having this in the header a very useful thing. Good point. This is in responses only i take it? We implemented a NACK response when things went wrong as opposed to an ACK. Not sure if that is what you are refering to. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 08:47:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00715 for ; Mon, 8 Mar 2004 08:47:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0L5W-0001r3-0B for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 08:46:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28DkXSf007123 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 08:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0L5V-0001qo-Rh for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 08:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00709 for ; Mon, 8 Mar 2004 08:46:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0L5U-0001Y0-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:46:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0L4a-0001QK-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:45:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0L40-0001IL-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 08:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0L41-0001oG-CQ; Mon, 08 Mar 2004 08:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0L3W-0001mu-F3 for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 08:44:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00663 for ; Mon, 8 Mar 2004 08:44:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0L3V-0001Ga-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0L2e-000195-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:43:37 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0L1t-000110-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 08:42:49 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030805432687:64483 ; Mon, 8 Mar 2004 05:43:26 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1078753355.1036.426.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 03/08/2004 05:43:27 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 05:43:28 AM, Serialize complete at 03/08/2004 05:43:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Issues list: Was( Future question for the discussion Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 08:42:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-08 at 06:20, avri@acm.org wrote: > Hi, > > One of the difference between the protocols is the use of peer-peer > model versus the master-slave model. Having worked with the > master-slave model in GSMP, I found it to have limitations and think > this should also be on the topics for discussion. > We should definetely add this to the list of discussions. I am resending the list below: 0) ID on the header. 1) Encoding 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability 8) Capability exchange 9) The FEM/CEM interface 10) Support for vendor functions 11) Cross check with model draft before it is published 12) Master Slave or peer-peer? I personally dont think we should care what the model or requirements draft says. What we want to have is a good protocol (as an example there are a few issues not mentioned in the requirements already on the list above). For this reason i feel like scratching issue 11 from the list. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 09:05:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01123 for ; Mon, 8 Mar 2004 09:05:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LMt-0002iS-NW for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 09:04:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28E4VhK010434 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 09:04:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LMs-0002iD-Um for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 09:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01102 for ; Mon, 8 Mar 2004 09:04:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0LMr-0003xi-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0LLw-0003q2-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:03:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0LLP-0003ih-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LLQ-0002eL-Jo; Mon, 08 Mar 2004 09:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LKy-0002e2-Oh for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 09:02:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01057 for ; Mon, 8 Mar 2004 09:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0LKx-0003hJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:02:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0LJy-0003Yt-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:01:31 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0LJ3-0003Jn-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:00:35 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Mon, 8 Mar 2004 22:08:48 +0800 Message-ID: <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> Subject: Re: [Forces-protocol] issue 1: packet encoding 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 21:55:25 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgQXZyaSwgSmFtYWwsIEhvcm11emQsIGFuZCBhbGwsDQoNClBsZWFzZSBhbGxvdyBtZSB0byBi ZWdpbiB0byBhZGRyZXNzIHRoaXMgaXNzdWUgYnkgdHJ5aW5nIHRvIHByb3Bvc2Ugc29tZSBiYXNp YyBydWxlcyB0aGF0IHdlIA0KKEdSTVAgdGVhbSkgdGhpbmsgd2hlbiB3ZSBkZXNpZ24gdGhlIHBy b3RvY29sIGhlYWRlciBhcyB3ZWxsIGFzIHRoZSBib2R5Og0KMS4gQXMgSmFtYWwgbWVudGlvbmVk LCBhIHZlcnkgaW1wb3J0YW50IHJ1bGUgaXMgdG8gcHV0IHRoaW5ncyB0aGF0IHN1cmVseSBldmVy eSBwcm90b2NvbA0KIG1lc3NnZSBuZWVkIHRvIHRoZSBwcm90b2NvbCBoZWFkZXIuIA0KMi4gV2hl biB0aGUgc2FtZSBnb2FsIGNhbiBiZSBtYWRlLCBhIHNhdmluZyBiaXRzIHNjaGVtZSBzaG91bGQg YmUgYWJzb2x1dGVseSBzZWxlY3RlZC4gDQpUaGlzIGlzIGV4cGVjaWFsbHkgZm9yIEZvckNFUyBw cm90b2NvbC4gSnVzdCBpbWFnaW5nIGh1bmRyZWRzIG9mIEVGcyB3b3JraW5nICB0b2dldGhlciAN CmFuZCBleGNoYW5naW5nIHRoaW5ncyBtYXkgb25seSB1c2UgYSBxdWl0ZSBsaW1pdGVkIHRyYW5z cG9ydCByZXNvdXJjZXMsIHdlIGhhdmUgbm8NCnJlYXNvbiB0byBzcGVuZCBvbmUgZXh0cmEgYml0 IGluIHRoZSBoZWFkZXIuDQoNClRoZW4gc29tZSBjb21tZW50czoNCg0KMS4gVGhlICJjb21tYW5k IiBmaWVsZA0KVGhpcyBpcyByZWFsbHkgYSBmaWVsZCB0aGF0IGNvbmZ1c2VzIG1lLiBUaGUgY29u ZnVzaW9uIGlzOg0KMSkgSWYgaXQgaXMgYSBmaWVsZCBvbmx5IHdpdGggY29tbWFuZCAiQWRkL0Rl bC9HZXQiLCBJIHN1cHBvc2Ugd2UgY2FuIGp1c3Qgb2Jzb2xldGUgaXQuIA0KVGhlIGNvbW1hbmQg Y2FuIGJlIHN1cmVseSBiZSBleHByZXNzZWQgaW4gdGhlIGZvbGxvd2VkIGJvZHkgYnkgdXNpbmcg VExWcy4NCjIpIElmIHdlIGtlZXAgaXQsIEknbSBhZnJhaWQgaXQncyBtZWFuaW5nIHNob3VsZCBi ZSBmYXIgZnJvbSB0aGVzZS4gRm9yIGV4YW1wbGUsIGhvdyANCmFuIGV2ZW50IHJlcG9ydCBjYW4g YmUgcmVwcmVzZW50ZWQsIGFuZCBob3cgYSBjb21tYW5kIGJ1bmRsZSBpcyByZXByZXNlbnRlZCB0 aGVuLCANCmFuZCBtYW55IG90aGVycz8gDQpXZSBqdXN0IHRoaW5rIHRvIGhhdmUgYSBmaWVsZCAg d2l0aCBpbnN1ZmZpY2llbnQgZnVuY3Rpb25zIHJlYWxseSBtYWtlcyBjb25mdXNpb25zLg0KDQpB cyBhIHJlc3VsdCwgSSBzdXBwb3NlIHR3byBzb2x1dGlvbiBzY2hlbWVzIGZvciB0aGlzIHByb2Js ZW06DQpTY2hlbWUgMTogRGVmaW5lIHRoaXMgYXMgIm1lc3NhZ2UgdHlwZSIsIHRvIGhhdmUgdGhl IG1lc3NhZ2UgYm9keSB0byBleHByZXNzIHRoZSANCm9wZXJhdGlvbiBub3QganVzdCBiYXNlZCBv biBUTFYgZm9ybWF0LiBUaGlzIG1lYW5zIHRoaW5ncyBsaWtlICJGbGFncyIgIm9wZXJhdGluZyBm aWVsZHMiIA0KYXJlIGV4cGxpY2l0bHkgZXhwcmVzc2VkIGFjY29yZGluZyB0byB0aGUgIm1lc3Nh Z2UgdHlwZSIgb3BlcmF0aW9uIHJlcXVpcmVtZW50cy4gUmVtZW1iZXINCiB0aGF0IGJ5IHVzaW5n IHRoaXMgc2NoZW1lLCB3ZSBoYXZlIGFscmVhZHkgdGFrZW4gdGhlIHdob2xlIEZvckNFUyBtZXNz YWdlIGFzIG9uZSBUTFYuDQpTY2hlbWUgMjogTm90IGRlZmluZSBhbnl0aGluZyBpbiB0aGUgaGVh ZGVyIG9uIHRoZSAiY29tbWFuZCIgb3IgIm1lc3NhZ2UgdHlwZSIsIGxlYXZpbmcgDQp0aGluZ3Mg ZGVmaW5lZCBpbiB0aGUgZm9sbG93ZWQgYm9keSwgd2hpbGUgdGhlIGJvZHkgaXMgZXhwcmVzc2Vk IGJ5IGEgc2V0IG9mIFRMVnMsIGVhY2ggVExWIA0KcmVwcmVzZW50aW5nIGEgdHlwZSBvZiBvcGVy YXRpb24uIA0KVGhlIGFkdmFudGFnZSBmb3IgU2NoZW1lMSBpcyBpdCBpcyB2ZXJ5IGNsZWFyIGlu IHNlbWFudGljcyBhbmQgc2F2ZXMgYml0cyBxdWl0ZSBhIGxvdC4gDQpUaGUgZGlzYWR2YW50YWdl IGlzIGl0IGhhcyB0byBkZWZpbmUgYSBzcGVjaWZpYyBtZXNzYWdlIHR5cGUgZm9yIGNvbW1hbmQg YnVuZGxlLiANClRoZSBhZHZhbnRhZ2UgZm9yIFNjaGVtZSAyIGlzIGl0IGlzIGVhc3kgdG8gaW1w bGVtZW50IGNvbW1hbmQgYnVuZGxlLCBidXQgdGhlIGRpc2FkdmFudGFnZQ0KIGlzIGl0IGNvc3Rz IG1vcmUgYml0cyBhbmQgbWFrZXMgcHJvdG9jb2wgaGVhZGVyIGxlc3MgdG8gZG8uDQoNCjIuIFRo ZSBDaGVja3N1bSBmaWVsZCBhbmQgb3RoZXIgZXJyb3IgY29udHJvbCBtZWNoYW5pc20NCk9uZSBl c3NlbnRpYWwgZnVuY3Rpb24gYSBwcm90b2NvbCBoZWFkZXIgdGFrZXMgaXMgZm9yIGEgcmVsaWFi bGUgaW5mb3JtYXRpb24gZXhjaGFuZ2UsIHRoZXJlZm9yZSwgDQp0aGUgY29tbW9uIGVycm9yIGNv bnRyb2wgbWVjaGFuaXNtIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgaGVhZGVyIGluc3RlYWQg aW4gdGhlIGJvZHkuIA0KDQpJdCBzZWVtcyBubyBhcmd1ZSB0aGF0IGEgY2hlY2tzdW0gc2hvdWxk IGJlIHByb3ZpZGVkIGFzIGFuIG9wdGlvbi4gT25seSBkaWZmZXJlbmNlIGJldHdlZW4gDQp0aGUg Y2FuZGlkYXRlIHByb3RvY29scyBpcyBob3cgaXQgc2hvdWxkIGJlIHB1dC4gR1JNUCBwdXRzIGl0 IGF0IHRoZSBwcm90b2NvbCBtZXNzYWdlIGVuZCwgDQpOZXRsaW5rMiBoYXMgaXQgYXMgYSBUTFYs IEkgc3VwcG9zZSBGQUNUIGFsc28gaW50ZW5kcyB0aGUgc2FtZS4gSSdtIHRoaW5raW5nIHRoZSBw dXJwb3NlIHRvIA0KaGF2ZSBpdCBhcyBhIFRMViBpcyBtYWlubHkgdHJ5aW5nIHRvIHJlYWNoIGEg dW5pZm9ybSBUTFYgZm9ybWF0LiBXaGF0IHdlIGFyZ3VlIGlzIHRvIHB1dCANCmNoZWNrc3VtIGlu IGEgVExWIG1heSBnZXQgbW9yZSBsb3NzIGZvciB0aGUgY2hlY2tpbmcgZnVuY3Rpb24sIGJlY2F1 c2UgaXQgdGhlbiB3aWxsIGJlIGluIGEgcmlzayANCnRoYXQgdGhlIFRMViBzdHJ1Y3R1cmUgaXRz ZWxmIG1heSBiZSBlcnJlZCwgd2hpY2ggbWF5IHJlc3VsdCBpbiB0aGUgaW52YWxpZGF0aW9uIG9m IHRoZSBjaGVja3N1bS4gDQpXaGlsZSBpbiBmb3JtZXIgY2FzZSwgb25seSB0aGUgcHJvdG9jb2wg bWVzc2FnZSBsZW5ndGggY2hhbmdlIHdpbGwgbWFrZSBjaGVja3N1bSBpbnZhbGlkLiANCkFjdHVh bGx5IGNoZWNrc3VtIGluIG1hbnkgcHJvdG9jb2xzIGFyZSBkaXJlY3RseSBwdXQgaW4gdGhlIG1l c3NhZ2Ugc3VyZmFjZSBpbnN0ZWFkIG9mIGJlaW5nIA0KaW5jYXBzdWxhdGVkIGRlZXBseSwgbGlr ZSBVRFAuIA0KDQpHUk1QIHJldXNlcyB0aGUgaWRlYSAicmVzdWx0IiBhbmQgImNvZGUiIGZyb20g R1NNUCwgSSdtIHN1cmUgdGhpcyBlcnJvciBjb250cm9sIGZ1bmN0aW9uIHNob3VsZCBiZSANCmlu Y2x1ZGVkIGluIHRoZSBwcm90b2NvbC4gQXMgdGhlIHByb3RvY29sIGhlYWRlciB0YWtlcyB0aGUg dGFza3MgZm9yIGEgcmVsaWFibGUgaW5mb3JtYXRpb24gZXhjaGFuZ2UsIEkNCnN0cm9uZ2x5IHN1 Z2dlc3QgaXQgaXMgcHV0IGluIHRoZSBoZWFkZXIuIENvdWxkIG90aGVyIGNhbmRpZGF0ZSB0ZWFt IHNob3cgeW91ciBvcGluaW9ucyBvciBzb2x1dGlvbnMgdG8gDQp0aGlzPw0KDQpJJ20gYWZyYWlk IGlzIGFscmVhZHkgdG9vIGxvbmcuIEknbCBwdXQgb3RoZXIgY29tbWVudHMgaW4gb3RoZXIgZW1h aWxzLg0KDQpDaGVlcnMsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiA8YXZyaUBhY20ub3JnPg0KVG86IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc+DQpT ZW50OiBNb25kYXksIE1hcmNoIDA4LCAyMDA0IDQ6MTcgUE0NClN1YmplY3Q6IFJlOiBbRm9yY2Vz LXByb3RvY29sXSBpc3N1ZSAxOiBwYWNrZXQgZW5jb2RpbmcNCg0KDQo+IEhpLA0KPiANCj4gSSBo YXZlIGp1c3QgY2F1Z2h0IHVwIHdpdGggdGhlIG1lc3NhZ2VzIG9uIHRoaXMgbGlzdC4NCj4gDQo+ IE9uZSBnZW5lcmFsIGNvbW1lbnQsIEkgdGhpbmsgdGhlIHdheSB5b3UgYXJlIGFsbCB3b3JraW5n IHRocm91Z2ggdGhlIA0KPiBpc3N1ZXMgaXMgZ3JlYXQgLSBmaWxscyBtZSB3aXRoIGhvcGUuDQo+ IA0KPiBTcGVjaWZpY2FsbHkgdG8gdGhlIGhlYWRlciwgYW5kIEkgZG9uJ3Qga25vdyBob3cgdGhp cyBmaXRzIGludG8gdGhlIA0KPiBpc3N1ZSBudW1iZXJpbmcgc2NoZW1lOg0KPiANCj4gLSBJIHRo aW5rIHlvdSBzaG91bGQgY29uc2lkZXIgYWRkaW5nIGFuIGVycm9yIGluZGljYXRpb24gdG8gdGhl IGhlYWRlci4gDQo+ICAgSXQgY2FuIGVpdGhlciBiZSBhbG9uZyB0aGUgbGluZXMgaW5jbHVkZWQg aW4gR1JNUCBvciBvdGhlcndpc2UuICBJIA0KPiBoYXZlIGZvdW5kIGhhdmluZyB0aGlzIGluIHRo ZSBoZWFkZXIgYSB2ZXJ5IHVzZWZ1bCB0aGluZy4NCj4gDQo+IC0gSSBhZ3JlZSB0aGF0IHlvdSBu ZWVkIHRvIGluY2x1ZGUgdmVyc2lvbiBhbmQgcHJlZmVyYWJseSBzdWJ2ZXJzaW9uIA0KPiBudW1i ZXIuDQo+IA0KPiAtIEkgYWxzbyB0aGluayB0aGF0IDggYml0cyBpcyBlbm91Z2ggZm9yIG1lc3Nh Z2UgdHlwZS4NCj4gDQo+IGJlc3QgcmVnYXJkcw0KPiBhLg0KPiANCj4gKGF2b2lkaW5nIGNvbW1l bnRpbmcgb24gdG9waWNzIG5vdCB5ZXQgdW5kZXIgZGlzY3Vzc2lvbiAtIGkgdGhpbmspDQo+IA0K PiANCj4gT24gNyBtYXIgMjAwNCwgYXQgMDcuMzcsIEtob3NyYXZpLCBIb3JtdXpkIE0gd3JvdGU6 DQo+IA0KPiA+IFRoZSBGb3JjZXMgTWVzc2FnZSBIZWFkZXI6DQo+ID4NCj4gPiAgICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN Cj4gPiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAzDQo+ID4gICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4g ICAgIHwgICAgICAgICAgICAgQ29tbWFuZCAgICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGgg ICAgICAgICAgICB8DQo+ID4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgIFNvdXJjZSB4SUQgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+ID4gICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbiB4 SUQgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+ID4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgIHwgICAgICAgICAgICAgZmxhZ3MgICAg ICAgICAgIHwgICAgICAgICAgICAgdHlwZWlkICAgICAgICAgICAgICB8DQo+ID4gICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPiBGb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2Vz LXByb3RvY29sDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 09:42:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03727 for ; Mon, 8 Mar 2004 09:42:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LxX-0006Tn-Ex for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 09:42:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28EgNRX024901 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 09:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LxX-0006TY-AI for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 09:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03699 for ; Mon, 8 Mar 2004 09:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0LxV-0003ll-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0LwM-0003Tn-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:41:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0LvI-0003DU-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 09:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LvJ-00068H-P6; Mon, 08 Mar 2004 09:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LvB-000675-Di for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 09:39:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03558 for ; Mon, 8 Mar 2004 09:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Lv9-0003C9-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:39:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Lu3-0002xK-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:38:48 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0LtG-0002cJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 09:37:58 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Mon, 8 Mar 2004 22:48:44 +0800 Message-ID: <09ea01c4051a$96312bf0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <1078523986.1036.116.camel@jzny.localdomain> <404900BF.6030305@alcatel.com> <1078538399.1037.120.camel@jzny.localdomain> Subject: Re: [Forces-protocol] issue 1: packet encoding MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 22:35:21 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmFtYWwsIEFsZXgsIGFuZCBhbGwsDQoNCkkganN1dCB3YW50IHRvIGhhdmUgdGhpcyBlbWFp bCBzcGVjaWZpY2FsbHkgZm9yIFRMViBmb3JtYXQgYW5kIExpc3QgZm9ybWF0IGRpc2N1c3Npb24u DQoNCkZpcnN0bHksIEkgaGF2ZSB0byBzYXkgdGhhdCB3aGV0aGVyIGEgTGlzdCBmb3JtYXQgaXMg ZXhwbGljaXRseSBkZWZpbmVkLCBpdCB3aWxsIGJlIHVzZWQgaW4gdGhlDQpwcm90b2NvbC4gQWN0 dWFsbHkgY3VycmVudCBjYW5kaWRhdGUgcHJvdG9jb2xzIGhhdmUgYWxsIGFscmVhZHkgdXNlZCB0 aGlzIGtpbmQgb2YgZm9ybWF0DQoocGxzIGFsbG93IG1lIHRvIG1lbnRpb24gdGhhdCB0aGUgZm9y bWF0IHVzZWQgYXQgUGFnZSAyMyBpbiBGQUNUIGlzIGFjdHVhbGx5IGEgbGlzdCkuDQpJJ20gc3Vy ZSBpdCB3aWxsIGJlIHVzZWQgbW9yZSB3aGVuIHRoZSBkYXRhcGF0aCBwYXJ0IGFuZCBvdGhlciBG RSBtb2RlbCBlbnRpdGllcyBhcmUgYmVjb21pbmcgDQptb3JlIGNsZWFyLiBUaGUgZXNzZW5jZSBm b3IgYSBsaXN0IGlzIHRvIGRlc2NyaWJlIGEgZ3JvdXAgb2YgdGhlIHNhbWUgZW50aXRpZXMsIGl0 cyBlbGVtZW50cyBjYW4gDQpiZSBUTFZzIG9yIGFueSBvdGhlciBlbGVtZW50cy4gT2YgY291cnNl LCB3ZSBtYXkgc2F5IHRoYXQgbGlzdCBmb3JtYXQgY2FuIHN1cmVseSBiZSByZXBsYWNlZCANCmJ5 IGEgVExWIGZvcm1hdCwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB2ZXJ5IGludGVudGlv bmFsbHkgdG8gZG8gbGlrZSB0aGlzLCBiZWNhdXNlIGl0DQppcyB2ZXJ5IG9idmlvdXMgdGhhdCBs aXN0IGZvcm1hdCBzYXZlcyBsb3RzIG9mIGJpdHMgYW5kIG1ha2UgdGhpbmdzIG1vcmUgY2xlYXIu IEkgZG9uJ3QgdGhpbmsgd2UNCm5lZWQgdG8gc2FjcmlmaWNlIGEgbG90IGp1c3QgdG8gbm9taW5h bGx5IGdldCBhIHVuaWZvcm0gbmFtZS4gIA0KDQpUbyBleHBsaWNpdGx5IGFuZCB1bmlmb3JtbHkg ZGVmaW5lIGEgbGlzdCBmb3JtYXQgaW4gR1JNUCBpcyBqdXN0IGluIHRoZSBwdXJwb3NlIG9mIGhh dmluZyB0aGUgDQpwcm90b2NvbCBmaWxlIG5vdCB0b28gYmlnLiBJdCBpcyB0cnVlIHdlIGhhdmUg c2F2ZWQgbG90cyBvZiB0eHQgYnkgZG9pbmcgbGlrZSB0aGlzLiANCg0KQ2hlZXJzLA0KV2VpbWlu Zw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2Fs aW0iIDxoYWRpQHpueXguY29tPg0KVG86IDxhbGV4LmF1ZHVAYWxjYXRlbC5jb20+DQpDYzogPGZv cmNlcy1wcm90b2NvbEBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwNiwgMjAwNCAx MDowMCBBTQ0KU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIGlzc3VlIDE6IHBhY2tldCBl bmNvZGluZw0KDQoNCj4gT24gRnJpLCAyMDA0LTAzLTA1IGF0IDE3OjM1LCBBbGV4IEF1ZHUgd3Jv dGU6DQo+ID4gSmFtYWwsDQo+ID4gDQo+ID4gQWZ0ZXIgYSBxdWljayBnbGFuY2UsIHdlIGRvbid0 IG5lZWQgIE91dGVyVExWIC8gSWlubmVyVExWIHRvIGJlDQo+ID4gZXhwbGljaXRseSBjYWxsZWQg b3V0LiANCj4gPiBBcyBmYXIgYXMgSSBrbm93LCB0aGlzIGlzIGFuIGluaGVyZW50IFRMViBlbmNv ZGluZyBwcm9wZXJ0eS4gDQo+IA0KPiBBbGV4LA0KPiANCj4gbm9kDQo+IA0KPiBjaGVlcnMsDQo+ IGphbWFsDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPiBGb3JjZXMtcHJvdG9j b2xAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9y Y2VzLXByb3RvY29sDQo= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 10:31:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07496 for ; Mon, 8 Mar 2004 10:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MiO-00077y-HI for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 10:30:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28FUmga027394 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 10:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MiN-00077j-UN for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 10:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07492 for ; Mon, 8 Mar 2004 10:30:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0MiL-00051R-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0MhW-0004ri-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:29:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mge-0004hZ-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mgf-0006xL-O2; Mon, 08 Mar 2004 10:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MgO-0006vf-Dw for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 10:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07361 for ; Mon, 8 Mar 2004 10:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0MgL-0004eu-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:28:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0MfO-0004TG-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:27:45 -0500 Received: from tomts6.bellnexxia.net ([209.226.175.26] helo=tomts6-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1B0MeQ-0004Ik-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:26:42 -0500 Received: from develSPavel ([67.69.27.58]) by tomts6-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040308152621.AXQ16454.tomts6-srv.bellnexxia.net@develSPavel>; Mon, 8 Mar 2004 10:26:21 -0500 Reply-To: From: "Sandy Pavel" To: Cc: Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <006701c40522$7f836140$a401a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C404F8.96AD5940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <404900BF.6030305@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 10:31:56 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C404F8.96AD5940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alex is right. The Value field of a TLV can contain other TLVs but this is the actual TLV definition. I suppose this explicit representation was made only for clarification. If we look at other protocols defined in the last few years, many use TLV. The reasons are many and it i no point in elaborating on this. I have noticed that XML was mentioned here. This requires quite a bit of resources and seems to be more appropriate for an application-type protocol rather than the one we try to define here. (this is debatable, of course). Sandy -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Alex Audu Sent: March 5, 2004 5:36 PM To: hadi@znyx.com Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] issue 1: packet encoding Jamal, After a quick glance, we don't need OuterTLV / IinnerTLV to be explicitly called out. As far as I know, this is an inherent TLV encoding property. I'll take a look at the rest and comment later. Regards, Alex. Jamal Hadi Salim wrote: Attached is text for stimulating discussion on issue 1. cheers, jamal _____ Packet encoding suggestion. Binary encoding to be used to be able to pack as much as possible within an allowed MTU. TLVs to be used to map the various attributes. TLVs within TLVs were used to encode complex attributes such as lists or compound structures. The layout below is to get a discussion going. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Forces message header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Forces Attributes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Forces Message Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | typeid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The xIDs are being discussed in issue 0. The command would be of the sort of ADD, DEL, GET. The xID will address the entity being targeted. [A command from a CE -> FE is for querying or configuration, whereas one from FE -> CE is a response or event]. The typeid identifies further the type of target by looking at typeid. [ for example, in our implementation we extended the popular tcpdump sniffer to look decode the packet for protocol debugging purposes. Length: length of the message including the attributes + header. XML encoding: XML encoding may be useful in capabilities definition (i.e slow path) but not in the configuration of data path tables. This is because of its nature to require higher bandwith and CPU computational needs. TLVs: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | variable TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Value (Data of size TLV length) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is possible to extend the data in the TLV to contain another TLV to build complex structures (such as the ones described in XML by the model draft or lists susch as those defined by GRMP). Example: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer TLV Type | Outer TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner TLV1 Type | Inner TLV1 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~~~~~~~~~~~~~~ VALUE1 ~~~~~~~~~~~~~~~~~~~~~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner TLV2 Type | Inner TLV2 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~~~~~~~~~~~~~~ VALUE2 ~~~~~~~~~~~~~~~~~~~~~~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Which could be used to represent the following layout : +-+-+-+-+-+-+-+-+-+-+-+ .-~-~-~-~-~-~-. | TLV1 | ------>| param 1 | +-+-+-+-+-+-+-+-+-+-+-+ -~-~-~-~-~-~- | TLV2 | --->--+ +-+-+-+-+-+-+-+-+-+-+-+ | V | / +-----------+ | V .-~-~-~-~-~-~-. | +--->| param2_1 | +-+-+-+-+-+-+-+-+-+-+-+ | -~-~-~-~-~-~- | TLV2_1 | --->-+ .-~-~-~-~-~-~-. +-+-+-+-+-+-+-+-+-+-+-+ +--->| param2_2 | | TLV2_2 | --->----+ -~-~-~-~-~-~- +-+-+-+-+-+-+-+-+-+-+-+ It is thought that TLVs and nested TLVs will generally constitute slightly higher requirements for compute and bandwdith than encodings based on fixed layouts (XML is many more factors demanding). The added advantage with TLV usage of course is ability to add new TLVs easily without redefining the packet or the protocol. In addition, being able to optionally leave a TLV out during communication (the message example would have been perfectly decoded if TLV1 was never encoded). A small challenge that needs to be overcome for TLVs is to detect where failures happen (when you have a list or other compound structure). This is mostly useful/needed for batching or configuring a list of elements. If we were to use our implementation as a sample space: we had the "all upto failed one applied" scheme, in which case a NACK with the failed TLV Type is sent back. An interesting idea is to encode an 8 bit sequence number in the type to find precisely which TLV failed. ------=_NextPart_000_0068_01C404F8.96AD5940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alex is right. The Value field of a = TLV can contain other TLVs but this is the = actual TLV definition.

I suppose this explicit = representation was made only for clarification.

 

If we look at other protocols = defined in the last few years, many use TLV. The reasons are many and = it

i no point in = elaborating on this. I have noticed that XML was mentioned here. This requires quite = a bit

of<= /span> resources and seems to be more appropriate for an = application-type protocol rather than the one we try to

define here. (this is debatable, of = course).

 

Sandy

 

 

 

-----Original Message-----
From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On Behalf Of Alex Audu
Sent: = March 5, 2004 = 5:36 PM
To: hadi@znyx.com
Cc: = forces-protocol@ietf.org
Subject: Re: = [Forces-protocol] issue 1: packet encoding

 

Jamal,

After a quick glance, we don't need  OuterTLV / IinnerTLV to be = explicitly called out.
As far as I know, this is an inherent TLV encoding property.

I'll take a look at the rest and comment later.

Regards,
Alex.

Jamal Hadi Salim wrote:

Attached is text =
for stimulating discussion on issue =
1.
 
cheers,
jamal
  =

 






 
Packet encoding suggestion. =

 
Binary encoding to be used to be able to pack =
as much as possible
within an allowed MTU. =

TLVs to be used to map the various =
attributes.
TLVs within TLVs were used to encode complex =
attributes such as
lists or compound =
structures.
 
The layout below is to get a discussion =
going.
 
 
     0       &nbs=
p;           =
1       &nbs=
p;           =
2       &nbs=
p;           =
3
     0 1 2 3 4 5 6 =
7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
    |       &nbs=
p;            =
       &nbs=
p;            =
;            =
           =
|
    |       &nbs=
p;           =
Forces message header       &nbs=
p;            =
;   |
    |       &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =
|
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
    |       &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =
|
    |       &nbs=
p;           =
Forces  =
Attributes       &nbs=
p;            =
;      =
|
    |       &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =
|
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
 
 
 
The Forces Message =
Header:
 
     0       &nbs=
p;           =
1       &nbs=
p;           =
2       &nbs=
p;           =
3
     0 1 2 3 4 5 6 =
7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
       &nbs=
p;            =
; 0       &nbs=
p;       1       &nbs=
p;       2       &nbs=
p;     3
<= pre style=3D'margin-left:36.0pt'>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>
    |       &nbs=
p;     Command       &nbs=
p; |       &nbs=
p;       Length       &nbs=
p;    |
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
    |       &nbs=
p;            =
;      Source xID         &nbs=
p;            =
;     |
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>
    |       &nbs=
p;            =
;    Destination xID       &nbs=
p;            =
;    |
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
    |       &nbs=
p;             &nbs=
p;  Sequence Number       &nbs=
p;            =
;    |
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
    |       &nbs=
p;     flags       &nbs=
p;   |       &nbs=
p;     typeid       &nbs=
p;      =
|
    =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
 
 
The xIDs are being discussed in issue =
0.
 
The command would be of the sort of ADD, =
DEL, =
GET.
The xID will address the entity being =
targeted.
[A command from a CE -> FE is for querying =
or configuration, whereas one
from FE -> CE is a response or =
event].
 
The typeid identifies further the type of =
target by looking at
typeid.
[ for example, in our implementation we =
extended the popular tcpdump 
sniffer to look decode the packet for =
protocol debugging purposes.
 
Length: length of the message including the =
attributes + header.
 
XML =
encoding:
XML encoding may be useful in capabilities =
definition
(i.e slow path) but not in the configuration =
of data path tables.
This is because of its nature to require =
higher bandwith and
CPU computational =
needs.
 
TLVs:
 
    0       &nbs=
p;           =
1       &nbs=
p;           =
2       &nbs=
p;           =
3
    0 1 2 3 4 5 6 7 8 9 =
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| TLV Type         &nbs=
p;          | =
variable TLV Length       &nbs=
p;     |
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
~       &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =
~
   =
|       &nbs=
p;    Value (Data of size TLV length)       &nbs=
p;            |
   =
~       &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =
~
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
 
It is possible to extend the data in the TLV =
to contain another
TLV to build complex structures (such as the =
ones described in
XML by the model draft or lists susch as =
those defined by GRMP).
 
Example:
    0       &nbs=
p;           =
1       &nbs=
p;           =
2       &nbs=
p;           =
3
    0 1 2 3 4 5 6 7 8 9 =
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| Outer TLV Type       &nbs=
p;      |    Outer TLV =
Length       &nbs=
p;     |
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| Inner TLV1 Type       &nbs=
p;     |   Inner TLV1 Length       &nbs=
p;     |
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| ~~~~~~~~~~~~~~       &nbs=
p;   VALUE1    =
~~~~~~~~~~~~~~~~~~~~~~     =
|
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| Inner TLV2 Type       &nbs=
p;     |   Inner TLV2 Length       &nbs=
p;     |
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
   =
| ~~~~~~~~~~~~~~       &nbs=
p;   VALUE2    =
~~~~~~~~~~~~~~~~~~~~~~     =
|
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
o:p>
 
 
Which could be used to represent the =
following layout :
 
  =
+-+-+-+-+-+-+-+-+-+-+-+        =
.-~-~-~-~-~-~-.
  =
|  TLV1       &nbs=
p;       | ------>|   param 1   =
|
  =
+-+-+-+-+-+-+-+-+-+-+-+       &nbs=
p; -~-~-~-~-~-~-
  =
|  TLV2       &nbs=
p;       | =
--->--+
  =
+-+-+-+-+-+-+-+-+-+-+-+       |
       &nbs=
p;            =
;            =
V
       &nbs=
p;            =
;            =
|
       &nbs=
p;            =
;           =
/
       &nbs=
p;          =
+-----------+
       &nbs=
p;          |       &nbs=
p;   
       &nbs=
p;          V       &nbs=
p;         =
.-~-~-~-~-~-~-.
       &nbs=
p;          |       &nbs=
p;    +--->|  param2_1   | =

  +-+-+-+-+-+-+-+-+-+-+-+      =
|     =
-~-~-~-~-~-~- 
  |  TLV2_1       &nbs=
p;     | --->-+       =
.-~-~-~-~-~-~-.
  =
+-+-+-+-+-+-+-+-+-+-+-+       &nbs=
p; +--->| param2_2    =
|
  =
|  TLV2_2       &nbs=
p;     | --->----+     -~-~-~-~-~-~- =

  +-+-+-+-+-+-+-+-+-+-+-+  =

 
 
It is thought that TLVs and nested TLVs will =
generally constitute
slightly higher requirements for compute and =
bandwdith than encodings 
based on fixed layouts (XML is many more =
factors demanding). 
The added advantage with TLV usage of course =
is ability to add new 
TLVs easily without redefining the packet or =
the protocol.
In addition, being able to optionally leave a =
TLV out during communication
(the message example would have been =
perfectly decoded if TLV1 was
never =
encoded).
 
A small challenge that needs to be overcome =
for TLVs is to detect
where failures happen (when you have a list =
or other compound structure). 
This is mostly useful/needed for batching or =
configuring a list of elements. 
If we were to use our implementation as a =
sample space: we had the "all 
upto failed one applied" scheme, in =
which case a NACK with the failed 
TLV Type is sent =
back.
 
An interesting idea is to encode an 8 bit =
sequence number in the 
type to find precisely which TLV =
failed.
 
 
  =
------=_NextPart_000_0068_01C404F8.96AD5940-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 10:42:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08578 for ; Mon, 8 Mar 2004 10:42:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mt3-0008GY-E4 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 10:41:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Ffnoi031768 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 10:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mt3-0008GJ-7U for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 10:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08522 for ; Mon, 8 Mar 2004 10:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mt0-00075h-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ms3-0006u3-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:40:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0MrI-0006jR-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0MrI-00086q-Sn; Mon, 08 Mar 2004 10:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mr1-0007ze-TX for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 10:39:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08054 for ; Mon, 8 Mar 2004 10:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mqz-0006gL-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Mq4-0006TU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:38:45 -0500 Received: from tomts35.bellnexxia.net ([209.226.175.109] helo=tomts35-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1B0MpI-0006Hk-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:37:57 -0500 Received: from develSPavel ([67.69.27.58]) by tomts35-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040308153745.DEGE20454.tomts35-srv.bellnexxia.net@develSPavel>; Mon, 8 Mar 2004 10:37:45 -0500 Reply-To: From: "Sandy Pavel" To: "'Khosravi, Hormuzd M'" , Cc: Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <006c01c40524$174c1480$a401a8c0@toronto.chantrynetworks.com> 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 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0542F5@orsmsx408.jf.intel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 10:43:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On the justification for a Priority field: As far as I can tell this protocol is not "routable" based On addressing scheme specified in its header. I therefore believe that priority processing is a function of the lower Level transport protocol. This is true even if the transport protocol used Is a L2 protocol. There should be a single point where the ForCES protocol messages are mapped To lower level transport protocol. And this is the point where the priority Should be specified. Regards, Sandy -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: March 8, 2004 2:13 AM To: hadi@znyx.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] issue 1: packet encoding -----Original Message----- On Behalf Of Jamal Hadi Salim > Here are my views on this issue, particularly the common header: > > Command: Agree this is needed. We think 8-12 bits will be more than > sufficient for this depending on whether it is subdivided. We have > sub-divided this field into Class/type...this is an OO approach, seemed > pretty neat. However, I am personally fine with having a single field > for this, no problem with that. I think we could resolve this later; i am not seeing a lot of commands. On the outset i can only see ADD/DEL/GET [HK] Ok, we can resolve this later. So I guess you are fine with 8 bits for the command? especially, if you only see a few of them. > Flags/Priority: We need 2-3 bits for priority in every message. I don't > think we need any other flags in all messages. How do you propose we do things like 2 phase commits; atomic transactions etc? [HK] You need flags for this, however this is only for configuration messages, they don't have to be in the common header. They will be part of the config message TLV. As you said below... "Agreed - the main thing is that if something needs to be used in all messages then it should go on this header (since its cheaper than a TLV)." Also in regards to priority; do you see this being used all the time? [HK] Sure, this is definitely needed in all messages. I believe even GRMP has this, infact I had a feeling till today that even netlink had it. and would an underlying transport priority be insufficient (example diffserv, 802.1p etc)? [HK] This is priority at the ForCES level which will eventually be mapped to the underlying transport/interconnect. We definitely need it at the ForCES level as well. > Typeid: This is one field I don't think is needed in all messages. I am > not sure why this is needed at all cause, we will be using the Model and > LFB IDs to address processing functional blocks on the FEs. I am not sure i see this. If you could explain more mayeb it would help. Like i said the only value is in being able to look at the outer header and recognizing for example the target where the message is being sent to (example LFB class). If not for anything else, debugging (via sniffing) is a good reason - this way i could dump the rest of the message by recognizing what the TLVs mean. [HK] Debugging doesn't seem to be a good reason to me to add a field to the common header. It has to be something very useful for the protocol and all messages. What do others think about this one? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 10:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09167 for ; Mon, 8 Mar 2004 10:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0N02-0000SH-DA for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 10:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Fn2w6001743 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 10:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0N02-0000S2-5H for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 10:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09128 for ; Mon, 8 Mar 2004 10:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mzz-0000cg-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:48:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Mz0-0000R6-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:48:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0My2-0000GA-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 10:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0My4-0000GL-8T; Mon, 08 Mar 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Mxr-0000Ft-1o for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 10:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08936 for ; Mon, 8 Mar 2004 10:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mxo-0000Ej-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:46:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Mws-00005c-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:45:48 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0Mw9-0007dG-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 10:45:01 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28FiSTN009965; Mon, 8 Mar 2004 09:44:29 -0600 (CST) Message-ID: <404C94DC.1080203@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wmwang@mail.hzic.edu.cn CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Comments from chat with ADs References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> <4048A7EB.2030808@alcatel.com> <1078530100.4049103fdc6dc@mail.hzic.edu.cn> In-Reply-To: <1078530100.4049103fdc6dc@mail.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------090805010909090506050706" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 09:44:28 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090805010909090506050706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by auds952.usa.alcatel.com id i28FiSTN009965 Content-Transfer-Encoding: quoted-printable Hello Weiming, I was refering to the C/D different queueing experiment (I think it is=20 Expeiriment II). The bottom line is you should be able to decouple events on C queue and=20 D queue from interfering with each other. You can set up simulation runs on OPNET=20 or similar environments to check this out. Regards, Alex. wmwang@mail.hzic.edu.cn wrote: >Hi Alex, > >Because we have several experiment cases, could you tell more which one= you=20 >are addressing and what is the result you think should be? > >I strongly suggest the same experiments be done by more guys here so th= at we=20 >can share to analyze the results. > >Cheers, >Weiming > >Quoting Alex Audu : > > =20 > >>Hello Weiming, >> >>I still believe that the result you got from your experiment could be=20 >>much more >>improved if you allocated two separate queues, one for C and the other=20 >>for D >>data. Then create two separate threads to process the queues (one for e= ach). >>Give both threads equal priority and you should be fine. If you want to= skew >>things in favor of the C, then you can adjust priority accordingly. >> >>Regards, >>Alex. >> >>Wang,Weiming wrote: >> >> =20 >> >>>Hi David, >>> >>>Some more comments on the multi-channels from your last email as below= : >>> >>>I agree that multiple FEs sharing the same physical link makes problem= s more >>> =20 >>> >>complicated. To make things more clear, I want state GRMP's ideas >> =20 >> >>>again here, for I think there might be some misunderstanding on it: >>> >>>1. GRMP presents that pure separation of C/D in the same physical link= is of >>> =20 >>> >>no use to DoS protection. DoS protection can only be achieved by inside= FE >>mechanisms except a separate physical link is used by C/D. This also a= pplies >>to multi-FEs sharing the same physical links as you mentioned above. Ac= tually >>I can not see such separation has solved the DoS problem for multi-FE c= ase >>from the above txt. =20 >> =20 >> >>>2. We do not oppose to have such separation if it's proven useful for >>> =20 >>> >>others. Actually the key GRMP has defined for DoS and congestion contro= l is >>the FE attribute for DoS protection policy, which has no limitation wit= h >>multi transport layer channels. If it's proven separation of C/D channe= ls are >>useful, GRMP can easily adapt it. But what we need more discussion is t= rying >>to see more reasons for such separations.=20 >> =20 >> >>>3. A combined control of C and D is useful for DoS protection as well = as for >>> =20 >>> >>congestion.=20 >> =20 >> >>>I have to note that the scheme proposed by FACT and also mentioned in = the >>> =20 >>> >>proposed basic merge principles only assume to provide a Data channel >>control mechanism ( a rate limit). We just argue that this is not enoug= h. >>Actually what you mentioned above is also to ask for such a control >>combination for multi-FEs cases. GRMP scheme can supply this very well = by >>using a FE attribute to specify DoS protection policy in which C packet= s with >>higher priorities can be ensured. I don't think other protocols have pr= ovided >>this mechanism (Note that this priority is different from that in ForCE= S >>message headers, which actually does not take effect for this purpose).= =20 >> =20 >> >>>To summarize, we just argue that a DoS protection policy like that pre= sented >>> =20 >>> >>by GRMP should be included in final ForCES protocol other than just by >>separation of C/D channels so as to effectively avoid DoS attack and al= so to >>manage the congestion. I think this idea is quite the same as what you >>presented in another email as some QoS hints transmitted from CE to FE = for >>DoS protection and congestion control.=20 >> =20 >> >>>Yours, >>>Weiming >>> >>>----- Original Message -----=20 >>>From: "Putzolu, David" >>>To: >>>Sent: Tuesday, March 02, 2004 9:06 PM >>>Subject: [Forces-protocol] Comments from chat with ADs >>> >>> >>>Patrick and I spent about 90 minutes last night >>>chatting with Bill and Alex about ForCES, with >>>maybe half of the time on the protocol. In >>>the conversations with them, along with some >>>follow-up chats I had with Allison Mankin, the >>>following topics where covered: multiple=20 >>>channels, multicast/unicast, and congestion=20 >>>control. Below is what I recall from memory=20 >>>(Patrick please correct me/elaborate as needed :) >>> >>> >>> >>>Multiple channels: =20 >>> >>>I discussed the interference issue that=20 >>>was identified by the GRMP team. Bill & >>>Alex agreed that many OS implementations can have >>>an interference property (i.e. where two different >>>connections will have queuing interference lower in >>>the networking stack in the OS). So it is necessary >>>to make sure when implementing a FE (or CE probably >>>as well) that this is taken into account. Methods >>>of doing that include: >>>* Manually queuing packets (i.e. feed OS few enough >>> packets that it cannot get into trouble - although >>> you pay a performance price for that, in that fine >>> grained scheduling takes cycles) >>>* Indicating to the OS to treat flows differently -=20 >>> some real-time OS will let you do this, that is they >>> are implemented to internally retain QoS between >>> flows. >>>However, it was also mentioned that intra-FE=20 >>>interference is only one kind of interference. Good >>>FE implementation (e.g. by manually queuing above the >>>OS) helps to fix intra-FE interference, but it does >>>not solve inter-FE interference. That is, if all >>>(C & D) packets are always on the same connection, >>>that makes it impossible on the wire to differentiate >>>them from one another. Imagine you have a bunch of >>>FEs with some of them being subject to DOS attack for >>>D packets, and you want to query one of the FEs for >>>statistics. It would be good to have some way of >>>ensuring the C packets (or any high priority packets - >>>OSPF HELLO maybe) get through. Separate channels >>>(as Jamal indicated, don't even have to be C & D) >>>makes this possible. Putting everything on one >>>channel makes it impossible to deal with inter-FE >>>interference in a differentiated fashion.=20 >>> >>>[WangRe] >>> >>> >>>=16S(=DCz=CAk=A2=DA=1C=A2Ys(S(X=A7,X=AC=B4Z+q=EB)=AE?=FF=0C0=D6'=AD~S(= =E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=F7=E8=AD=C7=AC=A6=BA-=A1=CA% >>> >>> =20 >>> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> =20 >> > > > > >------------------------------------------------- >This mail sent through HUCNIC Webmail system. > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > --------------090805010909090506050706 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Weiming,

I was refering to the C/D different queueing experiment (I think it is Expeiriment II).
The bottom line is you should be able to decouple events on C queue and D queue from
interfering with each other.   You can  set up simulation runs on OPNET or similar
environments to check this out.

Regards,
Alex.


wmwang@mail.hzic.edu.cn wrote:
Hi Alex,

Because we have several experiment cases,  could you tell more which one you 
are addressing and what is the result you think should be?

I strongly suggest  the same experiments be done by more guys here so that we 
can share to analyze the results.

Cheers,
Weiming

Quoting Alex Audu <alex.audu@alcatel.com>:

  
Hello Weiming,

I still believe that the result you got from your experiment could be 
much more
improved if you allocated two separate queues, one for C and the other 
for D
data. Then create two separate threads to process the queues (one for each).
Give both threads equal priority and you should be fine. If you want to skew
things in favor of the C, then you can adjust priority accordingly.

Regards,
Alex.

Wang,Weiming wrote:

    
Hi David,

Some more comments on the multi-channels from your last email as below:

I agree that multiple FEs sharing the same physical link makes problems more
      
complicated. To make things more clear, I want state GRMP's ideas
    
again here, for I think there might be some misunderstanding on it:

1. GRMP presents that pure separation of C/D in the same physical link is of
      
no use to DoS protection. DoS protection can only be achieved by inside FE
mechanisms except  a separate physical link is used by C/D. This also applies
to multi-FEs sharing the same physical links as you mentioned above. Actually
I can not see such separation has solved the DoS problem for multi-FE case
from the above txt.  
    
2. We do not oppose to have such separation if it's proven useful for
      
others. Actually the key GRMP has defined for DoS and congestion control is
the FE attribute for DoS protection policy, which has no limitation with
multi transport layer channels. If it's proven separation of C/D channels are
useful, GRMP can easily adapt it. But what we need more discussion is trying
to see more reasons for such separations. 
    
3. A combined control of C and D is useful for DoS protection as well as for
      
congestion. 
    
I have to note that the scheme proposed by FACT and also mentioned in the
      
proposed basic merge principles only assume to provide  a Data channel
control mechanism ( a rate limit). We just argue that this is not enough.
Actually what you mentioned above is also to ask for such a control
combination for multi-FEs cases. GRMP scheme can supply this very well by
using a FE attribute to specify DoS protection policy in which C packets with
higher priorities can be ensured. I don't think other protocols have provided
this mechanism (Note that this priority is different from that in ForCES
message headers, which actually does not take effect for this purpose).  
    
To summarize, we just argue that a DoS protection policy like that presented
      
by GRMP should be included in final ForCES protocol other than just by
separation of C/D channels so as to effectively avoid DoS attack and also to
manage the congestion. I think this idea is quite the same as what you
presented in another email as some QoS hints transmitted from CE to FE for
DoS protection and congestion control. 
    
Yours,
Weiming

----- Original Message ----- 
From: "Putzolu, David" <david.putzolu@intel.com>
To: <forces-protocol@ietf.org>
Sent: Tuesday, March 02, 2004 9:06 PM
Subject: [Forces-protocol] Comments from chat with ADs


Patrick and I spent about 90 minutes last night
chatting with Bill and Alex about ForCES, with
maybe half of the time on the protocol.  In
the conversations with them, along with some
follow-up chats I had with Allison Mankin, the
following topics where covered:  multiple 
channels, multicast/unicast, and congestion 
control.  Below is what I recall from memory 
(Patrick please correct me/elaborate as needed :)



Multiple channels:  

I discussed the interference issue that 
was identified by the GRMP team.  Bill &
Alex agreed that many OS implementations can have
an interference property (i.e. where two different
connections will have queuing interference lower in
the networking stack in the OS).  So it is necessary
to make sure when implementing a FE (or CE probably
as well) that this is taken into account.  Methods
of doing that include:
* Manually queuing packets (i.e. feed OS few enough
 packets that it cannot get into trouble - although
 you pay a performance price for that, in that fine
 grained scheduling takes cycles)
* Indicating to the OS to treat flows differently - 
 some real-time OS will let you do this, that is they
 are implemented to internally retain QoS between
 flows.
However, it was also mentioned that intra-FE 
interference is only one kind of interference.  Good
FE implementation (e.g. by manually queuing above the
OS) helps to fix intra-FE interference, but it does
not solve inter-FE interference.  That is, if all
(C & D) packets are always on the same connection,
that makes it impossible on the wire to differentiate
them from one another.  Imagine you have a bunch of
FEs with some of them being subject to DOS attack for
D packets, and you want to query one of the FEs for
statistics.  It would be good to have some way of
ensuring the C packets (or any high priority packets -
OSPF HELLO maybe) get through.  Separate channels
(as Jamal indicated, don't even have to be C & D)
makes this possible.   Putting everything on one
channel makes it impossible to deal with inter-FE
interference in a differentiated fashion. 

[WangRe]


ŠÜzÊk¢Ú¢YšŠX§‚X¬´Z+që)®‹hr‰bz×è®m¶›?ÿ0Ö'­~Šàþf¢–f§þX¬¶)ߣ÷è­Ç¬¦º-¡Ê%

      
_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol

    




-------------------------------------------------
This mail sent through HUCNIC Webmail system.


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------090805010909090506050706-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 11:34:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12415 for ; Mon, 8 Mar 2004 11:34:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NhT-0003Yh-Ht for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 11:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28GXtsR013679 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 11:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NhT-0003YV-22 for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 11:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12358 for ; Mon, 8 Mar 2004 11:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NhS-0001U9-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:33:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NgX-0001Il-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:32:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Nfc-00017d-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Nfc-0003TG-R2; Mon, 08 Mar 2004 11:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NfQ-0003Sl-Hb for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 11:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12248 for ; Mon, 8 Mar 2004 11:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NfP-00015R-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:31:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NeS-0000vm-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:30:49 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ndi-0000ck-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:30:02 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28GTUTN021060; Mon, 8 Mar 2004 10:29:30 -0600 (CST) Message-ID: <404C9F6A.8090403@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: hadi@znyx.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 10:29:30 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hormuzd, We should be able to support FEs in the thousands. A distribute GiGa router could comprise of 2048 FEs for example. The more powerful the FEs, the smaller this number ( I believe). Alex. Khosravi, Hormuzd M wrote: >Alright, here are my views on this issue/topic... > >[snip..] > >Length: Acc to the scalability requirements, we need to support hundreds >of FEs (<=1000) and even much less no of CEs (<=100). So 10 bits would >be enough for FEID/Dest ID and 7 bits for CEID/ Src ID. However, in >order to accommodate even higher requirements and have the fields 32-bit >aligned we used 16 bits for FEID, CEID. If there is a good technical >reason for requiring 32-bits I would be willing to compromise on this. >However, one thing to keep in mind is that this is the common header so >every byte we add to it will be added to all the messages, so it would >be a good design principle to be a bit stingy here. If it was part of an >optional TLV, we wouldn't care as much. > > >Let me know what other views are on this topic. > > >Thanks >Hormuzd > >-----Original Message----- >From: Jamal Hadi Salim [mailto:hadi@znyx.com] >Sent: Thursday, March 04, 2004 1:48 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Issue 0: Application addressing > >Hormuzd, >heres some text for application addressing > >---- >Source and Destination IDs: > >These are application level identifiers. They could be used >to address the following: >- an LFB on the FE, >- a set of LFBs on an FE >- a set of LFBs on different FEs >- proxies for LFBs, >- proxies for control application in the form on the CEs, >- the FE, >- a set of FEs >- all FEs >- the CE. >- a set of CEs >- all CEs > >The above shows need for having the ID being able to be IDed >as unicast, broadcast or multicast. > >For clarity, i could create a diagram of what we used. > >I will post the header i posted earlier next. Or maybe we should >stick to resolving this first. >Hopefully we can get to a good way to beat the several issues, i am >doing this to hopefuly come to a style that we can use to beat the >issues. > >cheers, >jamal > > > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 11:59:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13846 for ; Mon, 8 Mar 2004 11:59:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0O5W-00061E-NQ for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 11:58:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Gwkg1023130 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 11:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0O5W-00060z-AM for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 11:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13802 for ; Mon, 8 Mar 2004 11:58:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0O5V-0006qV-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:58:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0O4f-0006h8-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:57:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0O3o-0006XK-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 11:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0O3o-0005yK-Vu; Mon, 08 Mar 2004 11:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0O3W-0005xT-Oh for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 11:56:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13709 for ; Mon, 8 Mar 2004 11:56:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0O3V-0006UP-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:56:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0O2Y-0006LU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:55:44 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0O1j-00063x-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 11:54:51 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28GrMTN026625; Mon, 8 Mar 2004 10:53:22 -0600 (CST) Message-ID: <404CA502.1000004@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SPavel@chantrynetworks.com CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] issue 1: packet encoding References: <006701c40522$7f836140$a401a8c0@toronto.chantrynetworks.com> In-Reply-To: <006701c40522$7f836140$a401a8c0@toronto.chantrynetworks.com> Content-Type: multipart/alternative; boundary="------------070706080502010508020909" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 10:53:22 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070706080502010508020909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have raised this same issue in the past. We are hoping that the use of binary XML will decrease the presure on resources. But then we should be able to support other commonly available and efficient encoding of data for transport between FE and CE. Alex. Sandy Pavel wrote: > Alex is right. The Value field of a TLV can contain other TLVs but > this is the actual TLV definition. > > I suppose this explicit representation was made only for clarification. > > > > If we look at other protocols defined in the last few years, many use > TLV. The reasons are many and it > > i no point in elaborating on this. I have noticed that XML was > mentioned here. This requires quite a bit > > of resources and seems to be more appropriate for an application-type > protocol rather than the one we try to > > define here. (this is debatable, of course). > > > > Sandy > > > > > > > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Alex Audu > Sent: March 5, 2004 5:36 PM > To: hadi@znyx.com > Cc: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] issue 1: packet encoding > > > > Jamal, > > After a quick glance, we don't need OuterTLV / IinnerTLV to be > explicitly called out. > As far as I know, this is an inherent TLV encoding property. > > I'll take a look at the rest and comment later. > > Regards, > Alex. > > Jamal Hadi Salim wrote: > >Attached is text for stimulating discussion on issue 1. > > > >cheers, > >jamal > > > > > > > >------------------------------------------------------------------------ > > > > >Packet encoding suggestion. > > > >Binary encoding to be used to be able to pack as much as possible > >within an allowed MTU. > >TLVs to be used to map the various attributes. > >TLVs within TLVs were used to encode complex attributes such as > >lists or compound structures. > > > >The layout below is to get a discussion going. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Forces message header | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > | Forces Attributes | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > >The Forces Message Header: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > 0 1 2 3 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Command | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Source xID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Destination xID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | flags | typeid | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >The xIDs are being discussed in issue 0. > > > >The command would be of the sort of ADD, DEL, GET. > >The xID will address the entity being targeted. > >[A command from a CE -> FE is for querying or configuration, whereas one > >from FE -> CE is a response or event]. > > > >The typeid identifies further the type of target by looking at > >typeid. > >[ for example, in our implementation we extended the popular tcpdump > >sniffer to look decode the packet for protocol debugging purposes. > > > >Length: length of the message including the attributes + header. > > > >XML encoding: > >XML encoding may be useful in capabilities definition > >(i.e slow path) but not in the configuration of data path tables. > >This is because of its nature to require higher bandwith and > >CPU computational needs. > > > >TLVs: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | TLV Type | variable TLV Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ~ ~ > > | Value (Data of size TLV length) | > > ~ ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >It is possible to extend the data in the TLV to contain another > >TLV to build complex structures (such as the ones described in > >XML by the model draft or lists susch as those defined by GRMP). > > > >Example: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Outer TLV Type | Outer TLV Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner TLV1 Type | Inner TLV1 Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ~~~~~~~~~~~~~~ VALUE1 ~~~~~~~~~~~~~~~~~~~~~~ | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Inner TLV2 Type | Inner TLV2 Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ~~~~~~~~~~~~~~ VALUE2 ~~~~~~~~~~~~~~~~~~~~~~ | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Which could be used to represent the following layout : > > > > +-+-+-+-+-+-+-+-+-+-+-+ .-~-~-~-~-~-~-. > > | TLV1 | ------>| param 1 | > > +-+-+-+-+-+-+-+-+-+-+-+ -~-~-~-~-~-~- > > | TLV2 | --->--+ > > +-+-+-+-+-+-+-+-+-+-+-+ | > > V > > | > > / > > +-----------+ > > | > > V .-~-~-~-~-~-~-. > > | +--->| param2_1 | > > +-+-+-+-+-+-+-+-+-+-+-+ | -~-~-~-~-~-~- > > | TLV2_1 | --->-+ .-~-~-~-~-~-~-. > > +-+-+-+-+-+-+-+-+-+-+-+ +--->| param2_2 | > > | TLV2_2 | --->----+ -~-~-~-~-~-~- > > +-+-+-+-+-+-+-+-+-+-+-+ > > > > > >It is thought that TLVs and nested TLVs will generally constitute > >slightly higher requirements for compute and bandwdith than encodings > >based on fixed layouts (XML is many more factors demanding). > >The added advantage with TLV usage of course is ability to add new > >TLVs easily without redefining the packet or the protocol. > >In addition, being able to optionally leave a TLV out during communication > >(the message example would have been perfectly decoded if TLV1 was > >never encoded). > > > >A small challenge that needs to be overcome for TLVs is to detect > >where failures happen (when you have a list or other compound structure). > >This is mostly useful/needed for batching or configuring a list of elements. > >If we were to use our implementation as a sample space: we had the "all > >upto failed one applied" scheme, in which case a NACK with the failed > >TLV Type is sent back. > > > >An interesting idea is to encode an 8 bit sequence number in the > >type to find precisely which TLV failed. > > > > > > > --------------070706080502010508020909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have raised this same issue in the past.  We are hoping that the use of binary XML
will decrease the presure on resources. But then we should be able to support other
commonly available and efficient encoding of data for transport between FE and CE.

Alex.

Sandy Pavel wrote:

Alex is right. The Value field of a TLV can contain other TLVs but this is the actual TLV definition.

I suppose this explicit representation was made only for clarification.

 

If we look at other protocols defined in the last few years, many use TLV. The reasons are many and it

i no point in elaborating on this. I have noticed that XML was mentioned here. This requires quite a bit

of resources and seems to be more appropriate for an application-type protocol rather than the one we try to

define here. (this is debatable, of course).

 

Sandy

 

 

 

-----Original Message-----
From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Alex Audu
Sent: March 5, 2004 5:36 PM
To: hadi@znyx.com
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] issue 1: packet encoding

 

Jamal,

After a quick glance, we don't need  OuterTLV / IinnerTLV to be explicitly called out.
As far as I know, this is an inherent TLV encoding property.

I'll take a look at the rest and comment later.

Regards,
Alex.

Jamal Hadi Salim wrote:

Attached is text for stimulating discussion on issue 1.
 
cheers,
jamal
  
 






 
Packet encoding suggestion. 
 
Binary encoding to be used to be able to pack as much as possible
within an allowed MTU. 
TLVs to be used to map the various attributes.
TLVs within TLVs were used to encode complex attributes such as
lists or compound structures.
 
The layout below is to get a discussion going.
 
 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Forces message header                       |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                   Forces  Attributes                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
The Forces Message Header:
 
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     0               1               2             3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Command         |               Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Source xID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Destination xID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             flags           |             typeid              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
The xIDs are being discussed in issue 0.
 
The command would be of the sort of ADD, DEL, GET.
The xID will address the entity being targeted.
[A command from a CE -> FE is for querying or configuration, whereas one
from FE -> CE is a response or event].
 
The typeid identifies further the type of target by looking at
typeid.
[ for example, in our implementation we extended the popular tcpdump 
sniffer to look decode the packet for protocol debugging purposes.
 
Length: length of the message including the attributes + header.
 
XML encoding:
XML encoding may be useful in capabilities definition
(i.e slow path) but not in the configuration of data path tables.
This is because of its nature to require higher bandwith and
CPU computational needs.
 
TLVs:
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type                    | variable TLV Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |            Value (Data of size TLV length)                    |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
It is possible to extend the data in the TLV to contain another
TLV to build complex structures (such as the ones described in
XML by the model draft or lists susch as those defined by GRMP).
 
Example:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outer TLV Type              |    Outer TLV Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner TLV1 Type             |   Inner TLV1 Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ~~~~~~~~~~~~~~           VALUE1    ~~~~~~~~~~~~~~~~~~~~~~     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner TLV2 Type             |   Inner TLV2 Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ~~~~~~~~~~~~~~           VALUE2    ~~~~~~~~~~~~~~~~~~~~~~     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
Which could be used to represent the following layout :
 
  +-+-+-+-+-+-+-+-+-+-+-+        .-~-~-~-~-~-~-.
  |  TLV1               | ------>|   param 1   |
  +-+-+-+-+-+-+-+-+-+-+-+         -~-~-~-~-~-~-
  |  TLV2               | --->--+
  +-+-+-+-+-+-+-+-+-+-+-+       |
                                V
                                |
                               /
                  +-----------+
                  |           
                  V                 .-~-~-~-~-~-~-.
                  |            +--->|  param2_1   | 
  +-+-+-+-+-+-+-+-+-+-+-+      |     -~-~-~-~-~-~- 
  |  TLV2_1             | --->-+       .-~-~-~-~-~-~-.
  +-+-+-+-+-+-+-+-+-+-+-+         +--->| param2_2    |
  |  TLV2_2             | --->----+     -~-~-~-~-~-~- 
  +-+-+-+-+-+-+-+-+-+-+-+  
 
 
It is thought that TLVs and nested TLVs will generally constitute
slightly higher requirements for compute and bandwdith than encodings 
based on fixed layouts (XML is many more factors demanding). 
The added advantage with TLV usage of course is ability to add new 
TLVs easily without redefining the packet or the protocol.
In addition, being able to optionally leave a TLV out during communication
(the message example would have been perfectly decoded if TLV1 was
never encoded).
 
A small challenge that needs to be overcome for TLVs is to detect
where failures happen (when you have a list or other compound structure). 
This is mostly useful/needed for batching or configuring a list of elements. 
If we were to use our implementation as a sample space: we had the "all 
upto failed one applied" scheme, in which case a NACK with the failed 
TLV Type is sent back.
 
An interesting idea is to encode an 8 bit sequence number in the 
type to find precisely which TLV failed.
 
 
 
--------------070706080502010508020909-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 12:42:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15500 for ; Mon, 8 Mar 2004 12:42:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OlF-0001Im-C1 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 12:41:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28HfrEr004993 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 12:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OlE-0001IS-Jh for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 12:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15408 for ; Mon, 8 Mar 2004 12:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0OlD-0006O7-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 12:41:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0OiH-0005fB-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 12:38:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0OhW-0005Vj-01 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 12:38:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0Oed-0004rL-T3 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 12:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Oec-0000t9-LA; Mon, 08 Mar 2004 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0OeH-0000rr-Jn for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 12:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15219 for ; Mon, 8 Mar 2004 12:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0OeF-00056H-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 12:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0OdJ-0004xr-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 12:33:42 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0Oca-0004gx-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 12:32:56 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28HWPTN005638; Mon, 8 Mar 2004 11:32:25 -0600 (CST) Message-ID: <404CAE29.9050608@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: hadi@znyx.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] issue 1: packet encoding References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 11:32:25 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't know what the flags could be used for. The TypeID could be used for siganling the type of data encoding explicitly, (i.e. XML, ASN.1 etc). My preference will be the following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |vers |eType | prio| reservd | msgClass | msgType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source xID | Destination xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1) version # indicates the version of the protocol. 2) the type of encoding comes next. 3) the priority of the message comes next. 4) the command has been divided into message class and type to ease management and handling. 5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool! 6) the length is now 32 bits long. This will accommodate flow measurement messages which tend to be huge, from FE to CE. It will also accommodate large table dumps from CE to FE. 7) then comes the sequence number. Any comments? Regards, Alex. >Jamal, > >Before I give my comments, I would like to say that I appreciate the >fact that you did not copy/paste the netlink header from your draft over >here! That is a very positive sign to me, lets try to stick to the best >technical solution rather than pushing our own protocol implementations. >That's the best way to make progress on this merger!! > >Here are my views on this issue, particularly the common header: > >Command: Agree this is needed. We think 8-12 bits will be more than >sufficient for this depending on whether it is subdivided. We have >sub-divided this field into Class/type...this is an OO approach, seemed >pretty neat. However, I am personally fine with having a single field >for this, no problem with that. > >Length: Agree needed and agree with size. > >xIDs: Agree this is needed. More detailed comments on length, semantics >in my previous email. > >Sequence No: Agree needed and agree with size. > >Flags/Priority: We need 2-3 bits for priority in every message. I don't >think we need any other flags in all messages. > >Typeid: This is one field I don't think is needed in all messages. I am >not sure why this is needed at all cause, we will be using the Model and >LFB IDs to address processing functional blocks on the FEs. > >Missing field: Version (2-4 bits): This is present in all protocols, and >is generally included in most IETF protocols. Its usually the 1st field. > >General comment: Lets try to be stingy on the size of the header and its >fields since this will be included in all ForCES messages. > >Jamal's text....... >The Forces Message Header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Command | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flags | typeid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >XML encoding: >XML encoding may be useful in capabilities definition >(i.e slow path) but not in the configuration of data path tables. >This is because of its nature to require higher bandwith and >CPU computational needs. > >HK Comment: I think we should stick with a single encoding type, namely >TLV. This is also what some of the model team folks have mentioned >before for the protocol. Is there a reason why capabilities cannot be >expressed using TLVs? > > >Thanks >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim >Sent: Friday, March 05, 2004 2:00 PM >To: forces-protocol@ietf.org >Subject: [Forces-protocol] issue 1: packet encoding > > >Attached is text for stimulating discussion on issue 1. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 14:27:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22320 for ; Mon, 8 Mar 2004 14:27:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QOw-0001Zx-PM for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 14:26:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28JQwTY006069 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 14:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QOw-0001Zo-Hk for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 14:26:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22288 for ; Mon, 8 Mar 2004 14:26:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QOu-0003Qq-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:26:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QNs-0003Aa-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:25:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0QN2-0002xf-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QN3-0001Pc-Qo; Mon, 08 Mar 2004 14:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QN0-0001Oz-BM for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 14:24:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22172 for ; Mon, 8 Mar 2004 14:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QMx-0002x0-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QM0-0002jG-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:23:56 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0QL6-0002Ou-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:23:00 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28JMSTN000727; Mon, 8 Mar 2004 13:22:29 -0600 (CST) Message-ID: <404CC7F3.1000602@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@acm.org CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] issue 1: packet encoding References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> In-Reply-To: <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 13:22:27 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Avri, I think error indication is actually another type of data to be sent between FE and CE. So we should carry it in the message itself (as an error message type). Regards, Alex. avri@acm.org wrote: > Hi, > > I have just caught up with the messages on this list. > > One general comment, I think the way you are all working through the > issues is great - fills me with hope. > > Specifically to the header, and I don't know how this fits into the > issue numbering scheme: > > - I think you should consider adding an error indication to the > header. It can either be along the lines included in GRMP or > otherwise. I have found having this in the header a very useful thing. > > - I agree that you need to include version and preferably subversion > number. > > - I also think that 8 bits is enough for message type. > > best regards > a. > > (avoiding commenting on topics not yet under discussion - i think) > > > On 7 mar 2004, at 07.37, Khosravi, Hormuzd M wrote: > >> The Forces Message Header: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Command | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source xID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Destination xID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | flags | typeid | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 14:48:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23748 for ; Mon, 8 Mar 2004 14:48:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QjH-0003vb-Dg for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 14:48:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Jlxli015095 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 14:47:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QjH-0003vO-9K for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 14:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23728 for ; Mon, 8 Mar 2004 14:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QjE-0007bb-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QiB-0007Pd-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:46:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0QhL-0007Ei-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QhN-0003nW-TJ; Mon, 08 Mar 2004 14:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qgb-0003ls-Ha for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 14:45:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23511 for ; Mon, 8 Mar 2004 14:45:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QgY-00073z-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:45:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Qff-0006rT-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:44:16 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Qew-0006fe-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:43:31 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030811440767:64805 ; Mon, 8 Mar 2004 11:44:07 -0800 Subject: Re: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078775008.1037.455.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 03/08/2004 11:44:08 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 11:44:09 AM, Serialize complete at 03/08/2004 11:44:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 14:43:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weimimg, Please make sure you wrap your emails around 80 characters. On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote: [..] > 1. The "command" field > This is really a field that confuses me. The confusion is: > 1) If it is a field only with command "Add/Del/Get", I suppose we can just > obsolete it. > The command can be surely be expressed in the followed body by using TLVs. Every message will have a command. For that reason it belongs to the main header. > 2) If we keep it, I'm afraid it's meaning should be far from these. For > example, how > an event report can be represented, and how a command bundle is represented > then, > and many others? I will explain how we implemented events; note, this is different from the current command structure but shoudl give you a view: - An "add route" from CE->FE means to configure something on one or more FEs that are addressed. - An "add route" from FE->CE is an event notifying that a route was added. An alternative is to reserve one bit for saying its an event or configuration then you dont have to intepret directions. > We just think to have a field with insufficient functions really makes > confusions. > > As a result, I suppose two solution schemes for this problem: > Scheme 1: Define this as "message type", to have the message body to express > the > operation not just based on TLV format. This means things like "Flags" > "operating fields" > are explicitly expressed according to the "message type" operation > requirements. Remember > that by using this scheme, we have already taken the whole ForCES > message as one TLV. > Scheme 2: Not define anything in the header on the "command" or > "message type", leaving > things defined in the followed body, while the body is expressed > by a set of TLVs, each TLV > representing a type of operation. > The advantage for Scheme1 is it is very clear in semantics and > saves bits quite a lot. > The disadvantage is it has to define a specific message type for > command bundle. > The advantage for Scheme 2 is it is easy to implement command bundle, > but the disadvantage > is it costs more bits and makes protocol header less to do. I prefer to have the headers with flags; flags were usable on every message. > 2. The Checksum field and other error control mechanism > One essential function a protocol header takes is for a reliable > information exchange, therefore, > the common error control mechanism should be included in the header > instead in the body. > > It seems no argue that a checksum should be provided as an option. > Only difference between > the candidate protocols is how it should be put. GRMP puts it at the > protocol message end, > Netlink2 has it as a TLV, I suppose FACT also intends the same. I'm > thinking the purpose to > have it as a TLV is mainly trying to reach a uniform TLV format. What > we argue is to put > checksum in a TLV may get more loss for the checking function, because > it then will be in a risk > that the TLV structure itself may be erred, which may result in the > invalidation of the checksum. Netlink2 has the concept of several shades of reliability. Some messages dont need to be validated and therefore dont need a checksum. This is also the path we are following now, for that reason checksum should stay an optional field. > GRMP reuses the idea "result" and "code" from GSMP, I'm sure this > error control function should be > included in the protocol. As the protocol header takes the tasks for > a reliable information exchange, I > strongly suggest it is put in the header. Could other candidate team > show your opinions or solutions to > this? We had the concept of an ACK which returns results. Depending on the result, this could be considered a NACK. The ACK is requested per message using flagd and so sometimes may never be sent. Again this has to do with levels of reliability. In other words while the result is useful in the header, it is only useful when the result is requested. This is described in the section " The ACK Netlink2 Message". I think this is similar to the way you do it in GRMP. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 14:59:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24329 for ; Mon, 8 Mar 2004 14:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qtn-0004aY-EI for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 14:58:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28JwpmV017632 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 14:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qtn-0004aJ-83 for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 14:58:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24313 for ; Mon, 8 Mar 2004 14:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Qtk-0001se-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Qsq-0001ji-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:57:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Qry-0001b6-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 14:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qs0-0004Wn-QK; Mon, 08 Mar 2004 14:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Qrt-0004W4-5K for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 14:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24268 for ; Mon, 8 Mar 2004 14:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Qrq-0001Zc-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Qqt-0001PU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:55:52 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0Qpy-00016B-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 14:54:54 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28JsMTN007421; Mon, 8 Mar 2004 13:54:23 -0600 (CST) Message-ID: <404CCF6D.8030103@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@acm.org CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Future question for the discussion References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> In-Reply-To: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 13:54:21 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Avri, Could you give more details on thge type of limitations you encountered while working with Master/Slave model? That will really help us. Thanks, Alex. avri@acm.org wrote: > Hi, > > One of the difference between the protocols is the use of peer-peer > model versus the master-slave model. Having worked with the > master-slave model in GSMP, I found it to have limitations and think > this should also be on the topics for discussion. > > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:11:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25522 for ; Mon, 8 Mar 2004 15:11:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R5Q-0004Nw-KS for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:10:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KAqDl016848 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R5Q-0004Nf-Aj for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:10:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25449 for ; Mon, 8 Mar 2004 15:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R5M-0003zx-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:10:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R4W-0003pw-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:09:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0R3b-0003ff-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R3d-0003iT-4t; Mon, 08 Mar 2004 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R2g-00036S-4H for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25127 for ; Mon, 8 Mar 2004 15:07:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R2c-0003UC-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R1i-0003Iw-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:07:03 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0R0v-0002xM-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:06: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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i28K7jpk016186 for ; Mon, 8 Mar 2004 20:07:45 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i28Jxqma005847 for ; Mon, 8 Mar 2004 19:59:54 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030812053827306 for ; Mon, 08 Mar 2004 12:05:38 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 12:05:38 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Issue 100: On the issue play Message-ID: <468F3FDA28AA87429AD807992E22D07E1039B5@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 100: On the issue play Thread-Index: AcQD92pn/pSmiTrjQBS02nsiIUp7aABP2vjg From: "Deleganes, Ellen M" To: X-OriginalArrivalTime: 08 Mar 2004 20:05:38.0873 (UTC) FILETIME=[B9F34A90:01C40548] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 12:05:38 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0aGluayBpdGVtIDE0IGNhbiBiZSBwdXQgb2ZmIHVudGlsIHRoZSBwcm90b2NvbCB3b3JrIG1v dmVzIGZvcndhcmQuIEkgd291bGQgaG9wZSB0aGF0IHByb3RvY29sIHBheWxvYWQgZGV0YWlscyBh cmVuJ3QgYSBnYXRpbmcgZmFjdG9yIG9uIHdoZXRoZXIgb3Igbm90IHRoZSBwcm90b2NvbHMgY2Fu IGJlIG1lcmdlZC4NCg0KWW91IHNob3VsZG4ndCB0YWtlIHRoZSBtb2RlbCBkcmFmdCB0b28gbGl0 ZXJhbGx5LiBJdCBkZXNjcmliZXMgYSBtb2RlbCBub3QgYW4gaW1wbGVtZW50YXRpb24sIHNvIHdo ZW4gdGhlIG1vZGVsIGRyYWZ0IHVzZXMgYW4gQVNDSUkgYmFzZWQgbmFtZSBsaWtlICJJUHY0IExG QiIgaXQgaXMgb25seSBmb3IgaHVtYW4gcmVhZGFiaWxpdHksIG5vdCB3aGF0IGlzIHJlcXVpcmVk IG9mIGFuIGltcGxlbWVudGF0aW9uLiANCg0KUmVnYXJkcywNCkVsbGVuDQogDQo+ID4gMTQpIENv bmZsaWN0IGNoZWNrIHdpdGggY3VycmVudCBGRSBtb2RlbA0KPiANCj4gVGhpcyBpcyBub3QgYSBj b250ZXRpb3VzIGlzc3VlIC0gaXQgY2FuIGJlIHJlc29sdmVkDQo+IGxhdGVyLiBJIGFjdHVhbGx5 IGhhdmVudCByZWFkIHRoZSBsYXRlc3QgaW5jYXJuYXRpb24NCj4gb2YgdGhlIG1vZGVsIGRyYWZ0 LiB3aGF0IGRpZCB5b3UgaGF2ZSBpbiBtaW5kPw0KDQpbV2VpbWluZyBSZV0NCk1heWJlIEkgc2hv dWxkIG5vdCB1c2UgJ2NvbmZsaWN0JywgaW5zdGVhZCBzaG91bGQgYmUgYSBjb2hlcmVyZW50IGNo ZWNrLiBGb3IgaW5zdGFuY2UsIG5ldyBGRSBtb2RlbCBzdXBwb3NlIHRvIHVzZSANCkFTQ0lJIGJz ZWQgTEZCIG5hbWVzIGxpa2UgIklQdjQgTFBGIi4gSSdtIHN1cmUgYW4gTEZCIElEIHdpbGwgYXBw ZWFyIGluIEZvckNFUyBwcm90b2NvbCwgdGhlbiBob3cgdGhleSBhcmUgY29uc2lzdGVudCB3aXRo DQplYWNoIG90aGVyLiBPdGhlcnMgbGlrZSBzb21ldGhpbmcgbm90IHN1cmVkIHdobyB3aWxsIGRl ZmluZSB0aGVtLCBhbmQgYXQgd2hhdCBsZXZlbCwgZXRjLg0KDQpDaGVlcnMsDQpXZWltaW5nDQoN Chblpp/nm5vlhpZZ5aWo5L+L56KvceawmOWqn+Wih+ahqQjnqJXvo7UNCj9+5amgZuadhe6gnT/v vZfuhYDunobiiIgNCg== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:15:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25959 for ; Mon, 8 Mar 2004 15:15:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R9I-0005Vc-5l for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:14:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KEq2w021169 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:14:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R9H-0005VF-QB for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:14:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25912 for ; Mon, 8 Mar 2004 15:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R9G-0004df-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:14:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R8L-0004V1-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:13:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0R7T-0004MX-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R7T-0004te-Np; Mon, 08 Mar 2004 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0R7H-0004q8-NH for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25715 for ; Mon, 8 Mar 2004 15:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0R7G-0004KU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0R6K-0004AJ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:11:49 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0R5P-0003sE-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:10:51 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28KAJTN010242; Mon, 8 Mar 2004 14:10:19 -0600 (CST) Message-ID: <404CD324.5060502@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> <1078751018.1037.386.camel@jzny.localdomain> In-Reply-To: <1078751018.1037.386.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------000604080004060601050406" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 14:10:12 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000604080004060601050406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I believe what Weiming seems to be saying is that we don't have to expose the LFB addressing in the common message header, since not all messages will target LFBs. So, it makes sense that such LFB addressing be carried on the TLVs for the messages that apply to the TLVs. I fully agree with this idea. Id does away with clutter, and makes for cleaner implementation. Also, the code will run faster since you don't spend time checking if LFBs are being addressed or not before you actually handle the core message (especially when LFBs are not being addressed.) Regards, Alex. Jamal Hadi Salim wrote: >Hormuzd, Weiming, > >Apologies for long email; i am attempting to respond to two emails in >one. > >Ok, let me provide an example of an FE (same concept applies at >the CE). >Heres a diagram that may help to clarify what i have been refering >to; note that netlink2 did not start like this, however over >time implementation ended being like this; this shows an FE >side implementation. I have attached the two diagrams so they >dont get mangled. > >Figure 1. shows the netlink2 manager ( a s/ware daemon) managing >two socket connections on the lower side labelled as wire0 and wire1 >and entities called FECs on the upper side. >Figure2 shows the role of the FEC; it MAY manages one or more LFBs. >The communication mechanism used there is again beyond the scope of >ForCES. >Messages arriving at either of the sockets could end up in two sorts of >general classes of destinations: >1) for the FE - in which they are serviced by the netlink2 daemon. >2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes >them to those entities. > >Although i only list two classes, there could be more - but thats beside >the point. >FECs are OS processes/applications. (How they communicate to the >netlink2 daemon is beyond the scope of ForCES; lets say it could be a >local OS IPC.) > >As an example, there may be a FEC which controls several LFBs; >Another example is an FEC which sends and receives OSPF hellos. >Each FEC has a counterpart which understands it on the CE side. >The CE piece of OSPF (call it CEC) sends messages to >a specific PID when it wants to talk to the FEC portion (the hello >offloader). >As you can see this is application talking to another application; >this could be looked at as essentially IPC. Therefore the concept of PID >is useful. > >Now to address your emails: > >On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: > >Weiming, could you make sure your emails wrap around at 80 characters? >It helps when i am trying to respond. > > > > >>We think a layer-based tree structure according to the ForCES architecture >>is efficient to do such addressing. If we address entities at >>the FE coarse layer ( to take the FE as a whole entity, which idea is also >>used by new version of FE model ), we only need to >>have a FE ID. >> >> > >If i am not mistaken what you are talking about is a detail >on how the address gets split; i.e you want to have a hierachical >addressing - as an example you want to split the address above to >FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). >If this is the case, i think it is a small detail and we could move >on and talk baout it later; if not please look at the diagram and >tell me how you would split the ID to configure LFB0. I actually have >a feeling your approach to this would be VERY different from Hormuzd ;-> > > > >> To address >>CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, LFB >>Instance broadcast, and CE broadcast, following addressing can be >>implemented: >> >> > >I think we all agree on the broadcast or multicast to a specific >type of entities. > > > >>>- a set of LFBs on an FE >>> >>> >>- a set of LFBs on different FEs >> >> >>[Wang Re: Are the set of LFBs of the same type?] >> >> > >Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > > > >>- proxies for LFBs, >>- proxies for control application in the form on the CEs, >> >>[Wang Re: If ever we have these proxies, are they need to be seen at the >>protocol layer? >> >> > >No, there is nothing speacial needed at the protocol header. The list >was an exhaustive example. > > > >>Moreover, how about FE proxies then?] >> >> > >They dont need to be addressed by anything speacial in the header. > >On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: > > > >>[HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go >>with that terminology then? >> >> > >Lets talk about what needs to be addressed first before we jump to that. >Refer to the two diagrams i sent. > > > >>[HK] I don't see the value of having an App ID in the common header. How >>is it useful ? May be if you could give a good example of how this can >>be used, it would help. The ForCES endpoints are CEs and FEs which >>should be addressed in the common header. LFBs are like knobs on the FEs >>used to program its functionality. I am sure you know all this very well >>and I think most folks will agree on this. If we go with a different >>view, we will probably land up breaking the FE Model as well. Other >>views on this one ? >> >> > >Refer to the two diagrams i sent for an example, then lets discuss. > >[HK] Could you give me an example of why this is limiting? > >I was refering to the fact that you have a single ID to address >entities within an FE or CE. In my diagram i am rtying to show theres >more than one class of end targets. So calling it CEID or FEID >is limiting. > > > >>I would like >>to know if using 16 bits would break in some scenarios. If this was part >>of a TLV I wouldn't care as much, but since this is the common header, I >>am a bit concerned...acting stingy :-)) >> >> >. > >[HK] Exactly, ForCES has much limited/specific scope (NE) than general > > >>purpose middleware such as Corba. You cannot compare these 2 because of >>the difference in scope. >> >> > >I gave the historical experience of PCs (by quoting a naive bill gates), >IPV4(by making a mockery over the famous last words that brought IPV6 to >the world) and now i can add the experience of unix which would have >been more interesting with 64 bit PIDs. >Summary: Nothing would break; however it is useful to learn from history >and say lets go with something larger. > >Again, apologies for long email; hopefully this would group >things together. > >cheers, >jamal > > >------------------------------------------------------------------------ > > > > +-----FE0---------------------------------------------+ > | | > | | > | | > | /~~~~~\ /~~~~~\ /~~~~~\ | > | | FEC0 | | FEC1 | | FECx | | > | | | | | ..... | | | > | \_____/ \_____/ \_____/ | > | | | | | > | /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ | > | | | | > | | Netlink2 Manager | | > | | | | > | \_______________________________/ | > | | | | > | | | | > +--------------/--------------|-----------------------+ > | | > | | > wire0 --+ + --- wire1 > > >Figure 1. > > > /~~~~~\ > | FEC0 | > | | > \_____/ > | > Y > | netlink, proprietary, NPF API, etc > ^ > | > +-+---------+ > datapath | | processed packet > ----------> | LFB10 | ----> > | | > +___________+ > > >Figure 2. > > --------------000604080004060601050406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I believe what Weiming seems to be saying is that we don't have to expose the LFB
addressing in the common message header, since not all messages will target LFBs.
So, it makes sense that  such LFB addressing be carried on the TLVs for the messages
that apply to the TLVs.  I fully agree with this idea.  Id does away with clutter, and makes
for  cleaner  implementation.  Also, the code will run faster since you don't spend time
checking if LFBs are being addressed or not before you actually handle the core
message (especially when LFBs are not being addressed.)

Regards,
Alex.


Jamal Hadi Salim wrote:
Hormuzd, Weiming,

Apologies for long email; i am attempting to respond to two emails in
one.

Ok, let me provide an example of an FE (same concept applies at
the CE). 
Heres a diagram that may help to clarify what i have been refering
to; note that netlink2 did not start like this, however over
time implementation ended being like this; this shows an FE
side implementation. I have attached the two diagrams so they
dont get mangled.

Figure 1. shows the netlink2 manager ( a s/ware daemon) managing
two socket connections on the lower side labelled as wire0 and wire1
and entities called FECs on the upper side.
Figure2 shows the role of the FEC; it MAY manages one or more LFBs.
The communication mechanism used there is again beyond the scope of
ForCES.
Messages arriving at either of the sockets could end up in two sorts of
general classes of destinations:
1) for the FE - in which they are serviced by the netlink2 daemon.
2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes
them to those entities.

Although i only list two classes, there could be more - but thats beside
the point.
FECs are OS processes/applications. (How they communicate to the
netlink2 daemon is beyond the scope of ForCES; lets say it could be a
local OS IPC.)

As an example, there may be a FEC which controls several LFBs; 
Another example is an FEC which sends and receives OSPF hellos.
Each FEC has a counterpart which understands it on the CE side.
The CE piece of OSPF (call it CEC) sends messages to
a specific PID when it wants to talk to the FEC portion (the hello
offloader).
As you can see this is application talking to another application;
this could be looked at as essentially IPC. Therefore the concept of PID
is useful.

Now to address your emails:

On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote:

Weiming, could you make sure your emails wrap around at 80 characters?
It helps when i am trying to respond.


  
We think a layer-based tree structure according to the ForCES architecture 
is efficient to do such addressing. If we address entities at
the FE coarse layer ( to take the FE as a whole entity, which idea is also 
used by new version of FE model ), we only need to 
have a FE ID.  
    

If i am not mistaken what you are talking about is a detail
on how the address gets split; i.e you want to have a hierachical
addressing - as an example you want to split the address above to
FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above).
If this is the case, i think it is a small detail and we could move
on and talk baout it later; if not please look at the diagram and 
tell me how you would split the ID to configure LFB0. I actually have 
a feeling your approach to this would be VERY different from Hormuzd ;->

  
 To address 
CEs, we use CE ID.  By defining IDs for FE broadcast, LFB broadcast, LFB 
Instance broadcast, and CE broadcast, following addressing can be 
implemented:
    

I think we all agree on the broadcast or multicast to a specific
type of entities.

  
- a set of LFBs on an FE
      
- a set of LFBs on different FEs 


[Wang Re: Are the set of LFBs of the same type?]
    

Yes, example "all IPV4 fwding LFBs" instead of "all LFBs".

  
- proxies for LFBs,
- proxies for control application in the form on the CEs, 

[Wang Re:  If ever we have these proxies, are they need to be seen at the 
protocol layer? 
    

No, there is nothing speacial needed at the protocol header. The list 
was an exhaustive example.

  
Moreover, how about FE proxies then?]
    

They dont need to be addressed by anything speacial in the header.

On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: 

  
[HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go
with that terminology then?
    

Lets talk about what needs to be addressed first before we jump to that.
Refer to the two diagrams i sent.

  
[HK] I don't see the value of having an App ID in the common header. How
is it useful ? May be if you could give a good example of how this can
be used, it would help. The ForCES endpoints are CEs and FEs which
should be addressed in the common header. LFBs are like knobs on the FEs
used to program its functionality. I am sure you know all this very well
and I think most folks will agree on this. If we go with a different
view, we will probably land up breaking the FE Model as well. Other
views on this one ?
    

Refer to the two diagrams i sent for an example, then lets discuss.

[HK] Could you give me an example of why this is limiting? 

I was refering to the fact that you have a single ID to address
entities within an FE or CE. In my diagram i am rtying to show theres
more than one class of end targets. So calling it CEID or FEID
is limiting.

  
I would like
to know if using 16 bits would break in some scenarios. If this was part
of a TLV I wouldn't care as much, but since this is the common header, I
am a bit concerned...acting stingy :-))
    
.

[HK] Exactly, ForCES has much limited/specific scope (NE) than general
  
purpose middleware such as Corba. You cannot compare these 2 because of
the difference in scope.
    

I gave the historical experience of PCs (by quoting a naive bill gates), 
IPV4(by making a mockery over the famous last words that brought IPV6 to 
the world)  and  now i can add the experience of unix which would have 
been more interesting with 64 bit PIDs.
Summary: Nothing would break; however it is useful to learn from history
and say lets go with something larger.

Again, apologies for long email; hopefully this would group
things together.

cheers,
jamal
  



         +-----FE0---------------------------------------------+
         |                                                     |
         |                                                     |
         |                                                     |
         |      /~~~~~\     /~~~~~\         /~~~~~\            |
         |     | FEC0  |   | FEC1  |       |  FECx |           |
         |     |       |   |       | ..... |       |           |
         |      \_____/     \_____/         \_____/            |
         |         |           |               |               |
         |       /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\             |
         |      |                                 |            |
         |      |       Netlink2 Manager          |            |
         |      |                                 |            |
         |       \_______________________________/             |
         |               |             |                       |
         |               |             |                       |
         +--------------/--------------|-----------------------+
                       |               |
                       |               |
              wire0  --+               + --- wire1


Figure 1.


                    /~~~~~\
                   | FEC0  |
                   |       |
                    \_____/
                       |
                       Y
                       | netlink, proprietary, NPF API, etc
                       ^
                       |
                     +-+---------+
        datapath     |           |  processed packet
         ----------> |  LFB10    | ---->
                     |           |
                     +___________+


Figure 2.
--------------000604080004060601050406-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:30:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27590 for ; Mon, 8 Mar 2004 15:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RNq-0000na-9D for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:29:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KTsDD003069 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RNq-0000nQ-33 for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27581 for ; Mon, 8 Mar 2004 15:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RNo-0007Ww-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RMx-0007NS-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:29:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RM1-0007Cj-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RM1-0000c1-F5; Mon, 08 Mar 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RL3-0000Ze-IF for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27467 for ; Mon, 8 Mar 2004 15:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RL2-0006z8-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:27:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RKA-0006mQ-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:26:07 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0RJC-0006ZC-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:25:06 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030812254361:64854 ; Mon, 8 Mar 2004 12:25:43 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: forces-protocol@ietf.org In-Reply-To: <404CD324.5060502@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> <1078751018.1037.386.camel@jzny.localdomain> <404CD324.5060502@alcatel.com> Organization: ZNYX Networks Message-Id: <1078777502.1038.473.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 03/08/2004 12:25:43 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 12:25:45 PM, Serialize complete at 03/08/2004 12:25:45 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 15:25:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-08 at 15:10, Alex Audu wrote: > I believe what Weiming seems to be saying is that we don't have to > expose the LFB > addressing in the common message header, since not all messages will > target LFBs. Thats not what i read it to be. If it is the case then it is precisely what i am saying as well. But please dont respond to this message. Instead please respond to the points raised in detail in my email. By just adding a paragraph at the top and not addressing the other 9 out of 10 items raised in the email, we end up reiterating things which have already been said 3 emails later. This is not for you in particular but just general email/usenet DNA. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:37:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27960 for ; Mon, 8 Mar 2004 15:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RUb-0001Fn-9A for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:36:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Kar7U004813 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RUb-0001FY-0N for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:36:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27922 for ; Mon, 8 Mar 2004 15:36:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RUZ-0000yc-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:36:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RTc-0000oX-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:35:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RSm-0000el-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RSn-000154-8p; Mon, 08 Mar 2004 15:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RRy-00012q-8Q for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:34:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27809 for ; Mon, 8 Mar 2004 15:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RRw-0000Um-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RR0-0000Jf-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:33:11 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0RQB-00004U-00 for Forces-protocol@ietf.org; Mon, 08 Mar 2004 15:32:19 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28KVUTN014037; Mon, 8 Mar 2004 14:31:31 -0600 (CST) Message-ID: <404CD821.8070507@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@acm.org CC: Ligang Dong , Forces-protocol@ietf.org Subject: Re: [Forces-protocol] Future question for the discussion References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <000b01c4050e$6fd83d60$6f01a8c0@dlg> <6CADDF45-7104-11D8-B109-000393CC2112@acm.org> In-Reply-To: <6CADDF45-7104-11D8-B109-000393CC2112@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 14:31:29 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Avri, You can ignore my previous e-mail requesting for more info on your concerns about Master/Slave protocols. I see that you have provided adequate response as seen below. Sure we can debate the merits/de-merits of peer-to-peer vs master/slave. But you have to chose the protocol that models the environment or system you are trying to distribute. Certainly, the CE has control of the entire NE. So it is the master. It also has the final say as to which FE leaves the NE group and when. Say an active FE1 is being removed from service. There is a redundant FE2 that is inservice. A typical scenario will be as follows: 1) FE1 tells its CE that it is about to go out of service. 2) CE gets the message, informs FE2 to go active to replace the outgoing FE1 3) FE2 receives the message, goes active and sends an ACK to CE. 4) CE then sends an ACK to FE1 telling it that it can now go out of service. If we don't do this, FE1 could go out of service and cause a break in service. The fact that FE1 doesn't do anything unless its been told by CE to is the precept of master/slave control. You can't have a slave doing things independently at random. This is just one example,..and we can find many other scenarios to support the fact that peer-to-peer model is not ideal for ForCEs. For example, can an FE cuase a CE to be removed? Who determines who's to join the NE group? etc Regards, Alex. avri@acm.org wrote: > > On 8 mar 2004, at 22.08, Ligang Dong wrote: > >> hi, >> I cited one sentence from the ForCES Framework Protocol, "The ForCES >> protocol is a master-slave protocol in which FEs are slaves and CEs >> are masters." Do you mean that we should change this framework protocol? > > > Well, and I don't know if it time for this yet, but we have 2 models > being presented. As far as I understand it netlink2 is using a peer > to peer model of communications while Fact and GRMP are using a > master-slave model of communications. > > I don't disagree that the FE gets its LFB state etc. from the CE, in > this it has a more restricted scope of responsibility. The issues I > have with master/slave protocols are not which controls the state of > the other, but rather in the protocol messaging and in who can > initiate an exchange of info. > >> >> Besides, can you give more detail about the limitation of the >> master-slave model in GRMP. > > > I was speaking of limitations I had found working with GSMP, another > master-slave protocol, not GRMP. As the information in the so > called slave got more complex with optical switching we had the to > stretch the notion of what a 'slave' was permitted to do and to > communicate or its own initiative. At times it felt awkward. > > But I really just wanted to put this topic on the table for a later > timely discussion. > > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:39:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28262 for ; Mon, 8 Mar 2004 15:39:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RWZ-0001eZ-Sn for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:38:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KctrU006349 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RWZ-0001eK-HN for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28182 for ; Mon, 8 Mar 2004 15:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RWY-0001Ma-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RVX-0001A6-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:37:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RUj-000101-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RUk-0001H4-0l; Mon, 08 Mar 2004 15:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RUg-0001GC-WB for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:36:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27942 for ; Mon, 8 Mar 2004 15:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RUf-0000zU-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:36:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RTi-0000pj-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:35:59 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0RSu-0000W2-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:35:08 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i28KYbTN014689; Mon, 8 Mar 2004 14:34:37 -0600 (CST) Message-ID: <404CD8DC.3000104@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: avri@acm.org, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issues list: Was( Future question for the discussion References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> In-Reply-To: <1078753355.1036.426.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------010909040107030106050901" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Mar 2004 14:34:36 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------010909040107030106050901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamal, We can't ignore the model. It feeds into the the protocol work. Alex. Jamal Hadi Salim wrote: >On Mon, 2004-03-08 at 06:20, avri@acm.org wrote: > > >>Hi, >> >>One of the difference between the protocols is the use of peer-peer >>model versus the master-slave model. Having worked with the >>master-slave model in GSMP, I found it to have limitations and think >>this should also be on the topics for discussion. >> >> >> > >We should definetely add this to the list of discussions. >I am resending the list below: > >0) ID on the header. >1) Encoding >2) Multiple channels/connections >3) Transport: unicast/multicast/broadcast >{ TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} >4) Congestion control >5) Reliability >6) Security >7) High availability >8) Capability exchange >9) The FEM/CEM interface >10) Support for vendor functions >11) Cross check with model draft before it is published >12) Master Slave or peer-peer? > >I personally dont think we should care what the model or >requirements draft says. What we want to have is a good >protocol (as an example there are a few issues not mentioned >in the requirements already on the list above). >For this reason i feel like scratching issue 11 from the list. > >cheers, >jamal > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------010909040107030106050901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal,

We can't ignore the model. It feeds into the the protocol work.

Alex.

Jamal Hadi Salim wrote:
On Mon, 2004-03-08 at 06:20, avri@acm.org wrote:
  
Hi,

One of the difference between the protocols is the use of peer-peer 
model versus the master-slave model.  Having worked with the 
master-slave model in GSMP, I found it to have limitations and think 
this should also be on the topics for discussion.

    

We should definetely add this to the list of discussions.
I am resending the list below:

0) ID on the header.
1) Encoding
2) Multiple channels/connections
3) Transport: unicast/multicast/broadcast 
{ TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 
4) Congestion control
5) Reliability
6) Security
7) High availability
8) Capability exchange
9) The FEM/CEM interface
10) Support for vendor functions
11) Cross check with model draft before it is published
12) Master Slave or peer-peer?

I personally dont think we should care what the model or
requirements draft says. What we want to have is a good
protocol (as an example there are a few issues not mentioned
in the requirements already on the list above).
For this reason i feel like scratching issue 11 from the list.

cheers,
jamal



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------010909040107030106050901-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:48:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29278 for ; Mon, 8 Mar 2004 15:48:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Rf0-0002IZ-S9 for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:47:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Klc18008829 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:47:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Rez-0002IK-Qt for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29180 for ; Mon, 8 Mar 2004 15:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Rey-0003gc-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Rc9-0002rj-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:44:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0RZX-00025x-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RZY-00022b-5m; Mon, 08 Mar 2004 15:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RYq-0001ym-FS for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:41:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28452 for ; Mon, 8 Mar 2004 15:41:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RYp-0001uh-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RX2-0001Rf-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:39:25 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0RVr-0001DD-00 for Forces-protocol@ietf.org; Mon, 08 Mar 2004 15:38:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030812384686:64892 ; Mon, 8 Mar 2004 12:38:46 -0800 Subject: Re: [Forces-protocol] Future question for the discussion From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: avri@acm.org, Ligang Dong , Forces-protocol@ietf.org In-Reply-To: <404CD821.8070507@alcatel.com> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <000b01c4050e$6fd83d60$6f01a8c0@dlg> <6CADDF45-7104-11D8-B109-000393CC2112@acm.org> <404CD821.8070507@alcatel.com> Organization: ZNYX Networks Message-Id: <1078778285.1039.484.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 03/08/2004 12:38:47 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 12:38:51 PM, Serialize complete at 03/08/2004 12:38:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 15:38:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Could we please hold onto getting into this issue? It is listed as issue #12 at the moment. cheers, jamal On Mon, 2004-03-08 at 15:31, Alex Audu wrote: > Hi Avri, > > You can ignore my previous e-mail requesting for more info on your > concerns about > Master/Slave protocols. I see that you have provided adequate response > as seen below. > > Sure we can debate the merits/de-merits of peer-to-peer vs > master/slave. But you have > to chose the protocol that models the environment or system you are > trying to distribute. > Certainly, the CE has control of the entire NE. So it is the master. It > also has the final > say as to which FE leaves the NE group and when. Say an active FE1 is > being removed > from service. There is a redundant FE2 that is inservice. A typical > scenario will be as follows: > > 1) FE1 tells its CE that it is about to go out of service. > 2) CE gets the message, informs FE2 to go active to replace the outgoing FE1 > 3) FE2 receives the message, goes active and sends an ACK to CE. > 4) CE then sends an ACK to FE1 telling it that it can now go out of service. > > If we don't do this, FE1 could go out of service and cause a break in > service. > The fact that FE1 doesn't do anything unless its been told by CE to is > the precept > of master/slave control. You can't have a slave doing things > independently at random. > > This is just one example,..and we can find many other scenarios to support > the fact that peer-to-peer model is not ideal for ForCEs. For example, can > an FE cuase a CE to be removed? Who determines who's to join the NE > group? etc > > Regards, > Alex. > > > avri@acm.org wrote: > > > > > On 8 mar 2004, at 22.08, Ligang Dong wrote: > > > >> hi, > >> I cited one sentence from the ForCES Framework Protocol, "The ForCES > >> protocol is a master-slave protocol in which FEs are slaves and CEs > >> are masters." Do you mean that we should change this framework protocol? > > > > > > Well, and I don't know if it time for this yet, but we have 2 models > > being presented. As far as I understand it netlink2 is using a peer > > to peer model of communications while Fact and GRMP are using a > > master-slave model of communications. > > > > I don't disagree that the FE gets its LFB state etc. from the CE, in > > this it has a more restricted scope of responsibility. The issues I > > have with master/slave protocols are not which controls the state of > > the other, but rather in the protocol messaging and in who can > > initiate an exchange of info. > > > >> > >> Besides, can you give more detail about the limitation of the > >> master-slave model in GRMP. > > > > > > I was speaking of limitations I had found working with GSMP, another > > master-slave protocol, not GRMP. As the information in the so > > called slave got more complex with optical switching we had the to > > stretch the notion of what a 'slave' was permitted to do and to > > communicate or its own initiative. At times it felt awkward. > > > > But I really just wanted to put this topic on the table for a later > > timely discussion. > > > > a. > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 15:57:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01196 for ; Mon, 8 Mar 2004 15:57:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RoQ-0002vS-Is for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 15:57:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28KvMHZ011240 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 15:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RoQ-0002vD-8O for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 15:57:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01013 for ; Mon, 8 Mar 2004 15:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0RoO-0006RV-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RmK-0005qR-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:55:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0RkM-0005Iv-03 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:53:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0RgO-0007U4-OK for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 15:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0RgL-0002K5-AZ; Mon, 08 Mar 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Rg8-0002Jc-3j for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 15:48:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29411 for ; Mon, 8 Mar 2004 15:48:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Rg6-000420-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:48:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0RdS-0003Ft-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:46:03 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Ran-0002Rk-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 15:43:17 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030812435506:64900 ; Mon, 8 Mar 2004 12:43:55 -0800 Subject: Re: [Forces-protocol] Issues list: Was( Future question for the discussion From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: avri@acm.org, forces-protocol@ietf.org In-Reply-To: <404CD8DC.3000104@alcatel.com> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> <404CD8DC.3000104@alcatel.com> Organization: ZNYX Networks Message-Id: <1078778594.1040.490.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 03/08/2004 12:43:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/08/2004 12:43:56 PM, Serialize complete at 03/08/2004 12:43:56 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Mar 2004 15:43:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, As Ellen pointed out: addressing it does not stop us from reaching a consensus on a merger. Do you think we should still keep it? another way to do it is to make it the lowest priority then if we never get to it it wouldnt matter. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 8 19:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13977 for ; Mon, 8 Mar 2004 19:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VMl-0004BV-DF for forces-protocol-archive@odin.ietf.org; Mon, 08 Mar 2004 19:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i290j3vt016080 for forces-protocol-archive@odin.ietf.org; Mon, 8 Mar 2004 19:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VMj-0004An-I5 for forces-protocol-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 19:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13949 for ; Mon, 8 Mar 2004 19:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0VMh-0006rC-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 19:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0VLh-0006hJ-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 19:43:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0VKm-0006WG-00 for forces-protocol-web-archive@ietf.org; Mon, 08 Mar 2004 19:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VKn-00043t-8z; Mon, 08 Mar 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0VJs-00040d-BO for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 19:42:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13918 for ; Mon, 8 Mar 2004 19:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0VJq-0006Pu-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 19:42:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0VIx-0006HL-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 19:41:08 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0VIN-00068E-00 for Forces-protocol@ietf.org; Mon, 08 Mar 2004 19:40:42 -0500 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Tue, 9 Mar 2004 08:51:46 +0800 Message-ID: <002301c4056e$d7426290$6f01a8c0@dlg> From: "Ligang Dong" To: Cc: References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <000b01c4050e$6fd83d60$6f01a8c0@dlg> <6CADDF45-7104-11D8-B109-000393CC2112@acm.org> Subject: Re: [Forces-protocol] Future question for the discussion 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 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 08:38:28 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksDQoNCkZyb20gdGhlIHZpZXcgb2YgdGhlIGFkbWluaXN0cmF0aW9uLCB0aGUgQ0UgaXMgdGhl IG1hc3RlciBhbmQgdGhlIEZFIGlzIHRoZSBzbGF2ZS4gDQpJbiBvdGhlciB3b3JkcywgdGhlIENF IHRha2VzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBhZG1pbmlzdHJhdGluZyB0aGUgRkVzLiANCldp dGhvdXQgdGhlIGFkbWluaXN0cmF0aW9uIChlLmcuLCBhc2tpbmcgdGhlIEZFIHRvIHVwbG9hZCB0 aGUgTEZCKSBvZiB0aGUgQ0UsIHRoZSBGRSB3aXRob3V0IGFueSBMRkJzIGNhbiBkbyBub3RoaW5n LiANCkZ1cnRoZXJtb3JlLCB0aGlzIGtpbmQgb2YgbWFzdGVyLXNsYXZlIGRvZXMgbm90IGV4Y2x1 ZGUgdGhhdCB0aGUgRkUgaW5pdGlhdGVzIGFuIGV4Y2hhbmdlIG9mIGluZm8uICwgDQp3aGljaCBp cyBhbHJlYWR5IHN1cHBvcnRlZCBpbiBHUk1QLg0KT2J2aW91c2x5LCB0aGUgc2NlbmFyaW8gaW4g dGhlIEZvckNFUyBwcm90b2NvbCBpcyBjbG9zZXIgdG8gbWFzdGVyLXNsYXZlIG1vZGVsIHRoYW4g dGhlIHBlZXItdG8tcGVlciBtb2RlbC4NCg0KQmVzaWRlcywgdGlsbCBub3csIHRoZSBsaW1pdGF0 aW9uLCB3aGljaCB5b3UgZGVzY3JpYmVkIGFib3V0IEdTTVAsIG9mIHRoZSBtYXN0ZXItc2xhdmUg bW9kZWwgaGFzIG5vdCBoYXBwZW5lZCBpbiB0aGUgRm9yQ0VTIHByb3RvY29sLiANCg0KZG9uZw0K DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGF2cmlAYWNtLm9yZz4NClRv OiAiTGlnYW5nIERvbmciIDxkb25nbGdAbWFpbC5oemljLmVkdS5jbj4NCkNjOiA8Rm9yY2VzLXBy b3RvY29sQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBNYXJjaCAwOCwgMjAwNCA5OjI4IFBNDQpT dWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gRnV0dXJlIHF1ZXN0aW9uIGZvciB0aGUgZGlz Y3Vzc2lvbg0KDQoNCj4gDQo+IE9uIDggbWFyIDIwMDQsIGF0IDIyLjA4LCBMaWdhbmcgRG9uZyB3 cm90ZToNCj4gDQo+ID4gaGksDQo+ID4gSSBjaXRlZCBvbmUgc2VudGVuY2UgZnJvbSB0aGUgRm9y Q0VTIEZyYW1ld29yayBQcm90b2NvbCwgICJUaGUgRm9yQ0VTIA0KPiA+IHByb3RvY29sIGlzIGEg bWFzdGVyLXNsYXZlIHByb3RvY29sIGluIHdoaWNoIEZFcyBhcmUgc2xhdmVzIGFuZCBDRXMgDQo+ ID4gYXJlIG1hc3RlcnMuIiBEbyB5b3UgbWVhbiB0aGF0IHdlIHNob3VsZCBjaGFuZ2UgdGhpcyBm cmFtZXdvcmsgDQo+ID4gcHJvdG9jb2w/DQo+IA0KPiBXZWxsLCBhbmQgSSBkb24ndCBrbm93IGlm IGl0IHRpbWUgZm9yIHRoaXMgeWV0LCBidXQgd2UgaGF2ZSAyIG1vZGVscyANCj4gYmVpbmcgcHJl c2VudGVkLiAgQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBpdCBuZXRsaW5rMiBpcyB1c2luZyBhIHBl ZXIgdG8gDQo+IHBlZXIgbW9kZWwgb2YgY29tbXVuaWNhdGlvbnMgd2hpbGUgRmFjdCBhbmQgR1JN UCBhcmUgdXNpbmcgYSANCj4gbWFzdGVyLXNsYXZlIG1vZGVsIG9mIGNvbW11bmljYXRpb25zLg0K PiANCj4gSSBkb24ndCBkaXNhZ3JlZSB0aGF0IHRoZSBGRSBnZXRzIGl0cyBMRkIgc3RhdGUgZXRj LiBmcm9tIHRoZSBDRSwgaW4gDQo+IHRoaXMgaXQgaGFzIGEgbW9yZSByZXN0cmljdGVkIHNjb3Bl IG9mIHJlc3BvbnNpYmlsaXR5LiAgVGhlIGlzc3VlcyBJIA0KPiBoYXZlIHdpdGggbWFzdGVyL3Ns YXZlIHByb3RvY29scyBhcmUgbm90IHdoaWNoIGNvbnRyb2xzIHRoZSBzdGF0ZSBvZiANCj4gdGhl IG90aGVyLCBidXQgcmF0aGVyIGluIHRoZSBwcm90b2NvbCBtZXNzYWdpbmcgYW5kIGluIHdobyBj YW4gaW5pdGlhdGUgDQo+IGFuIGV4Y2hhbmdlIG9mIGluZm8uDQo+IA0KPiA+DQo+ID4gQmVzaWRl cywgY2FuIHlvdSBnaXZlIG1vcmUgZGV0YWlsIGFib3V0IHRoZSBsaW1pdGF0aW9uIG9mIHRoZSAN Cj4gPiBtYXN0ZXItc2xhdmUgbW9kZWwgaW4gR1JNUC4NCj4gDQo+IEkgd2FzIHNwZWFraW5nIG9m IGxpbWl0YXRpb25zIEkgaGFkIGZvdW5kIHdvcmtpbmcgd2l0aCBHU01QLCBhbm90aGVyIA0KPiBt YXN0ZXItc2xhdmUgcHJvdG9jb2wsICBub3QgR1JNUC4gICBBcyB0aGUgaW5mb3JtYXRpb24gaW4g dGhlIHNvIGNhbGxlZCANCj4gc2xhdmUgZ290IG1vcmUgY29tcGxleCB3aXRoIG9wdGljYWwgc3dp dGNoaW5nIHdlIGhhZCB0aGUgdG8gc3RyZXRjaCB0aGUgDQo+IG5vdGlvbiBvZiB3aGF0IGEgJ3Ns YXZlJyB3YXMgcGVybWl0dGVkIHRvIGRvIGFuZCB0byBjb21tdW5pY2F0ZSBvciBpdHMgDQo+IG93 biBpbml0aWF0aXZlLiAgQXQgdGltZXMgaXQgZmVsdCBhd2t3YXJkLg0KPiANCj4gQnV0IEkgcmVh bGx5IGp1c3Qgd2FudGVkIHRvIHB1dCB0aGlzIHRvcGljIG9uIHRoZSB0YWJsZSBmb3IgYSBsYXRl ciANCj4gdGltZWx5IGRpc2N1c3Npb24uDQo+IA0KPiBhLg0KPiANCj4g _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 00:45:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23668 for ; Tue, 9 Mar 2004 00:45:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a3G-0005f8-AE for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 00:45:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295jEF9021765 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 00:45:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a3G-0005ey-1Y for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 00:45:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23454 for ; Tue, 9 Mar 2004 00:45:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0a3D-00070d-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0a08-00065x-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:42:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Zxp-0005co-03 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:39:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0ZqU-0001DS-PV for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ZqT-0004aA-Sq; Tue, 09 Mar 2004 00:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Zpg-0004Tx-2O for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 00:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22894 for ; Tue, 9 Mar 2004 00:31:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Zpd-0004VC-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:31:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Zoj-0004Mm-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:30:13 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0ZoI-0004EO-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:29:46 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Tue, 9 Mar 2004 13:40:55 +0800 Message-ID: <0a9901c40597$37de90b0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD8027C65C3@orsmsx409.jf.intel.com> <039801c40273$9ec71bc0$845c21d2@Necom.hzic.edu.cn> <4048A7EB.2030808@alcatel.com> <1078530100.4049103fdc6dc@mail.hzic.edu.cn> <404C94DC.1080203@alcatel.com> Subject: Re: [Forces-protocol] Comments from chat with ADs MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A96_01C405DA.45E791F0" 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 13:27:30 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0A96_01C405DA.45E791F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KVGhlIGV4cGVyaW1lbnQgSUkgcmVzdWx0IGFjdHVhbGx5IG9ubHkgc2hvd3Mg dGhhdCB0aGUgQyBhbmQgRCBjaGFubmVsIHdpbGwgaW50ZXJmZXJlIHdpdGggDQplYWNoIG90aGVy IHdoZW4gdGhlIHBoeXNpY2FsIGxpbmsgdGhleSBhcmUgb24gaXMgb3ZlcmxvYWRlZCAoNTAlKzgw JT4xMDAlKS4NCkkgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlLiBZb3UgbWF5IG5ldmVyIGV4cGVj dCB0aGUgdHdvIGNoYW5uZWxzIGNvdWxkIHN0aWxsIHdvcmsgYXMgeW91IGV4cGVjdGVkIA0Kd2hl biB0aGUgcGh5Y2lzYWwgbGluayBoYXMgYmVlbiBvdmVybG9hZGVkLiANCg0KWW91cnMsDQpXZWlt aW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBBbGV4IEF1ZHUgDQog IFRvOiB3bXdhbmdAbWFpbC5oemljLmVkdS5jbiANCiAgQ2M6IGZvcmNlcy1wcm90b2NvbEBpZXRm Lm9yZyANCiAgU2VudDogTW9uZGF5LCBNYXJjaCAwOCwgMjAwNCAxMTo0NCBQTQ0KICBTdWJqZWN0 OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gQ29tbWVudHMgZnJvbSBjaGF0IHdpdGggQURzDQoNCg0K ICBIZWxsbyBXZWltaW5nLA0KDQogIEkgd2FzIHJlZmVyaW5nIHRvIHRoZSBDL0QgZGlmZmVyZW50 IHF1ZXVlaW5nIGV4cGVyaW1lbnQgKEkgdGhpbmsgaXQgaXMgRXhwZWlyaW1lbnQgSUkpLg0KICBU aGUgYm90dG9tIGxpbmUgaXMgeW91IHNob3VsZCBiZSBhYmxlIHRvIGRlY291cGxlIGV2ZW50cyBv biBDIHF1ZXVlIGFuZCBEIHF1ZXVlIGZyb20NCiAgaW50ZXJmZXJpbmcgd2l0aCBlYWNoIG90aGVy LiAgIFlvdSBjYW4gIHNldCB1cCBzaW11bGF0aW9uIHJ1bnMgb24gT1BORVQgb3Igc2ltaWxhcg0K ICBlbnZpcm9ubWVudHMgdG8gY2hlY2sgdGhpcyBvdXQuIA0KDQogIFJlZ2FyZHMsDQogIEFsZXgu DQogICANCg== ------=_NextPart_000_0A96_01C405DA.45E791F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SGkgQWxleCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+VGhlIGV4cGVyaW1lbnQgSUkgcmVzdWx0IGFjdHVhbGx5IG9ubHkgc2hvd3MgDQp0 aGF0Jm5ic3A7dGhlIEMgYW5kIEQgY2hhbm5lbCZuYnNwO3dpbGwgaW50ZXJmZXJlIHdpdGggPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5lYWNoIG90aGVyIHdoZW4g dGhlIHBoeXNpY2FsIGxpbmsmbmJzcDt0aGV5IA0KPC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPmFyZSBvbiZuYnNwO2lzIG92ZXJsb2FkZWQgDQooNTAlKzgwJSZndDsxMDAlKS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgdGhpbmsgdGhpcyBpcyByZWFz b25hYmxlLiBZb3UgbWF5IG5ldmVyIGV4cGVjdCANCnRoZSB0d28gY2hhbm5lbHMmbmJzcDtjb3Vs ZCBzdGlsbCB3b3JrIGFzIHlvdSBleHBlY3RlZCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPndoZW4gdGhlIHBoeWNpc2FsIGxpbmsgaGFzIGJlZW4gDQpvdmVybG9h ZGVkLjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Zb3Vycyw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9E SVY+DQo8RElWPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQo8QkxPQ0tRVU9U RSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7 IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lO LVJJR0hUOiAwcHgiPg0KICA8RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9O VDogMTBwdCBhcmlhbDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0 bGU9YWxleC5hdWR1QGFsY2F0ZWwuY29tIGhyZWY9Im1haWx0bzphbGV4LmF1ZHVAYWxjYXRlbC5j b20iPkFsZXggDQogIEF1ZHU8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFy aWFsIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIA0KICBocmVm PSJtYWlsdG86d213YW5nQG1haWwuaHppYy5lZHUuY24iPndtd2FuZ0BtYWlsLmh6aWMuZWR1LmNu PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+Q2M6PC9CPiA8 QSB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMt cHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlNlbnQ6PC9CPiBNb25kYXksIE1hcmNo IDA4LCAyMDA0IDExOjQ0IA0KICBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFy aWFsIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtGb3JjZXMtcHJvdG9jb2xdIENvbW1lbnRzIA0KICBm cm9tIGNoYXQgd2l0aCBBRHM8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+SGVsbG8gV2VpbWluZyw8 QlI+PEJSPkkgd2FzIHJlZmVyaW5nIHRvIHRoZSBDL0QgZGlmZmVyZW50IA0KICBxdWV1ZWluZyBl eHBlcmltZW50IChJIHRoaW5rIGl0IGlzIEV4cGVpcmltZW50IElJKS48QlI+VGhlIGJvdHRvbSBs aW5lIGlzIHlvdSANCiAgc2hvdWxkIGJlIGFibGUgdG8gZGVjb3VwbGUgZXZlbnRzIG9uIEMgcXVl dWUgYW5kIEQgcXVldWUgZnJvbTxCUj5pbnRlcmZlcmluZyANCiAgd2l0aCBlYWNoIG90aGVyLiZu YnNwOyZuYnNwOyBZb3UgY2FuJm5ic3A7IHNldCB1cCBzaW11bGF0aW9uIHJ1bnMgb24gT1BORVQg b3IgDQogIHNpbWlsYXI8QlI+ZW52aXJvbm1lbnRzIHRvIGNoZWNrIHRoaXMgb3V0LiA8QlI+PEJS PlJlZ2FyZHMsPEJSPkFsZXguPEJSPjxGT05UIA0KICBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDs8 L0ZPTlQ+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0A96_01C405DA.45E791F0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 00:50:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24472 for ; Tue, 9 Mar 2004 00:50:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a7v-0006N8-J7 for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 00:50:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295o3XS024483 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 00:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a7u-0006MO-9n for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 00:50:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24348 for ; Tue, 9 Mar 2004 00:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0a7r-0000fR-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:49:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0a63-00007c-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:48:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0a4F-0007Os-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:46:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0a4H-0001oM-Je for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a4G-00060V-QM; Tue, 09 Mar 2004 00:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a3e-0005ki-8T for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 00:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23610 for ; Tue, 9 Mar 2004 00:45:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0a3b-0007Cm-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0a0w-0006Hs-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:42:51 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Zxy-0005cu-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:39: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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i295h0st021259 for ; Tue, 9 Mar 2004 05:43:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i295XP2U015347 for ; Tue, 9 Mar 2004 05:33:30 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030821391108819 for ; Mon, 08 Mar 2004 21:39:11 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 21:39: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 Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E160776@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQD8ho0/Xelh9jEQf2vTOh8dSRJWAA6HSFgAB755wAAEC29kA== From: "Khosravi, Hormuzd M" To: "Putzolu, David" Cc: X-OriginalArrivalTime: 09 Mar 2004 05:39:11.0477 (UTC) FILETIME=[D975F250:01C40598] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 21:39:11 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alright, thanks for this correction. However, we do have a use for priority bits at the ForCES layer, its present in all the proposed protocols in some form and is part of the ForCES Requirements RFC section 6 #5. We initially had this as a 1 bit field however we received feedback from several WG members to increase the no. of bits to allow prioritization of different traffic on the data channel. Hormuzd -----Original Message----- From: Putzolu, David=20 Sent: Monday, March 08, 2004 2:07 PM To: Khosravi, Hormuzd M; 'hadi@znyx.com' Cc: 'forces-protocol@ietf.org' Subject: RE: [Forces-protocol] issue 1: packet encoding [hat off] Hormuzd wrote > > > Jamal wrote > > Hormuzd wrote > > > > Flags/Priority: We need 2-3 bits for priority in every message. I > > > don't think we need any other flags in all messages. >=20 > > Also in regards to priority; do you see this being used all the time? >=20 > [HK] Sure, this is definitely needed in all messages. I believe even > GRMP has this, infact I had a feeling till today that even netlink had > it. >=20 > > and would an underlying transport priority be insufficient > > (example diffserv, 802.1p etc)? >=20 > [HK] This is priority at the ForCES level which will eventually be > mapped to the underlying transport/interconnect. We definitely need it > at the ForCES level as well. I don't understand the priority bits. Priority bits in a header are not used to signal lower layers, they are used to signal at the layer the header is processed. Thus a router might look at the DS byte, but it ignores the=20 TCP URG flag. An Ethernet switch looks at 802.1p prio bits, but ignores the DS byte. Etc. Doing otherwise is a serious=20 layering violation. =20 The way you signal the networking stack in an application is via software APIs, not bits in a header - in Windows that is the WSAIoctl(SIO_SET_QOS) API. In Linux I think netlink APIs are used (not sure, Jamal probably knows). The kernel never looks at the data you pass over via write(), which is where the ForCES header would be delivered to (TCP|UDP|whatever). Unless you expect the ForCES daemon/agent on the other end of the connection to behave differently in the presence of these priority bits (how?) they have no use. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 01:03:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25189 for ; Tue, 9 Mar 2004 01:03:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aK0-0007TA-Av for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 01:02:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2962WlP028706 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 01:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aK0-0007Sv-0W for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 01:02:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25178 for ; Tue, 9 Mar 2004 01:02:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aJx-0003ET-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:02:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0aIz-000346-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:01:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0aIV-0002tb-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aIX-0007PA-Uv; Tue, 09 Mar 2004 01:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0aHp-0007NO-PG for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 01:00:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25098 for ; Tue, 9 Mar 2004 01:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aHm-0002rT-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 01:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0aGr-0002hq-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 00:59:18 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0aGB-0002NG-00 for Forces-protocol@ietf.org; Tue, 09 Mar 2004 00:58:35 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i295wqst029011; Tue, 9 Mar 2004 05:58:52 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i295nC2c022677; Tue, 9 Mar 2004 05:49:19 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030821550510617 ; Mon, 08 Mar 2004 21:55:05 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 21:55:05 -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 Subject: RE: [Forces-protocol] Future question for the discussion Message-ID: <468F3FDA28AA87429AD807992E22D07E160778@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Future question for the discussion Thread-Index: AcQFTdBmi5cuiNCSTLaSXRfHFvvHRQATQ05A From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 09 Mar 2004 05:55:05.0202 (UTC) FILETIME=[11ECD520:01C4059B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 21:55:05 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yes, I agree. Its getting difficult to follow 3 different discussions at the same time. If we continue in this random fashion, it will be difficult to make progress. Regards=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Monday, March 08, 2004 12:38 PM To: alex.audu@alcatel.com Cc: avri@acm.org; Ligang Dong; Forces-protocol@ietf.org Subject: Re: [Forces-protocol] Future question for the discussion Folks, Could we please hold onto getting into this issue? It is listed as issue #12 at the moment. cheers, jamal On Mon, 2004-03-08 at 15:31, Alex Audu wrote: > Hi Avri, >=20 > You can ignore my previous e-mail requesting for more info on your=20 > concerns about > Master/Slave protocols. I see that you have provided adequate response > as seen below. >=20 > Sure we can debate the merits/de-merits of peer-to-peer vs=20 > master/slave. But you have > to chose the protocol that models the environment or system you are=20 > trying to distribute. > Certainly, the CE has control of the entire NE. So it is the master. It=20 > also has the final > say as to which FE leaves the NE group and when. Say an active FE1 is=20 > being removed > from service. There is a redundant FE2 that is inservice. A typical=20 > scenario will be as follows: >=20 > 1) FE1 tells its CE that it is about to go out of service. > 2) CE gets the message, informs FE2 to go active to replace the outgoing FE1 > 3) FE2 receives the message, goes active and sends an ACK to CE. > 4) CE then sends an ACK to FE1 telling it that it can now go out of service. >=20 > If we don't do this, FE1 could go out of service and cause a break in > service. > The fact that FE1 doesn't do anything unless its been told by CE to is > the precept > of master/slave control. You can't have a slave doing things=20 > independently at random. >=20 > This is just one example,..and we can find many other scenarios to support > the fact that peer-to-peer model is not ideal for ForCEs. For example, can > an FE cuase a CE to be removed? Who determines who's to join the NE=20 > group? etc >=20 > Regards, > Alex. >=20 >=20 > avri@acm.org wrote: >=20 > > > > On 8 mar 2004, at 22.08, Ligang Dong wrote: > > > >> hi, > >> I cited one sentence from the ForCES Framework Protocol, "The ForCES=20 > >> protocol is a master-slave protocol in which FEs are slaves and CEs > >> are masters." Do you mean that we should change this framework protocol? > > > > > > Well, and I don't know if it time for this yet, but we have 2 models > > being presented. As far as I understand it netlink2 is using a peer > > to peer model of communications while Fact and GRMP are using a=20 > > master-slave model of communications. > > > > I don't disagree that the FE gets its LFB state etc. from the CE, in > > this it has a more restricted scope of responsibility. The issues I > > have with master/slave protocols are not which controls the state of > > the other, but rather in the protocol messaging and in who can=20 > > initiate an exchange of info. > > > >> > >> Besides, can you give more detail about the limitation of the=20 > >> master-slave model in GRMP. > > > > > > I was speaking of limitations I had found working with GSMP, another > > master-slave protocol, not GRMP. As the information in the so=20 > > called slave got more complex with optical switching we had the to=20 > > stretch the notion of what a 'slave' was permitted to do and to=20 > > communicate or its own initiative. At times it felt awkward. > > > > But I really just wanted to put this topic on the table for a later=20 > > timely discussion. > > > > a. > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 01:47:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27306 for ; Tue, 9 Mar 2004 01:47:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0b1S-00035x-29 for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 01:47:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i296lQ19011891 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 01:47:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0b1R-00035i-Ts for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 01:47:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27283 for ; Tue, 9 Mar 2004 01:47:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0b1O-0002qh-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:47:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0b0V-0002hE-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:46:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0b02-0002X4-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 01:45:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0b05-00033v-Gl; Tue, 09 Mar 2004 01:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0azL-000328-Rc for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 01:45:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27047 for ; Tue, 9 Mar 2004 01:45:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0azI-0002UH-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 01:45:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ayK-0002JM-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 01:44:12 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0axJ-0001zw-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 01:43:09 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i296kJst019163; Tue, 9 Mar 2004 06:46:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i296iBZx005989; Tue, 9 Mar 2004 06:44:24 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030822423415680 ; Mon, 08 Mar 2004 22:42:34 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Mar 2004 22:42: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 Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQFlr9tvDRIlJRBSBqH+SxPhIWFEwACjqtA From: "Putzolu, David" To: , X-OriginalArrivalTime: 09 Mar 2004 06:42:34.0592 (UTC) FILETIME=[B44B3E00:01C405A1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 8 Mar 2004 22:42:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avri wrote > > I have a general question about headers, is there any feeling in this=20 > group that a common header could not be arrived at. If not then we=20 > could move on to other issues. The reason I ask is that one=20 > can spend=20 > a whole lot of time fine tuning a header to be just right. If there=20 > are as of yet unresolved issues on the header, can anyone list them? I agree with Avri, and like others I am having a hard time=20 keeping up with all the different discussions. So if=20 people are comfortable with it, I suggest using a notation=20 similar to what Weiming mentioned in issue 100, perhaps=20 marking this one as, "Agreed to general outline of common=20 header, details to be resolved later" and moving on to another issue. Perhaps preserve the last header(s) that=20 Jamal and Hormuzd sent as the basis for the later detailed discussions. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 06:59:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22731 for ; Tue, 9 Mar 2004 06:59:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0fsk-0005Mu-Sn for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 06:58:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Bwk74020637 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 06:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0fsk-0005Mm-C2 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 06:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22638 for ; Tue, 9 Mar 2004 06:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0fsg-0001yg-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 06:58:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0frb-0001kZ-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 06:57:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0fr2-0001ZH-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 06:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0fr5-0004yd-K6; Tue, 09 Mar 2004 06:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0f97-0002c3-5f for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 06:11:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20699 for ; Tue, 9 Mar 2004 06:11:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0f93-0001Kh-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 06:11:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0f8A-0001BJ-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 06:10:39 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0f7i-00010q-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 06:10:10 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030903104538:65606 ; Tue, 9 Mar 2004 03:10:45 -0800 Subject: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: avri@acm.org, forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078830604.1036.546.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 03/09/2004 03:10:46 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 03:10:50 AM, Serialize complete at 03/09/2004 03:10:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 06:10:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > Avri wrote > > > I have a general question about headers, is there any feeling in this > > group that a common header could not be arrived at. If not then we > > could move on to other issues. The reason I ask is that one > > can spend > > a whole lot of time fine tuning a header to be just right. If there > > are as of yet unresolved issues on the header, can anyone list them? > > I agree with Avri, On the one hand i wanna say lets skip so we can make progress. OTOH, I am a little worried that the gaps in point of view are so huge that this will cause problems later. The only way we can close faster is if ontopic emails are addressed in the fastest possible way. On a personal level i am trying to prioritize responding to things on this list. But sometime i get a little discouraged. Example my last emails on topic 0 and topic 1 have not been responded to for at least 24 hours. Actually they have been a response which happens to be off topic. This worries me because i dont think we will make the deadline. If theres 10-12 serious issues and we have about 10 days to go AND we havent closed a single issue up to now --> theres _no way_ we can meet the deadline. We need to close 2 issues a day. Of course a brute force solution is to say theres desire to reach a compromise and stop there. But this in itself is dangerous and i would not prefer to go that route. So at the moment i am at a loss. Maybe the approach of listing issues which need to be agreed on is not the right one? What thoughts do people have on this? Other proposals that have been made so far that received no traction are: a) each protocol draft to list what they cant live without, b) Each protocol draft to list their implementation experiences and say what they found useful and what wasnt. > and like others I am having a hard time > keeping up with all the different discussions. Yes, this has been an issue but is general to any email or usent discussuions - problem is someone starts going off topic then other people respond. And the cycle continues. The best way to run "meetings" over email are: Rule 0: have an agenda (list of topics to discuss). We have this Rule 1 is to have a running topic (eg currently issue 1 and 0 are ontopic). No other topic is to be discussed. We are trying this. Rule 2 is not to respond to currently-offtopic emails. This is typically the easiest rule to break on email or usenet because of human nature. Naturally this has been the most broken rule. Rule 3 is once in a while people need to be reminded they are off topic. (I have tried to do this in personal emails as well as on the list.) Rule 4 is if the content does not reflect the subject line, change the subject line (like i just did with this email). I could almost say we are getting close to following the above; I counted and only 2 emails were offtopic out of last 6 as opposed to 6 out 10 before that. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:48:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03271 for ; Tue, 9 Mar 2004 10:48:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSJ-0001Dl-4r for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:47:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FlgRm004677 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSH-00014Y-8U for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03042 for ; Tue, 9 Mar 2004 10:47:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jSE-0004FR-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jO0-00030Z-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:43:17 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jML-0002UY-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jI1-0004Aa-5X for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHz-0004ML-1M; Tue, 09 Mar 2004 10:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0hwG-0004gv-Gz for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28048 for ; Tue, 9 Mar 2004 09:10:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0hwE-0002L7-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:10:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0hvF-0002BT-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:09:30 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0huG-0001uB-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:08:28 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030906090380:65696 ; Tue, 9 Mar 2004 06:09:03 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <0bae01c405db$14f713d0$845c21d2@Necom.hzic.edu.cn> References: <0bae01c405db$14f713d0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078841304.1035.572.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 03/09/2004 06:09:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 06:09:06 AM, Serialize complete at 03/09/2004 06:09:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 09:08:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-09 at 08:33, Wang,Weiming wrote: > Jamal, > > Actually I have understood what your Src. ID and Dest. ID is refered to > even before you put this email. In one word, your IDs (actually are > PIDs) are in fact mapped to PIDs of FECxs. This is correct. How that is done is implementation detail. > When I carefully read your > approach, it just seems to me that there may be some limitation to use > such an addressing scheme. Let's say there are two LFBs LFB1 and LFB2, > which in your scheme are belong to two different threads FEC1 and FEC2. A FEC can service zero or more LFBs as i mentioned in the last email. Look at xEC as something that will control an "atomic service". An atomic service could be an OSPF implementation at the CE and an hello offloader at the FE. In such a scenario, there are zero LFBs being controlled by the FEC. [Note i am refering to an LFB in this sense as an entity that is on the datapath] The example for multiple LFBs that i gave is the "IPV4 forwarder"- for this specific FEC you can have it control multiple LFBs ranging from Qos schedulers to nexthop entities, etc. So to just correct what you are refering to above: there is not a FEC for every LFB. > Now we need to address the two LFBs in one ForCES message, then I'm not > sure how this will be implemented in the PID based scheme? Will the two > LFBs be defined as a group then can be addressed at the same time or any > others? Refer to my note above, the FEC controls an atomic service. Given my example above, are you refering to sending one message to both the hello-offloader and IPV4 forwarder? When would this be useful? > Actually, GRMP (I suppose FACT also) can deal with this such > case very easily. It's true that GRMP uses quite the same addressing > method as FACT. The FE ID should be put in the message header, so that > the ID is only used to tell which FEs the message will go, while leaving > further addressing tasks to be implemented by the FEs themselves. Are > there any limitations for such an addressing way? This does not leave out further addressing of the LFBs embedded within the TLVs for a specifc LFB. I believe we are in agreement there. I may have assumed this so didnt communicate properly. Example a port LFB could further be mapped to an ifindex; a meter could further be mapped to an index, etc. Infact, the scheme i described has absolutely nothing to do with netlink2. Rather it is an implementation experience i was sharing. It does make a lot of sense if you think of Forces as distributed Inter process communication (which it is). Note that the scheme was initially suggested by Joel Halpern in the mailing list; i just came to the same conclusion the hard way - via experience. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:48:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03285 for ; Tue, 9 Mar 2004 10:48:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSK-0001ET-5v for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:47:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FliMF004728 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSK-0001E7-1Q for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03059 for ; Tue, 9 Mar 2004 10:47:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jSH-0004GZ-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jO4-00031F-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:43:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jML-0002Ul-02 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jHw-00049k-RI for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHk-00048u-Sn; Tue, 09 Mar 2004 10:36:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0hQJ-0002qg-Re for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 08:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26797 for ; Tue, 9 Mar 2004 08:37:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0hQI-0004XS-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:37:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0hPI-0004LS-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:36:29 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0hOD-00040j-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:35:22 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Tue, 9 Mar 2004 21:46:43 +0800 Message-ID: <0bae01c405db$14f713d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Jamal Hadi Salim" , Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 21:33:17 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, Actually I have understood what your Src. ID and Dest. ID is refered to even before you put this email. In one word, your IDs (actually are PIDs) are in fact mapped to PIDs of FECxs. When I carefully read your approach, it just seems to me that there may be some limitation to use such an addressing scheme. Let's say there are two LFBs LFB1 and LFB2, which in your scheme are belong to two different threads FEC1 and FEC2. Now we need to address the two LFBs in one ForCES message, then I'm not sure how this will be implemented in the PID based scheme? Will the two LFBs be defined as a group then can be addressed at the same time or any others? Actually, GRMP (I suppose FACT also) can deal with this such case very easily. It's true that GRMP uses quite the same addressing method as FACT. The FE ID should be put in the message header, so that the ID is only used to tell which FEs the message will go, while leaving further addressing tasks to be implemented by the FEs themselves. Are there any limitations for such an addressing way? Best regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Monday, March 08, 2004 9:03 PM Subject: Re: [Forces-protocol] Issue 0: Application addressing > Hormuzd, Weiming, > > Apologies for long email; i am attempting to respond to two emails in > one. > > Ok, let me provide an example of an FE (same concept applies at > the CE). > Heres a diagram that may help to clarify what i have been refering > to; note that netlink2 did not start like this, however over > time implementation ended being like this; this shows an FE > side implementation. I have attached the two diagrams so they > dont get mangled. > > Figure 1. shows the netlink2 manager ( a s/ware daemon) managing > two socket connections on the lower side labelled as wire0 and wire1 > and entities called FECs on the upper side. > Figure2 shows the role of the FEC; it MAY manages one or more LFBs. > The communication mechanism used there is again beyond the scope of > ForCES. > Messages arriving at either of the sockets could end up in two sorts of > general classes of destinations: > 1) for the FE - in which they are serviced by the netlink2 daemon. > 2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes > them to those entities. > > Although i only list two classes, there could be more - but thats beside > the point. > FECs are OS processes/applications. (How they communicate to the > netlink2 daemon is beyond the scope of ForCES; lets say it could be a > local OS IPC.) > > As an example, there may be a FEC which controls several LFBs; > Another example is an FEC which sends and receives OSPF hellos. > Each FEC has a counterpart which understands it on the CE side. > The CE piece of OSPF (call it CEC) sends messages to > a specific PID when it wants to talk to the FEC portion (the hello > offloader). > As you can see this is application talking to another application; > this could be looked at as essentially IPC. Therefore the concept of PID > is useful. > > Now to address your emails: > > On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: > > Weiming, could you make sure your emails wrap around at 80 characters? > It helps when i am trying to respond. > > > > We think a layer-based tree structure according to the ForCES architecture > > is efficient to do such addressing. If we address entities at > > the FE coarse layer ( to take the FE as a whole entity, which idea is also > > used by new version of FE model ), we only need to > > have a FE ID. > > If i am not mistaken what you are talking about is a detail > on how the address gets split; i.e you want to have a hierachical > addressing - as an example you want to split the address above to > FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). > If this is the case, i think it is a small detail and we could move > on and talk baout it later; if not please look at the diagram and > tell me how you would split the ID to configure LFB0. I actually have > a feeling your approach to this would be VERY different from Hormuzd;-> > > > To address > > CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, LFB > > Instance broadcast, and CE broadcast, following addressing can be > > implemented: > > I think we all agree on the broadcast or multicast to a specific > type of entities. > > >>- a set of LFBs on an FE > > - a set of LFBs on different FEs > > > > > > [Wang Re: Are the set of LFBs of the same type?] > > Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > > > - proxies for LFBs, > > - proxies for control application in the form on the CEs, > > > > [Wang Re: If ever we have these proxies, are they need to be seen at the > > protocol layer? > > No, there is nothing speacial needed at the protocol header. The list > was an exhaustive example. > > > Moreover, how about FE proxies then?] > > They dont need to be addressed by anything speacial in the header. > > On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: > > > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go > > with that terminology then? > > Lets talk about what needs to be addressed first before we jump to that. > Refer to the two diagrams i sent. > > > [HK] I don't see the value of having an App ID in the common header. How > > is it useful ? May be if you could give a good example of how this can > > be used, it would help. The ForCES endpoints are CEs and FEs which > > should be addressed in the common header. LFBs are like knobs on the FEs > > used to program its functionality. I am sure you know all this very well > > and I think most folks will agree on this. If we go with a different > > view, we will probably land up breaking the FE Model as well. Other > > views on this one ? > > Refer to the two diagrams i sent for an example, then lets discuss. > > [HK] Could you give me an example of why this is limiting? > > I was refering to the fact that you have a single ID to address > entities within an FE or CE. In my diagram i am rtying to show theres > more than one class of end targets. So calling it CEID or FEID > is limiting. > > > I would like > > to know if using 16 bits would break in some scenarios. If this was part > > of a TLV I wouldn't care as much, but since this is the common header, I > > am a bit concerned...acting stingy :-)) > .. > > [HK] Exactly, ForCES has much limited/specific scope (NE) than general > > purpose middleware such as Corba. You cannot compare these 2 because of > > the difference in scope. > > I gave the historical experience of PCs (by quoting a naive bill gates), > IPV4(by making a mockery over the famous last words that brought IPV6 to > the world) and now i can add the experience of unix which would have > been more interesting with 64 bit PIDs. > Summary: Nothing would break; however it is useful to learn from history > and say lets go with something larger. > > Again, apologies for long email; hopefully this would group > things together. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:49:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03619 for ; Tue, 9 Mar 2004 10:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jTT-0001cM-Nz for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:48:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FmtQ9006212 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:48:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jTT-0001c7-Ig for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03456 for ; Tue, 9 Mar 2004 10:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jTR-0004do-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jP8-0003Lm-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:44:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMa-0002UY-02 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jHP-00046c-CZ for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:36:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHO-0003ro-Am; Tue, 09 Mar 2004 10:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0hB0-0002J3-9B for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 08:21:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25852 for ; Tue, 9 Mar 2004 08:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0hAz-0001N6-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:21:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0hA9-0001D9-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:20:49 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0h9M-00011L-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:20:01 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Tue, 9 Mar 2004 21:30:53 +0800 Message-ID: <0b5901c405d8$de4fc0e0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> <1078775008.1037.455.camel@jzny.localdomain> Subject: Re: [Forces-protocol] issue 1: packet encoding 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 21:17:27 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, Could you just add some tag to indicate your reply? Or else, I have to help to add it so that others can see your reply. Some comments as below. Thank you. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Wang,Weiming" > Weimimg, > > On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote: > [..] > > > 1. The "command" field > > This is really a field that confuses me. The confusion is: > > 1) If it is a field only with command "Add/Del/Get", I suppose we can just > > obsolete it. The command can be surely be expressed in the followed body > > by using TLVs. >[Jamal Re: > Every message will have a command. For that reason it belongs to the > main header.] [Wang Re: I would say it is also possible to have a message contain more than one command. But I don't want push this too hard so that we may be quicker to reach an agreement.] > > > 2) If we keep it, I'm afraid its meaning should be far from these. For > > example, how an event report can be represented, and how a command bundle > > is represented then, and many others? >[Jamal Re: > I will explain how we implemented events; note, this is different from > the current command structure but shoudl give you a view: > - An "add route" from CE->FE means to configure something on one or more > FEs that are addressed. > - An "add route" from FE->CE is an event notifying that a route was > added. > > An alternative is to reserve one bit for saying its an event or > configuration then you dont have to intepret directions.] [Wang Re: Why not just let us use an "Event report message" instead of using such a "add route" along with some bit to say it is an event, while leaving the "command" field from being fully used.] > > We just think to have a field with insufficient functions really makes > > confusions. > > As a result, I suppose two solution schemes for this problem: > > > > Scheme 1: Define this as "message type", to have the message body to express > > the operation not just based on TLV format. This means things like "Flags" > > "operating fields" are explicitly expressed according to the "message type" > > operation requirements. Remember that by using this scheme, we have already > > taken the whole ForCES message as one TLV. > > > > Scheme 2: Not define anything in the header on the "command" or > > "message type", leaving things defined in the followed body, while the body > > is expressed by a set of TLVs, each TLV representing a type of operation. > > > > The advantage for Scheme1 is it is very clear in semantics and saves bits > > quite a lot. > > > > The disadvantage is it has to define a specific message type for > > command bundle. > > > > The advantage for Scheme 2 is it is easy to implement command bundle, > > but the disadvantage is it costs more bits and makes protocol header less > > to do. >{Jamal Re: > I prefer to have the headers with flags; flags were usable on every > message. ] [Wang Re: not very sure how your reply maps what I said.] > > > 2. The Checksum field and other error control mechanism > > One essential function a protocol header takes is for a reliable > > information exchange, therefore, the common error control mechanism should > > be included in the header instead in the body. > > > > It seems no argue that a checksum should be provided as an option. > > Only difference between the candidate protocols is how it should be put. > > GRMP puts it at the protocol message end, Netlink2 has it as a TLV, I > > suppose FACT also intends the same. I'm thinking the purpose to have it as > > a TLV is mainly trying to reach a uniform TLV format. What we argue is to > > put checksum in a TLV may get more loss for the checking function, because > > it then will be in a risk that the TLV structure itself may be erred, > > which may result in the invalidation of the checksum. > >[Jamal Re: > Netlink2 has the concept of several shades of reliability. > Some messages dont need to be validated and therefore dont > need a checksum. This is also the path we are following now, > for that reason checksum should stay an optional field. [Wang Re: checksum in GRMP is also optional, my opinion is it has better performance to optionally put it at the message end, just the same as UDP.] > ] > > > GRMP reuses the idea "result" and "code" from GSMP, I'm sure this > > error control function should be included in the protocol. As the protocol > > header takes the tasks for a reliable information exchange, I > > strongly suggest it is put in the header. Could other candidate team > > show your opinions or solutions to this? > > [Jamal Re: > We had the concept of an ACK which returns results. > Depending on the result, this could be considered a NACK. > The ACK is requested per message using flagd and so sometimes may never > be sent. Again this has to do with levels of reliability. > In other words while the result is useful in the header, > it is only useful when the result is requested. > This is described in the section " The ACK Netlink2 Message". > I think this is similar to the way you do it in GRMP. > ] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:49:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03722 for ; Tue, 9 Mar 2004 10:49:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jTk-0001mF-9a for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:49:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FnCs2006817 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jTj-0001lG-U8 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:49:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03556 for ; Tue, 9 Mar 2004 10:49:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jTh-0004jw-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:49:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jPR-0003Qx-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:44:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMd-0002Ul-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jHC-00045F-4r for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:36:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jH7-0003ha-Rp; Tue, 09 Mar 2004 10:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0gY6-0000Mu-Vk for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 07:41:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24473 for ; Tue, 9 Mar 2004 07:41:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0gY6-0002MW-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 07:41:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0gX8-0002BM-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 07:40:31 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0gWD-0001rr-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 07:39:33 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Tue, 9 Mar 2004 20:50:36 +0800 Message-ID: <0b5801c405d3$3e378200$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E05420D@orsmsx408.jf.intel.com> <08ba01c404cb$3ba4e130$845c21d2@Necom.hzic.edu.cn> <1078751018.1037.386.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 20:37:11 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, Actually I have understood what your Src. ID and Dest. ID is refered to even before you put this email. In one word, your IDs (actually are PIDs) are in fact mapped to PIDs of FECxs. When I carefully read your approach, it just seems to me that there may be some limitation to use such an addressing scheme. Let's say there are two LFBs LFB1 and LFB2, which in your scheme are belong to two different threads FEC1 and FEC2. Now we need to address the two LFBs in one ForCES message, then I'm not sure how this will be implemented in the PID based scheme? Will the two LFBs be defined as a group then can be addressed at the same time or any others? Actually, GRMP (I suppose FACT also) can deal with this such case very easily. It's true that GRMP uses quite the same addressing method as FACT. The FE ID should be put in the message header, so that the ID is only used to tell which FEs the message will go, while leaving further addressing tasks to be implemented by the FEs themselves. Are there any limitations for such an addressing way? Best regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Monday, March 08, 2004 9:03 PM Subject: Re: [Forces-protocol] Issue 0: Application addressing > Hormuzd, Weiming, > > Apologies for long email; i am attempting to respond to two emails in > one. > > Ok, let me provide an example of an FE (same concept applies at > the CE). > Heres a diagram that may help to clarify what i have been refering > to; note that netlink2 did not start like this, however over > time implementation ended being like this; this shows an FE > side implementation. I have attached the two diagrams so they > dont get mangled. > > Figure 1. shows the netlink2 manager ( a s/ware daemon) managing > two socket connections on the lower side labelled as wire0 and wire1 > and entities called FECs on the upper side. > Figure2 shows the role of the FEC; it MAY manages one or more LFBs. > The communication mechanism used there is again beyond the scope of > ForCES. > Messages arriving at either of the sockets could end up in two sorts of > general classes of destinations: > 1) for the FE - in which they are serviced by the netlink2 daemon. > 2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes > them to those entities. > > Although i only list two classes, there could be more - but thats beside > the point. > FECs are OS processes/applications. (How they communicate to the > netlink2 daemon is beyond the scope of ForCES; lets say it could be a > local OS IPC.) > > As an example, there may be a FEC which controls several LFBs; > Another example is an FEC which sends and receives OSPF hellos. > Each FEC has a counterpart which understands it on the CE side. > The CE piece of OSPF (call it CEC) sends messages to > a specific PID when it wants to talk to the FEC portion (the hello > offloader). > As you can see this is application talking to another application; > this could be looked at as essentially IPC. Therefore the concept of PID > is useful. > > Now to address your emails: > > On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: > > Weiming, could you make sure your emails wrap around at 80 characters? > It helps when i am trying to respond. > > > > We think a layer-based tree structure according to the ForCES architecture > > is efficient to do such addressing. If we address entities at > > the FE coarse layer ( to take the FE as a whole entity, which idea is also > > used by new version of FE model ), we only need to > > have a FE ID. > > If i am not mistaken what you are talking about is a detail > on how the address gets split; i.e you want to have a hierachical > addressing - as an example you want to split the address above to > FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). > If this is the case, i think it is a small detail and we could move > on and talk baout it later; if not please look at the diagram and > tell me how you would split the ID to configure LFB0. I actually have > a feeling your approach to this would be VERY different from Hormuzd ;-> > > > To address > > CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, LFB > > Instance broadcast, and CE broadcast, following addressing can be > > implemented: > > I think we all agree on the broadcast or multicast to a specific > type of entities. > > >>- a set of LFBs on an FE > > - a set of LFBs on different FEs > > > > > > [Wang Re: Are the set of LFBs of the same type?] > > Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > > > - proxies for LFBs, > > - proxies for control application in the form on the CEs, > > > > [Wang Re: If ever we have these proxies, are they need to be seen at the > > protocol layer? > > No, there is nothing speacial needed at the protocol header. The list > was an exhaustive example. > > > Moreover, how about FE proxies then?] > > They dont need to be addressed by anything speacial in the header. > > On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: > > > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go > > with that terminology then? > > Lets talk about what needs to be addressed first before we jump to that. > Refer to the two diagrams i sent. > > > [HK] I don't see the value of having an App ID in the common header. How > > is it useful ? May be if you could give a good example of how this can > > be used, it would help. The ForCES endpoints are CEs and FEs which > > should be addressed in the common header. LFBs are like knobs on the FEs > > used to program its functionality. I am sure you know all this very well > > and I think most folks will agree on this. If we go with a different > > view, we will probably land up breaking the FE Model as well. Other > > views on this one ? > > Refer to the two diagrams i sent for an example, then lets discuss. > > [HK] Could you give me an example of why this is limiting? > > I was refering to the fact that you have a single ID to address > entities within an FE or CE. In my diagram i am rtying to show theres > more than one class of end targets. So calling it CEID or FEID > is limiting. > > > I would like > > to know if using 16 bits would break in some scenarios. If this was part > > of a TLV I wouldn't care as much, but since this is the common header, I > > am a bit concerned...acting stingy :-)) > .. > > [HK] Exactly, ForCES has much limited/specific scope (NE) than general > > purpose middleware such as Corba. You cannot compare these 2 because of > > the difference in scope. > > I gave the historical experience of PCs (by quoting a naive bill gates), > IPV4(by making a mockery over the famous last words that brought IPV6 to > the world) and now i can add the experience of unix which would have > been more interesting with 64 bit PIDs. > Summary: Nothing would break; however it is useful to learn from history > and say lets go with something larger. > > Again, apologies for long email; hopefully this would group > things together. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:50:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03869 for ; Tue, 9 Mar 2004 10:50:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUB-00026Z-5Z for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:49:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Fndke008085 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUA-00026K-MB for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03695 for ; Tue, 9 Mar 2004 10:49:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jU8-0004rq-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:49:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jPw-0003ZE-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:45:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jMg-0002eq-02 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHm-0004Ac-B2; Tue, 09 Mar 2004 10:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0hY8-0003d9-Fe for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 08:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27096 for ; Tue, 9 Mar 2004 08:45:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0hY6-0005xd-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:45:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0hXC-0005oD-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:44:38 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0hWR-0005VK-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 08:43:52 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Tue, 9 Mar 2004 21:54:16 +0800 Message-ID: <0bcf01c405dc$22f71a60$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , Cc: "Weiming Wang" References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> <1078775008.1037.455.camel@jzny.localdomain> Subject: Re: [Forces-protocol] issue 1: packet encoding 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 21:40:50 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, Could you just add some tag to indicate your reply? Or else, I have to help to add it so that others can see your reply. Some comments as below. Thank you. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Wang,Weiming" > Weimimg, > > On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote: > [..] > > > 1. The "command" field > > This is really a field that confuses me. The confusion is: > > 1) If it is a field only with command "Add/Del/Get", I suppose we can just > > obsolete it. The command can be surely be expressed in the followed body > > by using TLVs. >[Jamal Re: > Every message will have a command. For that reason it belongs to the > main header.] [Wang Re: I would say it is also possible to have a message contain more than one command. But I don't want push this too hard so that we may be quicker to reach an agreement.] > > > 2) If we keep it, I'm afraid its meaning should be far from these. For > > example, how an event report can be represented, and how a command bundle > > is represented then, and many others? >[Jamal Re: > I will explain how we implemented events; note, this is different from > the current command structure but shoudl give you a view: > - An "add route" from CE->FE means to configure something on one or more > FEs that are addressed. > - An "add route" from FE->CE is an event notifying that a route was > added. > > An alternative is to reserve one bit for saying its an event or > configuration then you dont have to intepret directions.] [Wang Re: Why not just let us use an "Event report message" instead of using such a "add route" along with some bit to say it is an event, while leaving the "command" field from being fully used.] > > We just think to have a field with insufficient functions really makes > > confusions. > > As a result, I suppose two solution schemes for this problem: > > > > Scheme 1: Define this as "message type", to have the message body to express > > the operation not just based on TLV format. This means things like "Flags" > > "operating fields" are explicitly expressed according to the "message type" > > operation requirements. Remember that by using this scheme, we have already > > taken the whole ForCES message as one TLV. > > > > Scheme 2: Not define anything in the header on the "command" or > > "message type", leaving things defined in the followed body, while the body > > is expressed by a set of TLVs, each TLV representing a type of operation. > > > > The advantage for Scheme1 is it is very clear in semantics and saves bits > > quite a lot. > > > > The disadvantage is it has to define a specific message type for > > command bundle. > > > > The advantage for Scheme 2 is it is easy to implement command bundle, > > but the disadvantage is it costs more bits and makes protocol header less > > to do. >{Jamal Re: > I prefer to have the headers with flags; flags were usable on every > message. ] [Wang Re: not very sure how your reply maps what I said.] > > > 2. The Checksum field and other error control mechanism > > One essential function a protocol header takes is for a reliable > > information exchange, therefore, the common error control mechanism should > > be included in the header instead in the body. > > > > It seems no argue that a checksum should be provided as an option. > > Only difference between the candidate protocols is how it should be put. > > GRMP puts it at the protocol message end, Netlink2 has it as a TLV, I > > suppose FACT also intends the same. I'm thinking the purpose to have it as > > a TLV is mainly trying to reach a uniform TLV format. What we argue is to > > put checksum in a TLV may get more loss for the checking function, because > > it then will be in a risk that the TLV structure itself may be erred, > > which may result in the invalidation of the checksum. > >[Jamal Re: > Netlink2 has the concept of several shades of reliability. > Some messages dont need to be validated and therefore dont > need a checksum. This is also the path we are following now, > for that reason checksum should stay an optional field.] [Wang Re: checksum in GRMP is also optional, my opinion is it has better performance to optionally put it at the message end, just the same as UDP.] > > > GRMP reuses the idea "result" and "code" from GSMP, I'm sure this > > error control function should be included in the protocol. As the protocol > > header takes the tasks for a reliable information exchange, I > > strongly suggest it is put in the header. Could other candidate team > > show your opinions or solutions to this? > > [Jamal Re: > We had the concept of an ACK which returns results. > Depending on the result, this could be considered a NACK. > The ACK is requested per message using flagd and so sometimes may never > be sent. Again this has to do with levels of reliability. > In other words while the result is useful in the header, > it is only useful when the result is requested. > This is described in the section " The ACK Netlink2 Message". > I think this is similar to the way you do it in GRMP. > ] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 10:50:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04095 for ; Tue, 9 Mar 2004 10:50:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUt-0002ML-LG for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 10:50:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FoNZd009062 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUt-0002Lr-7U for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03953 for ; Tue, 9 Mar 2004 10:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jUq-00057A-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jQh-0003nV-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:46:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jMn-0002g9-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jMo-0006bW-TQ; Tue, 09 Mar 2004 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jMd-0006JZ-VP for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 10:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02315 for ; Tue, 9 Mar 2004 10:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jMS-0002dI-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 10:41:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jLV-0002R9-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 10:40:43 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0jKe-00025k-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 10:39:48 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i29FdFTN009180; Tue, 9 Mar 2004 09:39:16 -0600 (CST) Message-ID: <404DE523.4030703@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> In-Reply-To: <1078830604.1036.546.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------070104020404000909040101" Subject: [Forces-protocol] Re: Progress issue0 Application Addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Mar 2004 09:39:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070104020404000909040101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamal, All, Let Hormuzd moderate the discussion topics. You have tabled the first two issues. That is fine. So we discuss 0) Application Addressing and 1) Header Encoding. Issue 0: Application Addressing-- I think we have some concensus on Application Addressing: a) We don't address LFBs in the common header, but do so in the appropriate TLVs. (I believe Jamal and Weiming refered to this as hierarchical addressing) b) (any more refinements ?? ) Regards, Alex. Jamal Hadi Salim wrote: >On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > > >>Avri wrote > >> >> >>>I have a general question about headers, is there any feeling in this >>>group that a common header could not be arrived at. If not then we >>>could move on to other issues. The reason I ask is that one >>>can spend >>>a whole lot of time fine tuning a header to be just right. If there >>>are as of yet unresolved issues on the header, can anyone list them? >>> >>> >>I agree with Avri, >> >> > >On the one hand i wanna say lets skip so we can make progress. >OTOH, I am a little worried that the gaps in point of view >are so huge that this will cause problems later. >The only way we can close faster is if ontopic emails are addressed in >the fastest possible way. > >On a personal level i am trying to prioritize responding to things >on this list. But sometime i get a little discouraged. Example my last >emails on topic 0 and topic 1 have not been responded to for at least >24 hours. Actually they have been a response which happens to be off >topic. This worries me because i dont think we will make the deadline. >If theres 10-12 serious issues and we have about 10 days to go >AND we havent closed a single issue up to now --> theres _no way_ >we can meet the deadline. We need to close 2 issues a day. > >Of course a brute force solution is to say theres desire to reach a >compromise and stop there. But this in itself is dangerous and i >would not prefer to go that route. > >So at the moment i am at a loss. Maybe the approach of listing issues >which need to be agreed on is not the right one? What thoughts do people >have on this? Other proposals that have been made so far that received >no traction are: >a) each protocol draft to list what they cant live without, >b) Each protocol draft to list their implementation experiences and >say what they found useful and what wasnt. > > > >>and like others I am having a hard time >>keeping up with all the different discussions. >> >> > >Yes, this has been an issue but is general to any email or usent >discussuions - problem is someone starts going off >topic then other people respond. And the cycle continues. > >The best way to run "meetings" over email are: > >Rule 0: have an agenda (list of topics to discuss). We have this >Rule 1 is to have a running topic (eg currently issue 1 and 0 are >ontopic). No other topic is to be discussed. We are trying this. >Rule 2 is not to respond to currently-offtopic emails. This is typically >the easiest rule to break on email or usenet because of human nature. >Naturally this has been the most broken rule. >Rule 3 is once in a while people need to be reminded they are off topic. >(I have tried to do this in personal emails as well as on the list.) >Rule 4 is if the content does not reflect the subject line, change the >subject line (like i just did with this email). > >I could almost say we are getting close to following the above; I >counted and only 2 emails were offtopic out of last 6 as opposed to >6 out 10 before that. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------070104020404000909040101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal, All,

Let Hormuzd moderate the discussion topics.  You have tabled the first two issues.
That is fine.  So we discuss
0) Application Addressing and
1) Header Encoding.

Issue 0: Application Addressing--
I think we have some concensus on Application Addressing:
a) We don't address LFBs in the common header, but do so in the appropriate TLVs.
     (I believe Jamal and Weiming refered to this as hierarchical addressing)
b)  (any more refinements ?? )

Regards,
Alex.

Jamal Hadi Salim wrote:
On Tue, 2004-03-09 at 01:42, Putzolu, David wrote:
  
Avri wrote >
    
I have a general question about headers, is there any feeling in this 
group that a common header could not be arrived at.  If not then we 
could move on to other issues.  The reason I ask is that one 
can spend 
a whole lot of time fine tuning a header to be just right.  If there 
are as of yet unresolved issues on the header, can anyone list them?
      
I agree with Avri, 
    

On the one hand i wanna say lets skip so we can make progress.
OTOH, I am a little worried that the gaps in point of view
are so huge that this will cause problems later. 
The only way we can close faster is if ontopic emails are addressed in
the fastest possible way.

On a personal level i am trying to prioritize responding to things
on this list. But sometime i get a little discouraged. Example my last
emails on topic 0 and topic 1 have not been responded to for at least
24 hours. Actually they have been a response which happens to be off
topic. This worries me because i dont think we will make the deadline.
If theres 10-12 serious issues and we have about 10 days to go
AND we havent closed a single issue up to now --> theres _no way_ 
we can meet the deadline. We need to close 2 issues a day.

Of course a brute force solution is to say theres desire to reach a
compromise and stop there. But this in itself is dangerous and i
would not prefer to go that route.

So at the moment i am at a loss. Maybe the approach of listing issues
which need to be agreed on is not the right one? What thoughts do people
have on this? Other proposals that have been made so far that received
no traction are:
a) each protocol draft to list what they cant live without,
b) Each protocol draft to list their implementation experiences and
say what they found useful and what wasnt.

  
and like others I am having a hard time 
keeping up with all the different discussions.  
    

Yes, this has been an issue but is general to any email or usent
discussuions - problem is someone starts going off 
topic then other people respond. And the cycle continues. 

The best way to run "meetings" over email are:

Rule 0: have an agenda (list of topics to discuss). We have this
Rule 1 is to have a running topic (eg currently issue 1 and 0 are
ontopic). No other topic is to be discussed. We are trying this.
Rule 2 is not to respond to currently-offtopic emails. This is typically
the easiest rule to break on email or usenet because of human nature.
Naturally this has been the most broken rule. 
Rule 3 is once in a while people need to be reminded they are off topic.
(I have tried to do this in personal emails as well as on the list.)
Rule 4 is if the content does not reflect the subject line, change the
subject line (like i just did with this email).

I could almost say we are getting close to following the above; I
counted and only 2 emails were offtopic out of last 6 as opposed to
6 out 10 before that.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------070104020404000909040101-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:10:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05964 for ; Tue, 9 Mar 2004 11:10:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jnp-00050Q-Jq for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:09:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29G9vHO019241 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:09:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jnp-00050G-AL for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:09:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05920 for ; Tue, 9 Mar 2004 11:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jnm-0002P1-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jmZ-00022b-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:08:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jkx-0001XW-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jkz-0004Jf-7b; Tue, 09 Mar 2004 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jkX-0004I8-8G for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:06:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05337 for ; Tue, 9 Mar 2004 11:06:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jkU-0001L3-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:06:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jio-0000x3-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:04:47 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jhi-0000gl-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:03:38 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030908041431:65845 ; Tue, 9 Mar 2004 08:04:14 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org In-Reply-To: <404DE523.4030703@alcatel.com> References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> <404DE523.4030703@alcatel.com> Organization: ZNYX Networks Message-Id: <1078848212.1038.616.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 03/09/2004 08:04:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 08:04:16 AM, Serialize complete at 03/09/2004 08:04:16 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Re: Progress issue0 Application Addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 11:03:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-09 at 10:39, Alex Audu wrote: > Jamal, All, > > Let Hormuzd moderate the discussion topics. Is there a good reason for this? > You have tabled the first two issues. > That is fine. So we discuss > 0) Application Addressing and > 1) Header Encoding. > > Issue 0: Application Addressing-- > I think we have some concensus on Application Addressing: > a) We don't address LFBs in the common header, but do so in the > appropriate TLVs. > (I believe Jamal and Weiming refered to this as hierarchical > addressing) > b) (any more refinements ?? ) You are missing a lot of details. Normally, i would have explained things, but this is one of the reasons we are not moving fast. Please go back onto the thread and read again then summarize. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:12:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06297 for ; Tue, 9 Mar 2004 11:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jpi-0005ER-QG for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:11:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GBsLN020102 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jpi-0005E6-DW for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06201 for ; Tue, 9 Mar 2004 11:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jpf-0002v4-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:11:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0joB-0002TQ-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:10:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jn4-00029h-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jn3-0004uL-2h; Tue, 09 Mar 2004 11:09:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jmf-0004my-BV for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05751 for ; Tue, 9 Mar 2004 11:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jmc-00023k-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jkz-0001Xw-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:07:05 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0jj6-0000sY-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:05:04 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i29G4UTN014707; Tue, 9 Mar 2004 10:04:31 -0600 (CST) Message-ID: <404DEB0E.50400@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> In-Reply-To: <1078830604.1036.546.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------090409010006000307060603" Subject: [Forces-protocol] Re: Progress issue 1: packet encoding Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Mar 2004 10:04:30 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090409010006000307060603 Content-Type: multipart/alternative; boundary="------------050006070208010804070105" --------------050006070208010804070105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On Issue 1: packet encoding, it is easy to come to concensus on this one. So far, the train thoughts is per the attachment to this e-mail. Issues raised: 1) Avri raised issue of indicating an error with an error flag on the header. Comment: That is certainly one way to convey error conditions. But experience has shown that if you do that, you force your protocol software to check this flag for every message that comes in (to ascertain if it is error message or not), before proceeding. This is an incredible wate of processor cycles since an error condition is really an exception condition. Carrying an error indication with an error TLV is much better. It is like an error color code; you only do error processing if that color shows up. And all the other messages are handled similarly. This could easily be the difference between a protocol that is twice as fast and efficient compared to an otherwise poorly designed one. Regards, Alex. Jamal Hadi Salim wrote: >On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > > >>Avri wrote > >> >> >>>I have a general question about headers, is there any feeling in this >>>group that a common header could not be arrived at. If not then we >>>could move on to other issues. The reason I ask is that one >>>can spend >>>a whole lot of time fine tuning a header to be just right. If there >>>are as of yet unresolved issues on the header, can anyone list them? >>> >>> >>I agree with Avri, >> >> > >On the one hand i wanna say lets skip so we can make progress. >OTOH, I am a little worried that the gaps in point of view >are so huge that this will cause problems later. >The only way we can close faster is if ontopic emails are addressed in >the fastest possible way. > >On a personal level i am trying to prioritize responding to things >on this list. But sometime i get a little discouraged. Example my last >emails on topic 0 and topic 1 have not been responded to for at least >24 hours. Actually they have been a response which happens to be off >topic. This worries me because i dont think we will make the deadline. >If theres 10-12 serious issues and we have about 10 days to go >AND we havent closed a single issue up to now --> theres _no way_ >we can meet the deadline. We need to close 2 issues a day. > >Of course a brute force solution is to say theres desire to reach a >compromise and stop there. But this in itself is dangerous and i >would not prefer to go that route. > >So at the moment i am at a loss. Maybe the approach of listing issues >which need to be agreed on is not the right one? What thoughts do people >have on this? Other proposals that have been made so far that received >no traction are: >a) each protocol draft to list what they cant live without, >b) Each protocol draft to list their implementation experiences and >say what they found useful and what wasnt. > > > >>and like others I am having a hard time >>keeping up with all the different discussions. >> >> > >Yes, this has been an issue but is general to any email or usent >discussuions - problem is someone starts going off >topic then other people respond. And the cycle continues. > >The best way to run "meetings" over email are: > >Rule 0: have an agenda (list of topics to discuss). We have this >Rule 1 is to have a running topic (eg currently issue 1 and 0 are >ontopic). No other topic is to be discussed. We are trying this. >Rule 2 is not to respond to currently-offtopic emails. This is typically >the easiest rule to break on email or usenet because of human nature. >Naturally this has been the most broken rule. >Rule 3 is once in a while people need to be reminded they are off topic. >(I have tried to do this in personal emails as well as on the list.) >Rule 4 is if the content does not reflect the subject line, change the >subject line (like i just did with this email). > >I could almost say we are getting close to following the above; I >counted and only 2 emails were offtopic out of last 6 as opposed to >6 out 10 before that. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------050006070208010804070105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit On Issue 1: packet encoding,  it is easy to come to concensus on this one.  So far, the train
thoughts is per the attachment to this e-mail.

Issues raised:
1) Avri raised issue of indicating an error with an error flag on the header.

Comment:  That is certainly one way to convey error conditions. But experience has
shown that if you do that, you force your protocol software to check this flag for every
message that comes in (to ascertain if it is error message or not), before proceeding. This
is an incredible  wate of processor cycles since an error condition is really an exception
condition.

Carrying an error indication with an error TLV is much better.   It is like an error color
code; you only do error processing if that color shows up.  And all the other messages
are handled similarly.  This could easily be the difference between a protocol  that is
twice as fast and efficient  compared to an otherwise poorly designed one.

Regards,
Alex.




Jamal Hadi Salim wrote:
On Tue, 2004-03-09 at 01:42, Putzolu, David wrote:
  
Avri wrote >
    
I have a general question about headers, is there any feeling in this 
group that a common header could not be arrived at.  If not then we 
could move on to other issues.  The reason I ask is that one 
can spend 
a whole lot of time fine tuning a header to be just right.  If there 
are as of yet unresolved issues on the header, can anyone list them?
      
I agree with Avri, 
    

On the one hand i wanna say lets skip so we can make progress.
OTOH, I am a little worried that the gaps in point of view
are so huge that this will cause problems later. 
The only way we can close faster is if ontopic emails are addressed in
the fastest possible way.

On a personal level i am trying to prioritize responding to things
on this list. But sometime i get a little discouraged. Example my last
emails on topic 0 and topic 1 have not been responded to for at least
24 hours. Actually they have been a response which happens to be off
topic. This worries me because i dont think we will make the deadline.
If theres 10-12 serious issues and we have about 10 days to go
AND we havent closed a single issue up to now --> theres _no way_ 
we can meet the deadline. We need to close 2 issues a day.

Of course a brute force solution is to say theres desire to reach a
compromise and stop there. But this in itself is dangerous and i
would not prefer to go that route.

So at the moment i am at a loss. Maybe the approach of listing issues
which need to be agreed on is not the right one? What thoughts do people
have on this? Other proposals that have been made so far that received
no traction are:
a) each protocol draft to list what they cant live without,
b) Each protocol draft to list their implementation experiences and
say what they found useful and what wasnt.

  
and like others I am having a hard time 
keeping up with all the different discussions.  
    

Yes, this has been an issue but is general to any email or usent
discussuions - problem is someone starts going off 
topic then other people respond. And the cycle continues. 

The best way to run "meetings" over email are:

Rule 0: have an agenda (list of topics to discuss). We have this
Rule 1 is to have a running topic (eg currently issue 1 and 0 are
ontopic). No other topic is to be discussed. We are trying this.
Rule 2 is not to respond to currently-offtopic emails. This is typically
the easiest rule to break on email or usenet because of human nature.
Naturally this has been the most broken rule. 
Rule 3 is once in a while people need to be reminded they are off topic.
(I have tried to do this in personal emails as well as on the list.)
Rule 4 is if the content does not reflect the subject line, change the
subject line (like i just did with this email).

I could almost say we are getting close to following the above; I
counted and only 2 emails were offtopic out of last 6 as opposed to
6 out 10 before that.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------050006070208010804070105-- --------------090409010006000307060603 Content-Type: text/plain; name="header.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="header.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't know what the flags could be used for. The TypeID could be used for siganling the type of data encoding explicitly, (i.e. XML, ASN.1 etc). My preference will be the following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |vers |eType | prio| reservd | msgClass | msgType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source xID | Destination xID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1) version # indicates the version of the protocol. 2) the type of encoding comes next. 3) the priority of the message comes next. 4) the command has been divided into message class and type to ease management and handling. 5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool! 6) the length is now 32 bits long. This will accommodate flow measurement messages which tend to be huge, from FE to CE. It will also accommodate large table dumps from CE to FE. 7) then comes the sequence number. Any comments? Regards, Alex. > Jamal, > > Before I give my comments, I would like to say that I appreciate the > fact that you did not copy/paste the netlink header from your draft over > here! That is a very positive sign to me, lets try to stick to the best > technical solution rather than pushing our own protocol implementations. > That's the best way to make progress on this merger!! > > Here are my views on this issue, particularly the common header: > > Command: Agree this is needed. We think 8-12 bits will be more than > sufficient for this depending on whether it is subdivided. We have > sub-divided this field into Class/type...this is an OO approach, seemed > pretty neat. However, I am personally fine with having a single field > for this, no problem with that. > > Length: Agree needed and agree with size. > > xIDs: Agree this is needed. More detailed comments on length, semantics > in my previous email. > > Sequence No: Agree needed and agree with size. > > Flags/Priority: We need 2-3 bits for priority in every message. I don't > think we need any other flags in all messages. > > Typeid: This is one field I don't think is needed in all messages. I am > not sure why this is needed at all cause, we will be using the Model and > LFB IDs to address processing functional blocks on the FEs. > > Missing field: Version (2-4 bits): This is present in all protocols, and > is generally included in most IETF protocols. Its usually the 1st field. > > General comment: Lets try to be stingy on the size of the header and its > fields since this will be included in all ForCES messages. > > Jamal's text....... > The Forces Message Header: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Command | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flags | typeid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > XML encoding: > XML encoding may be useful in capabilities definition > (i.e slow path) but not in the configuration of data path tables. > This is because of its nature to require higher bandwith and > CPU computational needs. > > HK Comment: I think we should stick with a single encoding type, namely > TLV. This is also what some of the model team folks have mentioned > before for the protocol. Is there a reason why capabilities cannot be > expressed using TLVs? > > > Thanks > Hormu --------------090409010006000307060603-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:13:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06370 for ; Tue, 9 Mar 2004 11:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jqZ-0005JU-Ax for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:12:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GCl19020418 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:12:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jqZ-0005JF-6D for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06355 for ; Tue, 9 Mar 2004 11:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jqY-00039q-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jpy-0002y4-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:12:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jop-0002gz-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jor-00056n-5v; Tue, 09 Mar 2004 11:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jnx-00052W-99 for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:10:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05939 for ; Tue, 9 Mar 2004 11:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jnu-0002QW-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jmr-00027a-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:08:58 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jlN-0001c2-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:07:25 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030908080192:65856 ; Tue, 9 Mar 2004 08:08:01 -0800 Subject: Re: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, Weiming Wang In-Reply-To: <0c8401c405e5$a90986c0$845c21d2@Necom.hzic.edu.cn> References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <0c8401c405e5$a90986c0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078848440.1039.621.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 03/09/2004 08:08:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 08:08:03 AM, Serialize complete at 03/09/2004 08:08:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 11:07:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Weiming, On Tue, 2004-03-09 at 09:49, Wang,Weiming wrote: > Hi, > > I quite don't agree to limit a message type (or refered as "command") to only > "Add/Del/Get". If we are decided to use a "command" field in the header, I > think at least as a start, we should include following message types: There is no limiting to add/del/get. You have 8 bits (although this is not closed) you can therefore have upto 256 commands. I can express all the commands you posted with add/del/get: But thats something we can settle later. Can we close topic 1? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:21:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06653 for ; Tue, 9 Mar 2004 11:21:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jyD-0005u6-4j for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:20:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GKfKw022688 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jyC-0005tr-Tu for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:20:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06642 for ; Tue, 9 Mar 2004 11:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jyC-0004WT-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jxI-0004Ns-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:19:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jwb-0004Ev-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jwb-0005e7-4W; Tue, 09 Mar 2004 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jwE-0005cC-Oz for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06591 for ; Tue, 9 Mar 2004 11:18:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jwD-0004DY-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:18:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jvO-00044J-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:17:47 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0juW-0003ue-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:16:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030908172763:65886 ; Tue, 9 Mar 2004 08:17:27 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org In-Reply-To: <404DEB0E.50400@alcatel.com> References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> <404DEB0E.50400@alcatel.com> Organization: ZNYX Networks Message-Id: <1078849006.1038.625.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 03/09/2004 08:17:28 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 08:17:31 AM, Serialize complete at 03/09/2004 08:17:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Re: Progress issue 1: packet encoding Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 11:16:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a common trick. I thought both FACT and GRMP have it. Netlink2 for example has a special command for errors. The body will contain an error code and the offending original header (similar to ICMP source quench). These are issues we can settle. Can we please close topic 1? cheers, jamal On Tue, 2004-03-09 at 11:04, Alex Audu wrote: > On Issue 1: packet encoding, it is easy to come to concensus on this > one. So far, the train > thoughts is per the attachment to this e-mail. > > Issues raised: > 1) Avri raised issue of indicating an error with an error flag on the > header. > > Comment: That is certainly one way to convey error conditions. But > experience has > shown that if you do that, you force your protocol software to check > this flag for every > message that comes in (to ascertain if it is error message or not), > before proceeding. This > is an incredible wate of processor cycles since an error condition is > really an exception > condition. > > Carrying an error indication with an error TLV is much better. It is > like an error color > code; you only do error processing if that color shows up. And all > the other messages > are handled similarly. This could easily be the difference between a > protocol that is > twice as fast and efficient compared to an otherwise poorly designed > one. > > Regards, > Alex. > > > > > Jamal Hadi Salim wrote: > > On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > > > > > Avri wrote > > > > > > > > I have a general question about headers, is there any feeling in this > > > > group that a common header could not be arrived at. If not then we > > > > could move on to other issues. The reason I ask is that one > > > > can spend > > > > a whole lot of time fine tuning a header to be just right. If there > > > > are as of yet unresolved issues on the header, can anyone list them? > > > > > > > > > > I agree with Avri, > > > > > > > On the one hand i wanna say lets skip so we can make progress. > > OTOH, I am a little worried that the gaps in point of view > > are so huge that this will cause problems later. > > The only way we can close faster is if ontopic emails are addressed in > > the fastest possible way. > > > > On a personal level i am trying to prioritize responding to things > > on this list. But sometime i get a little discouraged. Example my last > > emails on topic 0 and topic 1 have not been responded to for at least > > 24 hours. Actually they have been a response which happens to be off > > topic. This worries me because i dont think we will make the deadline. > > If theres 10-12 serious issues and we have about 10 days to go > > AND we havent closed a single issue up to now --> theres _no way_ > > we can meet the deadline. We need to close 2 issues a day. > > > > Of course a brute force solution is to say theres desire to reach a > > compromise and stop there. But this in itself is dangerous and i > > would not prefer to go that route. > > > > So at the moment i am at a loss. Maybe the approach of listing issues > > which need to be agreed on is not the right one? What thoughts do people > > have on this? Other proposals that have been made so far that received > > no traction are: > > a) each protocol draft to list what they cant live without, > > b) Each protocol draft to list their implementation experiences and > > say what they found useful and what wasnt. > > > > > > > and like others I am having a hard time > > > keeping up with all the different discussions. > > > > > > > Yes, this has been an issue but is general to any email or usent > > discussuions - problem is someone starts going off > > topic then other people respond. And the cycle continues. > > > > The best way to run "meetings" over email are: > > > > Rule 0: have an agenda (list of topics to discuss). We have this > > Rule 1 is to have a running topic (eg currently issue 1 and 0 are > > ontopic). No other topic is to be discussed. We are trying this. > > Rule 2 is not to respond to currently-offtopic emails. This is typically > > the easiest rule to break on email or usenet because of human nature. > > Naturally this has been the most broken rule. > > Rule 3 is once in a while people need to be reminded they are off topic. > > (I have tried to do this in personal emails as well as on the list.) > > Rule 4 is if the content does not reflect the subject line, change the > > subject line (like i just did with this email). > > > > I could almost say we are getting close to following the above; I > > counted and only 2 emails were offtopic out of last 6 as opposed to > > 6 out 10 before that. > > > > cheers, > > jamal > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > ______________________________________________________________________ > > I don't know what the flags could be used for. The TypeID could be used for > siganling the type of data encoding explicitly, (i.e. XML, ASN.1 etc). > My preference will be the following. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |vers |eType | prio| reservd | msgClass | msgType | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | message length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source xID | Destination xID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 1) version # indicates the version of the protocol. > 2) the type of encoding comes next. > 3) the priority of the message comes next. > 4) the command has been divided into message class and type to ease management and handling. > 5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool! > 6) the length is now 32 bits long. This will accommodate flow measurement messages which > tend to be huge, from FE to CE. It will also accommodate large table dumps from CE to > FE. > 7) then comes the sequence number. > > Any comments? > > Regards, > Alex. > > > Jamal, > > > > Before I give my comments, I would like to say that I appreciate the > > fact that you did not copy/paste the netlink header from your draft over > > here! That is a very positive sign to me, lets try to stick to the best > > technical solution rather than pushing our own protocol implementations. > > That's the best way to make progress on this merger!! > > > > Here are my views on this issue, particularly the common header: > > > > Command: Agree this is needed. We think 8-12 bits will be more than > > sufficient for this depending on whether it is subdivided. We have > > sub-divided this field into Class/type...this is an OO approach, seemed > > pretty neat. However, I am personally fine with having a single field > > for this, no problem with that. > > > > Length: Agree needed and agree with size. > > > > xIDs: Agree this is needed. More detailed comments on length, semantics > > in my previous email. > > > > Sequence No: Agree needed and agree with size. > > > > Flags/Priority: We need 2-3 bits for priority in every message. I don't > > think we need any other flags in all messages. > > > > Typeid: This is one field I don't think is needed in all messages. I am > > not sure why this is needed at all cause, we will be using the Model and > > LFB IDs to address processing functional blocks on the FEs. > > > > Missing field: Version (2-4 bits): This is present in all protocols, and > > is generally included in most IETF protocols. Its usually the 1st field. > > > > General comment: Lets try to be stingy on the size of the header and its > > fields since this will be included in all ForCES messages. > > > > Jamal's text....... > > The Forces Message Header: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > 0 1 2 3 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Command | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Source xID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Destination xID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | flags | typeid | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > XML encoding: > > XML encoding may be useful in capabilities definition > > (i.e slow path) but not in the configuration of data path tables. > > This is because of its nature to require higher bandwith and > > CPU computational needs. > > > > HK Comment: I think we should stick with a single encoding type, namely > > TLV. This is also what some of the model team folks have mentioned > > before for the protocol. Is there a reason why capabilities cannot be > > expressed using TLVs? > > > > > > Thanks > > Hormu _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:23:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06702 for ; Tue, 9 Mar 2004 11:23:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0k09-00060F-53 for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:22:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GMffK023069 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0k08-000600-Qr for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:22:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06694 for ; Tue, 9 Mar 2004 11:22:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0k07-0004oA-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jzB-0004fk-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:21:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jyX-0004XH-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jyY-0005uZ-24; Tue, 09 Mar 2004 11:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jyB-0005th-IW for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06636 for ; Tue, 9 Mar 2004 11:20:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jyA-0004WJ-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jxH-0004Nc-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:19:43 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0jwU-00045l-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:18:54 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i29GHpTN018165; Tue, 9 Mar 2004 10:17:51 -0600 (CST) Message-ID: <404DEE2E.7000400@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: forces-protocol@ietf.org, "Putzolu, Daviddavid.putzoluati" , Wang@ietf-mx.cnri.reston.va.us, Weiming Subject: Re: [Forces-protocol] Is the list dead? References: <1078842828.1038.600.camel@jzny.localdomain> In-Reply-To: <1078842828.1038.600.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Mar 2004 10:17:50 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yeap, ..I am just getting a burst of e-mails that were sent almost two hours ago. Hhmm... Alex. Jamal Hadi Salim wrote: >Folks, >Is there a problem with the list? >I dont see any echoes back neither does the archive show >anything new. >Seems like we are having a few issues with this list >maybe we can move to a more reliable site? > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:51:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07842 for ; Tue, 9 Mar 2004 11:51:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kRu-00009t-Cq for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:51:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GpMFr000603 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:51:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kRs-00009e-Cw for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:51:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07737 for ; Tue, 9 Mar 2004 11:51:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kRr-0002eg-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:51:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kOu-0001nE-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:48:17 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0kNF-0001HJ-04 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:46:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0kD6-000611-U2 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kD4-0006yf-2t; Tue, 09 Mar 2004 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kCj-0006y3-Ed for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:35:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07227 for ; Tue, 9 Mar 2004 11:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kCi-0007Sm-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:35:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kBp-0007KP-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:34:46 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B0kBL-0007BL-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:34:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i29GXfTN023107; Tue, 9 Mar 2004 10:33:41 -0600 (CST) Message-ID: <404DF1E5.4090106@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> <404DE523.4030703@alcatel.com> <1078848212.1038.616.camel@jzny.localdomain> In-Reply-To: <1078848212.1038.616.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------050208020308060206070807" Subject: [Forces-protocol] Re: Progress issue0 Application Addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Mar 2004 10:33:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050208020308060206070807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jamal, I think Hormuzd is a good moderator (from experience in our design meetings). We could have someone else do it,..if you object. The other issue I'd like to raise is please, let us cut through the chase and go straight to the point. Some of the e-mails are really getting too long. We have our full-time jobs you know. You can be brief and be understandable. I think they call that succinctness. Regards, Alex. Jamal Hadi Salim wrote: >On Tue, 2004-03-09 at 10:39, Alex Audu wrote: > > >>Jamal, All, >> >>Let Hormuzd moderate the discussion topics. >> >> > >Is there a good reason for this? > > > >> You have tabled the first two issues. >>That is fine. So we discuss >>0) Application Addressing and >>1) Header Encoding. >> >>Issue 0: Application Addressing-- >>I think we have some concensus on Application Addressing: >>a) We don't address LFBs in the common header, but do so in the >>appropriate TLVs. >> (I believe Jamal and Weiming refered to this as hierarchical >>addressing) >>b) (any more refinements ?? ) >> >> > >You are missing a lot of details. Normally, i would have explained >things, but this is one of the reasons we are not moving fast. >Please go back onto the thread and read again then summarize. > >cheers, >jamal > > > > > --------------050208020308060206070807 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jamal,

I  think Hormuzd is a good moderator (from experience in our design meetings).  We could
have someone else do it,..if you object. 

The other issue I'd like to raise is please, let us cut through the chase and go straight to the
point. Some of the e-mails are really getting too long. We have our full-time jobs you know.
You can be brief and be understandable.  I think they call that succinctness.

Regards,
Alex.

Jamal Hadi Salim wrote:
On Tue, 2004-03-09 at 10:39, Alex Audu wrote:
  
Jamal, All,

Let Hormuzd moderate the discussion topics. 
    

Is there a good reason for this? 

  
 You have tabled the first two issues.
That is fine.  So we discuss 
0) Application Addressing and 
1) Header Encoding.

Issue 0: Application Addressing--
I think we have some concensus on Application Addressing: 
a) We don't address LFBs in the common header, but do so in the
appropriate TLVs.
     (I believe Jamal and Weiming refered to this as hierarchical
addressing)
b)  (any more refinements ?? )
    

You are missing a lot of details. Normally, i would have explained
things, but this is one of the reasons we are not moving fast.
Please go back onto the thread and read again then summarize.

cheers,
jamal
--------------050208020308060206070807-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 11:59:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08609 for ; Tue, 9 Mar 2004 11:59:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kZ6-0000fx-Pw for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 11:58:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Gwm22002591 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 11:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kZ6-0000fi-I8 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08560 for ; Tue, 9 Mar 2004 11:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kZ5-0004lK-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kYD-0004Y4-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:57:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0kXN-0004KX-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 11:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kXN-0000Ym-Cu; Tue, 09 Mar 2004 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kX7-0000XW-3O for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 11:56:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08321 for ; Tue, 9 Mar 2004 11:56:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kX5-0004I1-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:56:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kW3-00042T-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:55:40 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0kV6-0003kF-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 11:54:41 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030908551671:65966 ; Tue, 9 Mar 2004 08:55:16 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org In-Reply-To: <404DF1E5.4090106@alcatel.com> References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> <404DE523.4030703@alcatel.com> <1078848212.1038.616.camel@jzny.localdomain> <404DF1E5.4090106@alcatel.com> Organization: ZNYX Networks Message-Id: <1078851272.1038.648.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 03/09/2004 08:55:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 08:55:19 AM, Serialize complete at 03/09/2004 08:55:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Re: Progress Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 11:54:32 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-09 at 11:33, Alex Audu wrote: > Hi Jamal, > > I think Hormuzd is a good moderator (from experience in our design > meetings). We could have someone else do it,..if you object. I dont object to Hormuzd or yourself for that matter. You are not pointing whats wrong with the current process such that we need a moderator. The main issue as i see it is we have a short period of time. What we need is fast ontopic responses foremost not a moderator. > The other issue I'd like to raise is please, let us cut through the > chase and go straight to the > point. Some of the e-mails are really getting too long. Thats good feedback. I will try to cut down on the long emails. I will split my emails onto different smaller ones whenever i can. On your part, can you cut down on not syncing up with threads before pitching in with a sentence that misses the 90% of the email? > We have our full-time jobs you know. Trust me as someone who works for a small company in the current economy i am way overworked;-> But i am still making time for this so we can make progress. > You can be brief and be understandable. I think they call that > succinctness. I will try my best and so should you. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 12:09:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09131 for ; Tue, 9 Mar 2004 12:09:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kil-00021c-T1 for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 12:08:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29H8lPX007778 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 12:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kil-00021N-OC for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 12:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09100 for ; Tue, 9 Mar 2004 12:08:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kik-0006ff-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:08:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0khs-0006VD-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:07:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0kh4-0006Kq-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kh4-0001gG-0J; Tue, 09 Mar 2004 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kgv-0001cd-Qi for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 12:06:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08999 for ; Tue, 9 Mar 2004 12:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kgu-0006JK-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:06:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kft-000685-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:05:50 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0kf4-0005n4-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:04:58 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i29H6H0f022394; Tue, 9 Mar 2004 17:06:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i29Gvi2w009092; Tue, 9 Mar 2004 16:58:19 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030909040701423 ; Tue, 09 Mar 2004 09:04:07 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Mar 2004 09:04: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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQFDh3C5ffb4KqDQv2zEl1YcxybUAAzaqsw From: "Putzolu, David" To: , X-OriginalArrivalTime: 09 Mar 2004 17:04:07.0339 (UTC) FILETIME=[8880D7B0:01C405F8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 09:04:06 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal. I think this was the email you where asking for a response to - my response inline :)=20 Jamal wrote > > Figure2 shows the role of the FEC; it MAY manages one or more LFBs. > The communication mechanism used there is again beyond the scope of > ForCES. I agree, this is implementation specific. Also, the figures where=20 a good idea & good way to get the point across. > Messages arriving at either of the sockets could end up in=20 > two sorts of > general classes of destinations: > 1) for the FE - in which they are serviced by the netlink2 daemon. > 2) for any of FEC0 to FECx; in that case the netlink2 daemon=20 > multiplexes them to those entities. Agreed. > As an example, there may be a FEC which controls several LFBs;=20 > Another example is an FEC which sends and receives OSPF hellos. > Each FEC has a counterpart which understands it on the CE side. > The CE piece of OSPF (call it CEC) sends messages to > a specific PID when it wants to talk to the FEC portion (the hello > offloader). > As you can see this is application talking to another application; > this could be looked at as essentially IPC. Therefore the=20 > concept of PID > is useful. My impression is that the existance of FECs is implementation specific - i.e. one implementation may have different processes implementing forwarding. Another may contain all forwarding in the same process as the one receiving ForCES messages, and another may have one process per LFB. The ForCES daemon FEd (that received the ForCES messages over the wire) would either: i) consume & act on the message if it is a FE-wide message (although it might call some admin process under the covers - again implementation specific) ii) Look at the LFB the message is addressed to, and based on that, hand the message to the right LFB, or to the right process that owns the LFB. If multiple LFBs are addressed in a single message, it might deliver the relevant parts of the message to each LFB/LFB container process. So the FEd would probably have a table of LFB --> (how to contact process|which API to invoke|what file to write|etc) Not sure if I am disagreeing with you here or not - trying to elaborate to see if we have the same idea here :) > I think we all agree on the broadcast or multicast to a specific > type of entities. >=20 > >>- a set of LFBs on an FE > > - a set of LFBs on different FEs=20 > >=20 > > [Wang Re: Are the set of LFBs of the same type?] >=20 > Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". It sounds like there are two different kinds of addressing being proposed here: i) Single LFB unicasting - this message should only be received by/acted on by a single FE in the entire NE ii) Type-based broadcasting - this message should be received/ acted on by all LFBs of a specific type I think there is another kind of addressing needed - call it type-based multicasting: This message should be received/ acted on by a subset of all LFBs of some type. As an example, consider a router that has several line cards, all of which have an instance of the IPv4 forwarding LFB performing=20 forwarding for Internet traffic, and one of the line cards has an IPv4 forwarding LFB instance performing forwarding on a company intranet using private addressing. =20 > > - proxies for LFBs, > > - proxies for control application in the form on the CEs,=20 > >=20 > > [Wang Re: If ever we have these proxies, are they need to=20 > be seen at the protocol layer?=20 >=20 > No, there is nothing speacial needed at the protocol header. The list=20 > was an exhaustive example. >=20 > > Moreover, how about FE proxies then?] >=20 > They dont need to be addressed by anything speacial in the header. I agree, proxies should be indistinguishable from the thing they are proxying for. > [HK] Could you give me an example of why this is limiting?=20 >=20 > I was refering to the fact that you have a single ID to address > entities within an FE or CE. In my diagram i am rtying to show theres > more than one class of end targets. So calling it CEID or FEID > is limiting. Is this same ID used to identify LFBs as well? I guess I'm not sure what is the right way to do this. If everything is in the same namespace, name collisions need to be=20 managed (e.g. making sure two entities don't pick the same ID for themself). > > I would like > > to know if using 16 bits would break in some scenarios. If=20 > this was part > > of a TLV I wouldn't care as much, but since this is the=20 > common header, I > > am a bit concerned...acting stingy :-)) > .. >=20 > [HK] Exactly, ForCES has much limited/specific scope (NE) than general > > purpose middleware such as Corba. You cannot compare these=20 > 2 because of > > the difference in scope. >=20 > I gave the historical experience of PCs (by quoting a naive=20 > bill gates),=20 > IPV4(by making a mockery over the famous last words that=20 > brought IPV6 to=20 > the world) and now i can add the experience of unix which=20 > would have=20 > been more interesting with 64 bit PIDs. > Summary: Nothing would break; however it is useful to learn=20 > from history > and say lets go with something larger. I can't remember what the 16 bits are referring to. If it is referring to commands that can be issued to a FE (as opposed to LFBs) then I think 16 bits is enough, simply because I think humans are too lazy to come up with 2^16 different FE commands.=20 -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 12:52:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11633 for ; Tue, 9 Mar 2004 12:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lOV-0004rE-IT for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 12:51:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Hptal018666 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 12:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lOV-0004qz-B2 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 12:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11615 for ; Tue, 9 Mar 2004 12:51:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lOT-0007mx-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:51:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lNV-0007Z1-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:50:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0lMf-0007L7-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 12:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lMg-0004gP-G5; Tue, 09 Mar 2004 12:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lLy-0004Zt-UC for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 12:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11294 for ; Tue, 9 Mar 2004 12:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lLx-00078h-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:49:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lL0-0006uV-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:48:19 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0lKE-0006hA-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 12:47:30 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030909480676:66028 ; Tue, 9 Mar 2004 09:48:06 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078854444.1040.679.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 03/09/2004 09:48:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 09:48:08 AM, Serialize complete at 03/09/2004 09:48:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 12:47:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Thanks for taking the time. On Tue, 2004-03-09 at 12:04, Putzolu, David wrote: > Hi Jamal. > > I think this was the email you where asking for a response > to - my response inline :) Yes, this is it;-> > Jamal wrote > [Reducing size of email as much as possible as promised; alos breaking this into two emails] > My impression is that the existance of FECs is implementation > specific - absolutely; the idea i had was to share an experience to explain the value for IDs: That a single FE could have multiple addressable targets. > The ForCES daemon FEd (that received the ForCES messages over the wire) > would either: > i) consume & act on the message if it is a FE-wide message > (although it might call some admin process under the covers - > again implementation specific) correct. > ii) Look at the LFB the message is addressed to, and based > on that, hand the message to the right LFB, or to the right > process that owns the LFB. If multiple LFBs are addressed > in a single message, it might deliver the relevant parts of > the message to each LFB/LFB container process. So the FEd > would probably have a table of LFB --> (how to contact > process|which API to invoke|what file to write|etc) Correct. Again implementation details; bottom line of the example was to show the value of the PID and that it means several processes/threads etc are addressed within a CE/FE. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 13:08:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12643 for ; Tue, 9 Mar 2004 13:08:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ldr-00060K-PT for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 13:07:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29I7lko023068 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 13:07:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ldr-0005zx-CY for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 13:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12608 for ; Tue, 9 Mar 2004 13:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ldp-0003XO-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 13:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lcz-0003Ma-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 13:06:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0lc8-0003B2-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 13:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lc9-0005iy-Qy; Tue, 09 Mar 2004 13:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lbq-0005fr-JR for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 13:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12488 for ; Tue, 9 Mar 2004 13:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lbo-00037m-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 13:05:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0laq-0002vM-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 13:04:40 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0lZr-0002fM-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 13:03:39 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030910041553:66054 ; Tue, 9 Mar 2004 10:04:15 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078855411.1038.698.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 03/09/2004 10:04:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 10:04:17 AM, Serialize complete at 03/09/2004 10:04:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 13:03:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-09 at 12:04, Putzolu, David wrote: > It sounds like there are two different kinds of addressing > being proposed here: > i) Single LFB unicasting - this message should only be > received by/acted on by a single FE in the entire NE To be precise message is received by a single entity since there could be multiple entities in the FE. > ii) Type-based broadcasting - this message should be received/ > acted on by all LFBs of a specific type right. All bcast could be directed at the FEs or CEs without being meant to be for a LFB processing. I could provide examples. > I think there is another kind of addressing needed - call > it type-based multicasting: This message should be received/ > acted on by a subset of all LFBs of some type. Ok, never thought of this one. We didnt implement this but it is valuable. > Is this same ID used to identify LFBs as well? I guess > I'm not sure what is the right way to do this. If everything > is in the same namespace, name collisions need to be > managed (e.g. making sure two entities don't pick the > same ID for themself). I was trying to avoid refering to LFBs with the PID and rather restrict the PID to some OS-process/app such as an FEC. The identity of an LFB class would be the type field; this way a single OS process may handle multiple LFB classes. Let me provide an example walk: 1) FEd receives message. Based on dst PID sends it to the right location (an app like FEC for example) or consumes it. 2) FEC validates that it can process that message and understands what LFB/LFBs to muck with. 3) The decoded TLVs further reference entities within an LFB class i.e an LFB class essentially owns multiple instances of that LFB type. FEC now configures LFB. Now of course you could take the LFB instances such as an index of a nh table and give that a NE-universal id; but that would require a huge address space (maybe 128 bits may be insufficient). Collision resolution can be discussed later; i can explain how we did it but it is not going to add much value. > > Summary: Nothing would break; however it is useful to learn > > from history > > and say lets go with something larger. > > I can't remember what the 16 bits are referring to. > If it is referring to commands that can be issued to > a FE (as opposed to LFBs) then I think 16 bits is > enough, simply because I think humans are too lazy > to come up with 2^16 different FE commands. reference was to the ID field in the header. My opinion is given that there is possibility of addressing several processes per FE/CE, then no harm in using 32 bits. Again, bottom line of what i was trying to get through: - The different addressing schemes in previous email - That 32 bit ID was reasonable - That this was one way to implement without trying to enforce it on anyone. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 9 14:25:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16332 for ; Tue, 9 Mar 2004 14:25:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mqS-0002s0-42 for forces-protocol-archive@odin.ietf.org; Tue, 09 Mar 2004 14:24:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29JOqU5011031 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 14:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mqR-0002rq-V5 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 14:24:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16318 for ; Tue, 9 Mar 2004 14:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0mqP-00024X-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 14:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0mpT-0001uG-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 14:23:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0mod-0001j6-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 14:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mof-0002hk-7v; Tue, 09 Mar 2004 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0moX-0002hJ-7R for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 14:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16168 for ; Tue, 9 Mar 2004 14:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0moU-0001hX-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 14:22:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0mnP-0001UV-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 14:21:44 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0mmQ-0001BU-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 14:20:42 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i29JNhst002044; Tue, 9 Mar 2004 19:23:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i29JL9a5010548; Tue, 9 Mar 2004 19:21:48 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030911195618534 ; Tue, 09 Mar 2004 11:19:56 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Mar 2004 11:19:57 -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 Subject: RE: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E160ABF@orsmsx408.jf.intel.com> Thread-Topic: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQFzab3qYhKP5+8Sgy9hxowzZZHwAAPLXyQ From: "Khosravi, Hormuzd M" To: , "Putzolu, David" Cc: , X-OriginalArrivalTime: 09 Mar 2004 19:19:57.0379 (UTC) FILETIME=[824E4130:01C4060B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 11:19:56 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, I apologize for not having responded on issue 0, 1 yet. I had an early morning meeting today but will do this by end of day today. Just one thing, I don't think we need to get all the issues resolved by this deadline. We can complete the first few issues and send the results of that to the list. I had already sent out the list of high level principles that we all agree on and with a few mods we can forward that list to the forces wg as well. I agree with you that its important to get the header resolved first, this is a good exercise to see if we can reach some reasonable compromise. Regards Hormuzd=20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > Avri wrote > > > I have a general question about headers, is there any feeling in this=20 > > group that a common header could not be arrived at. If not then we=20 > > could move on to other issues. The reason I ask is that one=20 > > can spend=20 > > a whole lot of time fine tuning a header to be just right. If there > > are as of yet unresolved issues on the header, can anyone list them? >=20 > I agree with Avri,=20 On the one hand i wanna say lets skip so we can make progress. OTOH, I am a little worried that the gaps in point of view are so huge that this will cause problems later.=20 The only way we can close faster is if ontopic emails are addressed in the fastest possible way. On a personal level i am trying to prioritize responding to things on this list. But sometime i get a little discouraged. Example my last emails on topic 0 and topic 1 have not been responded to for at least 24 hours. Actually they have been a response which happens to be off topic. This worries me because i dont think we will make the deadline. If theres 10-12 serious issues and we have about 10 days to go AND we havent closed a single issue up to now --> theres _no way_=20 we can meet the deadline. We need to close 2 issues a day. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 03:08:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25232 for ; Wed, 10 Mar 2004 03:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ylP-0000j9-7f for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:08:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A88QmO002784 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:08:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ylN-0000ia-1V for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:08:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25223 for ; Wed, 10 Mar 2004 03:08:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ylJ-0003RK-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ykL-0003IB-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:07:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0yjy-00039f-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yk1-0000Uh-5e; Wed, 10 Mar 2004 03:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yjO-0000Td-DJ for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 03:06:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25192 for ; Wed, 10 Mar 2004 03:06:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0yjK-00038s-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0yiM-00030x-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:05:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0yhq-0002sm-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:04:46 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0yhr-0004cZ-R5 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:04:48 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 10 Mar 2004 16:04:41 +0800 Message-ID: <0de801c40674$75badcd0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> <1078830604.1036.546.camel@jzny.localdomain> <404DEB0E.50400@alcatel.com> <1078849006.1038.625.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Progress issue 1: packet encoding 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:51:13 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I agree to currently close issue 1. I think it is quite probable to reach an agreement on this issue when we write a draft, because there are no essential differences among the ideas. I evaluate the result for this issue as "an ageement can be reached in the future with the probability of 90%". Now the actual problem lies in the issue 0, that is to use a uniform PID or a tree structured FE ID: LFB ID: LFB Instance ID resolution for the addressing. The issue 0 needs more discussion before being closed because the difference there is very essential for the protocol. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Cc: "Putzolu, David" ; ; Sent: Wednesday, March 10, 2004 12:16 AM Subject: [Forces-protocol] Re: Progress issue 1: packet encoding > > This is a common trick. I thought both FACT and GRMP have it. > Netlink2 for example has a special command for errors. > The body will contain an error code and the offending original > header (similar to ICMP source quench). > > These are issues we can settle. Can we please close topic 1? > > cheers, > jamal > > On Tue, 2004-03-09 at 11:04, Alex Audu wrote: > > On Issue 1: packet encoding, it is easy to come to concensus on this > > one. So far, the train > > thoughts is per the attachment to this e-mail. > > > > Issues raised: > > 1) Avri raised issue of indicating an error with an error flag on the > > header. > > > > Comment: That is certainly one way to convey error conditions. But > > experience has > > shown that if you do that, you force your protocol software to check > > this flag for every > > message that comes in (to ascertain if it is error message or not), > > before proceeding. This > > is an incredible wate of processor cycles since an error condition is > > really an exception > > condition. > > > > Carrying an error indication with an error TLV is much better. It is > > like an error color > > code; you only do error processing if that color shows up. And all > > the other messages > > are handled similarly. This could easily be the difference between a > > protocol that is > > twice as fast and efficient compared to an otherwise poorly designed > > one. > > > > Regards, > > Alex. > > > > > > > > > > Jamal Hadi Salim wrote: > > > On Tue, 2004-03-09 at 01:42, Putzolu, David wrote: > > > > > > > Avri wrote > > > > > > > > > > I have a general question about headers, is there any feeling in this > > > > > group that a common header could not be arrived at. If not then we > > > > > could move on to other issues. The reason I ask is that one > > > > > can spend > > > > > a whole lot of time fine tuning a header to be just right. If there > > > > > are as of yet unresolved issues on the header, can anyone list them? > > > > > > > > > > > > > I agree with Avri, > > > > > > > > > > On the one hand i wanna say lets skip so we can make progress. > > > OTOH, I am a little worried that the gaps in point of view > > > are so huge that this will cause problems later. > > > The only way we can close faster is if ontopic emails are addressed in > > > the fastest possible way. > > > > > > On a personal level i am trying to prioritize responding to things > > > on this list. But sometime i get a little discouraged. Example my last > > > emails on topic 0 and topic 1 have not been responded to for at least > > > 24 hours. Actually they have been a response which happens to be off > > > topic. This worries me because i dont think we will make the deadline. > > > If theres 10-12 serious issues and we have about 10 days to go > > > AND we havent closed a single issue up to now --> theres _no way_ > > > we can meet the deadline. We need to close 2 issues a day. > > > > > > Of course a brute force solution is to say theres desire to reach a > > > compromise and stop there. But this in itself is dangerous and i > > > would not prefer to go that route. > > > > > > So at the moment i am at a loss. Maybe the approach of listing issues > > > which need to be agreed on is not the right one? What thoughts do people > > > have on this? Other proposals that have been made so far that received > > > no traction are: > > > a) each protocol draft to list what they cant live without, > > > b) Each protocol draft to list their implementation experiences and > > > say what they found useful and what wasnt. > > > > > > > > > > and like others I am having a hard time > > > > keeping up with all the different discussions. > > > > > > > > > > Yes, this has been an issue but is general to any email or usent > > > discussuions - problem is someone starts going off > > > topic then other people respond. And the cycle continues. > > > > > > The best way to run "meetings" over email are: > > > > > > Rule 0: have an agenda (list of topics to discuss). We have this > > > Rule 1 is to have a running topic (eg currently issue 1 and 0 are > > > ontopic). No other topic is to be discussed. We are trying this. > > > Rule 2 is not to respond to currently-offtopic emails. This is typically > > > the easiest rule to break on email or usenet because of human nature. > > > Naturally this has been the most broken rule. > > > Rule 3 is once in a while people need to be reminded they are off topic. > > > (I have tried to do this in personal emails as well as on the list.) > > > Rule 4 is if the content does not reflect the subject line, change the > > > subject line (like i just did with this email). > > > > > > I could almost say we are getting close to following the above; I > > > counted and only 2 emails were offtopic out of last 6 as opposed to > > > 6 out 10 before that. > > > > > > cheers, > > > jamal > > > > > > > > > _______________________________________________ > > > Forces-protocol mailing list > > > Forces-protocol@ietf.org > > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > > > > > ______________________________________________________________________ > > > > I don't know what the flags could be used for. The TypeID could be used for > > siganling the type of data encoding explicitly, (i.e. XML, ASN.1 etc). > > My preference will be the following. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > 0 1 2 3 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |vers |eType | prio| reservd | msgClass | msgType | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | message length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Source xID | Destination xID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > 1) version # indicates the version of the protocol. > > 2) the type of encoding comes next. > > 3) the priority of the message comes next. > > 4) the command has been divided into message class and type to ease management and handling. > > 5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool! > > 6) the length is now 32 bits long. This will accommodate flow measurement messages which > > tend to be huge, from FE to CE. It will also accommodate large table dumps from CE to > > FE. > > 7) then comes the sequence number. > > > > Any comments? > > > > Regards, > > Alex. > > > > > Jamal, > > > > > > Before I give my comments, I would like to say that I appreciate the > > > fact that you did not copy/paste the netlink header from your draft over > > > here! That is a very positive sign to me, lets try to stick to the best > > > technical solution rather than pushing our own protocol implementations. > > > That's the best way to make progress on this merger!! > > > > > > Here are my views on this issue, particularly the common header: > > > > > > Command: Agree this is needed. We think 8-12 bits will be more than > > > sufficient for this depending on whether it is subdivided. We have > > > sub-divided this field into Class/type...this is an OO approach, seemed > > > pretty neat. However, I am personally fine with having a single field > > > for this, no problem with that. > > > > > > Length: Agree needed and agree with size. > > > > > > xIDs: Agree this is needed. More detailed comments on length, semantics > > > in my previous email. > > > > > > Sequence No: Agree needed and agree with size. > > > > > > Flags/Priority: We need 2-3 bits for priority in every message. I don't > > > think we need any other flags in all messages. > > > > > > Typeid: This is one field I don't think is needed in all messages. I am > > > not sure why this is needed at all cause, we will be using the Model and > > > LFB IDs to address processing functional blocks on the FEs. > > > > > > Missing field: Version (2-4 bits): This is present in all protocols, and > > > is generally included in most IETF protocols. Its usually the 1st field. > > > > > > General comment: Lets try to be stingy on the size of the header and its > > > fields since this will be included in all ForCES messages. > > > > > > Jamal's text....... > > > The Forces Message Header: > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > 0 1 2 3 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Command | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Source xID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Destination xID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Sequence Number | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | flags | typeid | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > XML encoding: > > > XML encoding may be useful in capabilities definition > > > (i.e slow path) but not in the configuration of data path tables. > > > This is because of its nature to require higher bandwith and > > > CPU computational needs. > > > > > > HK Comment: I think we should stick with a single encoding type, namely > > > TLV. This is also what some of the model team folks have mentioned > > > before for the protocol. Is there a reason why capabilities cannot be > > > expressed using TLVs? > > > > > > > > > Thanks > > > Hormu > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 03:25:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25710 for ; Wed, 10 Mar 2004 03:25:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z1l-0001sx-L8 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:25:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8PL7o007236 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z1k-0001sd-9M for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25705 for ; Wed, 10 Mar 2004 03:25:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0z1i-00060K-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0z0o-0005sK-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:24:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0z0S-0005jw-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z0T-0001nI-Rl; Wed, 10 Mar 2004 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yzn-0001mF-Lu for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 03:23:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25662 for ; Wed, 10 Mar 2004 03:23:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0yzl-0005iD-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:23:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0yyp-0005Zc-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:22:20 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0yxx-0005JA-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:21:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2A8OfOC009994; Wed, 10 Mar 2004 08:24:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2A8MhAR019647; Wed, 10 Mar 2004 08:22:46 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031000205228475 ; Wed, 10 Mar 2004 00:20:52 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 00:20: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 Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E1BAED6@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQFEZTZ15dxy9OUTg6aOus5DhlVsQBX4dNQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 10 Mar 2004 08:20:52.0222 (UTC) FILETIME=[99F7E9E0:01C40678] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 00:20:52 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > [HK] Ok, we can resolve this later. So I guess you are fine with 8 bits > for the command? especially, if you only see a few of them. I am indifferent 8 bits may be sufficient; lets consider this one closed and revisit it later. [HK] Closed for now, but I have the same views as Weiming on this, we need more commands. >=20 > [HK] You need flags for this, however this is only for configuration > messages, they don't have to be in the common header. They will be part > of the config message TLV. As you said below... > "Agreed - the main thing is that if something needs to be used in all > messages then it should go on this header (since its cheaper than a > TLV)." I think we shouldnt hurry into getting rid of flags. They are used in all transaction type protocols i have come across. We used them extensively in _every_ message.=20 16 bit flags should suffice. If we are not in agreement i could go into semantics; [HK] We can reserve 16 bits for now (including 3 bits for priority, see below) and close this temporary. However we will have to revisit this to see if we agree on the semantics and if they will be useful for all messages. FACT and GRMP both don't have flags for transactional semantics in the common header, so this is definitely something which can go in the TLVs. > [HK] This is priority at the ForCES level which will eventually be > mapped to the underlying transport/interconnect. We definitely need it > at the ForCES level as well. Ok - closed. So how many bits do you see? [HK] 3 bits max. Let this be part of flags for now. > I am not sure i see this. If you could explain more mayeb it would help. > Like i said the only value is in being able to look at the outer header > and recognizing for example the target where the message is being sent > to (example LFB class). If not for anything else, debugging (via > sniffing) is a good reason - this way i could dump the rest of the > message by recognizing what the TLVs mean. >=20 > [HK] Debugging doesn't seem to be a good reason to me to add a field to > the common header. It has to be something very useful for the protocol > and all messages. What do others think about this one? >=20 I gave debugging as an example - and btw, it is a _very_ good reason to be able to debug protocols. The general idea is by inspecting the header i want to be able to tell what class of LFB it is going or coming from. If you can look at my earlier diagrams and tell me how you could see me decoding that message and identifying that LFB10 is a IPV4 forwarder then we could move on. [HK] I see limited value of this. How would it work if a single message were being addressed to multiple LFBs (command bundling)? I believe that we should separate LFB ID from FE ID and it should be part of TLVs rather than common header. See my email on issue 0. Does having LFB IDs as part of TLVs rather than common header break something ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 04:11:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25709 for ; Wed, 10 Mar 2004 03:25:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z1l-0001sv-KE for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:25:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8PLO7007230 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 03:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z1j-0001sP-Im for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:25:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25702 for ; Wed, 10 Mar 2004 03:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0z1h-00060F-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:25:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0z0n-0005sB-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:24:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0z0R-0005ju-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 03:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0z0T-0001n5-EY; Wed, 10 Mar 2004 03:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0yzm-0001mA-JP for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 03:23:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25654 for ; Wed, 10 Mar 2004 03:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0yzk-0005i3-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:23:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0yym-0005ZD-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:22:17 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B0yxt-0005J8-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 03:21:21 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2A8ObOC009955; Wed, 10 Mar 2004 08:24:37 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2A8Et0e020562; Wed, 10 Mar 2004 08:15:00 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031000205016100 ; Wed, 10 Mar 2004 00:20:50 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 00:20:50 -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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQFDh3iooC2FOfoTc6iFOhqeiu4xQBY/DBQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 10 Mar 2004 08:20:50.0686 (UTC) FILETIME=[990D89E0:01C40678] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 00:20:50 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal This issue is very fundamental and should be resolved before we move forward. I see what youre saying about FEC, CEC and remember having worked on these concepts while co-authoring the original netlink RFC with you. FEC or FE component is nothing but an abstraction of FE functionality just like LFBs. You seem to have distinguished them below giving a 1:n example but fundamentally both are abstractions. The ForCES WG and Model team have decided on using LFBs as a way to abstract FEs and we (protocol team) should stick to that. I don't see the value of adding another layer of abstraction over LFBs, your case for FEC/PID seems very implementation specific to me. Actually, I am surprised that you are bringing this up cause I remember the netlink2 team having clearly stated during one of your IETF presentations that you will be updating netlink2 terminology to be inline with the model and replace FEC with LFB in your draft, infact I believe you did this. Anyways, the other issue is of having LFB IDs or types in the common header. I don't think this is needed for the following reasons.. 1. Not all messages are addressed to LFBs 2. Some messages are addressed to multiple different LFBs (command bundling) 3. It's a good design practice to separate the LFB type/ID namespace from FE ID, CE ID namespace as David suggested. 4. I don't see how anything will break if LFB type/IDs are part of TLVs following the common header. I think there is a common understanding between the FACT and GRMP teams on this issue and I hope we can all reach a common view on this soon before moving forward. Regards=20 Hormuzd p.s. I am sure we will easily reach a conclusion on the length of the FE ID, CE ID once we agree on the semantics. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Monday, March 08, 2004 5:04 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing Hormuzd, Weiming, Apologies for long email; i am attempting to respond to two emails in one. Ok, let me provide an example of an FE (same concept applies at the CE).=20 Heres a diagram that may help to clarify what i have been refering to; note that netlink2 did not start like this, however over time implementation ended being like this; this shows an FE side implementation. I have attached the two diagrams so they dont get mangled. Figure 1. shows the netlink2 manager ( a s/ware daemon) managing two socket connections on the lower side labelled as wire0 and wire1 and entities called FECs on the upper side. Figure2 shows the role of the FEC; it MAY manages one or more LFBs. The communication mechanism used there is again beyond the scope of ForCES. Messages arriving at either of the sockets could end up in two sorts of general classes of destinations: 1) for the FE - in which they are serviced by the netlink2 daemon. 2) for any of FEC0 to FECx; in that case the netlink2 daemon multiplexes them to those entities. Although i only list two classes, there could be more - but thats beside the point. FECs are OS processes/applications. (How they communicate to the netlink2 daemon is beyond the scope of ForCES; lets say it could be a local OS IPC.) As an example, there may be a FEC which controls several LFBs;=20 Another example is an FEC which sends and receives OSPF hellos. Each FEC has a counterpart which understands it on the CE side. The CE piece of OSPF (call it CEC) sends messages to a specific PID when it wants to talk to the FEC portion (the hello offloader). As you can see this is application talking to another application; this could be looked at as essentially IPC. Therefore the concept of PID is useful. Now to address your emails: On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: Weiming, could you make sure your emails wrap around at 80 characters? It helps when i am trying to respond. > We think a layer-based tree structure according to the ForCES architecture=20 > is efficient to do such addressing. If we address entities at > the FE coarse layer ( to take the FE as a whole entity, which idea is also=20 > used by new version of FE model ), we only need to=20 > have a FE ID. =20 If i am not mistaken what you are talking about is a detail on how the address gets split; i.e you want to have a hierachical addressing - as an example you want to split the address above to FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). If this is the case, i think it is a small detail and we could move on and talk baout it later; if not please look at the diagram and=20 tell me how you would split the ID to configure LFB0. I actually have=20 a feeling your approach to this would be VERY different from Hormuzd ;-> > To address=20 > CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, LFB=20 > Instance broadcast, and CE broadcast, following addressing can be=20 > implemented: I think we all agree on the broadcast or multicast to a specific type of entities. >>- a set of LFBs on an FE > - a set of LFBs on different FEs=20 >=20 >=20 > [Wang Re: Are the set of LFBs of the same type?] Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > - proxies for LFBs, > - proxies for control application in the form on the CEs,=20 >=20 > [Wang Re: If ever we have these proxies, are they need to be seen at the=20 > protocol layer?=20 No, there is nothing speacial needed at the protocol header. The list=20 was an exhaustive example. > Moreover, how about FE proxies then?] They dont need to be addressed by anything speacial in the header. On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote:=20 > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go > with that terminology then? Lets talk about what needs to be addressed first before we jump to that. Refer to the two diagrams i sent. > [HK] I don't see the value of having an App ID in the common header. How > is it useful ? May be if you could give a good example of how this can > be used, it would help. The ForCES endpoints are CEs and FEs which > should be addressed in the common header. LFBs are like knobs on the FEs > used to program its functionality. I am sure you know all this very well > and I think most folks will agree on this. If we go with a different > view, we will probably land up breaking the FE Model as well. Other > views on this one ? Refer to the two diagrams i sent for an example, then lets discuss. [HK] Could you give me an example of why this is limiting?=20 I was refering to the fact that you have a single ID to address entities within an FE or CE. In my diagram i am rtying to show theres more than one class of end targets. So calling it CEID or FEID is limiting. > I would like > to know if using 16 bits would break in some scenarios. If this was part > of a TLV I wouldn't care as much, but since this is the common header, I > am a bit concerned...acting stingy :-)) .. [HK] Exactly, ForCES has much limited/specific scope (NE) than general > purpose middleware such as Corba. You cannot compare these 2 because of > the difference in scope. I gave the historical experience of PCs (by quoting a naive bill gates), IPV4(by making a mockery over the famous last words that brought IPV6 to the world) and now i can add the experience of unix which would have=20 been more interesting with 64 bit PIDs. Summary: Nothing would break; however it is useful to learn from history and say lets go with something larger. Again, apologies for long email; hopefully this would group things together. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 06:53:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04431 for ; Wed, 10 Mar 2004 06:53:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12GO-0002BN-VO for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 06:52:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ABqenv008385 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 06:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12GO-0002BA-Oa for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 06:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04414 for ; Wed, 10 Mar 2004 06:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12GK-000564-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 06:52:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12FI-0004w2-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 06:51:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B12Ej-0004nF-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 06:50:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12Em-0001zA-SH; Wed, 10 Mar 2004 06:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12Dt-0001rv-8N for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 06:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04312 for ; Wed, 10 Mar 2004 06:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12Dp-0004bj-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 06:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12Cx-0004NM-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 06:49:08 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B12C4-00048u-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 06:48:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031003484731:66883 ; Wed, 10 Mar 2004 03:48:47 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078919286.1037.837.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 03/10/2004 03:48:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 03:48:52 AM, Serialize complete at 03/10/2004 03:48:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 06:48:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote: > Hi Jamal > > This issue is very fundamental and should be resolved before we move > forward. I see what youre saying about FEC, CEC and remember having > worked on these concepts while co-authoring the original netlink RFC > with you. I can see where the confusion is. The names are maintained as in netlink (just like PID was) - the architecture described is NOT related to what is on netlink. I can change the name to FEA - for FE Application. However, this is an implementation detail (and i am not sure it even belongs in a draft). > FEC or FE component is nothing but an abstraction of FE functionality > just like LFBs. Its merely an implementation detail. The desire is to have multiple addressable entities. Given you saw it as a netlink FEC, i would suggest you revist my original posting (or just go by what i am describing here). > You seem to have distinguished them below giving a 1:n > example but fundamentally both are abstractions. The ForCES WG and Model > team have decided on using LFBs as a way to abstract FEs and we > (protocol team) should stick to that. Again, its an implementation (abstraction) detail. The closest thing (in modelling - not sure if it is in the model draft) an FEC comes to is a proxy for LFBs. Lets me ask this: how many _types_ of entities as addressable via the ID do you see? It seems to me you are saying theres only one (example the FE). Since the issue of the model draft keeps coming up, heres my opinion: I honestly dont care what the model draft says; it should be used as a guideline and not as dogma - we are here to decide on a good design of a ForCES protocol; if theres something that needs fixing on the model draft then it should be fixed. I dont see this issue as something that would need to be fixed on that draft. > I don't see the value of adding > another layer of abstraction over LFBs, your case for FEC/PID seems very > implementation specific to me. > Actually, I am surprised that you are bringing this up cause I remember > the netlink2 team having clearly stated during one of your IETF > presentations that you will be updating netlink2 terminology to be > inline with the model and replace FEC with LFB in your draft, infact I > believe you did this. > This detail was not on the Netlink2 draft. Grab the last netlink2 draft and grep for FEC and you will not see a single occurance. LFB is NOT an FEC. FEC is an application that is NOT on the data path. LFB is on the datapath. Can you clarify how you implemented? Maybe this would help. >From your email i am coming to the conclusion that our main difference seems to be the target of the destination of the ID. In your view theres only one class of destination, the members of the class being either an FE or CE. In my view i see it as an application (in the same philosphy as TCP/UDP ports) and there could be many of those in the FE or CE. I think we can make progress if at least see our differences; did i capture your opinion correctly? I will split the email here for readability. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 07:06:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04726 for ; Wed, 10 Mar 2004 07:06:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12Su-0003O2-IN for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:05:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AC5a9R013012 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:05:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12Su-0003Nn-E8 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 07:05:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04722 for ; Wed, 10 Mar 2004 07:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12Sq-0006zF-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:05:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12Rr-0006qT-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:04:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B12RJ-0006hx-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:03:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12RN-0003Lu-5g; Wed, 10 Mar 2004 07:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12R0-0003An-KP for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 07:03:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04683 for ; Wed, 10 Mar 2004 07:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12Qw-0006hC-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:03:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12Pw-0006Yb-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:02:32 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B12Pc-0006QB-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:02:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031004004675:66890 ; Wed, 10 Mar 2004 04:00:46 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078920001.1040.850.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 03/10/2004 04:00:47 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 04:02:51 AM, Serialize complete at 03/10/2004 04:02:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 07:00:01 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Part 2. On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote: > > Anyways, the other issue is of having LFB IDs or types in the common > header. I said no such thing. I think you may be thinking of Weiming who has suggested the target of an ID as [FE ID: LFB ID: LFB Instance ID] > I don't think this is needed for the following reasons.. > 1. Not all messages are addressed to LFBs > 2. Some messages are addressed to multiple different LFBs (command > bundling) > 3. It's a good design practice to separate the LFB type/ID namespace > from FE ID, CE ID namespace as David suggested. > 4. I don't see how anything will break if LFB type/IDs are part of TLVs > following the common header. I think it is becoming clear that our diference maybe what is the target of the ID. Can you clarify how many _types_ of targets do you see addressable. Weiming, can you clarify on your side as well? I think this will help us settle faster. > I think there is a common understanding between the FACT and GRMP teams > on this issue You keep saying this but i dont think theres any commonality between you and GRMP on this issue;-> You may have missed Weiming saying things are addressed by: [FE ID: LFB ID: LFB Instance ID] > and I hope we can all reach a common view on this soon > before moving forward. Indeed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 07:16:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05051 for ; Wed, 10 Mar 2004 07:16:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12cc-0005Gc-Lb for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:15:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ACFcQW020240 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:15:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12cc-0005GN-Gg for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 07:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05036 for ; Wed, 10 Mar 2004 07:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12cc-0000ks-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12bh-0000ah-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:14:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B12b3-0000QY-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12b3-00054E-9y; Wed, 10 Mar 2004 07:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12aZ-00052h-Ai for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 07:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04919 for ; Wed, 10 Mar 2004 07:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12aY-0000Op-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:13:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12Ze-0000FO-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:12:35 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B12Yx-00006M-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:11: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 2004031004122950:66897 ; Wed, 10 Mar 2004 04:12:29 -0800 Subject: RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BAED6@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BAED6@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078920703.1037.860.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 03/10/2004 04:12:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 04:12:30 AM, Serialize complete at 03/10/2004 04:12:30 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 07:11:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > I gave debugging as an example - and btw, it is a _very_ good reason > to be able to debug protocols. > The general idea is by inspecting the header i want to be able to tell > what class of LFB it is going or coming from. > If you can look at my earlier diagrams and tell me how you could see me > decoding that message and identifying that LFB10 is a IPV4 forwarder > then we could move on. > > [HK] I see limited value of this. How would it work if a single message > were being addressed to multiple LFBs (command bundling)? I believe that > we should separate LFB ID from FE ID and it should be part of TLVs > rather than common header. See my email on issue 0. Does having LFB IDs > as part of TLVs rather than common header break something ? I believe this issue will be resolved once we resolve issue 0. Note also Weiming and I had a discussion on the batching issue which we can go into later. LFB identification belongs to the message body, not the header. The idea of the type is to ID the message which i believe is important not just for debuggability. I described a rx packet walk to David repeated here for clarity. ------ 1) FEd receives message. Based on dst PID sends it to the right location (an app like FEC for example) or consumes it. 2) FEC validates that it can process that message and understands the LFB class (based on type) and what LFB/LFBs to muck with. 3) The decoded TLVs further reference entities within an LFB class i.e an LFB class essentially owns multiple instances of that LFB type. FEC now configures LFB. Now of course you could take the LFB instances such as an index of a nh table and give that a NE-universal id; but that would require a huge address space (maybe 128 bits may be insufficient). Collision resolution can be discussed later; i can explain how we did it but it is not going to add much value. -------- Lets put issue 1 to rest. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 07:26:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05580 for ; Wed, 10 Mar 2004 07:26:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12mB-0005dR-R4 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:25:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ACPVPC021655 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 07:25:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12mB-0005d4-L7 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 07:25:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05566 for ; Wed, 10 Mar 2004 07:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12mB-0002Na-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12lC-0002E6-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:24:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B12ki-00025x-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 07:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12ki-0005bj-O6; Wed, 10 Mar 2004 07:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B12kE-0005ax-M8 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 07:23:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05478 for ; Wed, 10 Mar 2004 07:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B12kE-00025Q-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:23:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B12jI-0001wd-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:22:32 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B12iP-0001ni-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 07:21:37 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031004221377:66900 ; Wed, 10 Mar 2004 04:22:13 -0800 Subject: RE: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Putzolu, David" , avri@acm.org, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E160ABF@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E160ABF@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078921289.1037.870.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 03/10/2004 04:22:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 04:22:15 AM, Serialize complete at 03/10/2004 04:22:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 07:21:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Tue, 2004-03-09 at 14:19, Khosravi, Hormuzd M wrote: > Just one thing, I don't think we need to get all the issues resolved by > this deadline. We can complete the first few issues and send the results > of that to the list. I had already sent out the list of high level > principles that we all agree on and with a few mods we can forward that > list to the forces wg as well. I agree with you that its important to > get the header resolved first, this is a good exercise to see if we can > reach some reasonable compromise. > I agree with you on principle. I think we should target at least > 50% of the issues. Can we put priorities on them? Heres my take so far (P1 > P2) 0) ID on the header. P1 1) Encoding P1 - closed 2) Multiple channels/connections - P1- Hormuzd writting text 3) Transport: unicast/multicast/broadcast - P1 { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control - P2 (solvable - more insight from 2 and 3 above) 5) Reliability - P2 (solvable - more insight from 2 and 3 above) 6) Security - P2 (solvable) 7) High availability -P2 (contentious) 8) Capability exchange - P2 (solvable) 9) The FEM/CEM interface - P2 10) Support for vendor functions - P2 11) Cross check with model draft before it is published - P2 12) Master Slave or peer-peer? - P1 (mostly because it would be contentious; Avri to write text?) Hormuzd if you are not writting text for #2, I could. Let me know. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 08:11:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07032 for ; Wed, 10 Mar 2004 08:11:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13Tp-0000qV-8x for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 08:10:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ADAbVW003245 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 08:10:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13Tp-0000qG-3N for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 08:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07008 for ; Wed, 10 Mar 2004 08:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13To-00022j-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 08:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13T1-0001tu-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 08:09:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B13SH-0001jy-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 08:09:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B13SI-0001mx-7p for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 08:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13SG-0000eJ-R2; Wed, 10 Mar 2004 08:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13Rx-0000dC-SA for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 08:08:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06973 for ; Wed, 10 Mar 2004 08:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13Rw-0001ij-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 08:08:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13R3-0001Yb-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 08:07:46 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B13QY-0001Oe-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 08:07:16 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 10 Mar 2004 21:18:33 +0800 Message-ID: <0e5901c406a0$4e0522f0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> <1078854444.1040.679.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 21:05:04 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, Hormuzd, David, and all, As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID means. Firstly, I should say, there are two possible descriptions for such a tree structure: The first is to have it as a whole ID and put it at the ForCES message header, and at the receiver side to resolve it from the head to the tail. I'l call this as an explicit description. I think Jamal actually means this description. The second is to have it implicitly described in the ForCES messages. That is, for instance, to have FEID put in the message header and may have put LFBTypeID and LFBInstanceID in the message body if needed. I would say the second method is more flexible and reasonable, and what I mean is actually the second one. Then, I have a suggestion that how about Let's try to find out the disadvantages for the two differenct addressing ways(PIDs based and FEID:FETypeID:FEInstanceID based), so that we may compare which is better. Please alow me first to try to show some limitations when using PIDs based addressing: 1. In ForCES architecture, it has already assumed that FEs and CEs may be from different vendors. As a CE that uses ForCES protocol, it has no right to control how an FE is implemented. This means, one vendoer may prefer to have LFB1 and LFB2 managed by one process (or say FEC) while another vendor may have one process (FEC1) for LFB1 and another process(FEC2) for LFB2. I just wonder how in this case the PID will be uniformly arranged to address the both cases. 2. In the PIDs scheme, it seems there is no idea like LFB type used as addressing index, all LFBs are actually represented by their instance IDs (which are defined also as PIDs), and the instance IDs are globally defined within a NE. This has lead two unhappy things: 1) ForCES user shoud carefull arrange these IDs so that there are no conflict on the instance IDs in the NE. 2) This has made the broadcast/multicast that is based on LFB types quite difficult, I suppose David also means this. On the contrary, in the tree structured addressing, the LFBInstanceID is local in a LFB type in a FE. Different FEs may use the same LFB instances, and different LFBs can also use the same instance ID. Therefore it's quite easy to arrange this IDs. Moreover, the broadcast/multicast based on LFB types can be implemented very easily in the tree structure addressing just by the use of FETypeID along with the FE ID as addressing ID. 3. The PIDs scheme also has put more burden on CE. The CE then need to manage a quite big database of PIDs, which include all managable entities in all FEs as well as CEs, and the database is basically linearly strucutured. While in tree structure, the CE only needs to maintain a very simple database for entity addressing (therorically only need to resolve the FE ID), leaving many ID resolution tasks done by individual FEs. The cause the tree structure can achieve this advantage is it actually maps the ForCES FE framework structure well. Jamal, I truly hope you may also point out the limitations for the tree structured addressing way. In this way, I think we may be easier to reach an agreement. Yours, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Putzolu, David" Cc: Sent: Wednesday, March 10, 2004 1:47 AM Subject: RE: [Forces-protocol] Issue 0: Application addressing > David, > Thanks for taking the time. > > On Tue, 2004-03-09 at 12:04, Putzolu, David wrote: > > Hi Jamal. > > > > I think this was the email you where asking for a response > > to - my response inline :) > > Yes, this is it;-> > > > Jamal wrote > > [Reducing size of email as much as possible as promised; alos breaking > this into two emails] > > > My impression is that the existance of FECs is implementation > > specific - > > absolutely; the idea i had was to share an experience to explain > the value for IDs: That a single FE could have multiple addressable > targets. > > > The ForCES daemon FEd (that received the ForCES messages over the wire) > > would either: > > i) consume & act on the message if it is a FE-wide message > > (although it might call some admin process under the covers - > > again implementation specific) > > correct. > > > ii) Look at the LFB the message is addressed to, and based > > on that, hand the message to the right LFB, or to the right > > process that owns the LFB. If multiple LFBs are addressed > > in a single message, it might deliver the relevant parts of > > the message to each LFB/LFB container process. So the FEd > > would probably have a table of LFB --> (how to contact > > process|which API to invoke|what file to write|etc) > > Correct. Again implementation details; > bottom line of the example was to show the value > of the PID and that it means several processes/threads etc are addressed > within a CE/FE. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 13:31:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24778 for ; Wed, 10 Mar 2004 13:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Tk-0007wx-Ry for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 13:30:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIUqaV030554 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 13:30:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Tk-0007wg-Kf for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 13:30:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24731 for ; Wed, 10 Mar 2004 13:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Ti-0005ve-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 13:30:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Sn-0005mV-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 13:29:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18Rw-0005dc-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 13:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Rx-0007ir-Rd; Wed, 10 Mar 2004 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Rn-0007f3-Jr for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 13:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24659 for ; Wed, 10 Mar 2004 13:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Rl-0005cM-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 13:28:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Qx-0005TO-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 13:28:00 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B18QM-0005IL-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 13:27:22 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2AIUVOC015027; Wed, 10 Mar 2004 18:30:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2AIJX1G017027; Wed, 10 Mar 2004 18:20:46 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031010263519342 ; Wed, 10 Mar 2004 10:26:35 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 10:26:35 -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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB130@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQGoN9M+4+mVugbTJSwLwLVtbiKJQAK+mXA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 10 Mar 2004 18:26:35.0113 (UTC) FILETIME=[3804FD90:01C406CD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 10:26:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, Jamal, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID means. Firstly, I should say, there are two possible descriptions for such a tree structure: The first is to have it as a whole ID and put it at the ForCES message header, and at the receiver side to resolve it from the head to the tail. I'l call this as an explicit description. I think Jamal actually means this description. The second is to have it implicitly described in the ForCES messages. That is, for instance, to have FEID put in the message header and may have put LFBTypeID and LFBInstanceID in the message body if needed. I would say the second method is more flexible and reasonable, and what I mean is actually the second one. [HK] I definitely agree with Weiming on this addressing scheme and how to place it in the protocol. This is same as the FE Model and I don't see any issues with this scheme. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 14:03:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26544 for ; Wed, 10 Mar 2004 14:03:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18ym-00030L-KJ for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:02:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AJ2u3m011548 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18ym-00030B-EJ for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 14:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26522 for ; Wed, 10 Mar 2004 14:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18yk-0003Zp-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:02:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18xl-0003QO-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:01:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18wu-0003Hb-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18ww-0002wn-Kx; Wed, 10 Mar 2004 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18wh-0002w6-I9 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 14:00:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26467 for ; Wed, 10 Mar 2004 14:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18wf-0003Fp-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:00:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18vh-00036h-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 13:59:45 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B18uo-0002qV-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 13:58:51 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2AJ0JU1002401 for ; Wed, 10 Mar 2004 19:00:20 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2AIpQ0u009231 for ; Wed, 10 Mar 2004 18:52:19 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031010581116211 for ; Wed, 10 Mar 2004 10:58:11 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 10:58: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> Thread-Topic: Issue 0: Application addressing Thread-Index: AcQG0aDqdreJ8xPPSHqX8ru2qkcBbQ== From: "Deleganes, Ellen M" To: X-OriginalArrivalTime: 10 Mar 2004 18:58:10.0937 (UTC) FILETIME=[A204C690:01C406D1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Issue 0: Application addressing Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 10:58:10 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, I am still trying to understand the value of the extra layer of abstraction (application addressed by the PID) for addressing purposes. This implies that the FE capabilities are reported to the CE need to be expanded because in addition to the LFBs and topologies the FE can support, the CE also needs to understand the mapping of the PIDs to the applications on the FE, and which applications are responsible for which LFBs. Otherwise, the CE would not know which PID it needed to send a message to in order to configure an LFB or set of LFBs. The CE could address the LFBs directly through the schemes being proposed on the list. In some schemes, using a PID could be less efficient. For example, if you happen to want to configure all LFBs on the FE of a certain type the same way, this could require more messages using the PID-based scheme. In the case where multiple applications are controlling LFBs that belong to the same class, then you would have to send a message to each application. In the direct LFB addressing scheme, you would probably only have to send one message indicating the LFB type. I believe this is also a similar argument that Weiming was making in a previous email. For the purposes of configuring and controlling LFBs, I don't see the value of the PID. Perhaps you can elaborate further. Regards, Ellen=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 14:23:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27769 for ; Wed, 10 Mar 2004 14:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19I7-00052W-Vr for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:22:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AJMt17019371 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:22:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19I7-00052M-Qe for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 14:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27762 for ; Wed, 10 Mar 2004 14:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19I5-0007Ez-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:22:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19HB-000761-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:21:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B19GH-0006wp-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19GI-0004xm-Vy; Wed, 10 Mar 2004 14:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19GF-0004wg-Tc for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 14:21:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27626 for ; Wed, 10 Mar 2004 14:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19GD-0006w5-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:20:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19FO-0006mx-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:20:06 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B19Ew-0006cd-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:19:38 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2AJLCU1017135; Wed, 10 Mar 2004 19:21:12 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2AJCg0k026293; Wed, 10 Mar 2004 19:13:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031011185519813 ; Wed, 10 Mar 2004 11:18:55 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 11:18:55 -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 Subject: RE: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB221@orsmsx408.jf.intel.com> Thread-Topic: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQGmj026dBLiyShROuON06ZFfZZ6QAOa4Eg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 10 Mar 2004 19:18:55.0680 (UTC) FILETIME=[87F17C00:01C406D4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 11:18:55 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, I think we might get upto issue#5 at Max in the current time frame. And if we can resolve upto that, I think it will be a great achievement ! BTW, I don't think #7 HA will be contentious. Also, we might land up discussing #8 in the context of the 1-5. I will put together text for #2, but before that I would really like to resolve #0 since that is very basic and is needed to proceed forward with a common understanding. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, March 10, 2004 4:21 AM To: Khosravi, Hormuzd M Cc: Putzolu, David; avri@acm.org; forces-protocol@ietf.org Subject: RE: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding Hormuzd, On Tue, 2004-03-09 at 14:19, Khosravi, Hormuzd M wrote: > Just one thing, I don't think we need to get all the issues resolved by > this deadline. We can complete the first few issues and send the results > of that to the list. I had already sent out the list of high level > principles that we all agree on and with a few mods we can forward that > list to the forces wg as well. I agree with you that its important to > get the header resolved first, this is a good exercise to see if we can > reach some reasonable compromise. >=20 I agree with you on principle. I think we should target at least > 50% of the issues. Can we put priorities on them? Heres my take so far (P1 > P2) 0) ID on the header. P1=20 1) Encoding P1 - closed 2) Multiple channels/connections - P1- Hormuzd writting text 3) Transport: unicast/multicast/broadcast - P1=20 { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC}=20 4) Congestion control - P2 (solvable - more insight from 2 and 3 above) 5) Reliability - P2 (solvable - more insight from 2 and 3 above) 6) Security - P2 (solvable) 7) High availability -P2 (contentious) 8) Capability exchange - P2 (solvable) 9) The FEM/CEM interface - P2 10) Support for vendor functions - P2 11) Cross check with model draft before it is published - P2 12) Master Slave or peer-peer? - P1 (mostly because it would be contentious; Avri to write text?) Hormuzd if you are not writting text for #2, I could. Let me know. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 14:39:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28914 for ; Wed, 10 Mar 2004 14:39:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19Xw-0006XL-UN for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:39:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AJdGcw025126 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:39:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19Xw-0006XB-Or for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 14:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28897 for ; Wed, 10 Mar 2004 14:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19Xu-0002di-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:39:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19Wg-0002RA-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:37:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B19Vj-0002Hg-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19Vl-00063H-83; Wed, 10 Mar 2004 14:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19Vi-00062i-5f for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 14:36:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28808 for ; Wed, 10 Mar 2004 14:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19Vf-0002Gz-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:36:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19Ur-000284-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:36:06 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B19U5-0001wQ-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:35:17 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2AJapU1027525; Wed, 10 Mar 2004 19:36:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2AJRc1C005365; Wed, 10 Mar 2004 19:28:51 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031011344329907 ; Wed, 10 Mar 2004 11:34:43 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 11:34: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 Subject: RE: [Forces-protocol] issue 1: packet encoding Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB257@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] issue 1: packet encoding Thread-Index: AcQGmOBuvzADwnPyS+m0Y0FV5OyuzgAPMZVQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 10 Mar 2004 19:34:43.0217 (UTC) FILETIME=[BCB82810:01C406D6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 11:34:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > I gave debugging as an example - and btw, it is a _very_ good reason > to be able to debug protocols. > The general idea is by inspecting the header i want to be able to tell > what class of LFB it is going or coming from. > If you can look at my earlier diagrams and tell me how you could see me > decoding that message and identifying that LFB10 is a IPV4 forwarder > then we could move on. >=20 > [HK] I see limited value of this. How would it work if a single message > were being addressed to multiple LFBs (command bundling)? I believe that > we should separate LFB ID from FE ID and it should be part of TLVs > rather than common header. See my email on issue 0. Does having LFB IDs > as part of TLVs rather than common header break something ? I believe this issue will be resolved once we resolve issue 0. [HK] I agree, lets resolve issue 0. Note also Weiming and I had a discussion on the batching issue which we can go into later. LFB identification belongs to the message body, not the header.=20 [HK] Great, we agree on that then. The idea of the type is to ID the message which i believe is important not just for debuggability. [HK] I can live with a type field in the header, but I am sure you will realize eventually that this is redundant information and not needed in the header. Now of course you could take the LFB instances such as an index of a nh table and give that a NE-universal id; but that would require a huge address space (maybe 128 bits may be insufficient). [HK] Let me clarify something here...LFB type is something like IPv4 Fwdr, LFB ID identifies an instance of such an IPv4 Fwdr, thus it is a reference to a single IPv4 Fwd table on the FE. Individual instances in this table will be further identified using indexes or whatever the model team defines, inside this table/LFB. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 14:47:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29250 for ; Wed, 10 Mar 2004 14:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19fG-0007PM-Ul for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:46:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AJkoHx028470 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 14:46:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19fG-0007P7-Oq for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 14:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29195 for ; Wed, 10 Mar 2004 14:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19fE-0003vM-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19eL-0003mB-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:45:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B19dV-0003ds-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 14:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19dW-0007Hg-Os; Wed, 10 Mar 2004 14:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19dT-0007HD-Ca for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 14:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29088 for ; Wed, 10 Mar 2004 14:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19dQ-0003dS-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19cV-0003UF-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:44:01 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B19c5-0003JT-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:43:33 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2AJh1TN028595; Wed, 10 Mar 2004 13:43:01 -0600 (CST) Message-ID: <404F6FC4.5080500@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Khosravi, Hormuzd M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BAED5@orsmsx408.jf.intel.com> <1078919286.1037.837.camel@jzny.localdomain> In-Reply-To: <1078919286.1037.837.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------020603040506090600070604" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 13:43:00 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020603040506090600070604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamal, It seems you are proposing a way to address components all the way to process level? Hmm.. Here are some problems I see with that: 1) The number of proceses running in an FE and the corresponding Process IDs are are arbitrally assigned by the native OS on that FE. Thus, FEA from vendor A and FEB from vendor B providing the same capabilities will most probably have entirely different process ID maps while running. If your CE wants to address common LFBs in these FEs, which processID are you going to use in your header? 2) ProcessIDs are very low level identifiers. They probably map to certain ports, and based on the implementation , you can have more than process map onto the same port ID. This complicates the scenario even further. So,..why are we wasting all the bandwidth talking about addressing processes? It really has no value. Let the OS resolve what process gets what message. Regards, Alex. Jamal Hadi Salim wrote: >Hormuzd, > >On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote: > > >>Hi Jamal >> >>This issue is very fundamental and should be resolved before we move >>forward. I see what youre saying about FEC, CEC and remember having >>worked on these concepts while co-authoring the original netlink RFC >>with you. >> >> > >I can see where the confusion is. >The names are maintained as in netlink (just like PID was) - the >architecture described is NOT related to what is on netlink. > >I can change the name to FEA - for FE Application. However, >this is an implementation detail (and i am not sure it even belongs >in a draft). > > > >>FEC or FE component is nothing but an abstraction of FE functionality >>just like LFBs. >> >> > >Its merely an implementation detail. The desire >is to have multiple addressable entities. Given you saw it as a >netlink FEC, i would suggest you revist my original posting (or just >go by what i am describing here). > > > >>You seem to have distinguished them below giving a 1:n >>example but fundamentally both are abstractions. The ForCES WG and Model >>team have decided on using LFBs as a way to abstract FEs and we >>(protocol team) should stick to that. >> >> > >Again, its an implementation (abstraction) detail. The closest thing (in >modelling - not sure if it is in the model draft) an FEC comes to >is a proxy for LFBs. >Lets me ask this: how many _types_ of entities as addressable via the ID >do you see? It seems to me you are saying theres only one (example the >FE). > >Since the issue of the model draft keeps coming up, heres my opinion: >I honestly dont care what the model draft says; it should be used >as a guideline and not as dogma - we are here to decide on a good >design of a ForCES protocol; if theres something that needs fixing >on the model draft then it should be fixed. I dont see this issue >as something that would need to be fixed on that draft. > > > >>I don't see the value of adding >>another layer of abstraction over LFBs, your case for FEC/PID seems very >>implementation specific to me. >>Actually, I am surprised that you are bringing this up cause I remember >>the netlink2 team having clearly stated during one of your IETF >>presentations that you will be updating netlink2 terminology to be >>inline with the model and replace FEC with LFB in your draft, infact I >>believe you did this. >> >> >> > >This detail was not on the Netlink2 draft. Grab the last netlink2 draft >and grep for FEC and you will not see a single occurance. >LFB is NOT an FEC. FEC is an application that is NOT on the data path. >LFB is on the datapath. >Can you clarify how you implemented? Maybe this would help. > >>From your email i am coming to the conclusion that our main difference >seems to be the target of the destination of the ID. In your view theres >only one class of destination, the members of the class being either an >FE or CE. In my view i see it as an application (in the same philosphy >as TCP/UDP ports) and there could be many of those in the FE or CE. >I think we can make progress if at least see our differences; did >i capture your opinion correctly? > >I will split the email here for readability. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------020603040506090600070604 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal,

It seems you are proposing a way to address components all the way to process level?
Hmm..  Here are some problems I see with that:
1)  The number of proceses running in an FE and the corresponding Process IDs are
      are arbitrally  assigned by the native OS on that FE.  Thus, FEA from vendor A and
      FEB from vendor B providing the same capabilities will most probably have entirely
      different process ID maps while running. If your CE wants to address common LFBs
      in these FEs, which processID are you going to use in your header?

2)  ProcessIDs are very low level identifiers. They probably map to certain ports, and
      based on the implementation , you can have more than process map onto the same
      port ID.  This complicates the scenario even further.

So,..why are we wasting all the bandwidth talking about addressing processes?  It  really
has no value. Let the OS resolve what process gets what message.

Regards,
Alex.

Jamal Hadi Salim wrote:
Hormuzd,

On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote:
  
Hi Jamal

This issue is very fundamental and should be resolved before we move
forward. I see what youre saying about FEC, CEC and remember having
worked on these concepts while co-authoring the original netlink RFC
with you.
    

I can see where the confusion is.
The names are maintained as in netlink (just like PID was) - the
architecture described is NOT related to what is on netlink. 

I can change the name to FEA - for FE Application. However,
this is an implementation detail (and i am not sure it even belongs
in a draft).

  
FEC or FE component is nothing but an abstraction of FE functionality
just like LFBs. 
    

Its merely an implementation detail. The desire
is to have multiple addressable entities. Given you saw it as a
netlink FEC, i would suggest you revist my original posting (or just
go by what i am describing here).

  
You seem to have distinguished them below giving a 1:n
example but fundamentally both are abstractions. The ForCES WG and Model
team have decided on using LFBs as a way to abstract FEs and we
(protocol team) should stick to that. 
    

Again, its an implementation (abstraction) detail. The closest thing (in
modelling - not sure if it is in the model draft) an FEC comes to
is a proxy for LFBs. 
Lets me ask this: how many _types_ of entities as addressable via the ID
do you see? It seems to me you are saying theres only one (example the
FE).

Since the issue of the model draft keeps coming up, heres my opinion:
I honestly dont care what the model draft says; it should be used
as a guideline and not as dogma - we are here to decide on a good
design of a ForCES protocol; if theres something that needs fixing
on the model draft then it should be fixed. I dont see this issue
as something that would need to be fixed on that draft.

  
I don't see the value of adding
another layer of abstraction over LFBs, your case for FEC/PID seems very
implementation specific to me.
Actually, I am surprised that you are bringing this up cause I remember
the netlink2 team having clearly stated during one of your IETF
presentations that you will be updating netlink2 terminology to be
inline with the model and replace FEC with LFB in your draft, infact I
believe you did this.

    

This detail was not on the Netlink2 draft. Grab the last netlink2 draft
and grep for FEC and you will not see a single occurance.
LFB is NOT an FEC. FEC is an application that is NOT on the data path.
LFB is on the datapath. 
Can you clarify how you implemented? Maybe this would help. 

>From your email i am coming to the conclusion that our main difference
seems to be the target of the destination of the ID. In your view theres
only one class of destination, the members of the class being either an
FE or CE. In my view i see it as an application (in the same philosphy
as TCP/UDP ports) and there could be many of those in the FE or CE.
I think we can make progress if at least see our differences; did
i capture your opinion correctly?

I will split the email here for readability. 

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------020603040506090600070604-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 15:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00031 for ; Wed, 10 Mar 2004 15:03:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19uq-00034w-5i for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 15:03:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AK2uD0011832 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 15:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19up-00033a-Lv for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 15:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00017 for ; Wed, 10 Mar 2004 15:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19um-0006Vu-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 15:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19ty-0006Nk-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 15:02:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B19sx-0006EZ-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 15:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19sz-0001Ig-C4; Wed, 10 Mar 2004 15:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B19sn-0001AB-7l for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 15:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29897 for ; Wed, 10 Mar 2004 15:00:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19sk-0006CF-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 15:00:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19rl-00062w-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:59:47 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B19qm-0005mf-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 14:58:44 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2AJw2TN001033; Wed, 10 Mar 2004 13:58:08 -0600 (CST) Message-ID: <404F7349.3030708@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> <1078854444.1040.679.camel@jzny.localdomain> <0e5901c406a0$4e0522f0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <0e5901c406a0$4e0522f0$845c21d2@Necom.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------090803060809040003070806" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 13:58:01 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090803060809040003070806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Exactly! This is exactly the point I made in my previous e-mail. Alex. Wang,Weiming wrote: >Hi Jamal, Hormuzd, David, and all, > >As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID >means. >Firstly, I should say, there are two possible descriptions for such a tree >structure: >The first is to have it as a whole ID and put it at the ForCES message header, >and at the receiver side to resolve it from the head to the tail. I'l call this >as an explicit description. I think Jamal actually means this description. >The second is to have it implicitly described in the ForCES messages. That is, >for instance, to have FEID put in the message header and may have put LFBTypeID >and LFBInstanceID in the message body if needed. > >I would say the second method is more flexible and reasonable, and what I mean >is actually the second one. > >Then, I have a suggestion that how about Let's try to find out the disadvantages >for the two differenct addressing ways(PIDs based and FEID:FETypeID:FEInstanceID >based), so that we may compare which is better. > >Please alow me first to try to show some limitations when using PIDs based >addressing: > >1. In ForCES architecture, it has already assumed that FEs and CEs may be from >different vendors. As a CE that uses ForCES protocol, it has no right to control >how an FE is implemented. This means, one vendoer may prefer to have LFB1 and >LFB2 managed by one process (or say FEC) while another vendor may have one >process (FEC1) for LFB1 and another process(FEC2) for LFB2. I just wonder how in >this case the PID will be uniformly arranged to address the both cases. > >2. In the PIDs scheme, it seems there is no idea like LFB type used as >addressing index, all LFBs are actually represented by their instance IDs (which >are defined also as PIDs), and the instance IDs are globally defined within a >NE. This has lead two unhappy things: >1) ForCES user shoud carefull arrange these IDs so that there are no conflict on >the instance IDs in the NE. >2) This has made the broadcast/multicast that is based on LFB types quite >difficult, I suppose David also means this. >On the contrary, in the tree structured addressing, the LFBInstanceID is local >in a LFB type in a FE. Different FEs may use the same LFB instances, and >different LFBs can also use the same instance ID. Therefore it's quite easy to >arrange this IDs. Moreover, the broadcast/multicast based on LFB types can be >implemented very easily in the tree structure addressing just by the use of >FETypeID along with the FE ID as addressing ID. > >3. The PIDs scheme also has put more burden on CE. The CE then need to manage a >quite big database of PIDs, which include all managable entities in all FEs as >well as CEs, and the database is basically linearly strucutured. While in tree >structure, the CE only needs to maintain a very simple database for entity >addressing (therorically only need to resolve the FE ID), leaving many ID >resolution tasks done by individual FEs. The cause the tree structure can >achieve this advantage is it actually maps the ForCES FE framework structure >well. > >Jamal, I truly hope you may also point out the limitations for the tree >structured addressing way. In this way, I think we may be easier to reach an >agreement. > >Yours, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" >To: "Putzolu, David" >Cc: >Sent: Wednesday, March 10, 2004 1:47 AM >Subject: RE: [Forces-protocol] Issue 0: Application addressing > > > > >>David, >>Thanks for taking the time. >> >>On Tue, 2004-03-09 at 12:04, Putzolu, David wrote: >> >> >>>Hi Jamal. >>> >>>I think this was the email you where asking for a response >>>to - my response inline :) >>> >>> >>Yes, this is it;-> >> >> >> >>>Jamal wrote > >>> >>> >>[Reducing size of email as much as possible as promised; alos breaking >>this into two emails] >> >> >> >>>My impression is that the existance of FECs is implementation >>>specific - >>> >>> >>absolutely; the idea i had was to share an experience to explain >>the value for IDs: That a single FE could have multiple addressable >>targets. >> >> >> >>> The ForCES daemon FEd (that received the ForCES messages over the wire) >>>would either: >>>i) consume & act on the message if it is a FE-wide message >>> (although it might call some admin process under the covers - >>> again implementation specific) >>> >>> >>correct. >> >> >> >>>ii) Look at the LFB the message is addressed to, and based >>> on that, hand the message to the right LFB, or to the right >>> process that owns the LFB. If multiple LFBs are addressed >>> in a single message, it might deliver the relevant parts of >>> the message to each LFB/LFB container process. So the FEd >>> would probably have a table of LFB --> (how to contact >>> process|which API to invoke|what file to write|etc) >>> >>> >>Correct. Again implementation details; >>bottom line of the example was to show the value >>of the PID and that it means several processes/threads etc are addressed >>within a CE/FE. >> >>cheers, >>jamal >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------090803060809040003070806 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Exactly! This is exactly the point I made in my previous e-mail.

Alex.

Wang,Weiming wrote:
Hi Jamal, Hormuzd, David, and all,

As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID
means.
Firstly, I should say, there are two possible descriptions for such a tree
structure:
The first is to have it as a whole ID and put it at the ForCES message header,
and at the receiver side to resolve it from the head to the tail. I'l call this
as an explicit description. I think Jamal actually means this description.
The second is to have it implicitly described in the ForCES messages. That is,
for instance, to have FEID put in the message header and may have put LFBTypeID
and LFBInstanceID in the message body if needed.

I would say the second method is more flexible and reasonable, and what I mean
is actually the second one.

Then, I have a suggestion that how about Let's try to find out the disadvantages
for the two differenct addressing ways(PIDs based and FEID:FETypeID:FEInstanceID
based),  so that we may compare which is better.

Please alow me first to try to show some limitations when using PIDs based
addressing:

1. In ForCES architecture, it has already assumed that FEs and CEs may be from
different vendors. As a CE that uses ForCES protocol, it has no right to control
how an FE is implemented. This means, one vendoer may prefer to have LFB1 and
LFB2 managed by one process (or say FEC) while another vendor may have one
process (FEC1) for LFB1 and another process(FEC2) for LFB2. I just wonder how in
this case the PID will be uniformly arranged to address the both cases.

2. In the PIDs scheme, it seems there is no idea like LFB type used as
addressing index, all LFBs are actually represented by their instance IDs (which
are defined also as PIDs), and the instance IDs are globally defined within a
NE. This has lead two unhappy things:
1) ForCES user shoud carefull arrange these IDs so that there are no conflict on
the instance IDs in the NE.
2) This has made the broadcast/multicast that is based on LFB types quite
difficult, I suppose David also means this.
On the contrary, in the tree structured addressing, the LFBInstanceID is local
in a LFB type in a FE. Different FEs may use the same LFB instances, and
different LFBs can also use the same instance ID. Therefore it's quite easy to
arrange this IDs. Moreover, the broadcast/multicast based on LFB types can be
implemented very easily in the tree structure addressing just by the use of
FETypeID along with the FE ID as addressing ID.

3. The PIDs scheme also has put more burden on CE. The CE then need to manage a
quite big database of PIDs, which include all managable entities in all FEs as
well as CEs, and the database is basically linearly strucutured. While in tree
structure, the CE only needs to maintain a very simple database for entity
addressing (therorically only need to resolve the FE ID), leaving many ID
resolution tasks done by individual FEs. The cause the tree structure can
achieve this advantage is it actually maps the ForCES FE framework structure
well.

Jamal, I truly hope you may also point out the limitations for the tree
structured addressing way. In this way, I think we may be easier to reach an
agreement.

Yours,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
To: "Putzolu, David" <david.putzolu@intel.com>
Cc: <forces-protocol@ietf.org>
Sent: Wednesday, March 10, 2004 1:47 AM
Subject: RE: [Forces-protocol] Issue 0: Application addressing


  
David,
Thanks for taking the time.

On Tue, 2004-03-09 at 12:04, Putzolu, David wrote:
    
Hi Jamal.

I think this was the email you where asking for a response
to - my response inline :)
      
Yes, this is it;->

    
Jamal wrote >
      
[Reducing size of email as much as possible as promised; alos breaking
this into two emails]

    
My impression is that the existance of FECs is implementation
specific -
      
absolutely; the idea i had was to share an experience to explain
the value for IDs: That a single FE could have multiple addressable
targets.

    
 The ForCES daemon FEd (that received the ForCES messages over the wire)
would either:
i) consume & act on the message if it is a FE-wide message
   (although it might call some admin process under the covers -
   again implementation specific)
      
correct.

    
ii) Look at the LFB the message is addressed to, and based
    on that, hand the message to the right LFB, or to the right
    process that owns the LFB. If multiple LFBs are addressed
    in a single message, it might deliver the relevant parts of
    the message to each LFB/LFB container process.  So the FEd
    would probably have a table of LFB --> (how to contact
    process|which API to invoke|what file to write|etc)
      
Correct. Again implementation details;
bottom line of the example was to show the value
of the PID and that it means several processes/threads etc are addressed
within a CE/FE.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
    



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------090803060809040003070806-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 16:33:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08096 for ; Wed, 10 Mar 2004 16:33:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BJt-0000up-B4 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:32:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ALWrYF003518 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BJt-0000uf-6D for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 16:32:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08079 for ; Wed, 10 Mar 2004 16:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BJr-0007ag-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:32:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BIx-0007Sj-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:31:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1BI3-0007K0-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:30:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BI4-0000sV-NX; Wed, 10 Mar 2004 16:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BH8-0000kh-UX for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 16:30:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07952 for ; Wed, 10 Mar 2004 16:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BH7-0007Aq-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BGH-00071u-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:29:09 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1BFr-0006sJ-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:28:43 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031013310773:368 ; Wed, 10 Mar 2004 13:31:07 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <0e5901c406a0$4e0522f0$845c21d2@Necom.hzic.edu.cn> References: <52D13A805349A249960B9943E5590BD802928E9B@orsmsx409.jf.intel.com> <1078854444.1040.679.camel@jzny.localdomain> <0e5901c406a0$4e0522f0$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1078954115.1045.103.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 03/10/2004 01:31:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 01:31:14 PM, Serialize complete at 03/10/2004 01:31:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 16:28:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The one day i decide to not look tons of responses show up. I like the momentum, please keep it up. On Wed, 2004-03-10 at 08:05, Wang,Weiming wrote: > Hi Jamal, Hormuzd, David, and all, > > As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID > means. Initially you said [FE ID: LFB ID: LFB Instance ID] Is this a typo or are you rethinking? > Firstly, I should say, there are two possible descriptions for such a tree > structure: > The first is to have it as a whole ID and put it at the ForCES message header, > and at the receiver side to resolve it from the head to the tail. I'l call this > as an explicit description. I think Jamal actually means this description. No - this is not what i was saying. But let me read on. > The second is to have it implicitly described in the ForCES messages. That is, > for instance, to have FEID put in the message header and may have put LFBTypeID > and LFBInstanceID in the message body if needed. Ok, now you are getting back to [FE ID: LFB ID: LFB Instance ID] I am assuming your earlier description was a typo. I am for putting LFBInstanceID in the message body for practical purposes (example it would make sense to have a table entry to hold LFB instance state; and it would not be unusual to have a million such entries). > I would say the second method is more flexible and reasonable, and what I mean > is actually the second one. You attributed the first thing as something i said; it may be a misunderstanding. Let me explain what i said using your description above: FEID identifies a termination point on the FE of the consumer of the message. This would typically be a OS process. I am suggesting there could in fact be multiple such processes on the physical FE. The LFBID i refered to as a typeid. We went into a small discussion of whether what you refer to as LFBID belongs in the header or the body for batching purposes. I pointed out that there is a threshold point where it would make sense to put it in either the body or the header - we then defered that discussion. The LFBInstanceID definetely belongs to the message body. > Then, I have a suggestion that how about Let's try to find out the disadvantages > for the two differenct addressing ways(PIDs based and FEID:FETypeID:FEInstanceID > based), so that we may compare which is better. So now you are back on a different scheme i think. What is a FETypeID? It seems you may be saying two different things since you are repeating it again. > Please alow me first to try to show some limitations when using PIDs based > addressing: > > 1. In ForCES architecture, it has already assumed that FEs and CEs may be from > different vendors. As a CE that uses ForCES protocol, it has no right to control > how an FE is implemented. Agreed. > This means, one vendoer may prefer to have LFB1 and > LFB2 managed by one process (or say FEC) while another vendor may have one > process (FEC1) for LFB1 and another process(FEC2) for LFB2. I just wonder how in > this case the PID will be uniformly arranged to address the both cases. The FEID/PID on a Forces message is static. You seem to be implying it is the OS PID - it is ABSOLUTELY NOT. I am trying my best to avoid implementation details; let me say that If you read Davids response, it is very clear that what the relationship is. To quote him: --- The FE daemon would .. ii) Look at the LFB the message is addressed to, and based on that, hand the message to the right LFB, or to the right process that owns the LFB. If multiple LFBs are addressed in a single message, it might deliver the relevant parts of the message to each LFB/LFB container process. So the FEd would probably have a table of LFB --> (how to contact process|which API to invoke|what file to write|etc) --- > 2. In the PIDs scheme, it seems there is no idea like LFB type used as > addressing index, all LFBs are actually represented by their instance IDs (which > are defined also as PIDs), and the instance IDs are globally defined within a > NE. You have misunderstood what i said. Read all i have said above and then lets revisit. Since the rest of your message is derived from this misunderstanding i will not respond so we can get back in sync. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 16:37:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08342 for ; Wed, 10 Mar 2004 16:37:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BNp-0001Cw-Dk for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:36:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ALavkd004631 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:36:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BNo-0001Cc-PA for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 16:36:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08310 for ; Wed, 10 Mar 2004 16:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BNm-0000MU-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:36:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BMr-0000Di-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:35:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1BLy-00005G-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BLz-00013T-7u; Wed, 10 Mar 2004 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BLt-00012Z-79 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 16:34:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08169 for ; Wed, 10 Mar 2004 16:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BLr-00004k-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:34:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BKv-0007kJ-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:33:58 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1BKS-0007c6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:33:28 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031013355831:374 ; Wed, 10 Mar 2004 13:35:58 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Wang,Weiming" , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB130@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB130@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1078954406.1045.106.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 03/10/2004 01:35:58 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 01:36:00 PM, Serialize complete at 03/10/2004 01:36:00 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 16:33:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 13:26, Khosravi, Hormuzd M wrote: > Weiming, Jamal, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > > As Jamal asked, I'll first clarify what the tree > FEID:FETypeID:FEInstanceID > [HK] I definitely agree with Weiming on this addressing scheme and how > to place it in the protocol. This is same as the FE Model and I don't > see any issues with this scheme. Hormuzd, What is it that you are agreeing to? is it the FEID:FETypeID:FEInstanceID or FEID:LFBTypeID:LFBInstanceID scheme he described? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 16:46:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08607 for ; Wed, 10 Mar 2004 16:46:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BWX-00023V-7A for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:45:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ALjvMj007895 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 16:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BWX-00023G-2A for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 16:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08598 for ; Wed, 10 Mar 2004 16:45:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BWV-0001oz-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BVa-0001gG-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:44:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1BUd-0001X9-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 16:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BUe-0001tV-NG; Wed, 10 Mar 2004 16:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BUX-0001qw-Uy for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 16:43:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08547 for ; Wed, 10 Mar 2004 16:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BUV-0001Vt-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:43:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BTa-0001MU-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:42:54 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1BSf-000158-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 16:41:58 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2ALhQU1012821; Wed, 10 Mar 2004 21:43:28 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2ALZD0e030412; Wed, 10 Mar 2004 21:35:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031013411215470 ; Wed, 10 Mar 2004 13:41:12 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 13:41: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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQG51fqq+d53UaVR++G7zmvblt4PAAAMxdA From: "Khosravi, Hormuzd M" To: Cc: "Wang,Weiming" , X-OriginalArrivalTime: 10 Mar 2004 21:41:12.0437 (UTC) FILETIME=[683F3A50:01C406E8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 13:41:12 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, It seems like there is a typo below, I didn't notice it before. I am agreeing to FEID:LFBTypeID:LFBInstanceID scheme being proposed for the protocol and model. Thanks for clarifying this, Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > As Jamal asked, I'll first clarify what the tree > FEID:FETypeID:FEInstanceID > [HK] I definitely agree with Weiming on this addressing scheme and how > to place it in the protocol. This is same as the FE Model and I don't > see any issues with this scheme. Hormuzd, What is it that you are agreeing to? is it the FEID:FETypeID:FEInstanceID or FEID:LFBTypeID:LFBInstanceID scheme he described? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 17:07:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09743 for ; Wed, 10 Mar 2004 17:07:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Bqs-0003zl-EK for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:06:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AM6w6b015356 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Bqs-0003zb-9g for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 17:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09700 for ; Wed, 10 Mar 2004 17:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Bqq-0005FC-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Bpu-00055u-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:05:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Boz-0004x9-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Bp0-0003tX-Qd; Wed, 10 Mar 2004 17:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Bo1-0003oq-3w for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 17:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09585 for ; Wed, 10 Mar 2004 17:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Bnz-0004nf-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BnO-0004ey-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:03:23 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Bmd-0004Rc-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:02:35 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031014050457:404 ; Wed, 10 Mar 2004 14:05:04 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Deleganes, Ellen M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1078956152.1044.136.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 03/10/2004 02:05:04 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 02:05:06 PM, Serialize complete at 03/10/2004 02:05:06 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 17:02:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ellen, On Wed, 2004-03-10 at 13:58, Deleganes, Ellen M wrote: > Jamal, > > I am still trying to understand the value of the extra layer of > abstraction (application addressed by the PID) for addressing purposes. To be clear there is no extra layer of abstraction. > This implies that the FE capabilities are reported to the CE need to be > expanded because in addition to the LFBs and topologies the FE can > support, the CE also needs to understand the mapping of the PIDs to the > applications on the FE, The CE needs to know which IDs it has allocated to which FE. It would allocate more than one. What application uses what ID on the FE is upto the FE. Same with how IDs are used on the CE. An app on a FE with ID1 can talk to an app on CE with ID2 (not unlike a TCP app on port1 can talk to a TCP app on port2). > and which applications are responsible for which > LFBs. Otherwise, the CE would not know which PID it needed to send a > message to in order to configure an LFB or set of LFBs. The CE could > address the LFBs directly through the schemes being proposed on the > list. Addressing LFBs directly is an NPFish approach. I dont have a problem with it. I just want to generalize it. For this reason i refer to to the consumer of the destination ID as a target or app instead of LFB or LFB proxy etc. > In some schemes, using a PID could be less efficient. For example, if > you happen to want to configure all LFBs on the FE of a certain type the > same way, this could require more messages using the PID-based scheme. > In the case where multiple applications are controlling LFBs that belong > to the same class, then you would have to send a message to each > application. In the direct LFB addressing scheme, you would probably > only have to send one message indicating the LFB type. I believe this is > also a similar argument that Weiming was making in a previous email. > > For the purposes of configuring and controlling LFBs, I don't see the > value of the PID. Perhaps you can elaborate further. Ok, let me explain this again just for sync purposes: Actually let me use one of the notations Weiming posted to do this. [FE ID: LFB ID: LFB Instance ID]; *FE ID will be mapped possible to a process of some sort. FEID IS NOT a OS PID rather an identifier of where to send the message once it hits the FE. I see this as something that sits on the main header. *LFBID maps to the type of LFB; example "TB rate meter". This may sit in the main header. But that decision is based on what the general case would turn out to be. I can discuss this later with you. *LFB Instance ID: maps to a specific instance of LFB eg an instance of TB rate meter - typically this maps to a table index. This really doesnt belong in the main header; unless someone has some good reasons for it to be there. I am gonna stop there to make sure we are in sync. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 17:34:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10661 for ; Wed, 10 Mar 2004 17:34:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CGx-0005qM-H4 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AMXtKo022462 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CGx-0005qD-Cg for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 17:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10641 for ; Wed, 10 Mar 2004 17:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CGv-0001S6-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:33:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CG2-0001JI-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:32:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1CF5-0001BA-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CF7-0005ct-88; Wed, 10 Mar 2004 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CF2-0005cg-Ao for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 17:31:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10598 for ; Wed, 10 Mar 2004 17:31:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CEz-0001A6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:31:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CE9-00012S-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:31:01 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1CDS-0000u6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:30:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031014324885:425 ; Wed, 10 Mar 2004 14:32:48 -0800 Subject: RE: Progress WAS (RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB221@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB221@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078957817.1035.7.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 03/10/2004 02:32:49 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 02:32:49 PM, Serialize complete at 03/10/2004 02:32:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 17:30:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Wed, 2004-03-10 at 14:18, Khosravi, Hormuzd M wrote: > Jamal, > > I think we might get upto issue#5 at Max in the current time frame. > And if we can resolve upto that, I think it will be a great achievement > ! I think if the momentum picks up after the initial glitches we should be fine in going past that. > BTW, I don't think #7 HA will be contentious. I labelled it that after a short discussion i had with Ram in Mineaopolis. Where is Ram btw? > Also, we might land up > discussing #8 in the context of the 1-5. I actually think #8 is easy; certainly 1-5 + any other dynamic discovery issues may map there. > I will put together text for > #2, but before that I would really like to resolve #0 since that is > very basic and is needed to proceed forward with a common understanding. Refer to my emails i just posted. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 17:38:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10788 for ; Wed, 10 Mar 2004 17:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CKr-0006QI-5b for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:37:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AMbv4H024671 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 17:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CKp-0006PV-AG for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 17:37:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10758 for ; Wed, 10 Mar 2004 17:37:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CKm-00021Y-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:37:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CJp-0001sW-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:36:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1CIx-0001kM-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 17:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CIy-00068T-IB; Wed, 10 Mar 2004 17:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CIt-000689-Gq for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 17:35:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10693 for ; Wed, 10 Mar 2004 17:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CIr-0001jX-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:35:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CHv-0001au-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:34:55 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1CH3-0001TF-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:34:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031014363090:429 ; Wed, 10 Mar 2004 14:36:30 -0800 Subject: RE: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB257@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB257@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078958038.1035.12.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 03/10/2004 02:36:31 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 02:36:32 PM, Serialize complete at 03/10/2004 02:36:32 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 17:33:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 14:34, Khosravi, Hormuzd M wrote: > -----Original Message----- > [HK] Let me clarify something here...LFB type is something like IPv4 > Fwdr, LFB ID identifies an instance of such an IPv4 Fwdr, thus it is a > reference to a single IPv4 Fwd table on the FE. Individual instances in > this table will be further identified using indexes or whatever the > model team defines, inside this table/LFB. Why do i think we are saying the same thing? ;-> Look at my other emails ;-> BTW, i dont understand all this confusion that has to do with an ID being an OS PID. It may a result of me calling the field PID. I hope my other emails clarified that. Alex, i am not responding to your email hoping my last few emails clarified this. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:02:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11859 for ; Wed, 10 Mar 2004 18:02:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ci7-0002lS-9y for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:01:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AN1xHH010589 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ci6-0002kd-HH for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:01:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11856 for ; Wed, 10 Mar 2004 18:01:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Ci3-0005wD-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:01:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ch7-0005nO-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:00:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1CgD-0005f1-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CgF-0001tq-CL; Wed, 10 Mar 2004 18:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CfK-0001sc-OR for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 17:59:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11789 for ; Wed, 10 Mar 2004 17:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CfI-0005Vo-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:59:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Cea-0005N3-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:58:21 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1Cdt-000594-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 17:57:37 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2AMv7TN002803; Wed, 10 Mar 2004 16:57:07 -0600 (CST) Message-ID: <404F9D41.1030405@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> <1078956152.1044.136.camel@jzny.localdomain> In-Reply-To: <1078956152.1044.136.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 16:57:05 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jamal, NO! FEID doesn't map onto a process. It maps onto a physical device: an FE. There is only one object instance of this per physical FE. Why would we map this to a process???? Regards, Alex. Jamal Hadi Salim wrote: >Ok, let me explain this again just for sync purposes: > >Actually let me use one of the notations Weiming posted to do this. >[FE ID: LFB ID: LFB Instance ID]; > >*FE ID will be mapped possible to a process of some sort. FEID IS NOT a >OS PID rather an identifier of where to send the message once it hits >the FE. I see this as something that sits on the main header. > >*LFBID maps to the type of LFB; example "TB rate meter". This may sit >in the main header. But that decision is based on what the general case >would turn out to be. I can discuss this later with you. > >*LFB Instance ID: maps to a specific instance of LFB eg an instance >of TB rate meter - typically this maps to a table index. This really >doesnt belong in the main header; unless someone has some good reasons >for it to be there. > >I am gonna stop there to make sure we are in sync. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:18:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13424 for ; Wed, 10 Mar 2004 18:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Cxb-0000JC-Vm for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANHxD7001184 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Cxb-0000J0-QI for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:17:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13359 for ; Wed, 10 Mar 2004 18:17:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CxZ-0000TY-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:17:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CwZ-0000Ki-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:16:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Cvf-0000CI-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Cvh-0008H4-8o; Wed, 10 Mar 2004 18:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Cuo-00083l-Ak for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13102 for ; Wed, 10 Mar 2004 18:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Cul-00004z-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ctt-0007k8-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:14:10 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1CtH-0007YY-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:13:31 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2ANErU1007327; Wed, 10 Mar 2004 23:14:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2ANE6Ab010029; Wed, 10 Mar 2004 23:14:36 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031015124429276 ; Wed, 10 Mar 2004 15:12:44 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 15:12:44 -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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQG8xi5LiaRnY44SHejuXhSZMzXGQAAKWkQ From: "Deleganes, Ellen M" To: , Cc: X-OriginalArrivalTime: 10 Mar 2004 23:12:44.0303 (UTC) FILETIME=[31A779F0:01C406F5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 15:12:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree with Alex. The FE ID should map to the FE, for the purposes of the protocol.=20 If the FE implementation has some kind of process (daemon, or whatever) that is handling incoming messages addressed to that FE to either process or distribute, that should not be exposed by the protocol. The protocol should not dictate or restrict implementation choices where possible. It is not even clear that an FE ID is needed in the protocol. For most underlying transports some destination identifier (IP address, MAC or whatever) is part of the transport header. Assuming only one FE is associated with that destination, an FE ID might not be necessary in the ForCES protocol header. Regards, Ellen -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Wednesday, March 10, 2004 2:57 PM To: hadi@znyx.com Cc: Deleganes, Ellen M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing Jamal, NO! FEID doesn't map onto a process. It maps onto a physical device: an=20 FE. There is only one object instance of this per physical FE. Why would we map this to a process???? Regards, Alex. =20 Jamal Hadi Salim wrote: >Ok, let me explain this again just for sync purposes: > >Actually let me use one of the notations Weiming posted to do this. >[FE ID: LFB ID: LFB Instance ID]; > >*FE ID will be mapped possible to a process of some sort. FEID IS NOT a >OS PID rather an identifier of where to send the message once it hits >the FE. I see this as something that sits on the main header.=20 > >*LFBID maps to the type of LFB; example "TB rate meter". This may sit >in the main header. But that decision is based on what the general case >would turn out to be. I can discuss this later with you. > >*LFB Instance ID: maps to a specific instance of LFB eg an instance >of TB rate meter - typically this maps to a table index. This really >doesnt belong in the main header; unless someone has some good reasons >for it to be there. > >I am gonna stop there to make sure we are in sync. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > =20 > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:23:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13668 for ; Wed, 10 Mar 2004 18:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D2T-0001ME-7E for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:23:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANN150005204 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D2S-0001Le-3x for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:23:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13648 for ; Wed, 10 Mar 2004 18:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1D2P-0001Bw-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1D1S-000137-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:21:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1D0W-0000uV-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D0Y-0001AZ-Nf; Wed, 10 Mar 2004 18:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D0U-00019m-7J for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:20:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13582 for ; Wed, 10 Mar 2004 18:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1D0R-0000tW-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:20:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CzZ-0000lX-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:20:02 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Cyb-0000dT-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:19:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031015212991:476 ; Wed, 10 Mar 2004 15:21:29 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <404F9D41.1030405@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> <1078956152.1044.136.camel@jzny.localdomain> <404F9D41.1030405@alcatel.com> Organization: ZNYX Networks Message-Id: <1078960737.1038.27.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 03/10/2004 03:21:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 03:21:32 PM, Serialize complete at 03/10/2004 03:21:32 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 18:18:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 17:57, Alex Audu wrote: > Jamal, > > NO! FEID doesn't map onto a process. It maps onto a physical device: an > FE. There > is only one object instance of this per physical FE. Why would we map > this to a > process???? I have a feeling your opinion of the FEID is some static configuration identifier, perhaps related to a slot number and geographical location within a room or two. Is this accurate? This is still valid and does not preclude anything i said so far. The hardware id is within the 32 bit number and definetely part of the FEID. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:31:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14009 for ; Wed, 10 Mar 2004 18:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DAA-0001sQ-I3 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:30:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANUwEi007211 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:30:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DAA-0001sE-Cx for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:30:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13982 for ; Wed, 10 Mar 2004 18:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DA7-0002QC-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1D99-0002HD-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:29:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1D8F-00028V-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D8H-0001cD-Pw; Wed, 10 Mar 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1D8D-0001aR-Kd for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:28:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13872 for ; Wed, 10 Mar 2004 18:28:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1D8A-00027n-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:28:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1D7C-0001y2-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:27:54 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1D6B-0001hq-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:26: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 2004031015292116:493 ; Wed, 10 Mar 2004 15:29:21 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Deleganes, Ellen M" Cc: alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078961209.1037.36.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 03/10/2004 03:29:21 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 03:29:23 PM, Serialize complete at 03/10/2004 03:29:23 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 18:26:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 18:12, Deleganes, Ellen M wrote: > I agree with Alex. The FE ID should map to the FE, for the purposes of > the protocol. > > If the FE implementation has some kind of process (daemon, or whatever) > that is handling incoming messages addressed to that FE to either > process or distribute, that should not be exposed by the protocol. The > protocol should not dictate or restrict implementation choices where > possible. You can use a single ID. Think of a machine that is proxying for several non-intelligent FEs. It would have more than one ID. This has nothing to do with implementation enforcement. An implementor could decide to run one or more daemons. The same applies to some variants of a partitioned FE. > It is not even clear that an FE ID is needed in the protocol. For most > underlying transports some destination identifier (IP address, MAC or > whatever) is part of the transport header. Assuming only one FE is > associated with that destination, an FE ID might not be necessary in the > ForCES protocol header. Missing the ID is enforcing an implementation; i.e there can only be a single daemon running. Refer to what i said above on the proxy. The protocol should not have to do anything speacila to identify proxies. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:37:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14203 for ; Wed, 10 Mar 2004 18:37:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DG7-0002Hk-TT for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANb7hn008757 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DG5-0002H5-A7 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14167 for ; Wed, 10 Mar 2004 18:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DG2-0003IC-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DEx-00038z-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:35:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1DE4-00030b-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DE6-0002Cd-SD; Wed, 10 Mar 2004 18:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DDB-00025D-Nl for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:34:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14107 for ; Wed, 10 Mar 2004 18:34:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DD8-0002ri-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:34:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DCA-0002jN-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:33:03 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1DBl-0002aw-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:32:37 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2ANW6TN007718; Wed, 10 Mar 2004 17:32:07 -0600 (CST) Message-ID: <404FA576.8080205@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Deleganes, Ellen M" CC: hadi@znyx.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------060103090107090705040309" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:32:06 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060103090107090705040309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Well, one good use of the FEID is to make life easy for the protocol when managing resources. For example, if the CE has to interact with 10 FEs, the CE might need to create 10 FE objects with sequential IDs (say 0-9). Each object hides all the details of the FE addressing. It is a lot easier for the CE to match FE ID 2 to the corresponding object, for example, than it is to map IP address 123.345.456.034. I mean, comparing an integer is much easier and quicker than comparing a string. Again, this impacts protocol speed. Regards, Alex. Deleganes, Ellen M wrote: >I agree with Alex. The FE ID should map to the FE, for the purposes of >the protocol. > >If the FE implementation has some kind of process (daemon, or whatever) >that is handling incoming messages addressed to that FE to either >process or distribute, that should not be exposed by the protocol. The >protocol should not dictate or restrict implementation choices where >possible. > >It is not even clear that an FE ID is needed in the protocol. For most >underlying transports some destination identifier (IP address, MAC or >whatever) is part of the transport header. Assuming only one FE is >associated with that destination, an FE ID might not be necessary in the >ForCES protocol header. > >Regards, >Ellen > >-----Original Message----- >From: Alex Audu [mailto:alex.audu@alcatel.com] >Sent: Wednesday, March 10, 2004 2:57 PM >To: hadi@znyx.com >Cc: Deleganes, Ellen M; forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Issue 0: Application addressing > >Jamal, > >NO! FEID doesn't map onto a process. It maps onto a physical device: an >FE. There >is only one object instance of this per physical FE. Why would we map > >this to a >process???? > >Regards, >Alex. > > >Jamal Hadi Salim wrote: > > > >>Ok, let me explain this again just for sync purposes: >> >>Actually let me use one of the notations Weiming posted to do this. >>[FE ID: LFB ID: LFB Instance ID]; >> >>*FE ID will be mapped possible to a process of some sort. FEID IS NOT a >>OS PID rather an identifier of where to send the message once it hits >>the FE. I see this as something that sits on the main header. >> >>*LFBID maps to the type of LFB; example "TB rate meter". This may sit >>in the main header. But that decision is based on what the general case >>would turn out to be. I can discuss this later with you. >> >>*LFB Instance ID: maps to a specific instance of LFB eg an instance >>of TB rate meter - typically this maps to a table index. This really >>doesnt belong in the main header; unless someone has some good reasons >>for it to be there. >> >>I am gonna stop there to make sure we are in sync. >> >>cheers, >>jamal >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> >> > > > --------------060103090107090705040309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Well, one good use of the FEID is to make life easy for the protocol when managing
resources. For example, if the CE has to interact with 10 FEs, the CE might  need to create
10 FE objects with sequential IDs (say 0-9).  Each object hides all the details of the FE
addressing.  It  is a lot easier for the CE to match FE ID 2  to the corresponding object, for example,  than it is to map IP address  123.345.456.034. I mean, comparing an integer
is much easier and quicker than comparing a string.  Again, this impacts protocol speed.

Regards,
Alex.

Deleganes, Ellen M wrote:
I agree with Alex. The FE ID should map to the FE, for the purposes of
the protocol. 

If the FE implementation has some kind of process (daemon, or whatever)
that is handling incoming messages addressed to that FE to either
process or distribute, that should not be exposed by the protocol. The
protocol should not dictate or restrict implementation choices where
possible.

It is not even clear that an FE ID is needed in the protocol. For most
underlying transports some destination identifier (IP address, MAC or
whatever) is part of the transport header. Assuming only one FE is
associated with that destination, an FE ID might not be necessary in the
ForCES protocol header.

Regards,
Ellen

-----Original Message-----
From: Alex Audu [mailto:alex.audu@alcatel.com] 
Sent: Wednesday, March 10, 2004 2:57 PM
To: hadi@znyx.com
Cc: Deleganes, Ellen M; forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Issue 0: Application addressing

Jamal,

NO! FEID doesn't map onto a process. It maps onto a physical device: an 
FE.  There
is only one object  instance of this per physical FE.   Why would we map

this to a
process????

Regards,
Alex.
 

Jamal Hadi Salim wrote:

  
Ok, let me explain this again just for sync purposes:

Actually let me use one of the notations Weiming posted to do this.
[FE ID: LFB ID: LFB Instance ID];

*FE ID will be mapped possible to a process of some sort. FEID IS NOT a
OS PID rather an identifier of where to send the message once it hits
the FE. I see this as something that sits on the main header. 

*LFBID maps to the type of LFB; example "TB rate meter". This may sit
in the main header. But that decision is based on what the general case
would turn out to be. I can discuss this later with you.

*LFB Instance ID: maps to a specific instance of LFB eg an instance
of TB rate meter - typically this maps to a table index. This really
doesnt belong in the main header; unless someone has some good reasons
for it to be there.

I am gonna stop there to make sure we are in sync.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------060103090107090705040309-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14435 for ; Wed, 10 Mar 2004 18:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DLr-0002xR-N5 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANh3mR011363 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DLr-0002xC-Ia for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14395 for ; Wed, 10 Mar 2004 18:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DLo-0004Bz-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:43:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DKr-00041Y-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:42:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1DJr-0003sG-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DJt-0002uR-KT; Wed, 10 Mar 2004 18:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DIx-0002jK-8Z for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14280 for ; Wed, 10 Mar 2004 18:39:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DHw-0003jE-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:39:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DHw-0003al-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:39:01 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1DHO-0003RY-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:38:27 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2ANbuTN008455; Wed, 10 Mar 2004 17:37:56 -0600 (CST) Message-ID: <404FA6D4.5070201@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> <1078956152.1044.136.camel@jzny.localdomain> <404F9D41.1030405@alcatel.com> <1078960737.1038.27.camel@jzny.localdomain> In-Reply-To: <1078960737.1038.27.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------070205080806090509050609" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:37:56 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070205080806090509050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit What I am saying is there should be no ambiguity as to which FE an FEID maps to. An FEID maps to one and only one FE instance. There should be no other interpretation of this FEID. At least I don't see a use case for what you are proposing. May be you can explain some more,.. Regards, Alex. Jamal Hadi Salim wrote: >On Wed, 2004-03-10 at 17:57, Alex Audu wrote: > > >>Jamal, >> >>NO! FEID doesn't map onto a process. It maps onto a physical device: an >>FE. There >>is only one object instance of this per physical FE. Why would we map >>this to a >>process???? >> >> > >I have a feeling your opinion of the FEID is some static configuration >identifier, perhaps related to a slot number and geographical location >within a room or two. Is this accurate? This is still valid and does not >preclude anything i said so far. The hardware id is within the 32 bit >number and definetely part of the FEID. > >cheers, >jamal > > > > > --------------070205080806090509050609 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit What I am saying is there  should be no ambiguity as to which FE an FEID maps to.
An FEID maps to one and only one FE instance.  There should be no other interpretation
of this FEID.  At least I don't see a use case for what you are proposing. May be you can
explain some more,..

Regards,
Alex.



Jamal Hadi Salim wrote:
On Wed, 2004-03-10 at 17:57, Alex Audu wrote:
  
Jamal,

NO! FEID doesn't map onto a process. It maps onto a physical device: an 
FE.  There
is only one object  instance of this per physical FE.   Why would we map 
this to a
process????
    

I have a feeling your opinion of the FEID is some static configuration
identifier, perhaps related to a slot number and geographical location
within a room or two. Is this accurate? This is still valid and does not
preclude anything i said so far. The hardware id is within the 32 bit
number and definetely part of the FEID. 
 
cheers,
jamal
--------------070205080806090509050609-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 18:50:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14645 for ; Wed, 10 Mar 2004 18:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DSY-0003Ok-Pp for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ANnwV0013056 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 18:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DSY-0003OV-Iw for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 18:49:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14623 for ; Wed, 10 Mar 2004 18:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DSV-0005D4-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DRY-000551-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1DQc-0004wv-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 18:47:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DQe-0003HC-OJ; Wed, 10 Mar 2004 18:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DPm-0003GJ-I1 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 18:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14565 for ; Wed, 10 Mar 2004 18:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DPj-0004oz-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DOr-0004gd-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:46:10 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1DON-0004XM-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 18:45: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 i2ANj9TN009279; Wed, 10 Mar 2004 17:45:09 -0600 (CST) Message-ID: <404FA885.9020501@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BB4E8@orsmsx408.jf.intel.com> <1078961209.1037.36.camel@jzny.localdomain> In-Reply-To: <1078961209.1037.36.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------080507030900010802090602" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:45:09 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080507030900010802090602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A machine that is proxying for multiple FEs should be transparent to the protocol. This is important for interoperability. In short, how the message gets routed to the FE of interest should be transparent to the protocol. Regards, Alex. Jamal Hadi Salim wrote: >On Wed, 2004-03-10 at 18:12, Deleganes, Ellen M wrote: > > >>I agree with Alex. The FE ID should map to the FE, for the purposes of >>the protocol. >> >>If the FE implementation has some kind of process (daemon, or whatever) >>that is handling incoming messages addressed to that FE to either >>process or distribute, that should not be exposed by the protocol. The >>protocol should not dictate or restrict implementation choices where >>possible. >> >> > >You can use a single ID. >Think of a machine that is proxying for several non-intelligent >FEs. It would have more than one ID. This has nothing to do with >implementation enforcement. An implementor could decide to run >one or more daemons. >The same applies to some variants of a partitioned FE. > > > >>It is not even clear that an FE ID is needed in the protocol. For most >>underlying transports some destination identifier (IP address, MAC or >>whatever) is part of the transport header. Assuming only one FE is >>associated with that destination, an FE ID might not be necessary in the >>ForCES protocol header. >> >> > >Missing the ID is enforcing an implementation; i.e there can only >be a single daemon running. >Refer to what i said above on the proxy. >The protocol should not have to do anything speacila to identify >proxies. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------080507030900010802090602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A machine that is proxying for multiple FEs should be transparent to the protocol. This is
important for interoperability. In short, how the message gets routed to the FE of interest
should be transparent to the protocol.

Regards,
Alex.

Jamal Hadi Salim wrote:
On Wed, 2004-03-10 at 18:12, Deleganes, Ellen M wrote:
  
I agree with Alex. The FE ID should map to the FE, for the purposes of
the protocol. 

If the FE implementation has some kind of process (daemon, or whatever)
that is handling incoming messages addressed to that FE to either
process or distribute, that should not be exposed by the protocol. The
protocol should not dictate or restrict implementation choices where
possible.
    

You can use a single ID. 
Think of a machine that is proxying for several non-intelligent
FEs. It would have more than one ID. This has nothing to do with
implementation enforcement. An implementor could decide to run
one or more daemons.
The same applies to some variants of a partitioned FE.

  
It is not even clear that an FE ID is needed in the protocol. For most
underlying transports some destination identifier (IP address, MAC or
whatever) is part of the transport header. Assuming only one FE is
associated with that destination, an FE ID might not be necessary in the
ForCES protocol header.
    

Missing the ID is enforcing an implementation; i.e there can only
be a single daemon running.
Refer to what i said above on the proxy.
The protocol should not have to do anything speacila to identify
proxies.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------080507030900010802090602-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 19:08:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15357 for ; Wed, 10 Mar 2004 19:08:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Dk2-0007E9-VE for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B082l0027768 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Dk1-0007Dc-Eq for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 19:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15316 for ; Wed, 10 Mar 2004 19:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Djy-00004E-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:07:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Dj0-0007i5-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:06:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Di2-0007Z7-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:05:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Di5-0006qe-60; Wed, 10 Mar 2004 19:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Di4-0006qC-0G for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 19:06:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15256 for ; Wed, 10 Mar 2004 19:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Di0-0007Yj-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Dh2-0007Pl-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:04:56 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Dg5-0007GF-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:03:57 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031016062640:531 ; Wed, 10 Mar 2004 16:06:26 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <404FA6D4.5070201@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB1C7@orsmsx408.jf.intel.com> <1078956152.1044.136.camel@jzny.localdomain> <404F9D41.1030405@alcatel.com> <1078960737.1038.27.camel@jzny.localdomain> <404FA6D4.5070201@alcatel.com> Organization: ZNYX Networks Message-Id: <1078963432.1035.48.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 03/10/2004 04:06:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 04:06:28 PM, Serialize complete at 03/10/2004 04:06:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 19:03:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 18:37, Alex Audu wrote: > What I am saying is there should be no ambiguity as to which FE an > FEID maps to. There is none. > An FEID maps to one and only one FE instance. There should be no > other interpretation > of this FEID. At least I don't see a use case for what you are > proposing. May be you can explain some more,.. Actually let me throw that at you instead; you said: On Wed, 2004-03-10 at 18:45, Alex Audu wrote: > A machine that is proxying for multiple FEs should be transparent to > the protocol. This is > important for interoperability. In short, how the message gets routed > to the FE of interest > should be transparent to the protocol. > So is this machine an FE, an FE proxy or what? Do you have multiple FEIDs destined to it or do you have a single one? The protocol is still using only the ID field (i dislike the FEID naming for this reason - its an ID). In other words no extra header info is needed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 19:26:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16320 for ; Wed, 10 Mar 2004 19:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1E1P-0008WG-8e for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:26:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B0Px8o032745 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1E1O-0008W4-Hn for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 19:25:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16299 for ; Wed, 10 Mar 2004 19:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1E1M-00030J-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1E0P-0002rQ-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:24:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1DzT-0002j7-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DzU-0008E2-Ki; Wed, 10 Mar 2004 19:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1DyY-00089u-K5 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 19:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16230 for ; Wed, 10 Mar 2004 19:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1DyW-0002aE-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1DxZ-0002QT-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:22:02 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Dwe-00027i-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:21:04 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2B0MQU1025907; Thu, 11 Mar 2004 00:22:26 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2B0LaAb001404; Thu, 11 Mar 2004 00:22:06 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031016201203345 ; Wed, 10 Mar 2004 16:20:12 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 16:20: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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQG/F2WoBetA0IoQS+YCUlr5bYG+gAAJS8g From: "Deleganes, Ellen M" To: , Cc: X-OriginalArrivalTime: 11 Mar 2004 00:20:12.0261 (UTC) FILETIME=[9E6CD950:01C406FE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 16:20:11 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So if you have a proxy that is "fronting" for multiple FEs, what does the ID contain? If it is the ID of the proxy, how does the proxy know which FE to configure? I think even in this case the ID should identify the FE so the proxy knows which FE the CE wishes to configure. If this is the case FE ID seems to be appropriate nomenclature.=20 How the message gets to the proxy should be transparent to the ForCES protocol. This can be handled by correctly addressing the message (or putting into the right socket or whatever) at the underlying transport the proxy ID should not have to be part of the ForCES protocol. This seems like the connection to a proxy is part of the pre-association phase and outside of ForCES. Regards, Ellen -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, March 10, 2004 4:04 PM To: alex.audu@alcatel.com Cc: Deleganes, Ellen M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing On Wed, 2004-03-10 at 18:37, Alex Audu wrote: > What I am saying is there should be no ambiguity as to which FE an > FEID maps to. There is none.=20 > An FEID maps to one and only one FE instance. There should be no > other interpretation > of this FEID. At least I don't see a use case for what you are > proposing. May be you can explain some more,.. Actually let me throw that at you instead; you said: On Wed, 2004-03-10 at 18:45, Alex Audu wrote:=20 > A machine that is proxying for multiple FEs should be transparent to > the protocol. This is=20 > important for interoperability. In short, how the message gets routed > to the FE of interest > should be transparent to the protocol. >=20 So is this machine an FE, an FE proxy or what? Do you have multiple FEIDs destined to it or do you have a single one? The protocol is still using only the ID field (i dislike the FEID naming for this reason - its an ID). In other words no extra header info is needed.=20 cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 19:51:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17258 for ; Wed, 10 Mar 2004 19:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EPf-00026y-1x for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B0p3oO008114 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 19:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EPe-00026m-Pf for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 19:51:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17250 for ; Wed, 10 Mar 2004 19:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EPc-0006sc-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EOd-0006io-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:49:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ENf-0006YX-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 19:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ENh-0001x4-7o; Wed, 10 Mar 2004 19:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EMy-0001t4-N4 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 19:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17127 for ; Wed, 10 Mar 2004 19:48:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EMw-0006QX-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EM8-0006Gc-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:47:24 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1ELV-00066E-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 19:46:47 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031016491544:554 ; Wed, 10 Mar 2004 16:49:15 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Deleganes, Ellen M" Cc: alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078966003.1037.59.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 03/10/2004 04:49:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 04:49:17 PM, Serialize complete at 03/10/2004 04:49:17 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 19:46:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote: > So if you have a proxy that is "fronting" for multiple FEs, what does > the ID contain? I would think there would be a unique ID for each FE being addressed. Protocol doesnt care who is handling it; > If it is the ID of the proxy, how does the proxy know > which FE to configure? > I think even in this case the ID should identify > the FE so the proxy knows which FE the CE wishes to configure. Exactly. So message goes say to IP X which is a proxy; but destination ID refers uniquely to the FE. > If this > is the case FE ID seems to be appropriate nomenclature. So far we seem to be saying the address looks like: ID:=FEID: LFBID: LFBInstanceID So you are refering to that one portion of the ID i hope? in which case we may have no issues. > How the message gets to the proxy should be transparent to the ForCES > protocol. It is. > This can be handled by correctly addressing the message (or > putting into the right socket or whatever) at the underlying transport > the proxy ID should not have to be part of the ForCES protocol. It is not. Nothing in the Forces header helps identify it as a proxy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 20:11:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18144 for ; Wed, 10 Mar 2004 20:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Eiy-0004U4-VA for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:11:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B1B0Ke017230 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Eiy-0004Tp-P6 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 20:11:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18116 for ; Wed, 10 Mar 2004 20:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Eiw-0002O1-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:10:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ehz-0002EE-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:10:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Eh1-00022n-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Eh3-0004OR-0v; Wed, 10 Mar 2004 20:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EgM-0004JK-Sg for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 20:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17989 for ; Wed, 10 Mar 2004 20:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EgK-0001tg-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EfN-0001hQ-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:07:18 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1EeW-0001MJ-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:06:24 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2B17qU1025803; Thu, 11 Mar 2004 01:07:52 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2B16uAf007587; Thu, 11 Mar 2004 01:07:31 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031017041511980 ; Wed, 10 Mar 2004 17:04:18 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 17:03:48 -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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB651@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQHAqhVhSve01+mQFehcIu2Ljrr5AAAD4AA From: "Deleganes, Ellen M" To: Cc: , X-OriginalArrivalTime: 11 Mar 2004 01:03:48.0466 (UTC) FILETIME=[B5CE0D20:01C40704] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:03:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, I think we are in agreement about the FE ID portion of the addressing and what it identifies (an FE instance). It also looks like everyone is in agreement that a LFBID and LFBInstanceID are also needed for the protocol. Where there appears to be disagreement is whether the LFBID and LFBInstanceID belong in the common header or in the TLV. I believe, like many others that LFB-related IDs (LFBID and LFBInstanceID) belong in the TLV and not the common header. The primary reason is to allow one message to affect more than one LFB. This is more reasonably handled in the TLV.=20 If we are in agreement that the LFBID and LFBInstanceID are part of the TLV, it seems like Issue 0 can be closed. Do others agree? Regards, Ellen -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Wednesday, March 10, 2004 4:47 PM To: Deleganes, Ellen M Cc: alex.audu@alcatel.com; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 0: Application addressing On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote: > So if you have a proxy that is "fronting" for multiple FEs, what does > the ID contain?=20 I would think there would be a unique ID for each FE being addressed. Protocol doesnt care who is handling it;=20 > If it is the ID of the proxy, how does the proxy know > which FE to configure?=20 > I think even in this case the ID should identify > the FE so the proxy knows which FE the CE wishes to configure. Exactly. So message goes say to IP X which is a proxy; but destination ID refers uniquely to the FE. > If this > is the case FE ID seems to be appropriate nomenclature.=20 So far we seem to be saying the address looks like: ID:=3DFEID: LFBID: LFBInstanceID So you are refering to that one portion of the ID i hope? in which case we may have no issues.=20 > How the message gets to the proxy should be transparent to the ForCES > protocol.=20 It is. > This can be handled by correctly addressing the message (or > putting into the right socket or whatever) at the underlying transport > the proxy ID should not have to be part of the ForCES protocol.=20 It is not. Nothing in the Forces header helps identify it as a proxy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 20:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18739 for ; Wed, 10 Mar 2004 20:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Etd-0004jP-GJ for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:22:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B1M1EK018181 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Etd-0004jA-BF for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 20:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18711 for ; Wed, 10 Mar 2004 20:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Etb-0003t2-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Esd-0003ju-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:21:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Eri-0003b5-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Erj-0004ew-96; Wed, 10 Mar 2004 20:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Eqm-0004dQ-Ji for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 20:19:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18594 for ; Wed, 10 Mar 2004 20:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Eqk-0003SA-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Epn-0003JT-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:18:04 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Eoz-000342-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:17:14 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2B1IpU1032448; Thu, 11 Mar 2004 01:18:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2B1IFAV015447; Thu, 11 Mar 2004 01:18:35 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031017164215735 ; Wed, 10 Mar 2004 17:16:42 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 17:16: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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <52D13A805349A249960B9943E5590BD8029CF156@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQHAqhVhSve01+mQFehcIu2Ljrr5AAAD4AAAACsPuA= From: "Putzolu, David" To: "Deleganes, Ellen M" , Cc: X-OriginalArrivalTime: 11 Mar 2004 01:16:42.0476 (UTC) FILETIME=[83269AC0:01C40706] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:16:41 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So just to be clear, is the following what people are proposing? Or is this too much detail? Structure of ForCES Message: ------------------ | ForCES Header | <- The FE daemon (FEd) receives this.=20 | ( includes | Includes stuff that must be in=20 | FEid ) | every msg e.g. total message length. |----------------| =20 | ForCES Payload | <- Elaborated below. ------------------ FEd processes this header, then payload (if present, see below). FEid may be used by Fed to choose a FE=20 instance on a PFE (physical FE) that received the=20 message. This could map to a process, a mezannine=20 card, or whatever. Or, if there is only a single FE that could have received this message (i.e. FE is at end of a unicast, L3/L2 addressed connection), maybe FEd just validates FEid is expected value and continues... Structure of ForCES Payload: ------------------ | LFB Message | <- ForCES Payload is one or more messages |----------------| to LFBs. Many LFB messages may | .... | be bundled in a single ForCES message. |----------------| =20 | LFB Message | <- Elaborated below ------------------=20 Payload is 0 or more LFB messages. If 0 LFB messages then ForCES header is the entire message. Structure of LFB message: ------------------ | LFB Identifier | <- Unique ID within the scope of a FE | | telling FEd which LFB should be given |----------------| this LFB message. | LFB Message Len| <- Tells FEd how long this LFB message |----------------| is e.g. 16 bytes. | LFB Message | <- 16 bytes of stuff to be handed to the | Payload | identified LFB. After handing 16 bytes to=20 ------------------ LFB the FEd moves forward 16 bytes and=20 processes next LFB message in same fashion until all done. =20 The FEd does not care about the message internals (including=20 message type), it just passes them on to LFBs. Structure of example LFB message payload passed to LFB: ------------------ | LFB Command Typ| <- Tells LFB what to do e.g. "Add Route" |----------------| =20 | LFB Command Val| <- Body of command e.g. "prefix =3D 138.12.0.0, | | mask =3D 255.255.0.0, ------------------ nexthop =3D 138.12.1.251" Does the above seem OK? Not trying to make up something new here, just to put pictures to the words people have been sending :) -David > -----Original Message----- > From: forces-protocol-admin@ietf.org=20 > [mailto:forces-protocol-admin@ietf.org] On Behalf Of=20 > Deleganes, Ellen M > Sent: Wednesday, March 10, 2004 5:04 PM > To: hadi@znyx.com > Cc: alex.audu@alcatel.com; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Issue 0: Application addressing >=20 > Jamal, >=20 > I think we are in agreement about the FE ID portion of the addressing > and what it identifies (an FE instance). It also looks like=20 > everyone is > in agreement that a LFBID and LFBInstanceID are also needed for the > protocol. Where there appears to be disagreement is whether the LFBID > and LFBInstanceID belong in the common header or in the TLV. >=20 > I believe, like many others that LFB-related IDs (LFBID and > LFBInstanceID) belong in the TLV and not the common header.=20 > The primary > reason is to allow one message to affect more than one LFB.=20 > This is more > reasonably handled in the TLV.=20 >=20 > If we are in agreement that the LFBID and LFBInstanceID are=20 > part of the > TLV, it seems like Issue 0 can be closed. Do others agree? >=20 > Regards, > Ellen >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, March 10, 2004 4:47 PM > To: Deleganes, Ellen M > Cc: alex.audu@alcatel.com; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Issue 0: Application addressing >=20 > On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote: > > So if you have a proxy that is "fronting" for multiple FEs,=20 > what does > > the ID contain?=20 >=20 > I would think there would be a unique ID for each FE being addressed. > Protocol doesnt care who is handling it;=20 >=20 > > If it is the ID of the proxy, how does the proxy know > > which FE to configure?=20 > > I think even in this case the ID should identify > > the FE so the proxy knows which FE the CE wishes to configure. >=20 > Exactly. So message goes say to IP X which is a proxy; but destination > ID refers uniquely to the FE. >=20 > > If this > > is the case FE ID seems to be appropriate nomenclature.=20 >=20 > So far we seem to be saying the address looks like: >=20 > ID:=3DFEID: LFBID: LFBInstanceID >=20 > So you are refering to that one portion of the ID i hope? > in which case we may have no issues.=20 >=20 > > How the message gets to the proxy should be transparent to=20 > the ForCES > > protocol.=20 >=20 > It is. >=20 > > This can be handled by correctly addressing the message (or > > putting into the right socket or whatever) at the=20 > underlying transport > > the proxy ID should not have to be part of the ForCES protocol.=20 >=20 > It is not. Nothing in the Forces header helps identify it as a proxy. >=20 > cheers, > jamal >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 20:26:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18815 for ; Wed, 10 Mar 2004 20:26:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ExY-0004qk-0N for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:26:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B1Q3mA018636 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 20:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ExX-0004qV-Ox for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 20:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18808 for ; Wed, 10 Mar 2004 20:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ExV-0004RJ-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EwY-0004Ix-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:25:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1EvY-0004AX-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 20:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EvZ-0004nU-V9; Wed, 10 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Eud-0004l2-M2 for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 20:23:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18766 for ; Wed, 10 Mar 2004 20:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Eub-00042C-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Eth-0003u6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:22:06 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Esq-0003d6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 20:21:12 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2B1MjU1002643; Thu, 11 Mar 2004 01:22:45 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2B1MPAR018298; Thu, 11 Mar 2004 01:22:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031017201817823 ; Wed, 10 Mar 2004 17:20:21 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 17:19:56 -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 Subject: RE: [Forces-protocol] Issue 0: Application addressing Message-ID: <468F3FDA28AA87429AD807992E22D07E1BB676@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 0: Application addressing Thread-Index: AcQHAqhVhSve01+mQFehcIu2Ljrr5AAAD4AAAAD3yPA= From: "Khosravi, Hormuzd M" To: "Deleganes, Ellen M" , Cc: , X-OriginalArrivalTime: 11 Mar 2004 01:19:56.0178 (UTC) FILETIME=[F69B2F20:01C40706] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Mar 2004 17:19:56 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Deleganes, Ellen M Jamal, I think we are in agreement about the FE ID portion of the addressing and what it identifies (an FE instance). It also looks like everyone is in agreement that a LFBID and LFBInstanceID are also needed for the protocol. Where there appears to be disagreement is whether the LFBID and LFBInstanceID belong in the common header or in the TLV. I believe, like many others that LFB-related IDs (LFBID and LFBInstanceID) belong in the TLV and not the common header. The primary reason is to allow one message to affect more than one LFB. This is more reasonably handled in the TLV.=20 If we are in agreement that the LFBID and LFBInstanceID are part of the TLV, it seems like Issue 0 can be closed. Do others agree? [HK] Yes, I do :-) Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 21:30:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21315 for ; Wed, 10 Mar 2004 21:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Fxb-00016Y-Sk for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2UBEh004240 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Fxb-00016J-Ms for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:30:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21309 for ; Wed, 10 Mar 2004 21:30:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1FxZ-0006VJ-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:30:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Fwi-0006NQ-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:29:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1FwQ-0006Ec-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FwS-00012h-9v; Wed, 10 Mar 2004 21:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Fvh-00010Q-8H for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 21:28:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21236 for ; Wed, 10 Mar 2004 21:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Fve-0006D9-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Fui-00064T-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:27:13 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Fu6-0005vw-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:26:34 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031018290391:624 ; Wed, 10 Mar 2004 18:29:03 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Deleganes, Ellen M" Cc: alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E1BB651@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB651@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078971991.1038.79.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 03/10/2004 06:29:04 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 06:29:06 PM, Serialize complete at 03/10/2004 06:29:06 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 21:26:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ellen, On Wed, 2004-03-10 at 20:03, Deleganes, Ellen M wrote: > Jamal, > > I think we are in agreement about the FE ID portion of the addressing > and what it identifies (an FE instance). It also looks like everyone is > in agreement that a LFBID and LFBInstanceID are also needed for the > protocol. Where there appears to be disagreement is whether the LFBID > and LFBInstanceID belong in the common header or in the TLV. > > I believe, like many others that LFB-related IDs (LFBID and > LFBInstanceID) belong in the TLV and not the common header. The primary > reason is to allow one message to affect more than one LFB. This is more > reasonably handled in the TLV. I had a small related discussion with Weiming on this and i asked for that to be deffered to later on; Let me repeat some bits of that discussion for clarity. I may be biased by the way we did things in netlink2; In netlink2 we batched several messages in one TCP or UDP PDU. In other words to send to x netlink2 messages you would have the following: L2hdr:IPhder:TCP/UDPhdr:Forcesmsg1:Forcesmsg2...ForcesMsgx (and you make sure you dont exceed the MTU) 1) The overhead in terms of processing is better with putting the LFBID within the main header because parsing of fixed headers is faster than that of TLVs. 2) Theres a space (bit-abuse) threshold where it becomes valuable to move the LFBid inside the body as a TLV. A 16 bit representing a LFBid will end up taking 64 bits (if you assume 16 bits for Type and 16 for length). So for a small batch of messages it is more valuable to put the LFBID in the main header; for a large number it is valuable to use the TLV space. The breakeven point for UDP is around 5 batched messages . Around 7 for TCP and lower for running directly over ethernet. So we may have to weight out the options and come to some conclusion. My opinion is we should probably allow both schemes - however i am not religious. I would like to hear what my other coauthors have to say on the topic before we close it. > If we are in agreement that the LFBID and LFBInstanceID are part of the > TLV, it seems like Issue 0 can be closed. Do others agree? Refer to above. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 21:53:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22389 for ; Wed, 10 Mar 2004 21:53:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GJs-0002jX-NV for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:53:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2rC4q010501 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GJs-0002jI-J6 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22383 for ; Wed, 10 Mar 2004 21:53:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GJp-0002BP-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:53:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GIv-00023d-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:52:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1GIg-0001vM-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GIj-0002hD-DK; Wed, 10 Mar 2004 21:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GHz-0002gU-ML for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 21:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22294 for ; Wed, 10 Mar 2004 21:51:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GHw-0001uc-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:51:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GH3-0001mC-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:50:18 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1GGV-0001d6-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:49:44 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031018521420:640 ; Wed, 10 Mar 2004 18:52:14 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD8029CF156@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8029CF156@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1078973382.1035.100.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 03/10/2004 06:52:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 06:52:15 PM, Serialize complete at 03/10/2004 06:52:15 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 21:49:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 20:16, Putzolu, David wrote: > So just to be clear, is the following what people are > proposing? Or is this too much detail? > > > Structure of ForCES Message: > ------------------ > | ForCES Header | <- The FE daemon (FEd) receives this. > | ( includes | Includes stuff that must be in > | FEid ) | every msg e.g. total message length. > |----------------| > | ForCES Payload | <- Elaborated below. > ------------------ > FEd processes this header, then payload (if present, > see below). FEid may be used by Fed to choose a FE > instance on a PFE (physical FE) that received the > message. This could map to a process, a mezannine > card, or whatever. Or, if there is only a single FE > that could have received this message (i.e. FE is at > end of a unicast, L3/L2 addressed connection), maybe > FEd just validates FEid is expected value and > continues... Good description. There will be messages that may terminate at the FEd (depending on implementation). Example discussions with the CEd on capabilities, joining the NE etc; > > Structure of ForCES Payload: > ------------------ > | LFB Message | <- ForCES Payload is one or more messages > |----------------| to LFBs. Many LFB messages may > | .... | be bundled in a single ForCES message. > |----------------| > | LFB Message | <- Elaborated below > ------------------ > Payload is 0 or more LFB messages. If 0 LFB messages then > ForCES header is the entire message. This is one of the two batching schemes, the other was: ------------------ | ForCES Header1 | <- The FE daemon (FEd) receives this. | ( includes | Includes stuff that must be in | FEid ) | every msg e.g. total message length. |----------------| | ForCES Payload | <- Elaborated below. ------------------ | ForCES Header2 | <- The FE daemon (FEd) receives this. | ( includes | Includes stuff that must be in | FEid ) | every msg e.g. total message length. |----------------| | ForCES Payload | <- Elaborated below. ------------------ ..... ..... .. ------------------ | ForCES Headerx | <- The FE daemon (FEd) receives this. | ( includes | Includes stuff that must be in | FEid ) | every msg e.g. total message length. |----------------| | ForCES Payload | <- Elaborated below. ------------------ Of course thats all wrapped around a TCP or UDP, etc PDU. > Structure of LFB message: > ------------------ > | LFB Identifier | <- Unique ID within the scope of a FE > | | telling FEd which LFB should be given > |----------------| this LFB message. > | LFB Message Len| <- Tells FEd how long this LFB message > |----------------| is e.g. 16 bytes. > | LFB Message | <- 16 bytes of stuff to be handed to the > | Payload | identified LFB. After handing 16 bytes to > ------------------ LFB the FEd moves forward 16 bytes and > processes next LFB message in same fashion until all done. > The FEd does not care about the message internals (including > message type), it just passes them on to LFBs. Essentially above is a TLV. > > Structure of example LFB message payload passed to LFB: > ------------------ > | LFB Command Typ| <- Tells LFB what to do e.g. "Add Route" > |----------------| > | LFB Command Val| <- Body of command e.g. "prefix = 138.12.0.0, > | | mask = 255.255.0.0, > ------------------ nexthop = 138.12.1.251" > > Does the above seem OK? Not trying to make up something new here, > just to put pictures to the words people have been sending :) > You alos want to be able to blast tons of these add route commands in one shot using an outer TLV of type "tons of route adds" and a bunch of inner ones of type "add route". I have seen an opionion expressed once that defines the values as TLVs as well; i.e prefix is a type value being 138.12.0.0, mask is a type with value of 255.255.0.0 , nexthop is a type of value 138.12.1.251. The idea was proposed by Joel; his arguement which is sane is that you could add a new TLV at any time and not have to rewrite the body of the command. I dont think this is a contentious issue at this point. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 21:58:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22550 for ; Wed, 10 Mar 2004 21:58:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GOm-0002sw-0c for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:58:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2wFVw011084 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 21:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GOl-0002sh-Oy for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22537 for ; Wed, 10 Mar 2004 21:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GOi-0002rT-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:58:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GNp-0002jF-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:57:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1GNW-0002aN-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 21:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GNY-0002r4-OG; Wed, 10 Mar 2004 21:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GMn-0002qX-3F for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 21:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22482 for ; Wed, 10 Mar 2004 21:56:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GMk-0002Zb-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:56:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GLk-0002RP-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:55:09 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1GLL-0002Jk-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 21:54:43 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031018571357:647 ; Wed, 10 Mar 2004 18:57:13 -0800 Subject: RE: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Deleganes, Ellen M" Cc: alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <1078971991.1038.79.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E1BB651@orsmsx408.jf.intel.com> <1078971991.1038.79.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1078973681.1036.105.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 03/10/2004 06:57:14 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 06:57:14 PM, Serialize complete at 03/10/2004 06:57:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 21:54:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I should have mentioned the work done by Guillame Goutaudier was very helpful for us in understanding batching better. Thanks Guillame. Reference is at: Goutaudier, G., "Enhancements and Prototype Implementation of the ForCES Netlink2 Protocol, IBM Research Report RZ3482", September 2003, . I think we can move on past issue 0. I would like my Netlink2 coauthors to comment - unfortunately they are all either tied up with customers or travelling at the moment. In any case, we can move on and revist later; i think the issue is now resolvable. cheers, jamal On Wed, 2004-03-10 at 21:26, Jamal Hadi Salim wrote: > Ellen, > > On Wed, 2004-03-10 at 20:03, Deleganes, Ellen M wrote: > > Jamal, > > > > I think we are in agreement about the FE ID portion of the addressing > > and what it identifies (an FE instance). It also looks like everyone is > > in agreement that a LFBID and LFBInstanceID are also needed for the > > protocol. Where there appears to be disagreement is whether the LFBID > > and LFBInstanceID belong in the common header or in the TLV. > > > > I believe, like many others that LFB-related IDs (LFBID and > > LFBInstanceID) belong in the TLV and not the common header. The primary > > reason is to allow one message to affect more than one LFB. This is more > > reasonably handled in the TLV. > > I had a small related discussion with Weiming on this and i asked for > that to be deffered to later on; Let me repeat some bits of that > discussion for clarity. > > I may be biased by the way we did things in netlink2; > In netlink2 we batched several messages in one TCP or UDP PDU. > In other words to send to x netlink2 messages you would > have the following: > L2hdr:IPhder:TCP/UDPhdr:Forcesmsg1:Forcesmsg2...ForcesMsgx > (and you make sure you dont exceed the MTU) > > 1) The overhead in terms of processing is better with putting the LFBID > within the main header because parsing of fixed headers is faster than > that of TLVs. > > 2) Theres a space (bit-abuse) threshold where it becomes valuable to > move the LFBid inside the body as a TLV. > A 16 bit representing a LFBid will end up taking 64 bits (if you assume > 16 bits for Type and 16 for length). > So for a small batch of messages it is more valuable to put the LFBID > in the main header; for a large number it is valuable to use > the TLV space. > The breakeven point for UDP is around 5 batched messages . Around 7 for > TCP and lower for running directly over ethernet. > > So we may have to weight out the options and come to some conclusion. > > My opinion is we should probably allow both schemes - however i am > not religious. I would like to hear what my other coauthors have to say > on the topic before we close it. > > > If we are in agreement that the LFBID and LFBInstanceID are part of the > > TLV, it seems like Issue 0 can be closed. Do others agree? > > Refer to above. > > cheers, > jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 22:22:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23382 for ; Wed, 10 Mar 2004 22:22:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gm1-0004Tg-AQ for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 22:22:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B3MHUJ017209 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 22:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gm1-0004TU-25 for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 22:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23376 for ; Wed, 10 Mar 2004 22:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Glx-0006NM-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 22:22:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gl0-0006Ey-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 22:21:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gkk-00066W-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 22:20:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gkm-0004SQ-OF; Wed, 10 Mar 2004 22:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gjz-0004RK-Mp for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 22:20:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23314 for ; Wed, 10 Mar 2004 22:20:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gjw-00065U-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 22:20:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gj0-0005xs-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 22:19:11 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1Gip-0005pz-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 22:19:00 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 11 Mar 2004 11:30:07 +0800 Message-ID: <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 11:16:36 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, Hormuzd, It's just a misprint of FEID:LFBTypeID:LFBInstanceID. Does FEID:FETypeID:FEInstanceID really mean something? Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Cc: "Wang,Weiming" ; Sent: Thursday, March 11, 2004 5:41 AM Subject: RE: [Forces-protocol] Issue 0: Application addressing Jamal, It seems like there is a typo below, I didn't notice it before. I am agreeing to FEID:LFBTypeID:LFBInstanceID scheme being proposed for the protocol and model. Thanks for clarifying this, Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > As Jamal asked, I'll first clarify what the tree > FEID:FETypeID:FEInstanceID > [HK] I definitely agree with Weiming on this addressing scheme and how > to place it in the protocol. This is same as the FE Model and I don't > see any issues with this scheme. Hormuzd, What is it that you are agreeing to? is it the FEID:FETypeID:FEInstanceID or FEID:LFBTypeID:LFBInstanceID scheme he described? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 23:03:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24666 for ; Wed, 10 Mar 2004 23:03:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HPw-0006gI-L0 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 23:03:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B43WfI025682 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 23:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HPw-0006g9-FQ for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 23:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24661 for ; Wed, 10 Mar 2004 23:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1HPs-0004Pg-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:03:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1HOq-0004En-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:02:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1HOR-00044x-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HOU-0006cX-4w; Wed, 10 Mar 2004 23:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HNk-0006be-Le for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 23:01:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24561 for ; Wed, 10 Mar 2004 23:01:12 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1HNh-00043K-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 23:01:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1HMi-0003uX-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 23:00:12 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B1HMT-0003ma-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 22:59:57 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i2B488ep032565 for ; Thu, 11 Mar 2004 05:08:10 +0100 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1078971991.1038.79.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E1BB651@orsmsx408.jf.intel.com> <1078971991.1038.79.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <896B19B7-7310-11D8-B275-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 0: Application addressing To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 12:59:46 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11 mar 2004, at 11.26, Jamal Hadi Salim wrote: > L2hdr:IPhder:TCP/UDPhdr:Forcesmsg1:Forcesmsg2...ForcesMsgx > (and you make sure you dont exceed the MTU) > > 1) The overhead in terms of processing is better with putting the LFBID > within the main header because parsing of fixed headers is faster than > that of TLVs. > > 2) Theres a space (bit-abuse) threshold where it becomes valuable to > move the LFBid inside the body as a TLV. > A 16 bit representing a LFBid will end up taking 64 bits (if you assume > 16 bits for Type and 16 for length). > So for a small batch of messages it is more valuable to put the LFBID > in the main header; for a large number it is valuable to use > the TLV space. > The breakeven point for UDP is around 5 batched messages . Around 7 for > TCP and lower for running directly over ethernet. > > So we may have to weight out the options and come to some conclusion. > > My opinion is we should probably allow both schemes - however i am > not religious. I would like to hear what my other coauthors have to say > on the topic before we close it. I think think allowing both my represent an interoperability problem. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 10 23:13:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25107 for ; Wed, 10 Mar 2004 23:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HYl-0007cH-QO for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 23:12:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B4CdGN029272 for forces-protocol-archive@odin.ietf.org; Wed, 10 Mar 2004 23:12:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HYl-0007c2-1l for forces-protocol-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 23:12:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25050 for ; Wed, 10 Mar 2004 23:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1HYi-0005uF-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:12:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1HXH-0005Yy-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:11:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1HVD-0005EB-00 for forces-protocol-web-archive@ietf.org; Wed, 10 Mar 2004 23:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HVF-0007Lh-Sm; Wed, 10 Mar 2004 23:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1HUr-0007Iz-0T for forces-protocol@optimus.ietf.org; Wed, 10 Mar 2004 23:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24804 for ; Wed, 10 Mar 2004 23:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1HUm-0005Bx-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 23:08:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1HSW-0004r9-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 23:06:14 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1HQf-0004Xt-00 for forces-protocol@ietf.org; Wed, 10 Mar 2004 23:04:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031020064848:690 ; Wed, 10 Mar 2004 20:06:48 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078977856.1038.110.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 03/10/2004 08:06:48 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2004 08:06:49 PM, Serialize complete at 03/10/2004 08:06:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Mar 2004 23:04:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, On Wed, 2004-03-10 at 22:16, Wang,Weiming wrote: > Hi Jamal, Hormuzd, > > It's just a misprint of FEID:LFBTypeID:LFBInstanceID. Does > FEID:FETypeID:FEInstanceID really mean something? FEID and FEInstanceID may have valid meaning; in any case check the discussion so far. One thing i would like to ensure we have lost in all that discussion is the semantics of multi/uni/broadcast IDs with ID being FEID:LFBTypeID:LFBInstanceID I believe we are all in agreement on the need for that unless i am mistaken. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 01:11:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00294 for ; Thu, 11 Mar 2004 01:11:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JPZ-0007uO-D0 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 01:11:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B6BHeX030394 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 01:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JPZ-0007u9-8l for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 01:11:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00139 for ; Thu, 11 Mar 2004 01:11:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JPW-00012E-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 01:11:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JNf-0000XP-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 01:09:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1JMY-0000C4-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 01:08:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1JEj-00062N-D0 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 01:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JEi-0006TI-2d; Thu, 11 Mar 2004 01:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JDv-0006SB-J8 for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 00:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29735 for ; Thu, 11 Mar 2004 00:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JDs-0006wy-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 00:59:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JCv-0006pR-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 00:58:14 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1JCE-0006iL-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 00:57:30 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 11 Mar 2004 14:08:50 +0800 Message-ID: <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> <1078977856.1038.110.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 13:55:20 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, To be hornest, we (GRMPs) have originally mainly considered the unicast/broadcast implementation based on FEID:LFBTypeID:LFBInstanceID, which can be shown as below: Firstly, we define three sepcific IDs for broadcast: FEID=0xffff, LFBTypeID=0xffff, LFBInstanceID=0xffff Then, . to address all FEs regarding the FE coarse layer manangement, just use FEID=0xffff . to address one LFB in one FE, use FEID:LFBTypeID:LFBInstanceID . to address all LFBs with the same type in one FE, use FEID:LFBTypeID:0xffff or just use FEID:LFBTypeID . to address all LFBs with the same type in all FEs, use 0xffff:LFBTypeID:0xffff or just use 0xffff:LFBTypeID . to address all LFBs with all types in one FE, use FEID:0xffff:0xffff, or just use FEID:0xffff . to address all LFBs with all types in all FEs, use 0xffff:0xffff:0xffff, or just use 0xffff:0xffff Because the three broadcast IDs is explicitly defined in the protocol, and all CEs and FEs with different vendors can understand it without any further information change between CEs and FEs, the above broadcast scheme can be implemented quite conviniently. Moreover, the above broadcast scheme has truly powered the addressing mechanism greatly, and we think it has met most ForCES requirements for fast and group addresssing. On multicast, one possible approach is to define GroupFEID (as mentioned by latest version of FACT), GroupLFBTypeID and GroupInstanceID. But generally, these group IDs will not be explicitly defined in the protocol, therefore, an exchange for such multicast IDs between CEs and FEs are required. For group FE ID, a something like "hook" (we actually have mentioned this earlier in the ForCES list) is needed to map the ID into transport layer multicast ID. When we deeply consider these group IDs, we find that its really unwise to stretch the multicast to LFBInstance layer, which may just burden us too much while the reward is less. Therefore, the most possible multicast will happen at FE layer and LFBType layer. Anyway, I agree with Jamal that we need to discuss this in the addressing issue instead in the issue 3. BTW, Jamal, I'm supprised it seems you can work almost 24H a day, though I'v been working more than 12H a day. :) Yours, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Wang,Weiming" Cc: Sent: Thursday, March 11, 2004 12:04 PM Subject: Re: [Forces-protocol] Issue 0: Application addressing > Weiming, > > On Wed, 2004-03-10 at 22:16, Wang,Weiming wrote: > > Hi Jamal, Hormuzd, > > > > It's just a misprint of FEID:LFBTypeID:LFBInstanceID. Does > > FEID:FETypeID:FEInstanceID really mean something? > > FEID and FEInstanceID may have valid meaning; in any case check the > discussion so far. > One thing i would like to ensure we have lost in all that discussion > is the semantics of multi/uni/broadcast IDs with ID being > FEID:LFBTypeID:LFBInstanceID > > I believe we are all in agreement on the need for that unless i am > mistaken. > > cheers, > jamal > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 04:54:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22337 for ; Thu, 11 Mar 2004 04:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MtI-0004na-K4 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 04:54:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9sCis018440 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 04:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MtH-0004nL-0d for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 04:54:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22276 for ; Thu, 11 Mar 2004 04:54:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1MtD-0005Z3-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 04:54:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mrz-0005LY-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 04:52:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1MrA-00059P-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 04:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MrC-0004Lc-Hm; Thu, 11 Mar 2004 04:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mqm-0004Jy-6y for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 04:51:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22182 for ; Thu, 11 Mar 2004 04:51:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mqj-00055Y-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 04:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mpu-0004su-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 04:50:43 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1Moy-0004fr-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 04:49:44 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 11 Mar 2004 18:00:56 +0800 Message-ID: <102701c4074d$db86fe70$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD8029CF156@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 17:47:24 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Hi David, Some inline comments. Cheers, Weiming ----- Original Message ----- From: "Putzolu, David" To: "Deleganes, Ellen M" ; Cc: Sent: Thursday, March 11, 2004 9:16 AM Subject: RE: [Forces-protocol] Issue 0: Application addressing So just to be clear, is the following what people are proposing? Or is this too much detail? Structure of ForCES Message: ------------------ | ForCES Header | <- The FE daemon (FEd) receives this. | ( includes | Includes stuff that must be in | FEid ) | every msg e.g. total message length. |----------------| | ForCES Payload | <- Elaborated below. ------------------ FEd processes this header, then payload (if present, see below). FEid may be used by Fed to choose a FE instance on a PFE (physical FE) that received the message. This could map to a process, a mezannine card, or whatever. Or, if there is only a single FE that could have received this message (i.e. FE is at end of a unicast, L3/L2 addressed connection), maybe FEd just validates FEid is expected value and continues... Structure of ForCES Payload: ------------------ | LFB Message | <- ForCES Payload is one or more messages |----------------| to LFBs. Many LFB messages may | .... | be bundled in a single ForCES message. |----------------| | LFB Message | <- Elaborated below ------------------ Payload is 0 or more LFB messages. If 0 LFB messages then ForCES header is the entire message. [Wang Re: The possible message types at the ForCES payload layer may not just that of LFB Messages. They may be messages for FE coarse layer operations that do not mean any LFBs, like FE event report, or may be CE event reports, etc. ] Structure of LFB message: ------------------ | LFB Identifier | <- Unique ID within the scope of a FE | | telling FEd which LFB should be given |----------------| this LFB message. | LFB Message Len| <- Tells FEd how long this LFB message |----------------| is e.g. 16 bytes. | LFB Message | <- 16 bytes of stuff to be handed to the | Payload | identified LFB. After handing 16 bytes to ------------------ LFB the FEd moves forward 16 bytes and processes next LFB message in same fashion until all done. The FEd does not care about the message internals (including message type), it just passes them on to LFBs. [Wang Re: Because of the reason I mentioned above, the Type in the message TLV will have global meaning in ForCES protocol, which means the Type should not only include all LFB ID types but also Types like FE event report, FE attributes, and even ACK type. This actually has brought another problem, the Type space should be larger than space for LFB ID, which means 16bits Type space is not enough.] Structure of example LFB message payload passed to LFB: ------------------ | LFB Command Typ| <- Tells LFB what to do e.g. "Add Route" |----------------| | LFB Command Val| <- Body of command e.g. "prefix = 138.12.0.0, | | mask = 255.255.0.0, ------------------ nexthop = 138.12.1.251" Does the above seem OK? Not trying to make up something new here, just to put pictures to the words people have been sending :) -David > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of > Deleganes, Ellen M > Sent: Wednesday, March 10, 2004 5:04 PM > To: hadi@znyx.com > Cc: alex.audu@alcatel.com; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Issue 0: Application addressing > > Jamal, > > I think we are in agreement about the FE ID portion of the addressing > and what it identifies (an FE instance). It also looks like > everyone is > in agreement that a LFBID and LFBInstanceID are also needed for the > protocol. Where there appears to be disagreement is whether the LFBID > and LFBInstanceID belong in the common header or in the TLV. > > I believe, like many others that LFB-related IDs (LFBID and > LFBInstanceID) belong in the TLV and not the common header. > The primary > reason is to allow one message to affect more than one LFB. > This is more > reasonably handled in the TLV. > > If we are in agreement that the LFBID and LFBInstanceID are > part of the > TLV, it seems like Issue 0 can be closed. Do others agree? > > Regards, > Ellen > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, March 10, 2004 4:47 PM > To: Deleganes, Ellen M > Cc: alex.audu@alcatel.com; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Issue 0: Application addressing > > On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote: > > So if you have a proxy that is "fronting" for multiple FEs, > what does > > the ID contain? > > I would think there would be a unique ID for each FE being addressed. > Protocol doesnt care who is handling it; > > > If it is the ID of the proxy, how does the proxy know > > which FE to configure? > > I think even in this case the ID should identify > > the FE so the proxy knows which FE the CE wishes to configure. > > Exactly. So message goes say to IP X which is a proxy; but destination > ID refers uniquely to the FE. > > > If this > > is the case FE ID seems to be appropriate nomenclature. > > So far we seem to be saying the address looks like: > > ID:=FEID: LFBID: LFBInstanceID > > So you are refering to that one portion of the ID i hope? > in which case we may have no issues. > > > How the message gets to the proxy should be transparent to > the ForCES > > protocol. > > It is. > > > This can be handled by correctly addressing the message (or > > putting into the right socket or whatever) at the > underlying transport > > the proxy ID should not have to be part of the ForCES protocol. > > It is not. Nothing in the Forces header helps identify it as a proxy. > > cheers, > jamal > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 06:33:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26448 for ; Thu, 11 Mar 2004 06:33:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OQX-0003Mz-H7 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 06:32:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BBWbpc012952 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 06:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OQX-0003Mp-6N for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 06:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26431 for ; Thu, 11 Mar 2004 06:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1OQT-0006X0-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:32:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1OPn-0006OX-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1OOw-0006Cp-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:30:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OOz-0003J3-89; Thu, 11 Mar 2004 06:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OOX-0003Gs-5O for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 06:30:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26280 for ; Thu, 11 Mar 2004 06:30:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1OOT-00067T-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:30:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ONU-0005pN-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:29:28 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1OMH-0005Xg-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:28:13 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031103304138:919 ; Thu, 11 Mar 2004 03:30:41 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing (unicast/broadcast) From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> <1078977856.1038.110.camel@jzny.localdomain> <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079004488.1038.127.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 03/11/2004 03:30:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/11/2004 03:30:45 AM, Serialize complete at 03/11/2004 03:30:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Mar 2004 06:28:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote: > Hi Jamal, > > To be hornest, we (GRMPs) have originally mainly considered the > unicast/broadcast implementation based on FEID:LFBTypeID:LFBInstanceID, which > can be shown as below: > > Firstly, we define three sepcific IDs for broadcast: FEID=0xffff, > LFBTypeID=0xffff, LFBInstanceID=0xffff In the general principle this is what netlink2 does as well. Note i am trying to adjust my thoughts to the new scheme compared to exactly what we did, so thanks for posting this. > Then, > . to address all FEs regarding the FE coarse layer manangement, just use > FEID=0xffff Makes sense > . to address one LFB in one FE, use FEID:LFBTypeID:LFBInstanceID Unicast essentially > . to address all LFBs with the same type in one FE, use FEID:LFBTypeID:0xffff or > just use FEID:LFBTypeID could translate to update attribute X on all LFBinstances on this LFB for this FEID. > . to address all LFBs with the same type in all FEs, use 0xffff:LFBTypeID:0xffff > or just use 0xffff:LFBTypeID Sensible. > . to address all LFBs with all types in one FE, use FEID:0xffff:0xffff, or just > use FEID:0xffff When would this be useful? > . to address all LFBs with all types in all FEs, use 0xffff:0xffff:0xffff, or > just use 0xffff:0xffff When would you wanna do this? > Because the three broadcast IDs is explicitly defined in the protocol, and all > CEs and FEs with different vendors can understand it without any further > information change between CEs and FEs, Static definition of broadcast is well understood. Let me cut the email here and address the other issue in a separate email. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 06:49:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27740 for ; Thu, 11 Mar 2004 06:49:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OgC-0004eV-Ak for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 06:48:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BBmmqH017877 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 06:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OgC-0004eG-4T for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 06:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27735 for ; Thu, 11 Mar 2004 06:48:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Og8-0001qi-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:48:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1OfF-0001gW-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:47:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1OeR-0001WF-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:46:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1OeT-0003JB-Vw for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 06:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OeT-0004WJ-Ir; Thu, 11 Mar 2004 06:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ody-0004Ux-3h for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 06:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27631 for ; Thu, 11 Mar 2004 06:46:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Odu-0001T6-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:46:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ocw-0001J4-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:45:26 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1Oc2-0000Kc-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 06:44:30 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 11 Mar 2004 19:52:21 +0800 Message-ID: <104b01c4075d$6bf2e550$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> <1078977856.1038.110.camel@jzny.localdomain> <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> <1079004488.1038.127.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Issue 0: Application addressing(unicast/broadcast) 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 19:38:46 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > > On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote: > > Hi Jamal, > > > > To be hornest, we (GRMPs) have originally mainly considered the > > unicast/broadcast implementation based on FEID:LFBTypeID:LFBInstanceID, which > > can be shown as below: > > > > Firstly, we define three sepcific IDs for broadcast: FEID=0xffff, > > LFBTypeID=0xffff, LFBInstanceID=0xffff > > In the general principle this is what netlink2 does as well. > Note i am trying to adjust my thoughts to the new scheme compared to > exactly what we did, so thanks for posting this. > > > Then, > > . to address all FEs regarding the FE coarse layer manangement, just use > > FEID=0xffff > > Makes sense > > > . to address one LFB in one FE, use FEID:LFBTypeID:LFBInstanceID > > Unicast essentially > > > . to address all LFBs with the same type in one FE, use FEID:LFBTypeID:0xffff or > > just use FEID:LFBTypeID > > could translate to update attribute X on all LFBinstances on this LFB > for this FEID. > > > . to address all LFBs with the same type in all FEs, use 0xffff:LFBTypeID:0xffff > > or just use 0xffff:LFBTypeID > > Sensible. > > > . to address all LFBs with all types in one FE, use FEID:0xffff:0xffff, or just > > use FEID:0xffff > > When would this be useful? [Wang Re: For very simple instance, something likt to start or stop all LFBs] > > > . to address all LFBs with all types in all FEs, use 0xffff:0xffff:0xffff, or > > just use 0xffff:0xffff > > When would you wanna do this? [Wang Re: as above] > > > Because the three broadcast IDs is explicitly defined in the protocol, and all > > CEs and FEs with different vendors can understand it without any further > > information change between CEs and FEs, > > Static definition of broadcast is well understood. > Let me cut the email here and address the other issue in a separate > email. > [Wang Re: Agreed, we need to hurry up.] Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 07:07:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28424 for ; Thu, 11 Mar 2004 07:07:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OxL-0006D5-Pc for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 07:06:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BC6Vf9023870 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 07:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OxL-0006Bq-Bs for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 07:06:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28415 for ; Thu, 11 Mar 2004 07:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1OxH-0004Qq-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 07:06:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1OwM-0004Jj-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 07:05:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Ovr-0004Cf-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 07:04:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ovu-0005u5-Ix; Thu, 11 Mar 2004 07:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1OvO-0005tG-NY for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 07:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28335 for ; Thu, 11 Mar 2004 07:04:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1OvK-0004BM-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 07:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1OuO-00043t-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 07:03:29 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Otk-0003wX-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 07:02:48 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031104051856:939 ; Thu, 11 Mar 2004 04:05:18 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing (multicast) From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> <1078977856.1038.110.camel@jzny.localdomain> <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079006565.1038.163.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 03/11/2004 04:05:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/11/2004 04:05:20 AM, Serialize complete at 03/11/2004 04:05:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Mar 2004 07:02:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote: > On multicast, one possible approach is to define GroupFEID (as mentioned by > latest version of FACT), GroupLFBTypeID and GroupInstanceID. But generally, > these group IDs will not be explicitly defined in the protocol, therefore, an > exchange for such multicast IDs between CEs and FEs are required. I dont see much difference from std multicast. The FEs and CEs will need to "join" groups already predefined (although the groups could be dynamically defined at the cost of adding some complexity). > For group FE > ID, a something like "hook" (we actually have mentioned this earlier in the > ForCES list) is needed to map the ID into transport layer multicast ID. The application level multicast should NOT be dependent on transport level multicast. i.e you should be able to use unicast transport with multicast or broadcast at the app level. Lets get to the transport, their mappings and semantics on issue 2. > When we > deeply consider these group IDs, we find that its really unwise to stretch the > multicast to LFBInstance layer, which may just burden us too much while the > reward is less. Therefore, the most possible multicast will happen at FE layer > and LFBType layer. Sounds sensible. Experience may change that view. > BTW, Jamal, I'm supprised it seems you can work almost 24H a day, though I'v > been working more than 12H a day. :) Some people have accused me of having a presence of 25 hours a day;->. Alex has infact insuniated i dont have work and on the other extreme some customers have wondered if i was a department of people;-> But if you think i have clones (in case you are following some of my Linux activities or have figured out that i have a new baby) wait until you meet more interesting people like Alan Cox. On a serious side, i am trying my best to make concessions whenever sensible and speed up the process so we can move on. I have this list as about the same priority as the one i use for our customers at the moment. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 10:47:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07530 for ; Thu, 11 Mar 2004 10:47:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SOc-0004fD-Dz for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 10:46:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BFksK8017923 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 10:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SOc-0004f0-94 for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 10:46:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07514 for ; Thu, 11 Mar 2004 10:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SOZ-0002wF-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 10:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1SNd-0002n4-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 10:45:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1SMm-0002e9-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 10:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SMo-0004c0-HX; Thu, 11 Mar 2004 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SMb-0004b2-86 for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 10:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07371 for ; Thu, 11 Mar 2004 10:44:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SMY-0002bz-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 10:44:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1SLd-0002U1-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 10:43:50 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1SKx-0002Ij-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 10:43:07 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2BFgaTN002785; Thu, 11 Mar 2004 09:42:36 -0600 (CST) Message-ID: <405088EB.3040004@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> In-Reply-To: <1078966003.1037.59.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------070409010204060403080209" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 09:42:35 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070409010204060403080209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Jamal, I think I see the crux of your argument. So, you route a message to the proxy with an ID (say FEID), and you are wondering how you address the dumb FEs that are being proxied. And you are refering to these dumb FEs as instances of the proxy FE. Im I correct? But you forget that the proxy and the dumb FEs share the same IP address. They probably have different transport addresses (different ports). So, lets say there are two dumb FEs (FE1 and FE2) attached to this proxy at address A. If the CE sends message to FE1, it will be routed to the proxy at address A, who will then forward it to FE1 based on the FEID in the message. The CE will create objects for FE1 and FE2 such that FE1 has FEID=1 and IpAddress = A, and FE2 has FEID=2, and IpAddress=A . I don't see any conflict; do you? Regards, Alex. Jamal Hadi Salim wrote: >On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote: > > > >>This can be handled by correctly addressing the message (or >>putting into the right socket or whatever) at the underlying transport >>the proxy ID should not have to be part of the ForCES protocol. >> >> > >It is not. Nothing in the Forces header helps identify it as a proxy. > >cheers, >jamal > > > > --------------070409010204060403080209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jamal,

I think I see the crux of your argument.  So, you route a message to the proxy with
an ID (say FEID), and you are wondering how you address the dumb FEs that are
being proxied. And you are refering to these dumb FEs as instances of the proxy FE.
Im I correct?

But you forget that the proxy and the dumb FEs share the same IP address. They
probably have different transport addresses (different ports).  So, lets say there are
two dumb FEs (FE1 and FE2) attached to this proxy at address A.  If the CE sends
message to FE1, it will be routed to the proxy at address A,  who will then forward
it to FE1 based  on the FEID in the message.

The CE will create objects for FE1 and FE2 such that FE1 has  FEID=1 and
IpAddress = A, and FE2 has FEID=2, and IpAddress=A .

I don't see any conflict; do you?

Regards,
Alex.  

Jamal Hadi Salim wrote:
On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote:
  

This can be handled by correctly addressing the message (or
putting into the right socket or whatever) at the underlying transport
the proxy ID should not have to be part of the ForCES protocol. 
    

It is not. Nothing in the Forces header helps identify it as a proxy.

cheers,
jamal
--------------070409010204060403080209-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 12:43:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12789 for ; Thu, 11 Mar 2004 12:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UCq-0006WA-PN for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 12:42:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BHgqK9025046 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 12:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UCo-0006Vm-6h for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 12:42:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12769 for ; Thu, 11 Mar 2004 12:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UCm-0004Tx-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 12:42:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1UBq-0004LT-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 12:41:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1UB6-0004Db-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 12:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UB7-0006H5-A7; Thu, 11 Mar 2004 12:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UAo-0006Fz-OD for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 12:40:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12714 for ; Thu, 11 Mar 2004 12:40:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UAn-0004C5-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 12:40:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1U9v-00044t-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 12:39:52 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1U99-0003oV-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 12:39:03 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2BHcQTN000678; Thu, 11 Mar 2004 11:38:27 -0600 (CST) Message-ID: <4050A412.4030200@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Wang,Weiming" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 0: Application addressing (multicast) References: <468F3FDA28AA87429AD807992E22D07E1BB3A3@orsmsx408.jf.intel.com> <0e8601c40717$434341e0$845c21d2@Necom.hzic.edu.cn> <1078977856.1038.110.camel@jzny.localdomain> <0f5701c4072d$6fbd3490$845c21d2@Necom.hzic.edu.cn> <1079006565.1038.163.camel@jzny.localdomain> In-Reply-To: <1079006565.1038.163.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------090900040006000203040500" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 11:38:26 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090900040006000203040500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree, ..I don't see any need for GroupFEID, and other such group IDs. Alex. Jamal Hadi Salim wrote: >Weiming, > >On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote: > > > >>On multicast, one possible approach is to define GroupFEID (as mentioned by >>latest version of FACT), GroupLFBTypeID and GroupInstanceID. But generally, >>these group IDs will not be explicitly defined in the protocol, therefore, an >>exchange for such multicast IDs between CEs and FEs are required. >> >> > >I dont see much difference from std multicast. The FEs and CEs >will need to "join" groups already predefined (although the groups could >be dynamically defined at the cost of adding some complexity). > > > >>For group FE >>ID, a something like "hook" (we actually have mentioned this earlier in the >>ForCES list) is needed to map the ID into transport layer multicast ID. >> >> > >The application level multicast should NOT be dependent on transport >level multicast. i.e you should be able to use unicast transport with >multicast or broadcast at the app level. >Lets get to the transport, their mappings and semantics on issue 2. > > > >>When we >>deeply consider these group IDs, we find that its really unwise to stretch the >>multicast to LFBInstance layer, which may just burden us too much while the >>reward is less. Therefore, the most possible multicast will happen at FE layer >>and LFBType layer. >> >> > >Sounds sensible. Experience may change that view. > > > >>BTW, Jamal, I'm supprised it seems you can work almost 24H a day, though I'v >>been working more than 12H a day. :) >> >> > >Some people have accused me of having a presence of 25 hours a >day;->. Alex has infact insuniated i dont have work and on the other >extreme some customers have wondered if i was a department of people;-> >But if you think i have clones (in case you are following some of my >Linux activities or have figured out that i have a new baby) wait until >you meet more interesting people like Alan Cox. > >On a serious side, i am trying my best to make concessions whenever >sensible and speed up the process so we can move on. I have this list as >about the same priority as the one i use for our customers at the >moment. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------090900040006000203040500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree, ..I don't see any need for GroupFEID, and other such group IDs.

Alex.

Jamal Hadi Salim wrote:
Weiming,

On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote:

  
On multicast, one possible approach is to define GroupFEID (as mentioned by
latest version of FACT), GroupLFBTypeID and GroupInstanceID. But generally,
these group IDs will not be explicitly defined in the protocol, therefore, an
exchange for such multicast IDs between CEs and FEs are required. 
    

I dont see much difference from std multicast. The FEs and CEs
will need to "join" groups already predefined (although the groups could
be dynamically defined at the cost of adding some complexity).  

  
For group FE
ID, a something like "hook" (we actually have mentioned this earlier in the
ForCES list) is needed to map the ID into transport layer multicast ID. 
    

The application level multicast should NOT be dependent on transport
level multicast. i.e you should be able to use unicast transport with
multicast or broadcast at the app level.
Lets get to the transport, their mappings and semantics on issue 2.

  
When we
deeply consider these group IDs, we find that its really unwise to stretch the
multicast to LFBInstance layer, which may just burden us too much while the
reward is less. Therefore, the most possible multicast will happen at FE layer
and LFBType layer.
    

Sounds sensible. Experience may change that view.

  
BTW, Jamal, I'm supprised it seems you can work almost 24H a day, though I'v
been working more than 12H a day. :)
    

Some people have accused me of having a presence of 25 hours a 
day;->. Alex has infact insuniated i dont have work and on the other
extreme some customers have wondered if i was a department of people;->
But if you think i have clones (in case you are following some of my
Linux activities or have figured out that i have a new baby) wait until
you meet more interesting people like Alan Cox.

On a serious side, i am trying my best to make concessions whenever
sensible and speed up the process so we can move on. I have this list as
about the same priority as the one i use for our customers at the
moment.

cheers,
jamal


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------090900040006000203040500-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 16:07:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25902 for ; Thu, 11 Mar 2004 16:07:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XOj-00020v-PS for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 16:07:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BL7Lkj007735 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 16:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XOi-00020L-SH for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 16:07:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25697 for ; Thu, 11 Mar 2004 16:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1XOh-0003fK-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 16:07:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1XM7-00034W-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 16:04:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1XKk-0002gK-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 16:03:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1XDm-0002sl-93 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 15:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1XDk-00081S-SX; Thu, 11 Mar 2004 15:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1WOH-0006Ui-Vh for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 15:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19199 for ; Thu, 11 Mar 2004 15:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1WOF-0000tj-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 15:02:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1WNM-0000nE-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 15:01:52 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1WN0-0000gO-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 15:01:30 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031112035562:1399 ; Thu, 11 Mar 2004 12:03:55 -0800 Subject: Re: [Forces-protocol] Issue 0: Application addressing From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <405088EB.3040004@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> Organization: Znyx Networks Message-Id: <1079035283.1038.65.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 03/11/2004 12:03:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/11/2004 12:04:00 PM, Serialize complete at 03/11/2004 12:04:00 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Mar 2004 15:01:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, On Thu, 2004-03-11 at 10:42, Alex Audu wrote: > Hello Jamal, > > I think I see the crux of your argument. So, you route a message to > the proxy with > an ID (say FEID), and you are wondering how you address the dumb FEs > that are > being proxied. And you are refering to these dumb FEs as instances of > the proxy FE. > Im I correct? The point i was trying to make is you can have one end point that owns several FEIDs. Call it a proxy etc. > But you forget that the proxy and the dumb FEs share the same IP > address. It doesnt matter if the "proxy" has one or more IPs and whether they are multihomed or aliased on the same interface; > They > probably have different transport addresses (different ports). So, > lets say there are > two dumb FEs (FE1 and FE2) attached to this proxy at address A. If > the CE sends > message to FE1, it will be routed to the proxy at address A, who will > then forward > it to FE1 based on the FEID in the message. Now you are suggesting an implementation. Another implementation is they all go to the same IP transport protocol port and the process muxes them using pigeons to the correct FE based on FEID etc. > The CE will create objects for FE1 and FE2 such that FE1 has FEID=1 > and > IpAddress = A, and FE2 has FEID=2, and IpAddress=A . > > I don't see any conflict; do you? There are no conflicts, but your proposal is implementation specific. I think we have reached a general understanding on this topic. In your other email you say: On Thu, 2004-03-11 at 12:38, Alex Audu wrote: > I agree, ..I don't see any need for GroupFEID, and other such group > IDs. > I actually wasnt agreeing with what you said above. I think the grouping of IDs is needed; the mechanics is what i was commenting on. BTW, momentum is dead. Who is the taker for topic #3? I could take it. Starting a timer ... cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 19:54:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07994 for ; Thu, 11 Mar 2004 19:54:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avm-0004Zg-KN for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0rgtR017580 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 19:53:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1avm-0004ZT-3t for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07765 for ; Thu, 11 Mar 2004 19:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1avk-0004Ta-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 19:53:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1as1-0003N6-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 19:49:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aon-0002bd-03 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1abC-0005IV-79 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 19:32:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ab5-0001gr-Lm; Thu, 11 Mar 2004 19:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Y04-0004lt-Qa for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 16:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28868 for ; Thu, 11 Mar 2004 16:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Y02-0002CU-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 16:45:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Xz6-000253-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 16:44:56 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1XyQ-0001qy-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 16:44:14 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2BLhhTN015154; Thu, 11 Mar 2004 15:43:43 -0600 (CST) Message-ID: <4050DD8D.5040301@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> In-Reply-To: <1079035283.1038.65.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------010702090907010409000205" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 15:43:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------010702090907010409000205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Issue 3: We can start by agreeing that Unicast is a MUST implement, and MCAST, BCAST a SHOULD. Any comments? As an asside, on the GroupFEID issue, certainly you can define any grouping to help the application accomplish its goal, but we don't want that bubled up to the protocol addressing structure. Regards, Alex. Jamal Hadi Salim wrote: >In your other email you say: > >On Thu, 2004-03-11 at 12:38, Alex Audu wrote: > > >>I agree, ..I don't see any need for GroupFEID, and other such group >>IDs. >> >> >> > >I actually wasnt agreeing with what you said above. I think the grouping >of IDs is needed; the mechanics is what i was commenting on. > >BTW, momentum is dead. Who is the taker for topic #3? I could take it. >Starting a timer ... > >cheers, >jamal > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------010702090907010409000205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 3:

We can start by agreeing that Unicast is a MUST implement, and MCAST, BCAST a
SHOULD.

Any comments?


As an asside, on the GroupFEID  issue, certainly you can define any grouping to
help the application accomplish its goal, but we don't want that bubled up to the
protocol addressing structure.

Regards,
Alex.
Jamal Hadi Salim wrote:
In your other email you say:

On Thu, 2004-03-11 at 12:38, Alex Audu wrote: 
  
I agree, ..I don't see any need for GroupFEID, and other such group
IDs.

    

I actually wasnt agreeing with what you said above. I think the grouping
of IDs is needed; the mechanics is what i was commenting on.

BTW, momentum is dead. Who is the taker for topic #3? I could take it.
Starting a timer ...

cheers,
jamal



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------010702090907010409000205-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 11 23:13:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15741 for ; Thu, 11 Mar 2004 23:13:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1e2O-0006Nm-Im for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 23:12:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C4CiP4024528 for forces-protocol-archive@odin.ietf.org; Thu, 11 Mar 2004 23:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1e2O-0006NX-Cb for forces-protocol-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 23:12:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15734 for ; Thu, 11 Mar 2004 23:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1e2M-00002X-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 23:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1e1Y-0007iT-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 23:11:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1e0g-0007ay-00 for forces-protocol-web-archive@ietf.org; Thu, 11 Mar 2004 23:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1e0j-0006Lt-9M; Thu, 11 Mar 2004 23:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dzy-0006LF-NK for forces-protocol@optimus.ietf.org; Thu, 11 Mar 2004 23:10:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15687 for ; Thu, 11 Mar 2004 23:10:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dzv-0007a4-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 23:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1dz2-0007Tl-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 23:09:18 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1dyX-0007NQ-00 for forces-protocol@ietf.org; Thu, 11 Mar 2004 23:08:46 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 12 Mar 2004 12:19:50 +0800 Message-ID: <111501c407e7$5e2a0b30$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: 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 Subject: [Forces-protocol] Issue 2: Multiple channels/connections Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 12:06:17 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Hi, all I don't know why it suddenly becomes so silent here. To try to speed up the process, pls allow me to activate the Issue 2. I know Hormuzd may be writing something, it just does not conflict. This issue has in fact been quite largely discussed. I (suppose Jamal also ) think what we need to do now is just to find more reasons for such arrangement. Our team idea is: 1. The idea to distinguish the Control packets from Data packets to have them able to be differently processed is very useful for DoS protection as well as for achieving different transport reliability, therefore it MUST be included in ForCES protocol. 2. It seems no use (I suppose Jamal says little use) for us to protect DoS by stretching out such distinguish to physical link (that is to setup two different channels for the two kinds of packets), therefore, it should not be described as a kind of DoS protection means in the protocol. 3. To setup two different channels to achieve different reliability may be practical, but it should not be described as a MUST item in the protocol, instead a "RECOMMEND" is better. This is because we must consider that we have already required the ForCES protocol SHOULD be able to support multiple interconnections, and in some interconnections like some backplanes (we should allow many kinds of backplane connections), we are actually not very sure if a separate channel is available or how it is separated. Actually currently, we only know that over IP network, UDP and TCP can be used for such separation. We also don't have to explicitly list how such separation is implemented. On the other hand, not to use lower reliability channel for Data packet transport actually does not harm too much. As a result, we suggest the protocol description may be look like "If available at transport layer, ForCES protocol RECOMMENS to use two different channels with different reliability to transport Control packets and Data packets, with the lower reliability channel assigned to Data packet, so as to save system resources and improve the Control channel transport performance. Any thoughts? Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 02:36:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06381 for ; Fri, 12 Mar 2004 02:36:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hDV-0008OZ-VW for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 02:36:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C7aPM9032260 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 02:36:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hDT-0008OF-T1 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 02:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06369 for ; Fri, 12 Mar 2004 02:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1hDQ-0003tD-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1hCa-0003mU-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:35:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1hC6-0003f1-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:34:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hC8-0008Iq-Vi; Fri, 12 Mar 2004 02:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hBS-0008G4-J2 for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 02:34:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06264 for ; Fri, 12 Mar 2004 02:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1hBO-0003dS-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:34:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1hAV-0003WB-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:33:20 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1h9o-0003HC-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:32:37 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2C7YGWO014508; Fri, 12 Mar 2004 07:34:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2C7Q5ZF005701; Fri, 12 Mar 2004 07:26:08 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031123320328104 ; Thu, 11 Mar 2004 23:32:03 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Mar 2004 23:32: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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQH6Ahr0NjHQlGDTb+c0dsUzSqkVQAGyY7A From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 12 Mar 2004 07:32:03.0079 (UTC) FILETIME=[1CE3A970:01C40804] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Mar 2004 23:32:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, Unfortunately, I strongly disagree with #3 below, you keep pushing on this inspite of several good reasons pointed out my most of the folks including David's discussion with the Ads. I am not opposed to recommending some of the packet scheduling schemes that have been described in GRMP, however I believe we need separate D&C channels/connections and might actually want to have optional multicast connections as well for the C channel/connection, in addition to unicast. I will send out text on this over the weekend, but if you keep pushing against having 2 connections, it will be difficult to reach a merger. Regards=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Thursday, March 11, 2004 8:06 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] Issue 2: Multiple channels/connections Hi, all I don't know why it suddenly becomes so silent here. To try to speed up the process, pls allow me to activate the Issue 2. I know Hormuzd may be writing something, it just does not conflict. This issue has in fact been quite largely discussed. I (suppose Jamal also ) think what we need to do now is just to find more reasons for such arrangement. Our team idea is: 1. The idea to distinguish the Control packets from Data packets to have them able to be differently processed is very useful for DoS protection as well as for achieving different transport reliability, therefore it MUST be included in ForCES protocol. 2. It seems no use (I suppose Jamal says little use) for us to protect DoS by stretching out such distinguish to physical link (that is to setup two different channels for the two kinds of packets), therefore, it should not be described as a kind of DoS protection means in the protocol. 3. To setup two different channels to achieve different reliability may be practical, but it should not be described as a MUST item in the protocol, instead a "RECOMMEND" is better. This is because we must consider that we have already required the ForCES protocol SHOULD be able to support multiple interconnections, and in some interconnections like some backplanes (we should allow many kinds of backplane connections), we are actually not very sure if a separate channel is available or how it is separated. Actually currently, we only know that over IP network, UDP and TCP can be used for such separation. We also don't have to explicitly list how such separation is implemented. On the other hand, not to use lower reliability channel for Data packet transport actually does not harm too much. As a result, we suggest the protocol description may be look like "If available at transport layer, ForCES protocol RECOMMENS to use two different channels with different reliability to transport Control packets and Data packets, with the lower reliability channel assigned to Data packet, so as to save system resources and improve the Control channel transport performance. Any thoughts? Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 02:58:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07153 for ; Fri, 12 Mar 2004 02:58:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hYk-0001Hx-M0 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 02:58:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C7wMbV004950 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 02:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hYj-0001Hl-Nf for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 02:58:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07147 for ; Fri, 12 Mar 2004 02:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1hYg-0006X4-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:58:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1hXl-0006QT-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:57:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1hXP-0006Jd-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 02:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hXS-0001G0-5c; Fri, 12 Mar 2004 02:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1hWk-0001Eg-IR for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 02:56:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07062 for ; Fri, 12 Mar 2004 02:56:15 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1hWg-0006IL-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1hVm-0006Bq-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:55:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1hVJ-00065A-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 02:54:49 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1hVH-000MtS-0z for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:54:50 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <867F8C87-73FA-11D8-B275-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 16:54:44 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I guess I am confused. Hormuzd, are you saying that it is critical to you that use of 2 channels is a MUST even in a system that does not support multiple channels? As I read Weiming's suggestion, it was that one SHOULD use multiple channels in IP systems where they are available. On the very close systems in a box, where multiple physical channels may not be available, it doesn't seem to make sense to require their use. a. On 12 mar 2004, at 16.32, Khosravi, Hormuzd M wrote: > Weiming, > > Unfortunately, I strongly disagree with #3 below, you keep pushing on > this inspite of several good reasons pointed out my most of the folks > including David's discussion with the Ads. I am not opposed to > recommending some of the packet scheduling schemes that have been > described in GRMP, however I believe we need separate D&C > channels/connections and might actually want to have optional multicast > connections as well for the C channel/connection, in addition to > unicast. > > I will send out text on this over the weekend, but if you keep pushing > against having 2 connections, it will be difficult to reach a merger. > > Regards > Hormuzd > > > 3. To setup two different channels to achieve different reliability may > be > practical, but it should not be described as a MUST item in the > protocol, > instead a "RECOMMEND" is better. This is because we must consider that > we have > already required the ForCES protocol SHOULD be able to support multiple > interconnections, and in some interconnections like some backplanes (we > should > allow many kinds of backplane connections), we are actually not very > sure if a > separate channel is available or how it is separated. Actually > currently, we > only know that over IP network, UDP and TCP can be used for such > separation. We > also don't have to explicitly list how such separation is implemented. > On the > other hand, not to use lower reliability channel for Data packet > transport > actually does not harm too much. As a result, we suggest the protocol > description may be look like "If available at transport layer, ForCES > protocol > RECOMMENS to use two different channels with different reliability to > transport > Control packets and Data packets, with the lower reliability channel > assigned to > Data packet, so as to save system resources and improve the Control > channel > transport performance. > > Any thoughts? > > Yours, > Weiming > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 05:35:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12450 for ; Fri, 12 Mar 2004 05:35:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1k0o-0001Vo-3o for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 05:35:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CAZUoK005811 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 05:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1k0n-0001Ve-KK for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 05:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12446 for ; Fri, 12 Mar 2004 05:35:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1k0k-0002Vq-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 05:35:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jzm-0002On-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 05:34:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jzJ-0002Hs-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 05:33:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jzM-0001Qt-JG; Fri, 12 Mar 2004 05:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jyj-0001P3-Ma for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 05:33:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12396 for ; Fri, 12 Mar 2004 05:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jyg-0002Fd-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 05:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jxk-00028g-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 05:32:21 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1B1jwr-0001vF-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 05:31:25 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2CAUtVC142930; Fri, 12 Mar 2004 10:30:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2CAUuZr236642; Fri, 12 Mar 2004 11:30:56 +0100 Received: from zurich.ibm.com (dhcp71-176.zurich.ibm.com [9.4.71.176]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA312038; Fri, 12 Mar 2004 11:30:53 +0100 Message-ID: <4051915E.2010505@zurich.ibm.com> From: Patrick Droz Organization: IBM Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: hadi@znyx.com, "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> In-Reply-To: <4050DD8D.5040301@alcatel.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070402090903050908040904" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:30:54 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070402090903050908040904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Alex, why not take the same approach that OSPF is taking. Unicast a MUST Mcast/Bcast a must if available. Regards, Patrick Alex Audu wrote: > Issue 3: > > We can start by agreeing that Unicast is a MUST implement, and MCAST, > BCAST a > SHOULD. > > Any comments? > > > As an asside, on the GroupFEID issue, certainly you can define any > grouping to > help the application accomplish its goal, but we don't want that bubled > up to the > protocol addressing structure. > > Regards, > Alex. > Jamal Hadi Salim wrote: > >>In your other email you say: >> >>On Thu, 2004-03-11 at 12:38, Alex Audu wrote: >> >> >>>I agree, ..I don't see any need for GroupFEID, and other such group >>>IDs. >>> >>> >>> >> >>I actually wasnt agreeing with what you said above. I think the grouping >>of IDs is needed; the mechanics is what i was commenting on. >> >>BTW, momentum is dead. Who is the taker for topic #3? I could take it. >>Starting a timer ... >> >>cheers, >>jamal >> >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> -- 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 --------------ms070402090903050908040904 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 oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAzMTIx MDMwNTRaMCMGCSqGSIb3DQEJBDEWBBSz+4dheFu+ZOXrxQrQEy/t5dfoCTBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgCjqxfOGOISMW1vAiZOyYE1Daurq2isWHHio tV7UNH7dKEktVfVWpf8MNT7RG2v2MN4U+A1qq9LuRdzFc+T1Z3bZXf+ArRC8BE1f78RGFfCl brPRIsAhuh7zY4FLzxk5PURh8UWG9/cU9OAy5m8NCTb6bUa+/tz4go+4Xr4CXxkBAAAAAAAA --------------ms070402090903050908040904-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 06:17:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14577 for ; Fri, 12 Mar 2004 06:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ked-0003vW-PR for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:16:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CBGdtd015088 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:16:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ked-0003vH-8a for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 06:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14574 for ; Fri, 12 Mar 2004 06:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1keZ-00010I-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1kdh-0000tj-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:15:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1kd4-0000mU-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kd6-0003rX-1r; Fri, 12 Mar 2004 06:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kcg-0003oa-0n for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 06:14:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14520 for ; Fri, 12 Mar 2004 06:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1kcc-0000lz-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:14:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1kbk-0000eB-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:13:40 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1kb7-0000VI-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:13:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031203153122:2077 ; Fri, 12 Mar 2004 03:15:31 -0800 Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <4050DD8D.5040301@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> Organization: ZNYX Networks Message-Id: <1079089980.1055.21.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 03/12/2004 03:15:31 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 03:15:33 AM, Serialize complete at 03/12/2004 03:15:33 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 06:13:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Sorry I slowed down a little there. On Thu, 2004-03-11 at 16:43, Alex Audu wrote: > Issue 3: > > We can start by agreeing that Unicast is a MUST implement, and MCAST, > BCAST a > SHOULD. > > Any comments? Well I like the AD suggestions, which to quote David: --- "dual mandatory" approach. I.e.: If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. ------- In my opinion multicast should be used only within a "close proximity" only. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 06:31:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15004 for ; Fri, 12 Mar 2004 06:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ksx-0004MK-6C for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:31:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CBVRRD016750 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ksx-0004M5-28 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 06:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15000 for ; Fri, 12 Mar 2004 06:31:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1kst-0002nO-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:31:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1krz-0002gc-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:30:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1krZ-0002Zu-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1krc-0004FQ-Dp; Fri, 12 Mar 2004 06:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1krC-0004EC-Rs for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 06:29:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14890 for ; Fri, 12 Mar 2004 06:29:34 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1kr8-0002ZJ-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:29:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1kqE-0002S7-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:28:38 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1kpn-0002KY-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:28:11 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1kpn-000Bpx-TT for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:28:12 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <867F8C87-73FA-11D8-B275-000393CC2112@acm.org> References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> <867F8C87-73FA-11D8-B275-000393CC2112@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <561CBA8A-7418-11D8-BC30-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 20:28:08 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Never being one to do something just because the AD's are in favor it, I thought about this some more. While I totally agree that multiple channels can often be useful and MAY or even SHOULD be deployed where possible, I just cannot wrap my mind around the assertion that they are necessary either for DOS defense or for giving control messages priority on a busy link. Perhaps I have been living with and arguing in favor of the fate sharing Internet for too long. And I have seen all sorts of solutions for giving routing protocol messages priority even when data and routing protocols where traveling on the same network link, which is sort of the normal case. I don't understand why ForCES would be any different. I certainly believe that there MUST be a way to prioritize, and identify C traffic from D traffic I just can't see why it must be done one particular way; i.e. separate channels. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 06:36:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15544 for ; Fri, 12 Mar 2004 06:36:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kxQ-0004mO-BW for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CBa3ME018361 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 06:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kxP-0004lc-BQ for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 06:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15433 for ; Fri, 12 Mar 2004 06:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1kxK-0003lD-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1kvt-0003Ph-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:34:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1kuO-00033d-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 06:32:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kuR-0004YX-Sd; Fri, 12 Mar 2004 06:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1kts-0004WK-MS for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 06:32:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15025 for ; Fri, 12 Mar 2004 06:32:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1kto-0002x6-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:32:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1kst-0002nV-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:31:23 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1ks1-0002gi-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 06:30:29 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031203325937:2089 ; Fri, 12 Mar 2004 03:32:59 -0800 Subject: Issue 0 still WAS(Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <4050DD8D.5040301@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> Organization: ZNYX Networks Message-Id: <1079091028.1051.40.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 03/12/2004 03:32:59 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 03:33:01 AM, Serialize complete at 03/12/2004 03:33:01 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 06:30:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-11 at 16:43, Alex Audu wrote: > > As an asside, on the GroupFEID issue, certainly you can define any > grouping to > help the application accomplish its goal, but we don't want that > bubled up to the > protocol addressing structure. > I dont disagree with your general sentiment. I think it may end up being tricky to do it right without adding a little tweak. The ways i see this done is: a) such a ID is known apriori; we saw the broadcast group for the three address pieces listed as this (0xffff) b) such ID is configured on all devices via FEM/CEM interface. The view ive been hearing is to avoid that interface whenever possible. My belief is that this is a configuration issue which belongs to the FEM/CEM interface. Otherwise you are only left with c). c) Part of the async capability exchange. Which can be done to not complicate the protocol. You can repsond to this topic or defer it (on my part this is the last response for now) - i think on topic 0 we are there and this is a detail; lets use our energies on the other issues. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 07:04:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16926 for ; Fri, 12 Mar 2004 07:04:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1lOu-0000s1-0g for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 07:04:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CC4RRm003345 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 07:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1lOt-0000rr-HH for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 07:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16911 for ; Fri, 12 Mar 2004 07:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1lOp-00007d-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:04:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1lNy-00000t-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:03:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1lNR-0007hk-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:02:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1lNV-0000n4-Es; Fri, 12 Mar 2004 07:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1lMv-0000lm-5r for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 07:02:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16815 for ; Fri, 12 Mar 2004 07:02:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1lMq-0007fM-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:02:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1lLv-0007XU-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:01:23 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1lKw-0007PS-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:00:22 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031204002074:2112 ; Fri, 12 Mar 2004 04:00:20 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <111501c407e7$5e2a0b30$845c21d2@Necom.hzic.edu.cn> References: <111501c407e7$5e2a0b30$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079092631.1053.61.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 03/12/2004 04:00:21 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 04:02:53 AM, Serialize complete at 03/12/2004 04:02:53 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 06:57:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-11 at 23:06, Wang,Weiming wrote: > Hi, all > > I don't know why it suddenly becomes so silent here. To try to speed up the > process, pls allow me to activate the Issue 2. I know Hormuzd may be writing > something, it just does not conflict. > > This issue has in fact been quite largely discussed. I (suppose Jamal also ) > think what we need to do now is just to find more reasons for such arrangement. Correct, my view was a) need to describe the characterization of the channels b) need to describe when/why multiple channels would be needed. Let me read on you email first (and thanks for taking the effort to write this up). > Our team idea is: > > 1. The idea to distinguish the Control packets from Data packets to have them > able to be differently processed is very useful for DoS protection as well as > for achieving different transport reliability, therefore it MUST be included in > ForCES protocol. For DoS: Do you see anything extra in the headers other than what has been discussed already? If yes, can you explain? My view described earlier: a) The forces header as discussed already should be sufficient to describe the packet contents i.e based on the header you should be able to tell if the packet is data or control. b) We have the 3 bit priority field for this to protect at the application level. c) At the L2/3 we have either diffserv or 802.1p etc d) At the physical link we can either have two or more separate physical links or an example idea mentioned previously have several DMA channels to distinguish between the different levels of priority. e) per flow ingress scheduling of some form which may involve rate limiting. b) is the only binding issue. The rest are either implementation or administrative configuration issue. Infact one could argue since we provide the mechanism even b) falls under the same category. > 2. It seems no use (I suppose Jamal says little use) for us to protect DoS by > stretching out such distinguish to physical link (that is to setup two different > channels for the two kinds of packets), therefore, it should not be described as > a kind of DoS protection means in the protocol. I agree. At least not for DOS purposes. I will chop this email here for readability. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 07:30:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17708 for ; Fri, 12 Mar 2004 07:30:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ln9-0002qq-H2 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 07:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CCTVQ4010954 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 07:29:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ln8-0002qb-Nn for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 07:29:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17704 for ; Fri, 12 Mar 2004 07:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ln8-0003Bb-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:29:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1lm9-00035L-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:28:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1llg-0002yw-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 07:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1llg-0002p2-CV; Fri, 12 Mar 2004 07:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ll9-0002oi-6W for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 07:27:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17671 for ; Fri, 12 Mar 2004 07:27:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ll8-0002yC-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:27:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1lkE-0002rZ-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:26:31 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1ljO-0002k2-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 07:25:38 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031204280587:2128 ; Fri, 12 Mar 2004 04:28:05 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <111501c407e7$5e2a0b30$845c21d2@Necom.hzic.edu.cn> References: <111501c407e7$5e2a0b30$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079094333.1051.91.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 03/12/2004 04:28:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 04:28:07 AM, Serialize complete at 03/12/2004 04:28:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 07:25:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-11 at 23:06, Wang,Weiming wrote: > > 3. To setup two different channels to achieve different reliability may be > practical, but it should not be described as a MUST item in the protocol, > instead a "RECOMMEND" is better. This is because we must consider that we have > already required the ForCES protocol SHOULD be able to support multiple > interconnections, and in some interconnections like some backplanes (we should > allow many kinds of backplane connections), we are actually not very sure if a > separate channel is available or how it is separated. Actually currently, we > only know that over IP network, UDP and TCP can be used for such separation. We > also don't have to explicitly list how such separation is implemented. On the > other hand, not to use lower reliability channel for Data packet transport > actually does not harm too much. As a result, we suggest the protocol > description may be look like "If available at transport layer, ForCES protocol > RECOMMENS to use two different channels with different reliability to transport > Control packets and Data packets, with the lower reliability channel assigned to > Data packet, so as to save system resources and improve the Control channel > transport performance. I am in general agreeement with you i.e cannot mandate that hardware be built with multiple channels. At least this will rule out a _lot_ of legacy existing hardware (which i think will benefit from ForCES). Maybe the first step is to to define what "channel" is. Is it fair to say that it is strictly a link/physical link ONLY? There maybe "sessions" on each "channel". But if one of the sessions is freely DoSing the link, then it may fill it up in which case the separation is of no value. This brings me to what i said earlier: a) What are the different characteristics of each channel/session? I see them defined in terms of reliability, cost, latency and throughput. Is there an attribute thats missing? b) When do you use a channel/session? This is a policy issue - but needs to be decided for the protocol to be simple. In our implementation we had two types of sessions all over one physical channel. Our major policy was based on strictly cost. There was always a TCP connection between each FE to one or more CEs. There was at least one multicast connection. Both were reliable; and had the same throughput and latency characteristics. >From a CE, the TCP connection was more costly because a send to all FEs requires a replicast. OTOH, a single message was sent to all FEs using multicast. So always send on the multicast first. Retransmits on the multicast session are expensive on the FE side because some FEs which have already received the message now receive it a second time. As you can see, we did not need to separate into C and D channels. I have a feeling theres some fundamental thing i am missing with this desire to separate C and D (other than an academic one which i mostly ignore). cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 09:40:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24157 for ; Fri, 12 Mar 2004 09:40:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1np2-0003Pp-Iq for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 09:39:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEdaij013130 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 09:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1np2-0003Pd-95 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:39:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24146 for ; Fri, 12 Mar 2004 09:39:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1np0-0005yR-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 09:39:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1noB-0005qn-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 09:38:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1nnU-0005gi-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 09:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nnV-0003CT-ES; Fri, 12 Mar 2004 09:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nnC-000395-5l for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 09:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23911 for ; Fri, 12 Mar 2004 09:37:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nnA-0005di-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 09:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nmA-0005QN-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 09:36:38 -0500 Received: from ms-smtp-03-lbl.southeast.rr.com ([24.25.9.102] helo=ms-smtp-03-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1B1nl2-00056b-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 09:35:28 -0500 Received: from creeksidenet.com (cpe-024-163-075-077.nc.rr.com [24.163.75.77]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i2CEZMs1010130; Fri, 12 Mar 2004 09:35:23 -0500 (EST) Message-ID: <4051CAB2.1060905@creeksidenet.com> From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: alex.audu@alcatel.com, "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <1079089980.1055.21.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 09:35:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree on the dual must and think it will save a lot of interoperability problems down the road. I also like the close proximity idea (although it could be seen to contradict the dual must) because it could save us from doing something silly about multicast reliability just to address the "not close" case. Jeff Jamal Hadi Salim wrote: >Alex, >Sorry I slowed down a little there. > >On Thu, 2004-03-11 at 16:43, Alex Audu wrote: > > >>Issue 3: >> >>We can start by agreeing that Unicast is a MUST implement, and MCAST, >>BCAST a >>SHOULD. >> >>Any comments? >> >> > >Well I like the AD suggestions, which to quote David: > >--- >"dual mandatory" approach. I.e.: > >If your underlying interconnect supports multicast, >then you MUST implement the following (multicast) >method of communication. > >If your underlying interconnect supports unicast, then >you MUST implement the following (unicast) method >of communication. > >This will guarantee interop, although at a potential >extra cost (cost being having to potentially support >both when both are present). While this isn't optimal, >it does at least give some flexibility. >------- > >In my opinion multicast should be used only within a >"close proximity" only. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 10:45:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28902 for ; Fri, 12 Mar 2004 10:45:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1opz-0006Ax-Es for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 10:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CFidcM023735 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 10:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1opz-0006Ak-8f for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 10:44:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28867 for ; Fri, 12 Mar 2004 10:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1opw-0006y3-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 10:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1op4-0006rN-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 10:43:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ooN-0006jj-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 10:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ooP-00065e-Ky; Fri, 12 Mar 2004 10:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1oo6-00065B-EW for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 10:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28766 for ; Fri, 12 Mar 2004 10:42:38 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1oo4-0006ir-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 10:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1on8-0006bm-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 10:41:42 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1omZ-0006UI-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 10:41:08 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 12 Mar 2004 23:52:17 +0800 Received: from 219.82.188.243 ( [219.82.188.243]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Fri, 12 Mar 2004 23:52:17 +0800 Message-ID: <1079106737.4051dcc1106a0@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <1079089980.1055.21.camel@jzny.localdomain> In-Reply-To: <1079089980.1055.21.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 23:52:17 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jamal, Quoting Jamal Hadi Salim : > > In my opinion multicast should be used only within a > "close proximity" only. > [Weiming Re] That's very good point, I think. To separately considier the Issue 3 for the close proximity and for the remote multihops deployment may be useful to resolve this Issue. Yours, Weiming ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 11:29:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01203 for ; Fri, 12 Mar 2004 11:29:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pWn-0000qc-24 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CGSr0l003258 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pWm-0000qT-Ty for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 11:28:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01158 for ; Fri, 12 Mar 2004 11:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pWm-0005HC-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:28:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pVZ-00055K-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:27:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pVF-0004yv-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:27:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1pU2-0002vp-BW for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pU0-0000mZ-7w; Fri, 12 Mar 2004 11:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pTa-0000lg-6h for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 11:25:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01034 for ; Fri, 12 Mar 2004 11:25:31 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pTZ-0004rF-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:25:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pSg-0004k7-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:24:39 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B1pRj-0004cH-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:23:40 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 13 Mar 2004 00:35:05 +0800 Received: from 219.82.161.94 ( [219.82.161.94]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 13 Mar 2004 00:35:05 +0800 Message-ID: <1079109305.4051e6c89643b@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 00:35:05 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hormuzd, I have to say your reply is really out of my estimation. I thought you might have arguement on #2 and an agreement on #3 could be quickly reached after some comments and modification. Because you have not presented in your reply, I actually don't know what is it that makes you strongly disagree. To be hornest, I have got a feeling that you might have thought we are "keeping pushing on something" just to oppose FACT. That's really a big misunderstanding between us. From my past posts and also from the direct talk between us, I have for several times mentioned that I think FACT has already contributed to DoS protection by proposing the idea to separately process the C and D. What we are doing is to perfect the idea and to discuss how it can be better performed. We (GRMP team) respect this idea. We are not specifically pushing something against this idea. I have also mentioned in our talk that we(GRMP) are ready to give up to accept the idea of multipul channels (with its purpose not for DoS). Actually #3 is that we think a compromise. Although it is our desire to participate in IETF work and we sincerely hope the merge could be successful, as a scientist, I have to say we will more desire to obey the truth we believe, we just can not give it up to achieve others even though the others are very attractive. I hope my explanation can help in some way for us to mutually understand more. Sincerely, Weiming Quoting "Khosravi, Hormuzd M" : > Weiming, > > Unfortunately, I strongly disagree with #3 below, you keep pushing on > this inspite of several good reasons pointed out my most of the folks > including David's discussion with the Ads. I am not opposed to > recommending some of the packet scheduling schemes that have been > described in GRMP, however I believe we need separate D&C > channels/connections and might actually want to have optional multicast > connections as well for the C channel/connection, in addition to > unicast. > > I will send out text on this over the weekend, but if you keep pushing > against having 2 connections, it will be difficult to reach a merger. > > Regards > Hormuzd ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 11:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01241 for ; Fri, 12 Mar 2004 11:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pWv-0000r7-BZ for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CGT1KE003283 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pWv-0000qs-7a for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 11:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01174 for ; Fri, 12 Mar 2004 11:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pWu-0005IQ-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pVc-00055y-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:27:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pVH-0004yv-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:27:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1pT7-0002v5-Iq for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pT5-0000l6-D0; Fri, 12 Mar 2004 11:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pSl-0000kB-AC for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 11:24:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01016 for ; Fri, 12 Mar 2004 11:24:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pSk-0004ka-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:24:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pRn-0004dN-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:23:44 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pRS-0004Vs-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:23:23 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031208254992:2261 ; Fri, 12 Mar 2004 08:25:49 -0800 Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org In-Reply-To: <1079106737.4051dcc1106a0@mail.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <1079089980.1055.21.camel@jzny.localdomain> <1079106737.4051dcc1106a0@mail.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1079108589.1038.24.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 03/12/2004 08:25:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 08:25:52 AM, Serialize complete at 03/12/2004 08:25:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 11:23:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Quoting Jamal Hadi Salim : > > > > > In my opinion multicast should be used only within a > > "close proximity" only. > > On Fri, 2004-03-12 at 09:35, jeff pickering wrote: > I agree on the dual must and think it will save a lot of interoperability > problems down the road. I also like the close proximity idea (although > it could be seen to contradict the dual must) because it could save us from > doing something silly about multicast reliability just to address the > "not close" case. Agree. Reliability and Congestion control MUST be addressed. The nice thing about being able to limit the scope is to reduce complexity. I know we did. OTOH, if it ends being that we have to use something like RMT (I would hate to have to do that given the amount of fat that comes with it) then so be it. On Fri, 2004-03-12 at 10:52, wmwang@mail.hzic.edu.cn wrote: > [Weiming Re] That's very good point, I think. To separately considier the Issue > 3 for the close proximity and for the remote multihops deployment may be useful > to resolve this Issue. I think we should be able to close the issue if we agree to the following: a) that we will proceed with the thought that dual mandatory approach is where we are going b) that we will have a close proximity vs non-close proximity approach to partitioning the domains. Theres a lot we can learn from something like OSPF for mechanisms (Areas, broadcast/multicast/NBMA, etc) but i dont think we have to reach agreement on the details in order to close the issue. Thoughts? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 11:53:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02618 for ; Fri, 12 Mar 2004 11:53:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pto-0005Kj-PS for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:52:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CGqerW020495 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 11:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pto-0005KU-IX for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 11:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02586 for ; Fri, 12 Mar 2004 11:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ptn-0000yz-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pst-0000qy-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:51:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1psD-0000gp-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 11:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1psE-0005CI-5K; Fri, 12 Mar 2004 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1prt-0005Ak-42 for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 11:50:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02315 for ; Fri, 12 Mar 2004 11:50:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1prs-0000dh-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:50:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pqv-0000PI-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:49:41 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pqB-0000Hp-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 11:48:55 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031208512390:2283 ; Fri, 12 Mar 2004 08:51:23 -0800 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org In-Reply-To: <1079109305.4051e6c89643b@mail.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> <1079109305.4051e6c89643b@mail.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1079110131.1040.69.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 03/12/2004 08:51:24 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 08:51:25 AM, Serialize complete at 03/12/2004 08:51:25 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 11:48:52 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Guys, The goal is to have a NEW protocol. The protocol is NOT Netlink2, NOT GRMP and NOT FACT. At least thats the approach i have been taking[1]. The goal is also to share most importantly experiences. Nothing (at least at the IETF) is as important as an experience (the "we believe in running code" part). This also does not rule out good ideas that havent been implemented in my view. Weiming, I respect your approach to be technically correct first, but understand that there may be More Than One Way To Do It(tm) - all of which could be True(tm). Hormuzd: to be fair to Weiming, you did make a very strong statement without substantiating it. I know we have had discussions on the topic so far, but lets recall some of the points made so we can move on. Please repost your arguements. To make it even more interesting i dont agree with either of you on the need for C and D channels ;-> I posted my reasoning and experiences earlier. Can we have the discussion back on track and close it? cheers, jamal [1]Look at what we have agreed to and compare with netlink2 and you can see how they differ. On Fri, 2004-03-12 at 11:35, wmwang@mail.hzic.edu.cn wrote: > Hormuzd, > > I have to say your reply is really out of my estimation. I thought you might > have arguement on #2 and an agreement on #3 could be quickly reached after some > comments and modification. Because you have not presented in your reply, I > actually don't know what is it that makes you strongly disagree. > > To be hornest, I have got a feeling that you might have thought we are "keeping > pushing on something" just to oppose FACT. That's really a big misunderstanding > between us. From my past posts and also from the direct talk between us, I have > for several times mentioned that I think FACT has already contributed to DoS > protection by proposing the idea to separately process the C and D. What we are > doing is to perfect the idea and to discuss how it can be better performed. We > (GRMP team) respect this idea. We are not specifically pushing something > against this idea. > > I have also mentioned in our talk that we(GRMP) are ready to give up to accept > the idea of multipul channels (with its purpose not for DoS). Actually #3 is > that we think a compromise. > > Although it is our desire to participate in IETF work and we sincerely hope the > merge could be successful, as a scientist, I have to say we will more desire to > obey the truth we believe, we just can not give it up to achieve others even > though the others are very attractive. > > I hope my explanation can help in some way for us to mutually understand more. > > Sincerely, > Weiming > > > > > > Quoting "Khosravi, Hormuzd M" : > > > Weiming, > > > > Unfortunately, I strongly disagree with #3 below, you keep pushing on > > this inspite of several good reasons pointed out my most of the folks > > including David's discussion with the Ads. I am not opposed to > > recommending some of the packet scheduling schemes that have been > > described in GRMP, however I believe we need separate D&C > > channels/connections and might actually want to have optional multicast > > connections as well for the C channel/connection, in addition to > > unicast. > > > > I will send out text on this over the weekend, but if you keep pushing > > against having 2 connections, it will be difficult to reach a merger. > > > > Regards > > Hormuzd > > > ------------------------------------------------- > This mail sent through HUCNIC Webmail system. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 12:55:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07592 for ; Fri, 12 Mar 2004 12:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qsD-0002AT-H5 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 12:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHt5iV008327 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 12:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qsD-0002AE-C3 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07551 for ; Fri, 12 Mar 2004 12:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qsB-0003ND-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 12:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qrN-0003B9-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 12:54:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1qqB-0002vG-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 12:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qqC-0001wh-5h; Fri, 12 Mar 2004 12:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qpr-0001wP-UW for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 12:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07268 for ; Fri, 12 Mar 2004 12:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qpq-0002rn-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 12:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qoo-0002jI-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 12:51:34 -0500 Received: from petasus.ch.intel.com ([143.182.124.5]) by ietf-mx with esmtp (Exim 4.12) id 1B1qnq-0002VU-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 12:50:35 -0500 Received: from azsmsxvs041.ch.intel.com (azsmsxvs041.ch.intel.com [143.182.252.55]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i2CHmbnh032227; Fri, 12 Mar 2004 17:49:59 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs041.ch.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031210495917348 ; Fri, 12 Mar 2004 10:49:59 -0700 Received: from azsmsx311.amr.corp.intel.com ([10.2.161.35]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 10:49:59 -0700 Received: from orsmsx311.amr.corp.intel.com ([192.168.65.40]) by azsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 10:49:58 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 09:49:58 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <52D13A805349A249960B9943E5590BD8029CF893@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQIJV64sA1iSum9RnyYcTYWRzgrLwAM+1jg From: "Putzolu, David" To: , X-OriginalArrivalTime: 12 Mar 2004 17:49:58.0339 (UTC) FILETIME=[6F776130:01C4085A] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 09:49:57 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is my understanding of the reasons for separate channels for different priority traffic (for now I'll leave aside whether C & D are the different priorities or if there is some other priority): 1) If I build hardware that has two physical channels, but ForCES carries everything in a single logical connection, it becomes impossible (short of extremely ugly layer violations) to use my dual channel hardware, because all the ForCES messages are coming down in a single stream. 2) If I build hardware that has one physical connection, but has multiple levels of QoS (e.g. Ethernet backplane with support for 802.1p), but ForCES carries everything in a single logical connection, it becomes impossible to utilize my hardware's QoS support (short of those ugly layer=20 violations - Ethernet MAC chip cracking the ForCES header=20 to look at priority bits) 3) If I build hardware that has one physical connection, and no support for QoS, but I design ForCES to carry things in separate logical channels, I can easily map them down to the single physical channel. This is merely a problem of multiplexing, and is normal for lower layers to do. Basically, if one puts everything on one logical channel, it precludes some very realistic, beneficial, and deployed=20 hardware approaches. If one puts different priority traffic in different logical channels, one enables those hardware approaches without precluding anything. I'll leave the question of C & D for another email, got a meeting to run to :) -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 16:49:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20842 for ; Fri, 12 Mar 2004 16:49:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uWP-0004Bv-MC for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 16:48:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLmn99016110 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 16:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uWP-0004Bl-E1 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:48:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20823 for ; Fri, 12 Mar 2004 16:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uWN-0001d4-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:48:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uVR-0001av-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:47:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1uUd-0001Yg-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uUf-00047p-8c; Fri, 12 Mar 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uUZ-000476-7T for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 16:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20716 for ; Fri, 12 Mar 2004 16:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uUX-0001Xa-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 16:46:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uTi-0001Tm-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 16:46:03 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1uSl-0001Kx-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 16:45:03 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2CLiWTN019060; Fri, 12 Mar 2004 15:44:32 -0600 (CST) Message-ID: <40522F3F.802@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@acm.org CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> <867F8C87-73FA-11D8-B275-000393CC2112@acm.org> <561CBA8A-7418-11D8-BC30-000393CC2112@acm.org> In-Reply-To: <561CBA8A-7418-11D8-BC30-000393CC2112@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 15:44:31 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Avri, No doubt, the separation of the control packets from data packets that STP (Signal Transfer Points) affords TDM networks is the core reason why TDM networks are far more secure that IP networks. Since ForCES allows us to Separate control element from Forwarding element over space, then if we can carry control signals from C to FE over a separate channel from the one carrying user data (hellos, link state packts, etc), we can surely improve the chance of the NE surviving a D flooding attack. Som have argued that you can carry both C/D packets on the same channel, but assign different priorities to them. Well,..doing this doesn't buy one much if you have a million D packets choking up the channel. So, a separate channel is definitely desirable. We can make using separate D/C channels as a SHOULD strength (with conditions). But what is the implication of that on interoperable secure operation? If different vendors make C and FE boxes, the chance that one would support separate C/D channels while the other doesn't is greater. That will force the C/FE inter-action to fall back on the less secure single channel model. I am not sure that is a desireable solution given the increased attention on security these days. Regards, Alex. avri@acm.org wrote: > Hi, > > Never being one to do something just because the AD's are in favor it, > I thought about this some more. > > While I totally agree that multiple channels can often be useful and > MAY or even SHOULD be deployed where possible, I just cannot wrap my > mind around the assertion that they are necessary either for DOS > defense or for giving control messages priority on a busy link. > > Perhaps I have been living with and arguing in favor of the fate > sharing Internet for too long. And I have seen all sorts of solutions > for giving routing protocol messages priority even when data and > routing protocols where traveling on the same network link, which is > sort of the normal case. I don't understand why ForCES would be any > different. I certainly believe that there MUST be a way to > prioritize, and identify C traffic from D traffic I just can't see why > it must be done one particular way; i.e. separate channels. > > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 18:07:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25703 for ; Fri, 12 Mar 2004 18:07:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vkP-0005AE-O2 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:07:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CN7LdH019818 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vkO-00059P-ND for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25644 for ; Fri, 12 Mar 2004 18:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vkM-0006dP-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:07:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vjJ-0006UQ-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:06:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1viA-0006K7-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1viC-0004U7-Ol; Fri, 12 Mar 2004 18:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vhd-0004JZ-D3 for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 18:04:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25102 for ; Fri, 12 Mar 2004 18:04:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vha-0006Ej-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vgd-000640-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:03:28 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B1vej-0005j0-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:01:29 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2CN0qLc003686 for ; Fri, 12 Mar 2004 17:00:52 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Mar 2004 16:59:04 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 17:00:35 -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 GPWXB30R; Fri, 12 Mar 2004 18:00:52 -0500 Message-ID: <40524120.6060903@ericsson.com> From: Jon Maloy 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 To: alex.audu@alcatel.com CC: avri@acm.org, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <468F3FDA28AA87429AD807992E22D07E24E79C@orsmsx408.jf.intel.com> <867F8C87-73FA-11D8-B275-000393CC2112@acm.org> <561CBA8A-7418-11D8-BC30-000393CC2112@acm.org> <40522F3F.802@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2004 22:59:04.0265 (UTC) FILETIME=[9DB31B90:01C40885] Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 18:00:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit /jon Alex Audu wrote: > Hello Avri, > > No doubt, the separation of the control packets from data packets that > STP (Signal > Transfer Points) affords TDM networks is the core reason why TDM > networks are > far more secure that IP networks. > Since ForCES allows us to Separate control element from Forwarding > element over > space, then if we can carry control signals from C to FE over a > separate channel from > the one carrying user data (hellos, link state packts, etc), we can > surely improve the > chance of the NE surviving a D flooding attack. Agree. > > > Som have argued that you can carry both C/D packets on the same > channel, but assign > different priorities to them. Well,..doing this doesn't buy one much > if you have a million > D packets choking up the channel. So, a separate channel is > definitely desirable. That depends on where you handle the congestion for D-packets. In a sending FE one can check for congestion front up, i.e. already in the send operation, and low priority D-packets marked as droppable may be thrown away instead of being added to the send queue. Those packets will never choke any media or router. Separate logical channels, i.e. connections with different priorities, and where some even are marked as unreliable, is definitely needed, but that does not imply there is a need for a different physical channel, or indeed different protocols (UDP vs TCP) to handle them. It is only a matter of proper handling of priorities, and doing it at the right level: For IP protocols, one can add a simple sliding window (a "sent" and an "acked" counter, and a fairly big send window) at the ForcCES protocol level (we can not reach the TCP window, and UDP has none). High priority connections have an infinite window, low priority senders drop the packets when the window is full, instead of sending them. (With TIPC, a similar mechanism is built in.) > > > We can make using separate D/C channels as a SHOULD strength (with > conditions). A MUST would imply that we think other solutions are impossible, and would force vendors to add functionality they may consider unecessary. > But what is the implication of that on interoperable secure > operation? If different vendors > make C and FE boxes, the chance that one would support separate C/D > channels while the > other doesn't is greater. That will force the C/FE inter-action to > fall back on the less secure > single channel model. Less reliable, yes, but why less secure ? > I am not sure that is a desireable solution given the increased > attention > on security these days. > > > Regards, > Alex. > > avri@acm.org wrote: > >> Hi, >> >> Never being one to do something just because the AD's are in favor >> it, I thought about this some more. >> >> While I totally agree that multiple channels can often be useful and >> MAY or even SHOULD be deployed where possible, I just cannot wrap my >> mind around the assertion that they are necessary either for DOS >> defense or for giving control messages priority on a busy link. >> >> Perhaps I have been living with and arguing in favor of the fate >> sharing Internet for too long. And I have seen all sorts of >> solutions for giving routing protocol messages priority even when >> data and routing protocols where traveling on the same network link, >> which is sort of the normal case. I don't understand why ForCES >> would be any different. I certainly believe that there MUST be a way >> to prioritize, and identify C traffic from D traffic I just can't see >> why it must be done one particular way; i.e. separate channels. >> >> a. >> >> >> _______________________________________________ >> Forces-protocol mailing list >> Forces-protocol@ietf.org >> https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 18:20:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27095 for ; Fri, 12 Mar 2004 18:20:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vwR-0000N0-7h for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:19:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNJlEm001416 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:19:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vwR-0000Ml-1y for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:19:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27061 for ; Fri, 12 Mar 2004 18:19:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vwO-0007Ll-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:19:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vvS-0007K1-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:18:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vuf-0007It-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:17:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vui-0008Ma-4r; Fri, 12 Mar 2004 18:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vuX-0008Jn-Kr for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 18:17:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26899 for ; Fri, 12 Mar 2004 18:17:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vuU-0007IS-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:17:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vtY-0007HV-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:16:49 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1vtG-0007GM-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:16:30 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031215185325:2747 ; Fri, 12 Mar 2004 15:18:53 -0800 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: avri@acm.org, forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD8029CF893@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8029CF893@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079133381.1126.21.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 03/12/2004 03:18:53 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 03:19:01 PM, Serialize complete at 03/12/2004 03:19:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 18:16:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi David, Let me do a compare with a node with two ethernet ports to put into context what you are saying. I suppose we can assume we can attach IP addresses to these ports. If we are going to run over IP, then such a node is refered to as multihomed. Is this a fair corelation? Lets refer to sockets as the logical connections. On Fri, 2004-03-12 at 12:49, Putzolu, David wrote: > 1) If I build hardware that has two physical channels, but > ForCES carries everything in a single logical connection, > it becomes impossible (short of extremely ugly layer > violations) to use my dual channel hardware, because all > the ForCES messages are coming down in a single stream. So you have one socket but two ethernet ports. If i understood you corectly, lets say you had 10 ethernet ports, would you then say you want to take advantage of all of them? I suppose you have to draw a line somewhere which seems to me this is a config choice, no? If you are running on top of SCTP it would manage this for you. BTW, didnt get the layer violations you are refering to. An alternative is to use simple lower layers tecniques like trunking/bonding. I dont think you require to manage the knowledge at the Forces level. > 2) If I build hardware that has one physical connection, but > has multiple levels of QoS (e.g. Ethernet backplane with > support for 802.1p), but ForCES carries everything in a > single logical connection, it becomes impossible to utilize > my hardware's QoS support (short of those ugly layer > violations - Ethernet MAC chip cracking the ForCES header > to look at priority bits) So one ethernet, one socket. I know in Linux it would be trivial to map the Forces prio bits to either diffserv or 802.1p on the sending side. The Forces prio bits are more valuable IMO at the application level where you can process higher priority before lower priority etc. This May be orthogonal to whatever prioritization bits at the lower levels. > 3) If I build hardware that has one physical connection, and > no support for QoS, but I design ForCES to carry things in > separate logical channels, I can easily map them down to > the single physical channel. This is merely a problem of > multiplexing, and is normal for lower layers to do. sure. > Basically, if one puts everything on one logical channel, it > precludes some very realistic, beneficial, and deployed > hardware approaches. I dont think multiple hardware paths should be precluded. What we need to understand is the nature of the beast. What differentiates the different "channels" and when to use them. I suppose the other question is "how many channels" - or is this a config issue? I dont see anything nmagical about the number 2. Or D & C. > If one puts different priority traffic in different logical > channels, one enables those hardware approaches without > precluding anything. Nothing stops that as far as i can see. > I'll leave the question of C & D for another email, got a > meeting to run to :) Waiting ;-> I really am having ISDN dejavus, but wuill wait to hear the reasoning first. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 18:34:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27615 for ; Fri, 12 Mar 2004 18:34:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wA2-0001gU-BO for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:33:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNXofu006473 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 18:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1wA2-0001gK-0S for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:33:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27594 for ; Fri, 12 Mar 2004 18:33:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w9z-00000p-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:33:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w94-0007ky-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:32:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1w8E-0007i5-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 18:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w8H-0001WB-1E; Fri, 12 Mar 2004 18:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w87-0001Vg-7Q for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 18:31:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27436 for ; Fri, 12 Mar 2004 18:31:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w84-0007gn-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:31:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w76-0007f1-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:30:49 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B1w6J-0007dc-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 18:29:59 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031215322767:2763 ; Fri, 12 Mar 2004 15:32:27 -0800 Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: alex.audu@alcatel.com Cc: Patrick Droz , "Deleganes, Ellen M" , forces-protocol@ietf.org In-Reply-To: <40522277.1050507@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <4051915E.2010505@zurich.ibm.com> <40522277.1050507@alcatel.com> Organization: ZNYX Networks Message-Id: <1079134193.1126.37.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 03/12/2004 03:32:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/12/2004 03:32:29 PM, Serialize complete at 03/12/2004 03:32:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 12 Mar 2004 18:29:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Seems like you are trying to take my spot as most frequent poster;-> On Fri, 2004-03-12 at 15:49, Alex Audu wrote: > 1) In a critical environment like the one we are talking about, we need > ACKs to give a warm-fuzzy feeling that FEs are getting what the CEs are > blasting at them. Acks are MUST for reliability. In some cases, you dont need to receive ACKs (eg unidirectional heartbeats). > What is the implication of this as number of FEs rise into the thousands? > You run the risk of tons of ACKs comming back and overwhleming the CE. > That is essentially a flooding attack on the CE. > I believe it is called ACK implosion in literature. A lot > of ways have been proposed to avoid this,..like selective > ACK/NACK,..etc. These > suggested solutions are pretty complex. You want all those ACKs from All FE if you want to be reliable in the case of ForCES; lets do the math though, because for what you have described i think you are mistaken in the case that the CE is overwhelmed. You may have meant some of the FEs will be overwhelmed. Lets say you had 10000 FEs. The CE sends one multicast message and receives 10000 ACks. Thats 10001 messages Consider the case of unicast. You send 10000 messages and receive 10000 ACKs. The math says you are sending 50% less traffic with multicast. > 2) As the number of FEs grows, the chance of packet loss increases in > the network when doing multicast. You have to fall back on retransmits to > accommodate this. Again refer to the math above. It seems to me its a lot worse for unicast. Retransmits are a necessary part of reliability. > That essentially whipes out the percieved benefits of mulitcast. ;-> > 3) How do you synchronize your packets and make sure they are recieved > in order at the the FEs? > You have to build something extra into your application > or the FoRCES protocol to take care of such issues. Absolutely you have to build something into the protocol. The ordering in Forces is at the application level. Thats why we have two phase commits. Until the FE receives all the messages it cant commit a transactions. This has nothing to do with multicast. > And if you don't specify it, > there is danger of different implementations resulting in interoperability > issues. Refer to above. > 4) And there are issues of security to address. I think we will have to address this within scope of locality. But this is a separate issue. > In short, I am not sure we know enough about multicast to mandate its > use in a > critical envirnonment. If we are not concerned about timing, sure, we > can retransmit > a couple of times untill all the endpoints get the data. But we resorted > to multicast to > save time in the first place. Refer to my comments and repost. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 19:37:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02083 for ; Fri, 12 Mar 2004 19:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x94-0005zA-Td for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 19:36:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D0asWk023008 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 19:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x94-0005z1-P8 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 19:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02077 for ; Fri, 12 Mar 2004 19:36:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1x93-0004sz-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 19:36:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1x89-0004qo-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 19:35:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1x7G-0004oJ-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 19:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x7G-0005xS-UN; Fri, 12 Mar 2004 19:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1x73-0005wE-Gy for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 19:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02017 for ; Fri, 12 Mar 2004 19:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1x71-0004mq-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 19:34:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1x68-0004kt-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 19:33:53 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1x5K-0004hT-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 19:33:02 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2D0YeWO029244; Sat, 13 Mar 2004 00:34:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2D0WU0u010940; Sat, 13 Mar 2004 00:34:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031216323011236 ; Fri, 12 Mar 2004 16:32:30 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 16:32:30 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQIiA2y40WibEDGQ6K/kBVkR2pRKQAAKS9g From: "Putzolu, David" To: Cc: X-OriginalArrivalTime: 13 Mar 2004 00:32:30.0038 (UTC) FILETIME=[AB002F60:01C40892] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 16:32:29 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal. My response is inlined below, but before I go into it, I thought I'd show how one would use multiple logical connections (sockets) in a clean fashion to provide differential levels of service to packets on a variety of implementations: Case 1: Single Ethernet wire shared by FEs to talk to CE, supports QoS via 802.1p. Each FE does the following: Step 1) Open socket 1, which is intended for the low priority=20 packets. Leave the 802.1p settings alone for packets going over this socket. Step 2) Open socket 2, which is intended for the high priority packets. Make ioctl() or other call necessary to set any packets over this socket to get 802.1p bits set. Result: High priority packets from any FE take precedence over low priority packets from any FE, only compete with high priority packets from other FEs. Case 2: Two Ethernet wires, one for high priority packets shared by all FEs, other for low priority packets shared by all FEs. Each FE does the following: Step 1) Open socket 1, which is intended for the low priority packets, using IP address on low priority Ethernet. Step 2) Open socket 2, which is intended for the high priority packets, using IP address on high priority Ethernet. Result: High priority packets from any FE only compete with high priority packets from other FEs. I'd be interested in seeing how one would provide similar differential treatment of packets using a single socket. I've guessed at methods of doing it below, but my guesses where all rather ugly and had the aforementioned layer violations... Now on to the response :) Jamal wrote > > Let me do a compare with a node with two Ethernet ports > to put into context what you are saying. I suppose we can assume=20 > we can attach IP addresses to these ports. If we are going to run=20 > over IP, then such a node is referred to as multihomed. > Is this a fair corelation? > > Lets refer to sockets as the logical connections. Sure. Jamal wrote > > On Fri, 2004-03-12 at 12:49, Putzolu, David wrote: > > 1) If I build hardware that has two physical channels, but > > ForCES carries everything in a single logical connection, > > it becomes impossible (short of extremely ugly layer > > violations) to use my dual channel hardware, because all > > the ForCES messages are coming down in a single stream. >=20 > So you have one socket but two ethernet ports. > If i understood you corectly, lets say you had 10 ethernet=20 > ports, would you then say you want to take advantage of all of them?=20 > I suppose you have to draw a line somewhere which seems to me=20 > this is a config choice, no? Not sure what the implication is of this para, so I have no response :) Jamal wrote: > If you are running on top of SCTP it would manage this for you. SCTP multihoming uses secondary paths for backup purposes - it transmits all packets on the primary channel, using the backup only upon losses, eventually switching to backups if losses get too bad (RFC2960, section 6.4). An SCTP implementation might choose to round-robin across the multihomed connections (RFC3286, section 4), however, that is implementation dependent, and still would in no way to treat high priority ForCES packets differently from low priority ForCES packets - they would just be round-robined. One could use SCTP's unordered option (RFC2960 section 6.6) by=20 hacking the SCTP implementation it to put any U flagged packet=20 on the backup channel, and all non-U packets on the primary=20 channel. This would prevent other FE's low priority traffic (running on the primary channel) from congestion crushing the high priority traffic from this FE, at least until the other FE's SCTP decides to start using the backup channel (likely if the primary is overloaded). Furthermore, this requires a custom SCTP implementation - modifying SCTP just to support ForCES is=20 ugly (and not feasible in all operating systems - we cannot mandate that anybody who wants to use ForCES must use an open source OS where they can freely modify transport protocol=20 implementations!) Finally, one could hack SCTP to automatically break open all packets=20 handed to it, guess if they are ForCES packets, and then decide=20 which ForCES priority classes to map to the backup channel=20 and which to map to the primary channel. In addition to being a layer violation, this runs into the same problem as above in terms of hurting anybody who does not have free reign to=20 modifying their SCTP implementation. Jamal wrote > > An alternative is to use simple lower layers tecniques like > trunking/bonding.=20 Trunking/bonding lower layers provides no differential treatment of higher priority packets vs. lower priority packets. > > 2) If I build hardware that has one physical connection, but > > has multiple levels of QoS (e.g. Ethernet backplane with > > support for 802.1p), but ForCES carries everything in a > > single logical connection, it becomes impossible to utilize > > my hardware's QoS support (short of those ugly layer=20 > > violations - Ethernet MAC chip cracking the ForCES header=20 > > to look at priority bits) >=20 > So one ethernet, one socket.=20 > I know in Linux it would be trivial to map the Forces prio bits to > either diffserv or 802.1p on the sending side.=20 Here are a couple ways of doing this - if=20 you have another in mind please let me know! 1) Hack Linux kernel to look at every packet handed over a TCP socket via write() and try to guess if it is a ForCES packet, then look at the priority field and set the 802.1p bits appropriately. Modifying one's implementation of TCP or SCTP just to run ForCES is both a layer violation and impractical for anybody who doesn't have an open source OS where they can freely modify the transport proto impl. 2) Every time FEd is about to send a packet, before calling write() make the appropriate system call (ioctl?) to change the 802.1p bits associated with the socket to match whatever=20 priority is needed. This would likely cause packet=20 reordering within a single TCP or SCTP stream - causing=20 the expedited high priority packets to get stuck in SCTP/TCP=20 until the low priority ones make it through. I guess if this was combined with setting the U flag for the packet in SCTP at least the reordering issue could be circumvented. > > Basically, if one puts everything on one logical channel, it > > precludes some very realistic, beneficial, and deployed=20 > > hardware approaches. >=20 > I dont think multiple hardware paths should be precluded. > What we need to understand is the nature of the beast. > What differentiates the different "channels" and when to use them. > I suppose the other question is "how many channels" - or is this a > config issue? I dont see anything nmagical about the number 2. > Or D & C. My goal with this part of the conversation is merely to show that putting everything over a single logical connection (socket) severely impinges on the ability to (cleanly) implement=20 any sort of prioritization system on the wire. This was in=20 response to the assertion made that separate channels don't=20 give us anything. This part of the discussion is more of a theoretical discussion - I am trying to show what I believe to be an objective point which is actually independent of ForCES itself. Once that point is cleared up I'll be happy to go into discussing the (subjective) point of whether ForCES in particular needs the=20 ability to treat packets differently, and what kind of packets=20 deserve differential treatment. :) Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 20:57:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06196 for ; Fri, 12 Mar 2004 20:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yOX-0002VZ-6g for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 20:56:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D1uvlt009641 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 20:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yOX-0002VQ-1A for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 20:56:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06184 for ; Fri, 12 Mar 2004 20:56:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yOU-0002HX-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 20:56:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yNX-0002F6-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 20:55:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1yMe-0002DB-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 20:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yMg-0002QP-4H; Fri, 12 Mar 2004 20:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yMW-0002PW-L3 for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 20:54:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06129 for ; Fri, 12 Mar 2004 20:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yMU-0002BX-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 20:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yLX-00028n-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 20:53:52 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1yKh-00022n-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 20:52:59 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2D1uC8u004455; Sat, 13 Mar 2004 01:56:12 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2D1sBxi017640; Sat, 13 Mar 2004 01:54:13 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031217521617831 ; Fri, 12 Mar 2004 17:52:16 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 17:52:16 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EE1D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQIUjY7Cx65BYtUTQiKXvds/z/s9wAD4qOg From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 13 Mar 2004 01:52:16.0174 (UTC) FILETIME=[CFC294E0:01C4089D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 17:52:15 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Guys, The goal is to have a NEW protocol. The protocol is NOT Netlink2, NOT GRMP and NOT FACT. At least thats the approach i have been taking[1]. The goal is also to share most importantly experiences. Nothing (at least at the IETF) is as important as an experience (the "we believe in running code" part). This also does not rule out good ideas that havent been implemented in my view. [HK] Completely Agree Hormuzd: to be fair to Weiming, you did make a very strong statement without substantiating it. I know we have had discussions on the topic so far, but lets recall some of the points made so we can move on. Please repost your arguements. [HK] Agreed, I will send out a more detailed email over the weekend. The problem is that I have done this before and so have many others, However Weiming keeps repeating his point of view again and again. I don't disagree with everything that Weiming is suggesting, infact FACT and GRMP are probably closer in this respect that netlink2... Its just a bit tiresome sometimes...anyways I will do this again. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 21:48:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08494 for ; Fri, 12 Mar 2004 21:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zCN-00051j-5D for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 21:48:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D2mRrV019317 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 21:48:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1zCM-00051U-T8 for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 21:48:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08446 for ; Fri, 12 Mar 2004 21:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1zCJ-0005M6-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 21:48:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1zBW-0005Es-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 21:47:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1zA0-00055c-01 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 21:46:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1yyO-0000Uw-T7 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 21:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yyP-00049I-0K; Fri, 12 Mar 2004 21:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yyJ-00048o-Bi for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 21:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07638 for ; Fri, 12 Mar 2004 21:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yyG-0004Pa-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 21:33:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yxN-0004M9-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 21:32:57 -0500 Received: from ms-smtp-02-lbl.southeast.rr.com ([24.25.9.101] helo=ms-smtp-02-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1B1ywn-0004JK-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 21:32:21 -0500 Received: from creeksidenet.com (cpe-024-163-075-077.nc.rr.com [24.163.75.77]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i2D2WGkF011096; Fri, 12 Mar 2004 21:32:17 -0500 (EST) Message-ID: <405272B0.6010403@creeksidenet.com> From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: Patrick Droz , hadi@znyx.com, "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <4051915E.2010505@zurich.ibm.com> <40522277.1050507@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 21:32:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Using unicast to avoid multicast ack implosion devolves into the worst case of not only a unicast ack for every packet, but also the unicast packet causing the ack. Im afraid we need to accept some level of complexity to enable the scaling we need. Cheers, Jeff Alex Audu wrote: > Hello Patrick, > > Sorry it took me this late to respond. I really don't know what a > "MUST if available" > means. The main issue with multicast is that there are still a lot of > unresolved issues > about it viz: > 1) In a critical environment like the one we are talking about, we > need ACKs to give > a warm-fuzzy feeling that FEs are getting what the CEs are > blasting at them. What is > the implication of this as number of FEs rise into the thousands? > You run the risk > of tons of ACKs comming back and overwhleming the CE. That is > essentially a > flooding attack on the CE. I believe it is called ACK implosion in > literature. A lot > of ways have been proposed to avoid this,..like selective > ACK/NACK,..etc. These > suggested solutions are pretty complex. > > 2) As the number of FEs grows, the chance of packet loss increases in > the network > when doing multicast. You have to fall back on retransmits to > accommodate this. > That essentially whipes out the percieved benefits of mulitcast. > > 3) How do you synchronize your packets and make sure they are recieved > in order at the > the FEs? You have to build something extra into your application > or the FoRCES > protocol to take care of such issues. And if you don't specify > it, there is danger of > different implementations resulting in interoperability issues. > > 4) And there are issues of security to address. > > In short, I am not sure we know enough about multicast to mandate its > use in a > critical envirnonment. If we are not concerned about timing, sure, we > can retransmit > a couple of times untill all the endpoints get the data. But we > resorted to multicast to > save time in the first place. > > Regards, > Alex. > > Patrick Droz wrote: > >> Hi Alex, >> >> why not take the same approach that OSPF is taking. >> Unicast a MUST >> Mcast/Bcast a must if available. >> >> Regards, >> Patrick >> >> Alex Audu wrote: >> >>> Issue 3: >>> >>> We can start by agreeing that Unicast is a MUST implement, and >>> MCAST, BCAST a >>> SHOULD. >>> >>> Any comments? >>> >>> >>> As an asside, on the GroupFEID issue, certainly you can define any >>> grouping to >>> help the application accomplish its goal, but we don't want that >>> bubled up to the >>> protocol addressing structure. >>> >>> Regards, >>> Alex. >>> Jamal Hadi Salim wrote: >>> >>>> In your other email you say: >>>> >>>> On Thu, 2004-03-11 at 12:38, Alex Audu wrote: >>>> >>>>> I agree, ..I don't see any need for GroupFEID, and other such group >>>>> IDs. >>>>> >>>>> >>>> >>>> >>>> >>>> I actually wasnt agreeing with what you said above. I think the >>>> grouping >>>> of IDs is needed; the mechanics is what i was commenting on. >>>> >>>> BTW, momentum is dead. Who is the taker for topic #3? I could take it. >>>> Starting a timer ... >>>> >>>> cheers, >>>> jamal >>>> >>>> >>>> >>>> _______________________________________________ >>>> Forces-protocol mailing list >>>> Forces-protocol@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/forces-protocol >>>> >>>> >> > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 23:49:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12976 for ; Fri, 12 Mar 2004 23:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2150-0002FT-Uk for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 23:48:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D4mwb8008644 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 23:48:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B214z-0002FL-4p for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 23:48:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12968 for ; Fri, 12 Mar 2004 23:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B214w-0005Bl-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:48:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2140-0005A5-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:47:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2137-000581-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2138-0002Dw-F0; Fri, 12 Mar 2004 23:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B212N-0002DR-11 for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 23:46:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12916 for ; Fri, 12 Mar 2004 23:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B212K-00055n-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B211S-00052m-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:45:19 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2111-0004y8-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:44:51 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2D4mC99002923; Sat, 13 Mar 2004 04:48:12 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2D4bdOP018337; Sat, 13 Mar 2004 04:38:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031220442126215 ; Fri, 12 Mar 2004 20:44:21 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 20:44: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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EE2C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQITrZQ0UEFCcuyT7aBvcnDQGs3xwAZK2Mg From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 13 Mar 2004 04:44:21.0557 (UTC) FILETIME=[DA2AFE50:01C408B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 20:44:21 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Hormuzd, I have to say your reply is really out of my estimation. I thought you might=20 have arguement on #2 and an agreement on #3 could be quickly reached after some comments and modification. Because you have not presented in your reply, I actually don't know what is it that makes you strongly disagree. [HK] I apologize for not having replied in detail. It was late at night, I read your mail real fast and felt like you were repeating the same arguments. However, I reread your email again right now and agree with most of it. I still disagree with parts of #3 but not everything. To be hornest, I have got a feeling that you might have thought we are "keeping pushing on something" just to oppose FACT. That's really a big misunderstanding between us. From my past posts and also from the direct talk between us, I have for several times mentioned that I think FACT has already contributed to DoS protection by proposing the idea to separately process the C and D. What we are doing is to perfect the idea and to discuss how it can be better performed. We(GRMP team) respect this idea. We are not specifically pushing something against this idea. [HK] I understand this, I don't think there is any misunderstanding. I am glad that we agree on the basics and are just arguing on the details. Sorry if I came out too harsh on my previous email, that was not my intent. Although it is our desire to participate in IETF work and we sincerely hope the merge could be successful, as a scientist, I have to say we will more desire to obey the truth we believe, we just can not give it up to achieve others even though the others are very attractive.=20 [HK] I understand and can relate to that sentiment. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 12 23:53:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13109 for ; Fri, 12 Mar 2004 23:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B218u-0002JU-FP for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 23:53:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D4r0Rn008889 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 23:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B218t-0002JD-Ax for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 23:52:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13094 for ; Fri, 12 Mar 2004 23:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B218q-0005KW-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:52:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B217t-0005Hz-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:51:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B216z-0005G8-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 23:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2170-0002Gt-T1; Fri, 12 Mar 2004 23:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2167-0002GN-9A for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 23:50:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12994 for ; Fri, 12 Mar 2004 23:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2163-0005DS-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:50:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B214w-0005Br-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:48:56 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2146-000591-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 23:48:02 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2D4pH99003749; Sat, 13 Mar 2004 04:51:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2D4n66a012156; Sat, 13 Mar 2004 04:49:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031220472628331 ; Fri, 12 Mar 2004 20:47:26 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 20:47: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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EE2D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQIB51yECaWHC4oRcOlmtBpJNSOBwAqfW4g From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 13 Mar 2004 04:47:26.0402 (UTC) FILETIME=[48581A20:01C408B6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 20:47:25 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avri, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org I guess I am confused. Hormuzd, are you saying that it is critical to=20 you that use of 2 channels is a MUST even in a system that does not=20 support multiple channels? [HK] May be the terminology is confusing, lets go with connections for now. Any OS that has a TCP/IP stack can provide multiple connections, either TCP connections on different ports, or TCP and UDP connections, or TCP and DCCP connections (in the near future). As I read Weiming's suggestion, it was that one SHOULD use multiple=20 channels in IP systems where they are available. On the very close=20 systems in a box, where multiple physical channels may not be=20 available, it doesn't seem to make sense to require their use. [HK] For IP systems, I believe separate D&C connections are a MUST. For systems in a box running ForCES directly over L2, I was thinking using something like TIPC which can provide separate connections might provide the answer. However, this is something that we need to discuss further and I am flexible on this. Hope this helps clarify my previous email, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 01:38:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16960 for ; Sat, 13 Mar 2004 01:38:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22mX-0007zy-KQ for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 01:38:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D6c102030727 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 01:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22mW-0007zL-HB for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 01:38:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16923 for ; Sat, 13 Mar 2004 01:37:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B22mT-00032w-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 01:37:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B22lV-0002zu-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 01:36:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B22kZ-0002xi-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 01:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22kb-0007gi-FM; Sat, 13 Mar 2004 01:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22jf-0007fQ-6T for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 01:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16827 for ; Sat, 13 Mar 2004 01:35:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B22jc-0002ud-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 01:35:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B22if-0002sa-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 01:34:02 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B22hw-0002oq-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 01:33:16 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2D6Yv2i031307; Sat, 13 Mar 2004 06:34:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2D6Ya6Y010191; Sat, 13 Mar 2004 06:34:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031222324601387 ; Fri, 12 Mar 2004 22:32:46 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Mar 2004 22:32: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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EE35@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQH6Ahr0NjHQlGDTb+c0dsUzSqkVQA2xPuw From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 13 Mar 2004 06:32:46.0348 (UTC) FILETIME=[FF5354C0:01C408C4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 22:32:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming 1. The idea to distinguish the Control packets from Data packets to have them able to be differently processed is very useful for DoS protection as well as for achieving different transport reliability, therefore it MUST be included in ForCES protocol. [HK] Agree 2. It seems no use (I suppose Jamal says little use) for us to protect DoS by stretching out such distinguish to physical link (that is to setup two different channels for the two kinds of packets), therefore, it should not be described as a kind of DoS protection means in the protocol. [HK] I disagree on this one, having separate connections which are congestion aware will provide robustness against DoS, not completely protect in all situations.=20 3. To setup two different channels to achieve different reliability may be practical, but it should not be described as a MUST item in the protocol, instead a "RECOMMEND" is better. This is because we must consider that we have already required the ForCES protocol SHOULD be able to support multiple interconnections, and in some interconnections like some backplanes (we should allow many kinds of backplane connections), we are actually not very sure if a separate channel is available or how it is separated. Actually currently, we only know that over IP network, UDP and TCP can be used for such separation. We also don't have to explicitly list how such separation is implemented. On the other hand, not to use lower reliability channel for Data packet transport actually does not harm too much. As a result, we suggest the protocol description may be look like "If available at transport layer, ForCES protocol RECOMMENS to use two different channels with different reliability to transport Control packets and Data packets, with the lower reliability channel assigned to Data packet, so as to save system resources and improve the Control channel transport performance. [HK] For IP, using separate C&D connections should be a MUST. However, UDP is not the best fit for D channel, this is probably the reason why you see no benefit of multiple connections against DoS in your experiments. The D channel should be congestion aware. For non-IP situation, multiple connections needs to be discussed. If we use TIPC for non-IP situation, it might provide the answer. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 06:49:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10873 for ; Sat, 13 Mar 2004 06:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B27dX-0006b9-Hl for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 06:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DBn3aY025359 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 06:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B27dX-0006aw-1S for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 06:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10746 for ; Sat, 13 Mar 2004 06:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B27dT-00059f-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 06:48:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B27c3-0004xT-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 06:47:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B27aw-0004s4-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 06:46:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B27Qw-0007LO-1G for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 06:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B27Qv-0005v9-Rt; Sat, 13 Mar 2004 06:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B27QW-0005uS-CH for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 06:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10266 for ; Sat, 13 Mar 2004 06:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B27QS-0004Ms-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 06:35:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B27Pc-0004IP-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 06:34:40 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B27Oj-00049B-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 06:33:50 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Sat, 13 Mar 2004 19:45:08 +0800 Message-ID: <149601c408ee$bb8c76c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E24EE2C@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 19:31:29 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, That's ok. Let's hurry up to move on. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: ; Sent: Saturday, March 13, 2004 12:44 PM Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Weiming, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Hormuzd, I have to say your reply is really out of my estimation. I thought you might have arguement on #2 and an agreement on #3 could be quickly reached after some comments and modification. Because you have not presented in your reply, I actually don't know what is it that makes you strongly disagree. [HK] I apologize for not having replied in detail. It was late at night, I read your mail real fast and felt like you were repeating the same arguments. However, I reread your email again right now and agree with most of it. I still disagree with parts of #3 but not everything. To be hornest, I have got a feeling that you might have thought we are "keeping pushing on something" just to oppose FACT. That's really a big misunderstanding between us. From my past posts and also from the direct talk between us, I have for several times mentioned that I think FACT has already contributed to DoS protection by proposing the idea to separately process the C and D. What we are doing is to perfect the idea and to discuss how it can be better performed. We(GRMP team) respect this idea. We are not specifically pushing something against this idea. [HK] I understand this, I don't think there is any misunderstanding. I am glad that we agree on the basics and are just arguing on the details. Sorry if I came out too harsh on my previous email, that was not my intent. Although it is our desire to participate in IETF work and we sincerely hope the merge could be successful, as a scientist, I have to say we will more desire to obey the truth we believe, we just can not give it up to achieve others even though the others are very attractive. [HK] I understand and can relate to that sentiment. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 10:10:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17731 for ; Sat, 13 Mar 2004 10:10:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Alh-0008UP-RE for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 10:09:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DF9fsX032627 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 10:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Alh-0008UA-Ke for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 10:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17664 for ; Sat, 13 Mar 2004 10:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Alf-0002Gd-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:09:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Akd-00029H-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:08:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Ak4-00023m-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Ak5-0007vj-AF; Sat, 13 Mar 2004 10:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2AjN-0007bU-4F for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 10:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17211 for ; Sat, 13 Mar 2004 10:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2AjL-0001x9-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:07:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2AiN-0001nE-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:06:16 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2AhP-0001gk-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:05:15 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031307074151:3215 ; Sat, 13 Mar 2004 07:07:41 -0800 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079190310.1124.262.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 03/13/2004 07:07:42 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/13/2004 07:07:44 AM, Serialize complete at 03/13/2004 07:07:44 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2004 10:05:11 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi David, On Fri, 2004-03-12 at 19:32, Putzolu, David wrote: > Case 1: Single Ethernet wire shared by FEs to talk to CE, > supports QoS via 802.1p. Each FE does the following: > Step 1) Open socket 1, which is intended for the low priority > packets. Leave the 802.1p settings alone for packets > going over this socket. > Step 2) Open socket 2, which is intended for the high priority > packets. Make ioctl() or other call necessary to set > any packets over this socket to get 802.1p bits set. > Result: High priority packets from any FE take precedence > over low priority packets from any FE, only compete with > high priority packets from other FEs. sounds reasonable. > Case 2: Two Ethernet wires, one for high priority packets > shared by all FEs, other for low priority packets shared > by all FEs. Each FE does the following: > Step 1) Open socket 1, which is intended for the low priority > packets, using IP address on low priority Ethernet. > Step 2) Open socket 2, which is intended for the high priority > packets, using IP address on high priority Ethernet. > Result: High priority packets from any FE only compete with > high priority packets from other FEs. reasonable - but you need to know these details(there are two ethernet links therefore must open two sockets and send high priority packets on link 0) at bootstrap time. > I'd be interested in seeing how one would provide similar > differential treatment of packets using a single socket. > I've guessed at methods of doing it below, but my guesses > where all rather ugly and had the aforementioned layer > violations... > I think the problem with your setup is you trying to have knowledge of the phyiscal link at the Forces level. At least havent said that you discover the number of physical links dynamically ;-> I have actually thought of this issue but never implemented it. Implement Forces as a socket family. This means most of the header is built by the (kernel) socket abstraction code. And a lot of things are hidden from the application. This does not preclude that some config is needed. You have a single socket riding on top of many ethernet pipes. FEd/CEd sets a default priority to be used in an out of band control path to the kernel. Prioritization (as well as other packet attributes such as reliability are done per packet). Anytime app wants to override the defaults it sends out of band metadata(like cmsg interface) along with the message and the socket abstraction uses that information to configure appropriately. The key is that the app is oblivious about how many physical or logical connections exist and whether they go via the moon or mars. Although i have spoken in terms of sockets and kernels - consider the above as a communication abstraction layer. I havent paid attention to the TIPC doc (its on my todo as is the model draft), i believe this is a problem they must have already solved. Jon? > Jamal wrote > > > On Fri, 2004-03-12 at 12:49, Putzolu, David wrote: > > > 1) If I build hardware that has two physical channels, but > > > ForCES carries everything in a single logical connection, > > > it becomes impossible (short of extremely ugly layer > > > violations) to use my dual channel hardware, because all > > > the ForCES messages are coming down in a single stream. > > > > So you have one socket but two ethernet ports. > > If i understood you corectly, lets say you had 10 ethernet > > ports, would you then say you want to take advantage of all of them? > > I suppose you have to draw a line somewhere which seems to me > > this is a config choice, no? > > Not sure what the implication is of this para, so I have no > response :) Same as what i said above; how much should the protocol know? If there was 8 ethernet links available (to map to the three priority bits), why not use all of them? Why only have two? Is simplicty the reason, if yes, why block the use of 8 when i want to?;-> So instead of saying lets have a C&D, why not say lets have two links with different qualities (of service). I gave the criteria as: reliability, cost, latency and throughput. Its almost sounding like RFC1349;-> [After reading Alexes email on how great PSTN networks are i cringed a little. I thought i had paid for my sins already for working on SS7 all those years, but he had to remind me;->]. The bellheads have this dogmatic view that there has to be clear separation of control and data. Sure they will waste a gigabit pipe to send 10kbps traffic on it. I thought these guys lost the battle already ;-> The design then is driven by "i am going to build this and it will last 50 years and no replacement needed". Its anti-innovation (although others may think its pro-robustness). On a serious side, pick any commodity L2/3 switch blade (i know all my companys products have this) these days and have at least one management port thats out of band; it is not unusual to see two or even three. Then theres the switch fabric which has many ports some of which could be used for management. But even given theres two classes of links (and i think people doing CSIX may have a different view), what has this got to do with Forces the protocol other than it being a config issue? Let me cut the email here for readability. Go and get some coffee. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 10:36:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19028 for ; Sat, 13 Mar 2004 10:36:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BBW-0003Pr-Hp for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 10:36:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DFaMFT013123 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 10:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BBW-0003PZ-9g for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 10:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19018 for ; Sat, 13 Mar 2004 10:36:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2BBU-0003dR-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BAb-0003aN-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:35:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2BAD-0003XA-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 10:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BAF-0003Nr-IG; Sat, 13 Mar 2004 10:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2B9X-0003L6-GH for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 10:34:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18963 for ; Sat, 13 Mar 2004 10:34:15 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2B9V-0003Vo-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:34:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2B8Z-0003Sr-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:33:20 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B2B82-0003QD-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 10:32:47 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2B82-000C5I-7G for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:32:46 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1079190310.1124.262.camel@jzny.localdomain> References: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> <1079190310.1124.262.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 00:32:45 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a question. If there is no control traffic on the data link, how will you know if there is a data link failure? Do you just wait for a transport protocol time out? And is that sufficiently timely? Or will you have some other mechanism? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 11:11:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19940 for ; Sat, 13 Mar 2004 11:11:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BjR-00051C-1A for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 11:11:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DGBOoC019284 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 11:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BjQ-00050x-Q9 for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 11:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19933 for ; Sat, 13 Mar 2004 11:11:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2BjO-0005dM-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 11:11:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BiR-0005Zy-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 11:10:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Bi5-0005Wq-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 11:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Bi7-0004zK-4d; Sat, 13 Mar 2004 11:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2BhT-0004yR-OM for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 11:09:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19891 for ; Sat, 13 Mar 2004 11:09:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2BhR-0005Vb-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 11:09:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2BgU-0005S0-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 11:08:23 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2Bfa-0005Os-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 11:07:26 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031308095275:3259 ; Sat, 13 Mar 2004 08:09:52 -0800 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079194042.1126.323.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 03/13/2004 08:09:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/13/2004 08:09:55 AM, Serialize complete at 03/13/2004 08:09:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2004 11:07:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-12 at 19:32, Putzolu, David wrote: > Jamal wrote: > > If you are running on top of SCTP it would manage this for you. > [useful comments removed for brevity] ok. I was under the impression you could plugin a path selection algorithm if you wanted (i could almost swear that was possible on linux, but i may be wrong). In any case i was looking more at getting to have connection management to be a separate topic from the protocol. I like some of the features SCTP has but it scares me on how feature rich it is. > One could use SCTP's unordered option (RFC2960 section 6.6) by > hacking the SCTP implementation it to put any U flagged packet > on the backup channel, and all non-U packets on the primary > channel. This would prevent other FE's low priority traffic > (running on the primary channel) from congestion crushing the > high priority traffic from this FE, at least until the other FE's > SCTP decides to start using the backup channel (likely if the > primary is overloaded). Furthermore, this requires a custom > SCTP implementation - modifying SCTP just to support ForCES is > ugly (and not feasible in all operating systems - we cannot > mandate that anybody who wants to use ForCES must use an open > source OS where they can freely modify transport protocol > implementations!) In Linux, this would be a simple change. Did you say other operating systems exist?;-> > Finally, one could hack SCTP to automatically break open all packets > handed to it, guess if they are ForCES packets, and then decide > which ForCES priority classes to map to the backup channel > and which to map to the primary channel. In addition to being a > layer violation, this runs into the same problem as above > in terms of hurting anybody who does not have free reign to > modifying their SCTP implementation. On the sending side, the forces level priority is useful for mapping to link/l3 layer prio. No violations; you pass metadata from the (higher) forces layer and it is mapped to the L2/3 level. On the receive path the L2/3 prio is only useful at those (L2/3)levels. At the application level, the forces prio becomes relevant for processing reasons. Example, in a simple strict priority you could have 8 queues and process the highest priority until theres no more work left etc. > > Jamal wrote > > > An alternative is to use simple lower layers tecniques like > > trunking/bonding. > > Trunking/bonding lower layers provides no differential treatment > of higher priority packets vs. lower priority packets. A lot of vendors have some form of loadbalancing at this level. For some glossy-ware, here are a couple of examples: http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml or: www.ieee802.org/3/trunk_study/tutorial/pctrunk.pdf Some of our own products are a lot more flexible than that and you can set any arbitrary bits in a packet header (within the first 64 bytes) as the selectors on which links gets the packet. Again my main point is Forces doesnt need to know anything about these details. Its a transport/communication management issue. > > So one ethernet, one socket. > > I know in Linux it would be trivial to map the Forces prio bits to > > either diffserv or 802.1p on the sending side. > > Here are a couple ways of doing this - if > you have another in mind please let me know! > 1) Hack Linux kernel to look at every packet handed over a > TCP socket via write() and try to guess if it is a ForCES > packet, then look at the priority field and set the 802.1p > bits appropriately. Modifying one's implementation of > TCP or SCTP just to run ForCES is both a layer violation > and impractical for anybody who doesn't have an open source > OS where they can freely modify the transport proto impl. Definetely true if you hack at the TCP level. I was more thinking of a _ForCES_ write() not TCP i.e like i said earlier - with a connection created by socket(PF_FORCES,...) But even a simple abstraction at user space before calling a forces_write(setprioto4, ,...) should hide all that. > 2) Every time FEd is about to send a packet, before calling write() > make the appropriate system call (ioctl?) to change the > 802.1p bits associated with the socket to match whatever > priority is needed. This would likely cause packet > reordering within a single TCP or SCTP stream - causing > the expedited high priority packets to get stuck in SCTP/TCP > until the low priority ones make it through. I guess if this > was combined with setting the U flag for the packet in > SCTP at least the reordering issue could be circumvented. > True this will require probably multi-queues at the send socket level to work effectively. PF_FORCES will have to take care of this. But even with single queues hacks are know to exist to prioritize data (and jump queues)- example is usage ot TCP URG flag. I dont think a single socket queue is sufficient. > My goal with this part of the conversation is merely to show > that putting everything over a single logical connection (socket) > severely impinges on the ability to (cleanly) implement > any sort of prioritization system on the wire. This was in > response to the assertion made that separate channels don't > give us anything. This part of the discussion is more of a > theoretical discussion - I am trying to show what I > believe to be an objective point which is actually independent > of ForCES itself. > > Once that point is cleared up I'll be happy to go into discussing > the (subjective) point of whether ForCES in particular needs the > ability to treat packets differently, and what kind of packets > deserve differential treatment. :) Ok, agreed. I do think that if you have x physical links each with different priority that infact you have a good solid (although more expensive) setup. What bothers me is any mandating of one, two, three, .. eight such channels. So far i have NOT heard a good reason. Again, I dont disagree that 2 links is better than one. or eight for that matter is better than 2. My problem is somehow that Forces needs to know this. What bothers me is any mandating of one, two, three, .. eight such channels. So far i have NOT heard a good reason why. I claim its an implementation/config issue (which is orthogonal to Forces). cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 12:46:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23342 for ; Sat, 13 Mar 2004 12:46:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2DDN-00012e-TR for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 12:46:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DHkPGS004003 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 12:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2DDN-00012T-N4 for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 12:46:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23331 for ; Sat, 13 Mar 2004 12:46:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2DDM-0004wc-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 12:46:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2DCg-0004t9-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 12:45:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2DC2-0004nQ-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 12:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2DC3-00010Z-Fr; Sat, 13 Mar 2004 12:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2DBo-000104-Ml for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 12:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23156 for ; Sat, 13 Mar 2004 12:44:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2DBn-0004l4-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 12:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2DAg-0004dG-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 12:43:39 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2DA7-0004Xe-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 12:43:03 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031309453041:3296 ; Sat, 13 Mar 2004 09:45:30 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <52D13A805349A249960B9943E5590BD8029CFB32@orsmsx409.jf.intel.com> <1079190310.1124.262.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1079199780.1127.418.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 03/13/2004 09:45:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/13/2004 09:45:32 AM, Serialize complete at 03/13/2004 09:45:32 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2004 12:43:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Avri, On Sat, 2004-03-13 at 10:32, avri@acm.org wrote: > Hi, > > I have a question. If there is no control traffic on the data link, > how will you know if there is a data link failure? Do you just wait > for a transport protocol time out? And is that sufficiently timely? Or > will you have some other mechanism? I think it is useful for whatever is managing the connections to know when a link goes down. These typically (should) happen via event notifications. The fallback (albeit slower way) is to depend on some control data or hearbeats. Not sure if that answers it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 14:38:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27523 for ; Sat, 13 Mar 2004 14:38:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Exr-0005yV-Vx for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 14:38:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DJcVsN022961 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 14:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Exr-0005yG-QK for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 14:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27516 for ; Sat, 13 Mar 2004 14:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Exp-0005ag-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Eww-0005X8-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:37:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2EwN-0005TA-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2EwP-0005dt-Jc; Sat, 13 Mar 2004 14:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Evr-0005cg-6j for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 14:36:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27444 for ; Sat, 13 Mar 2004 14:36:23 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Evo-0005RZ-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Euu-0005OK-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:35:29 -0500 Received: from imo-m14.mx.aol.com ([64.12.138.204]) by ietf-mx with esmtp (Exim 4.12) id 1B2EuI-0005Gn-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:34:50 -0500 Received: from Aaudu2000@aol.com by imo-m14.mx.aol.com (mail_out_v37_r1.2.) id l.108.2d1bdde8 (2612); Sat, 13 Mar 2004 14:34:06 -0500 (EST) Message-ID: <108.2d1bdde8.2d84bc2e@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: hadi@znyx.com, avri@acm.org CC: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079206446" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 14:34:06 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079206446 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is where application level ACKs come in handy. We have all agreed that ACKs are needed in ForCES message exchanges between CE and FEs. Regards, Alex. In a message dated 3/13/2004 11:45:09 AM Central Standard Time, hadi@znyx.com writes: Hi Avri, On Sat, 2004-03-13 at 10:32, avri@acm.org wrote: > Hi, > > I have a question. If there is no control traffic on the data link, > how will you know if there is a data link failure? Do you just wait > for a transport protocol time out? And is that sufficiently timely? Or > will you have some other mechanism? I think it is useful for whatever is managing the connections to know when a link goes down. These typically (should) happen via event notifications. The fallback (albeit slower way) is to depend on some control data or hearbeats. Not sure if that answers it. cheers, jamal -------------------------------1079206446 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
This is where application level ACKs come in handy.  We have all a= greed that ACKs are
needed in ForCES message exchanges between CE and FEs.
 
Regards,
Alex.
 
In a message dated 3/13/2004 11:45:09 AM Central Standard Time, hadi@zn= yx.com writes:
Hi Avri,

On Sat, 2004-03-13 at 10:32, a= vri@acm.org wrote:
> Hi,
>
> I have a question.  If=20= there is no control traffic on the data link,
> how will you know if=20= there is a data link failure?  Do you just wait
> for a transpor= t protocol time out? And is that sufficiently timely?  Or
> will= you have some other mechanism?

I think it is useful for whatever is=20= managing the connections to know
when a link goes down. These typically (= should) happen via event
notifications.
The fallback (albeit slower wa= y) is to depend on some control data or
hearbeats.

Not sure if tha= t answers it.

cheers,
jamal
-------------------------------1079206446-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 14:56:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27927 for ; Sat, 13 Mar 2004 14:56:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FFH-0006ea-L1 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 14:56:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DJuVO1025576 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 14:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FFH-0006eR-DZ for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 14:56:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27920 for ; Sat, 13 Mar 2004 14:56:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2FFE-0006lb-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:56:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2FEJ-0006iB-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:55:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2FDp-0006eY-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 14:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FDr-0006bu-4f; Sat, 13 Mar 2004 14:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FDJ-0006b1-Kc for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 14:54:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27876 for ; Sat, 13 Mar 2004 14:54:26 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2FDG-0006dQ-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:54:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2FCH-0006a4-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:53:26 -0500 Received: from imo-d06.mx.aol.com ([205.188.157.38]) by ietf-mx with esmtp (Exim 4.12) id 1B2FBi-0006Tz-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 14:52:50 -0500 Received: from Aaudu2000@aol.com by imo-d06.mx.aol.com (mail_out_v37.4.) id l.1aa.213270ea (2612); Sat, 13 Mar 2004 14:52:08 -0500 (EST) Message-ID: <1aa.213270ea.2d84c068@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: hadi@znyx.com, david.putzolu@intel.com CC: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079207528" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 14:52:08 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079207528 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jamal, It is true that the recommendation to use D/C channels can't be reflected on the protocol specification. It has more to do with the framework than the protocol itself. But it has to be mandated somehow to allow for interoperability. I don't see any other way to do this. Do you? Cheers, Alex. In a message dated 3/13/2004 10:10:28 AM Central Standard Time, hadi@znyx.com writes: David Putzolu wrote: > My goal with this part of the conversation is merely to show > that putting everything over a single logical connection (socket) > severely impinges on the ability to (cleanly) implement > any sort of prioritization system on the wire. This was in > response to the assertion made that separate channels don't > give us anything. This part of the discussion is more of a > theoretical discussion - I am trying to show what I > believe to be an objective point which is actually independent > of ForCES itself. > > Once that point is cleared up I'll be happy to go into discussing > the (subjective) point of whether ForCES in particular needs the > ability to treat packets differently, and what kind of packets > deserve differential treatment. :) Ok, agreed. I do think that if you have x physical links each with different priority that infact you have a good solid (although more expensive) setup. What bothers me is any mandating of one, two, three, .. eight such channels. So far i have NOT heard a good reason. Again, I dont disagree that 2 links is better than one. or eight for that matter is better than 2. My problem is somehow that Forces needs to know this. What bothers me is any mandating of one, two, three, .. eight such channels. So far i have NOT heard a good reason why. I claim its an implementation/config issue (which is orthogonal to Forces). cheers, jamal -------------------------------1079207528 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Jamal,
 
It is true that the recommendation to use D/C channels can't be reflect= ed on the
protocol specification. It has more to do with the framework than the p= rotocol itself.
But it has to be mandated somehow to allow for interoperability. I don'= t see any other
way to do this. Do you?
 
Cheers,
Alex.
 
In a message dated 3/13/2004 10:10:28 AM Central Standard Time, hadi@zn= yx.com writes:


David Putzolu wrote:

> My go= al with this part of the conversation is merely to show
> that putting= everything over a single logical connection (socket)
> severely impin= ges on the ability to (cleanly) implement
> any sort of prioritizatio= n system on the wire.  This was in
> response to the assertion m= ade that separate channels don't
> give us anything.  This part=20= of the discussion is more of a
> theoretical discussion - I am trying=20= to show what I
> believe to be an objective point which is actually in= dependent
> of ForCES itself.
>
> Once that point is clear= ed up I'll be happy to go into discussing
> the (subjective) point of=20= whether ForCES in particular needs the
> ability to treat packets dif= ferently, and what kind of packets
> deserve differential treatment.&= nbsp; :)

Ok, agreed. I do think that if you have x physical links
= each with different priority that infact you have a good solid
(although=20= more expensive) setup.
What bothers me is any mandating of one, two, thr= ee, .. eight
such channels.
So far i have NOT heard a good reason.
= Again, I dont disagree that 2 links is better than one.
or eight for that= matter is better than 2.
My problem is somehow that Forces needs to kno= w this.
What bothers me is any mandating of one, two, three, .. eightsuch channels.
So far i have NOT heard a good reason why. I claim its an=
implementation/config issue (which is orthogonal to Forces).

che= ers,
jamal
-------------------------------1079207528-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 15:17:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29411 for ; Sat, 13 Mar 2004 15:17:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FZY-0007wM-Ii for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 15:17:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DKHSE3030515 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 15:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FZY-0007vw-Bf for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 15:17:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29370 for ; Sat, 13 Mar 2004 15:17:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2FZX-0000FU-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:17:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2FYe-0000CW-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:16:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2FY9-00008x-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FY9-0007bF-KG; Sat, 13 Mar 2004 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2FXb-0007Se-N8 for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 15:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29164 for ; Sat, 13 Mar 2004 15:15:25 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2FXa-00007R-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:15:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2FWf-00004K-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:14:31 -0500 Received: from imo-m18.mx.aol.com ([64.12.138.208]) by ietf-mx with esmtp (Exim 4.12) id 1B2FWK-00000l-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:14:08 -0500 Received: from Aaudu2000@aol.com by imo-m18.mx.aol.com (mail_out_v37.4.) id l.1a3.21875053 (2612); Sat, 13 Mar 2004 15:13:26 -0500 (EST) Message-ID: <1a3.21875053.2d84c566@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: hadi@znyx.com, david.putzolu@intel.com CC: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079208806" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 15:13:26 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079208806 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit It is just common sense! Carry C/D on separate channels and you decouple the events happening on any one of the channels from impacting on the other. With the increasing threats hackers pose to our networks today, and the increasing important role that the internet plays in our lives (especially commercially), we owe it to society to build as secure a network/network element as we can. You should note that there is a movement afoot to start making service providers liable for damage done to consumers as result of security breaches in the providers' networks. It is coming. It is only a matter of time. We don't have to wait till then before we take security engineering seriously. Regards, Alex. In a message dated 3/13/2004 9:08:28 AM Central Standard Time, hadi@znyx.com writes: [After reading Alexes email on how great PSTN networks are i cringed a little. I thought i had paid for my sins already for working on SS7 all those years, but he had to remind me;->]. The bellheads have this dogmatic view that there has to be clear separation of control and data. Sure they will waste a gigabit pipe to send 10kbps traffic on it. I thought these guys lost the battle already ;-> The design then is driven by "i am going to build this and it will last 50 years and no replacement needed". Its anti-innovation (although others may think its pro-robustness). On a serious side, pick any commodity L2/3 switch blade (i know all my companys products have this) these days and have at least one management port thats out of band; it is not unusual to see two or even three. Then theres the switch fabric which has many ports some of which could be used for management. But even given theres two classes of links (and i think people doing CSIX may have a different view), what has this got to do with Forces the protocol other than it being a config issue? Let me cut the email here for readability. Go and get some coffee. cheers, jamal -------------------------------1079208806 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
It is just common sense! Carry C/D on separate channels and you decoupl= e the events
happening on any one of the channels from impacting on the other. = With the increasing
threats hackers pose to our networks today, and the increasing importan= t role that the
internet plays in our lives (especially commercially), we owe it to soc= iety to build as
secure a network/network element as we can.  You should note that=20= there is a movement
afoot to start making service providers liable for damage done to consu= mers as result of
security breaches in the providers' networks.  It is coming. It is= only a matter of time.
We don't have to wait till then before we take security engineerin= g seriously.
 
Regards,
Alex.
 
In a message dated 3/13/2004 9:08:28 AM Central Standard Time, hadi@zny= x.com writes:
[After reading Alexes email on how great PSTN=20= networks are i cringed a
little. I thought i had paid for my sins already= for working on SS7
all those years, but he had to remind me;->].
= The bellheads have this dogmatic view that there has to be clear
separati= on of control and data. Sure they will waste a gigabit pipe to
send 10kbp= s traffic on it. I thought these guys lost the battle
already ;-> The= design then is driven by "i am going to build this and
it will last 50 y= ears and no replacement needed". Its anti-innovation
(although others may= think its pro-robustness).
On a serious side, pick any commodity L2/3 sw= itch blade (i know all my
companys products have this) these days and hav= e at least one management
port thats out of band; it is not unusual to se= e two or even three.
Then theres the switch fabric which has many ports s= ome of which could
be used for management.
But even given theres two c= lasses of links (and i think people doing
CSIX may have a different view)= , what has this got to do with Forces
the protocol other than it being a=20= config issue?

Let me cut the email here for readability. Go and get s= ome coffee.

cheers,
jamal
-------------------------------1079208806-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 15:53:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00452 for ; Sat, 13 Mar 2004 15:53:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2G8Q-0001i6-L1 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 15:53:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DKrUxK006568 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 15:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2G8Q-0001hr-93 for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 15:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00405 for ; Sat, 13 Mar 2004 15:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2G8O-0002XX-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2G7R-0002Sw-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:52:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2G6x-0002Q4-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 15:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2G6y-0001f5-L3; Sat, 13 Mar 2004 15:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2G6U-0001ed-4O for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 15:51:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00389 for ; Sat, 13 Mar 2004 15:51:27 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2G6S-0002P0-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:51:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2G5W-0002LY-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:50:31 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx with esmtp (Exim 4.12) id 1B2G4r-0002Ew-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 15:49:49 -0500 Received: from Aaudu2000@aol.com by imo-d22.mx.aol.com (mail_out_v37.4.) id t.12d.3c35d544 (2612); Sat, 13 Mar 2004 15:49:10 -0500 (EST) Message-ID: <12d.3c35d544.2d84cdc6@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: jon.maloy@ericsson.com, alex.audu@alcatel.com CC: avri@acm.org, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079210950" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 15:49:10 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079210950 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello Jon, We manadate dual channels (one for C and the other D) to guarrantee interoperable secured networking. Why more secure? As soon as CE detects that FE is being DOS'd, it should be able to send control signals easily to mitigate the situation. If the control packets are caught behind a million D packets still in the queue, there is no chance for this to happen quickly. Some have also floated the idea that in a single box environment, maybe we should relax the requirement a bit. Well,..I think as long as CE and FE are separate, the link/channel between them may be a choke point if that link carries both C and D packets. Such C/D packets should be conveyed over different channels (queues,..etc). Regards, Alex. In a message dated 3/12/2004 5:05:36 PM Central Standard Time, jon.maloy@ericsson.com writes: A MUST would imply that we think other solutions are impossible, and would force vendors to add functionality they may consider unecessary. > But what is the implication of that on interoperable secure > operation? If different vendors > make C and FE boxes, the chance that one would support separate C/D > channels while the > other doesn't is greater. That will force the C/FE inter-action to > fall back on the less secure > single channel model. Less reliable, yes, but why less secure ? > I am not sure that is a desireable solution given the increased > attention > on security these days. -------------------------------1079210950 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello Jon,
 
We manadate dual channels (one for C and the other D) to guarrantee int= eroperable
secured networking. 
 
Why more secure?  As soon as CE detects that FE is being DOS'= d, it should be able
to send control signals easily to mitigate the situation. If the c= ontrol packets are caught
behind a million D packets still in the queue, there is no chance for&n= bsp;this to happen quickly.
 
Some have also floated the idea that in a single box environment, maybe= we should relax
the requirement a bit.  Well,..I think as long as CE and FE are se= parate, the link/channel
between them may be a choke point if that link carries both C and D pac= kets.  Such C/D
packets should be conveyed over different channels (queues,..etc).
 
 
Regards,
Alex.
 
In a message dated 3/12/2004 5:05:36 PM Central Standard Time, jon.malo= y@ericsson.com writes:
A MUST would imply that we think other solutio= ns are impossible, and
would force
vendors to add functionality they=20= may consider unecessary.

> But what is the implication of that on&= nbsp; interoperable secure
> operation?  If different vendors> make C and FE boxes, the chance that one would support separate C/D > channels while the
> other doesn't is greater.  That will=20= force the C/FE inter-action to
> fall back on the less secure
>= single channel model.

Less reliable, yes, but why less secure ?
=
> I am not sure that is  a  desireable solution given the i= ncreased
> attention
> on security these days.
-------------------------------1079210950-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 13 17:52:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04787 for ; Sat, 13 Mar 2004 17:52:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Hyh-0006wn-T8 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 17:51:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DMpZeI026699 for forces-protocol-archive@odin.ietf.org; Sat, 13 Mar 2004 17:51:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Hyh-0006wY-O8 for forces-protocol-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 17:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04780 for ; Sat, 13 Mar 2004 17:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Hyf-0004GX-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 17:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Hxi-0004CY-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 17:50:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2HxB-00048x-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 17:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2HxD-0006vU-8d; Sat, 13 Mar 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Hwj-0006ui-Kb for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 17:49:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04752 for ; Sat, 13 Mar 2004 17:49:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Hwh-00048T-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 17:49:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Hvs-00045C-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 17:48:41 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2HvV-00040u-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 17:48:17 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031314504417:3404 ; Sat, 13 Mar 2004 14:50:44 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Aaudu2000@aol.com Cc: david.putzolu@intel.com, forces-protocol@ietf.org In-Reply-To: <1aa.213270ea.2d84c068@aol.com> References: <1aa.213270ea.2d84c068@aol.com> Organization: ZNYX Networks Message-Id: <1079218093.1123.488.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 03/13/2004 02:50:44 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/13/2004 02:50:46 PM, Serialize complete at 03/13/2004 02:50:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Mar 2004 17:48:13 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, On Sat, 2004-03-13 at 14:52, Aaudu2000@aol.com wrote: > Jamal, > > It is true that the recommendation to use D/C channels can't be > reflected on the protocol specification. It has more to do with the > framework than the protocol itself. Agreed. BTW, didnt mean to repeat some sentences several times on that last email. I must have hit a cut and paste by mistake > But it has to be mandated somehow to allow for interoperability. I > don't see any other way to do this. Interoperability is a MUST. Where we disagree is the mandating piece, and in particular the magic number 2. > Do you? I think it is an issue of config to be honest or even implementation. Solving the problem of how to intermix multicast and unicast connections also solves this problem. > It is just common sense! Carry C/D on separate channels and you > decouple the events happening on any one of the channels from > impacting on the other. Sure. And the difference between the two links is priority. And if you had 4 links you could have more granularity and less impacting of 4 priority levels. Why 2 only? I dont care what you call them D, C, E, Z;-> > With the increasing threats hackers pose to our networks today, and > the increasing important role that the > internet plays in our lives (especially commercially), we owe it to > society to build as > secure a network/network element as we can. Ah, sure. Traffic going outside the box with no mechanism for being secured would be a really BAD idea. Are you going to lock this second link in a closet so noone has access to it? Why not make 4 such links for redundancy. Guys i am trying to work with you so we can can move on. I need to at least convince myself. So far i have have heard the following reasoning: 1) separation allows security. Seems to be making some assumptions for this to be true - as example: theres no way to access the C link from anywhere and brute force DOS it (fill the pipe with meaningles data). Otherwise this link is not secure. If you can guarantee noone access it, isnt that just simply good engineering and nothing else? Maybe in the appendix soemwhere we can list Good Practice and make recommendations on configuration. But why only two channels? Why the hard coding? 2) separation allows prioritization (at least when links are the separation point). No doubt. Infact the security issue being mentioned is also related to this issue. But what has this got to do with having two channels?? Why not 5? Help me out by responding to those questions. We are beating on this problem too long. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 00:00:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18572 for ; Sun, 14 Mar 2004 00:00:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Njh-0005PT-Rf for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 00:00:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E50Tub020791 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 00:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Njh-0005PG-IL for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 00:00:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18514 for ; Sun, 14 Mar 2004 00:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Nje-0004UP-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 00:00:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Nif-0004Kt-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 23:59:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2NhH-0004BD-00 for forces-protocol-web-archive@ietf.org; Sat, 13 Mar 2004 23:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2NhI-0005Fz-Nh; Sat, 13 Mar 2004 23:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Nh4-0005Ff-Jk for forces-protocol@optimus.ietf.org; Sat, 13 Mar 2004 23:57:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18279 for ; Sat, 13 Mar 2004 23:57:43 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Nh2-0004Ae-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 23:57:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Ng8-00046Q-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 23:56:49 -0500 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx with esmtp (Exim 4.12) id 1B2NfK-0003ws-00 for forces-protocol@ietf.org; Sat, 13 Mar 2004 23:55:58 -0500 Received: from Aaudu2000@aol.com by imo-d23.mx.aol.com (mail_out_v37_r1.2.) id l.1ac.2184379c (26116); Sat, 13 Mar 2004 23:55:17 -0500 (EST) Message-ID: <1ac.2184379c.2d853fb5@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: hadi@znyx.com CC: david.putzolu@intel.com, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079240117" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Mar 2004 23:55:17 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079240117 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit OK,..so we give it another try. Why two and not five or six? Because we are dealing with two message types: Control messages and Redirected (Data) messages!!! Putting these messages on two different channels is not the same as assigning different priorities with both messages going on the same pipe. And priorities can't help you in the DOS scenario we are concerned about beacuse can't you first need to pull the packet off the queue or channel, check the priority before deciding what to do with it. You can imagine how many CPU cycles it takes to do that. And if you have to do this for a million D packets before you get to a C packet, you may lose a lot of valuable time before you have a chance to mitigate the problem. You say it is an issue of configuration. How can something be configured if it does not exist? For it to be configured, ForCES protocol on both FE and CE must support it. The only way to ensure this is to mandate it. Regards, Alex. In a message dated 3/13/2004 4:50:35 PM Central Standard Time, hadi@znyx.com writes: Alex, On Sat, 2004-03-13 at 14:52, Aaudu2000@aol.com wrote: > Jamal, > > It is true that the recommendation to use D/C channels can't be > reflected on the protocol specification. It has more to do with the > framework than the protocol itself. Agreed. BTW, didnt mean to repeat some sentences several times on that last email. I must have hit a cut and paste by mistake > But it has to be mandated somehow to allow for interoperability. I > don't see any other way to do this. Interoperability is a MUST. Where we disagree is the mandating piece, and in particular the magic number 2. > Do you? I think it is an issue of config to be honest or even implementation. Solving the problem of how to intermix multicast and unicast connections also solves this problem. > It is just common sense! Carry C/D on separate channels and you > decouple the events happening on any one of the channels from > impacting on the other. Sure. And the difference between the two links is priority. And if you had 4 links you could have more granularity and less impacting of 4 priority levels. Why 2 only? I dont care what you call them D, C, E, Z;-> > With the increasing threats hackers pose to our networks today, and > the increasing important role that the > internet plays in our lives (especially commercially), we owe it to > society to build as > secure a network/network element as we can. Ah, sure. Traffic going outside the box with no mechanism for being secured would be a really BAD idea. Are you going to lock this second link in a closet so noone has access to it? Why not make 4 such links for redundancy. Guys i am trying to work with you so we can can move on. I need to at least convince myself. So far i have have heard the following reasoning: 1) separation allows security. Seems to be making some assumptions for this to be true - as example: theres no way to access the C link from anywhere and brute force DOS it (fill the pipe with meaningles data). Otherwise this link is not secure. If you can guarantee noone access it, isnt that just simply good engineering and nothing else? Maybe in the appendix soemwhere we can list Good Practice and make recommendations on configuration. But why only two channels? Why the hard coding? 2) separation allows prioritization (at least when links are the separation point). No doubt. Infact the security issue being mentioned is also related to this issue. But what has this got to do with having two channels?? Why not 5? Help me out by responding to those questions. We are beating on this problem too long. cheers, jamal -------------------------------1079240117 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
OK,..so we give it another try.
 
Why two and not five or six?  Because we are dealin= g with two message types:
Control messages and Redirected (Data) messages!!!
 
Putting these messages on two different channels is not the same as ass= igning
different priorities with both messages going on the same pipe. &n= bsp;And priorities
can't help you in the DOS scenario we are concerned about beacuse = can't  you
first need to pull the packet off the queue or channel, check the prior= ity before
deciding what to do with it. You can imagine how many CPU cycles it tak= es to
do that.  And if you have to do this for a million D packets befor= e you get to a C
packet, you may lose a lot of valuable time before you h= ave a chance to mitigate
the problem.
 
You say it is an issue of configuration. How can something be configure= d if it does
not exist? For it to be configured, ForCES protocol on both FE and CE m= ust support
it. The only way to ensure this is to mandate it. 
 
Regards,
Alex.
 
In a message dated 3/13/2004 4:50:35 PM Central Standard Time, hadi@zny= x.com writes:
Alex,

On Sat, 2004-03-13 at 14:52, Aaud= u2000@aol.com wrote:
> Jamal,
> 
> It is true that t= he recommendation to use D/C channels can't be
> reflected on the prot= ocol specification. It has more to do with the
> framework than the pr= otocol itself.

Agreed. BTW, didnt mean to repeat some sentences sever= al times on that
last email. I must have hit a cut and paste by mistake
> But it has to be mandated somehow to allow for interoperability.=20= I
> don't see any other way to do this.

Interoperability is a=20= MUST. Where we disagree is the mandating piece,
and in particular the mag= ic number 2.

> Do you?

I think it is an issue of config to=20= be honest or even implementation.
Solving the problem of how to intermix=20= multicast and unicast connections
also solves this problem.

>=20= It is just common sense! Carry C/D on separate channels and you
> dec= ouple the events happening on any one of the channels from
> impactin= g on the other.

Sure. And the difference between the two links is pr= iority.
And if you had 4 links you could have more granularity and less<= BR>impacting of 4 priority levels.
Why 2 only? I dont care what you call=20= them D, C, E, Z;->

> With the increasing threats hackers pose t= o our networks today, and
> the increasing important role that the > internet plays in our lives (especially commercially), we owe it to> society to build as
> secure a network/network element as we c= an. 

Ah, sure. Traffic going outside the box with no mechanism=20= for being
secured would be a really BAD idea.
Are you going to lock t= his second link in a closet so noone has access
to it? Why not make 4 suc= h links for redundancy.

Guys i am trying to work with you so we can c= an move on. I need to at
least convince myself.

So far i have have= heard the following reasoning:
1) separation allows security. Seems to b= e making some assumptions for
this to be true - as example: theres no way= to access the C link from
anywhere and brute force DOS it (fill the pipe= with meaningles data).
Otherwise this link is not secure.
If you can=20= guarantee noone access it, isnt that just simply good
engineering and not= hing else? Maybe in the appendix soemwhere we can
list Good Practice and=20= make recommendations on configuration.
But why only two channels?
Why=20= the hard coding?

2) separation allows prioritization (at least when l= inks are the
separation point).
No doubt. Infact the security issue b= eing mentioned is also related to
this issue.
But what has this got to= do with having two channels??
Why not 5?

Help me out by respondin= g to those questions. We are beating on this
problem too long.

che= ers,
jamal
-------------------------------1079240117-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 00:09:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19021 for ; Sun, 14 Mar 2004 00:09:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Nrk-0006bQ-LS for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 00:08:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E58mIY025374 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 00:08:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Nrk-0006bB-H8 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 00:08:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19009 for ; Sun, 14 Mar 2004 00:08:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Nri-0005Rs-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 00:08:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Nqp-0005N2-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 00:07:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Npz-0005Hh-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 00:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Nq1-00064n-ER; Sun, 14 Mar 2004 00:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Npp-00063N-H9 for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 00:06:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18900 for ; Sun, 14 Mar 2004 00:06:45 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Npn-0005Fh-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 00:06:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Nop-00058C-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 00:05:48 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B2Nnm-00050M-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 00:04:42 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Nnm-000C1a-Ue for forces-protocol@ietf.org; Sun, 14 Mar 2004 05:04:43 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1079218093.1123.488.camel@jzny.localdomain> References: <1aa.213270ea.2d84c068@aol.com> <1079218093.1123.488.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <182A376C-7575-11D8-BC30-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 14:04:38 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I see several different issues here: 1. when we speak of multiple channels/connections I think we are speaking of several different things - differential packet marking - e.g. priority - different queues for differently marked packets - different logical channels - different transport layer connections. I think that the first of these is a protocol issue and am in complete agreement that this must be done. I think the others are either implementation issues or transport encapsulation issues and not specifically protocol issues. 2. Is forcing an ACK for every data packet a sufficient for determining the health of a separate data channel. I suspect it isn't and 'LMP-like' mechanisms such as heartbeat may also be necessary. If this is what we decide we must be aware that we are adding a control mechanism to the data channel. also given that there is a bandwidth expense to ACKing every packet and thus a worsening of any DOS threat, I assume that a mechanism will be necessary for suppressing the sending of every ACK. This makes the necessity of a separate link management mechanism necessary for anyone who chooses to use separate connections for data more apparent. 3. I think that in case we make the use of a separate transport connection optional, it is reasonable to make this a configuration parameter, either in the pre-association phase or during the process of creating the association. 4. While from an intuitive point of view, separate data channels appear to provide security, I have found that such intuitive security mechanisms often give a false sense of security. And given the extra risk of attack that separating control and data sometimes causes I believe we cannot rely on this as a security solution. But I am not a security expert and think that before we declare this necessary from a security pov, we should consult a security expert. If we are willing to settle on the MUST for differential marking and leave the rest for future discussion, we may be able to move on. If we can't I suggest we put this on a second list of issues that require further discussion, and we can look at that list at the end and decide whether we believe these are show stoppers or just hurdles we have yet to overcome. This points out my belief that we need to determine whether we have show-stopper issues to make the required determination regarding a merged protocol, we do not need to have solved every issue, not even every hard still open issue. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 07:45:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17803 for ; Sun, 14 Mar 2004 07:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2UzC-0001Nc-Vf for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 07:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ECiwLO005300 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 07:44:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2UzC-0001NP-N0 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 07:44:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17775 for ; Sun, 14 Mar 2004 07:44:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2UzB-0001rN-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 07:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2UyF-0001lc-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 07:43:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2UxJ-0001fg-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 07:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2UxJ-0001Jg-Gs; Sun, 14 Mar 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2UwK-0001Io-7U for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 07:42:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17663 for ; Sun, 14 Mar 2004 07:41:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2UwJ-0001Z4-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 07:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2UvR-0001UJ-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 07:41:06 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2UvD-0001PF-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 07:40: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 2004031404431692:3628 ; Sun, 14 Mar 2004 04:43:16 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Aaudu2000@aol.com Cc: david.putzolu@intel.com, forces-protocol@ietf.org In-Reply-To: <1ac.2184379c.2d853fb5@aol.com> References: <1ac.2184379c.2d853fb5@aol.com> Organization: ZNYX Networks Message-Id: <1079268047.8028.57.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 03/14/2004 04:43:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/14/2004 04:43:19 AM, Serialize complete at 03/14/2004 04:43:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Mar 2004 07:40:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2004-03-13 at 23:55, Aaudu2000@aol.com wrote: > OK,..so we give it another try. > > Why two and not five or six? Because we are dealing with two message > types: > Control messages and Redirected (Data) messages!!! Are redirected data packets different in from normal control messages in terms of encapsulation? i.e are they NOT wrapped around using the ForCES protocol headers? In our implementation they were. Hence probably my bias. If they are transported within a ForCES message, what makes them require to be on a separate link in comparison to more a response to a commit of a "route add"? I would think that events are another class, btw. But thats a digression. Something else: If you had 5 links available for management, in your scenario, you cant use them all, correct? You can only use two? > Putting these messages on two different channels is not the same as > assigning different priorities with both messages going on the same > pipe. Depends on the nature of the pipe. If you send on one thats known to be less congested vs a congested one then you are prioritizing. > And priorities can't help you in the DOS scenario we are concerned > about beacuse can't you first need to pull the packet off the queue > or channel, check the priority before deciding what to do with it. > You can imagine how many CPU cycles it takes to > do that. And if you have to do this for a million D packets before > you get to a C > packet, you may lose a lot of valuable time before you have a chance > to mitigate > the problem. We did agree that 2 physical links are better than one; and 8 are better than 2. We also did agree that if all of those Links are being DoSed using something that just fills the pipe, then it doesnt matter if you had one or eight. You seem to say that this C link is somehow never susceptible to such an attack? Then it would make sense. But what has that got to do with the ForCES protocol? > You say it is an issue of configuration. How can something be > configured if it does > not exist? For it to be configured, ForCES protocol on both FE and CE > must support Sure; i meant configuration on both sides. Pick any protocol, and you need parameters; try to set two OSPF capable devices in different areas and you will quickly run into issues. > it. The only way to ensure this is to mandate it. Are you mandating that a ForCES FE MUST have two physical links? i.e the few million devices out there with one physical management link cannot be used? Iam afraid that I violently disagree with that. I am gonna add to my list of "why we need two links": 0) We need two links and two links only because we have ONLY two classes of traffic: Data and control. 1) separation (using two links)allows security. 2) separation (suing two links) allows prioritization cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 09:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21042 for ; Sun, 14 Mar 2004 09:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Wdu-0006OY-LG for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 09:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EEV6Om024581 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 09:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Wdu-0006OO-CZ for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 09:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20924 for ; Sun, 14 Mar 2004 09:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Wds-00054c-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:31:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Wcr-0004tC-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:30:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Wbs-0004k1-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Wbt-0006Fl-6w; Sun, 14 Mar 2004 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2VZc-0002yJ-RM for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 08:22:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19066 for ; Sun, 14 Mar 2004 08:22:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2VZb-0005mG-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:22:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2VYH-0005fW-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:21:14 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2VXh-0005ZP-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:20:37 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031405230407:3644 ; Sun, 14 Mar 2004 05:23:04 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <182A376C-7575-11D8-BC30-000393CC2112@acm.org> References: <1aa.213270ea.2d84c068@aol.com> <1079218093.1123.488.camel@jzny.localdomain> <182A376C-7575-11D8-BC30-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1079270434.8019.98.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 03/14/2004 05:23:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/14/2004 05:23:06 AM, Serialize complete at 03/14/2004 05:23:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Mar 2004 08:20:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Avri, On Sun, 2004-03-14 at 00:04, avri@acm.org wrote: > Hi, > > I see several different issues here: > > 1. when we speak of multiple channels/connections I think we are > speaking of several different things > - differential packet marking - e.g. priority > - different queues for differently marked packets > - different logical channels > - different transport layer connections. > > I think that the first of these is a protocol issue and am in complete > agreement that this must be done. Agreed. > I think the others are either implementation issues or transport > encapsulation issues and not specifically protocol issues. Agreed. > 2. Is forcing an ACK for every data packet a sufficient for determining > the health of a separate data channel. I suspect it isn't and > 'LMP-like' mechanisms such as heartbeat may also be necessary. BTW, this topic probably should fall under the issue of Availability (issue #7). Havent looked at LMP; I may be going off (#2) topic, but here goes: I am familiar with other health check/availability schemes like VRRP which are purely dependent on hearbeats. The problem with VRRP is it is unidirectional. In this case i would think from CE to FEs; This provides knowledge to the FEs when CEs go down but not the other way around. In our case, a single message from the CE is sent on the multicast channel every heartbeat period. Netlink2 has ability to selectively request for ACKs. So on every third heartbeat message to the FEs, a request for an ACK is made. We arbitrarly selected number 3. However the request for ACKs may never be triggered if the state of all FEs is known to be healthy (example because of recent route add response from all the FEs). Additionaly (we never implemented this) you could have responses from the FEs carry health information (such as link states). A smart ACK implosion scheme also controls how many FEs respond to reduce traffic to be processed by CE. > If this > is what we decide we must be aware that we are adding a control > mechanism to the data channel. Do you mean control is a message that is terminated by the CE or FE as opposed of going to the LFB? I am still struggling to understand the desire for separation of links. > also given that there is a bandwidth > expense to ACKing every packet and thus a worsening of any DOS threat, > I assume that a mechanism will be necessary for suppressing the sending > of every ACK. This makes the necessity of a separate link management > mechanism necessary for anyone who chooses to use separate connections > for data more apparent. I think if there exists a good link management protocol that is sanctioned by the IETF it may make sense to reuse it. Note however the health checks may involve more than links. > 3. I think that in case we make the use of a separate transport > connection optional, it is reasonable to make this a configuration > parameter, either in the pre-association phase or during the process of > creating the association. Agreed. Preassociation is the config phase. > 4. While from an intuitive point of view, separate data channels appear > to provide security, I have found that such intuitive security > mechanisms often give a false sense of security. And given the extra > risk of attack that separating control and data sometimes causes I > believe we cannot rely on this as a security solution. But I am not a > security expert and think that before we declare this necessary from a > security pov, we should consult a security expert. I think if the separate channel is NOT accessible it may provide some sense of security until someone finds a way to access it - in which case it becomes another channel that can be DOSed. > If we are willing to settle on the MUST for differential marking and > leave the rest for future discussion, we may be able to move on. If we Sounds reasonable to me. > can't I suggest we put this on a second list of issues that require > further discussion, and we can look at that list at the end and decide > whether we believe these are show stoppers or just hurdles we have yet > to overcome. To me it looks like more of a hurdle. To be honest i havent liked any of the reasoning i have seen so far. I want to jump on the boat but it has to make some sense we are not going towards a waterfall. > This points out my belief that we need to determine whether we have > show-stopper issues to make the required determination regarding a > merged protocol, we do not need to have solved every issue, not even > every hard still open issue. I agree. We need to move on. We should also be able to close issue #3. Any objections? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 09:31:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21064 for ; Sun, 14 Mar 2004 09:31:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2WeC-0006Qo-6S for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 09:31:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EEVOV8024716 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 09:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2WeC-0006QZ-2v for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 09:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20988 for ; Sun, 14 Mar 2004 09:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2WeA-00056i-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:31:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2WdC-0004wp-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:30:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Wc4-0004lZ-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 09:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Wbv-0006H3-Ct; Sun, 14 Mar 2004 09:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2VpX-0003fH-As for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 08:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19559 for ; Sun, 14 Mar 2004 08:39:01 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2VpW-0007bN-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Vob-0007WE-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:38:05 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B2Vno-0007R0-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 08:37:16 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2Vnk-0001iM-Po for forces-protocol@ietf.org; Sun, 14 Mar 2004 13:37:15 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1079270434.8019.98.camel@jzny.localdomain> References: <1aa.213270ea.2d84c068@aol.com> <1079218093.1123.488.camel@jzny.localdomain> <182A376C-7575-11D8-BC30-000393CC2112@acm.org> <1079270434.8019.98.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 21:37:07 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am not suggesting that we use LMB. What I am suggesting is that is we have a separate connection that does not fate-share with the control, then we need to have a monitor it. I..e something that monitors that link. a. On 14 mar 2004, at 21.20, Jamal Hadi Salim wrote: > >> 2. Is forcing an ACK for every data packet a sufficient for >> determining >> the health of a separate data channel. I suspect it isn't and >> 'LMP-like' mechanisms such as heartbeat may also be necessary. > > BTW, this topic probably should fall under the issue of Availability > (issue #7). > Havent looked at LMP; I may be going off (#2) topic, but here goes: > I am familiar with other health check/availability schemes like VRRP > which are purely dependent on hearbeats. > The problem with VRRP is it is unidirectional. In this case i would > think from CE to FEs; This provides knowledge to the FEs when CEs go > down but not the other way around. > In our case, a single message from the CE is sent on the multicast > channel every heartbeat period. Netlink2 has ability to selectively > request for ACKs. So on every third heartbeat message to the FEs, a > request for an ACK is made. We arbitrarly selected number 3. However > the > request for ACKs may never be triggered if the state of all FEs is > known > to be healthy (example because of recent route add response from all > the > FEs). > Additionaly (we never implemented this) you could have responses from > the FEs carry health information (such as link states). > A smart ACK implosion scheme also controls how many FEs respond > to reduce traffic to be processed by CE. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 15:00:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03620 for ; Sun, 14 Mar 2004 15:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bm5-0004iJ-9Z for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 14:59:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EJxra3018113 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 14:59:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bm4-0004i4-T1 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 14:59:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03519 for ; Sun, 14 Mar 2004 14:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2bm2-0003N5-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 14:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2bkn-000380-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 14:58:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2bkM-0002yc-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 14:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bkO-0003c9-Gx; Sun, 14 Mar 2004 14:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2XWA-00036G-4N for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 10:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22558 for ; Sun, 14 Mar 2004 10:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2XW7-00030Q-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 10:27:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2XVB-0002uj-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 10:26:10 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B2XUZ-0002cC-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 10:25:31 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 14 Mar 2004 23:35:10 +0800 Message-ID: <15ed01c409d8$06193e00$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD8029CF893@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 23:21:29 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Hi David, Firstly, I really appreciate you have presented a very helpful scenario for the discussion. Please see reply inline. ----- Original Message ----- From: "Putzolu, David" Here is my understanding of the reasons for separate channels for different priority traffic (for now I'll leave aside whether C & D are the different priorities or if there is some other priority): 1) If I build hardware that has two physical channels, but ForCES carries everything in a single logical connection, it becomes impossible (short of extremely ugly layer violations) to use my dual channel hardware, because all the ForCES messages are coming down in a single stream. [Weiming Re: Actually you have raised another question, that is how ForCES can couple with the case where there are multiple hardware links (2, 3, and even more) between a CE and a FE. It's true that the C/D channel separation in physical link may fit well to 2 physical links case, but how about 3, 4 or more physical links? I noticed that Jamal has also noticed this. Because we can not force the implementation layer to use how many physical links (2,3,4...), I have to say not to explicilitly ask for C/D channel separation in ForCES protocol is still more reasonable. That means if they have exactly two links, they may use C/D separation, if they have more, they may not use such separation. There is another question how one stream can be coupled with two or more physical links. Actually there are many techiniques toward this such as demultiplexing . But I would prefer not to mention this in the protocol, to leave it to the implementation layer. ] 2) If I build hardware that has one physical connection, but has multiple levels of QoS (e.g. Ethernet backplane with support for 802.1p), but ForCES carries everything in a single logical connection, it becomes impossible to utilize my hardware's QoS support (short of those ugly layer violations - Ethernet MAC chip cracking the ForCES header to look at priority bits) [Weiming Re: This is exactly what GRMP has already paid attention. Please allow me to quote a part from GRMP to better explain it. Quote GRMP P. 47: DoS Protection Policy has the data format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| CCP | Reserved | BW Lower Limit| BW Upper Limit| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| DCP | Reserved | BW Lower Limit| BW Upper Limit| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C, D Tag: Control channel, Data channel priority 0 - Normal priority 1 - High Priority Note that the function of the priority here is different from that of the priority flag in GRMP message headers. This priority is only for the message transmission priority between CE and FE, while the priority in message header is for CE or FE to process the message when it arrives at CE or FE. Priority in GRMP message header has no effect on protecting DoS attacks for attackers are also able to set the priorities. /quote From above description, we know that the priority for DoS protection is defined as an FE attribute instead as that in the message header. The priority for DoS protection (as well as for congestion, reliability) is different from that defined in ForCES header, which is just for message processing when the messages has already arrived at terminal. In this scheme, there is no difficulty (no ugly layer violation) for the priority to be mapped into transport layer. (Note that when GRMP mentioned Control channel and Data channel avove, it does not mean a channel in the physical link. Actually I suppose in the multilevel Ethernet QoS case, the channel idea also only exists at the sender and receiver side (different queues) instead in the physical link. ] 3) If I build hardware that has one physical connection, and no support for QoS, but I design ForCES to carry things in separate logical channels, I can easily map them down to the single physical channel. This is merely a problem of multiplexing, and is normal for lower layers to do. [Weiming Re: This is why I propose we should use "RECOMMEND" instead "MUST". Just as you mentioned here, some may not support different channels. If we use "MUST", they may think that they can not meet the requirements and just abandon using ForCES. ] Basically, if one puts everything on one logical channel, it precludes some very realistic, beneficial, and deployed hardware approaches. If one puts different priority traffic in different logical channels, one enables those hardware approaches without precluding anything. [Weiming Re: by using the idea like the DoS protection policy as an FE attribute (Of course the policy contents in GRMP still need to be polished), the transport layer benefits can be adpoted. On the other hand, I still don't see multiple channels/connections in the physical link help more for this. ] Sincerely, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 18:41:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14254 for ; Sun, 14 Mar 2004 18:41:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fES-0006tP-1m for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 18:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ENfOPc026492 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 18:41:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fER-0006tD-OR for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 18:41:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14250 for ; Sun, 14 Mar 2004 18:41:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fEO-00004c-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 18:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fDU-0007me-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 18:40:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2fD8-0007gh-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 18:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fDA-0006rb-Br; Sun, 14 Mar 2004 18:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fCV-0006qI-BL for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 18:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14199 for ; Sun, 14 Mar 2004 18:39:19 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fCS-0007fY-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:39:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fBZ-0007Zh-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:38:26 -0500 Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fAz-0007SC-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:37:49 -0500 Received: from Aaudu2000@aol.com by imo-m20.mx.aol.com (mail_out_v37.4.) id l.1e1.1b3e6afa (16930); Sun, 14 Mar 2004 18:37:04 -0500 (EST) Message-ID: <1e1.1b3e6afa.2d8646a0@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: hadi@znyx.com CC: david.putzolu@intel.com, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079307424" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 18:37:04 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079307424 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Jamal, Redirected packets are definitely different in terms of payload from control packets. In FACT, this is indicated by giving them different message classes (and types). What is the point being put across with the five links/channels issue? I really don't understand that. It is harder to DOS the C link because it is not exposed to packets from outside the NE. Redirected packets are foreign packets (in origin) and are very succeptible to manipulation by hostile third parties. Hence D link will be more vulnerable to attacks. Regards, Alex. In a message dated 3/14/2004 6:41:07 AM Central Standard Time, hadi@znyx.com writes: On Sat, 2004-03-13 at 23:55, Aaudu2000@aol.com wrote: > OK,..so we give it another try. > > Why two and not five or six? Because we are dealing with two message > types: > Control messages and Redirected (Data) messages!!! Are redirected data packets different in from normal control messages in terms of encapsulation? i.e are they NOT wrapped around using the ForCES protocol headers? In our implementation they were. Hence probably my bias. If they are transported within a ForCES message, what makes them require to be on a separate link in comparison to more a response to a commit of a "route add"? I would think that events are another class, btw. But thats a digression. Something else: If you had 5 links available for management, in your scenario, you cant use them all, correct? You can only use two? > Putting these messages on two different channels is not the same as > assigning different priorities with both messages going on the same > pipe. Depends on the nature of the pipe. If you send on one thats known to be less congested vs a congested one then you are prioritizing. > And priorities can't help you in the DOS scenario we are concerned > about beacuse can't you first need to pull the packet off the queue > or channel, check the priority before deciding what to do with it. > You can imagine how many CPU cycles it takes to > do that. And if you have to do this for a million D packets before > you get to a C > packet, you may lose a lot of valuable time before you have a chance > to mitigate > the problem. We did agree that 2 physical links are better than one; and 8 are better than 2. We also did agree that if all of those Links are being DoSed using something that just fills the pipe, then it doesnt matter if you had one or eight. You seem to say that this C link is somehow never susceptible to such an attack? Then it would make sense. But what has that got to do with the ForCES protocol? > You say it is an issue of configuration. How can something be > configured if it does > not exist? For it to be configured, ForCES protocol on both FE and CE > must support Sure; i meant configuration on both sides. Pick any protocol, and you need parameters; try to set two OSPF capable devices in different areas and you will quickly run into issues. > it. The only way to ensure this is to mandate it. Are you mandating that a ForCES FE MUST have two physical links? i.e the few million devices out there with one physical management link cannot be used? Iam afraid that I violently disagree with that. I am gonna add to my list of "why we need two links": 0) We need two links and two links only because we have ONLY two classes of traffic: Data and control. 1) separation (using two links)allows security. 2) separation (suing two links) allows prioritization cheers, jamal -------------------------------1079307424 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Jamal,
 
Redirected packets are definitely different in terms of payload from co= ntrol packets.
In FACT, this is indicated by giving them different message c= lasses (and types).
 
What is the point being put across with the five links/channels issue?=20= I really don't
understand that.
 
It is harder to DOS the C link because it is not exposed to packets fro= m outside the
NE. Redirected packets are foreign packets (in origin) and are very suc= ceptible to
manipulation by hostile third parties. Hence D link will be more vulner= able to attacks.
 
Regards,
Alex.
 
In a message dated 3/14/2004 6:41:07 AM Central Standard Time, hadi@zny= x.com writes:
On Sat, 2004-03-13 at 23:55, Aaudu2000@aol.com= wrote:
> OK,..so we give it another try.
> 
> Why t= wo and not five or six?  Because we are dealing with two message
>= ; types:
> Control messages and Redirected (Data) messages!!!

= Are redirected data packets different in from normal control messages
in=20= terms of encapsulation? i.e are they NOT wrapped around using the
ForCES=20= protocol headers? In our implementation they were. Hence probably
my bias= .
If they are transported within a ForCES message, what makes them requir= e
to be on a separate link in comparison to more a response to a commit o= f
a "route add"?
I would think that events are another class, btw. But= thats a
digression.

Something else:
If you had 5 links availab= le for management, in your scenario, you cant
use them all, correct? You=20= can only use two?

> Putting these messages on two different channe= ls is not the same as
> assigning different priorities with both messa= ges going on the same
> pipe. 

Depends on the nature of t= he pipe. If you send on one thats known to be
less congested vs a congest= ed one then you are prioritizing.

> And priorities can't help you=20= in the DOS scenario we are concerned
> about beacuse can't  you f= irst need to pull the packet off the queue
> or channel, check the pri= ority before deciding what to do with it.
>  You can imagine how=20= many CPU cycles it takes to
> do that.  And if you have to do th= is for a million D packets before
> you get to a C
> packet, yo= u may lose a lot of valuable time before you have a chance
> to mitiga= te
> the problem.

We did agree that 2 physical links are bette= r than one; and
8 are better than 2.
We also did agree that if all of=20= those Links are being DoSed using
something that just fills the pipe, the= n it doesnt matter
if you had one or eight.
You seem to say that this=20= C link is somehow never susceptible to such an
attack? Then it would make= sense. But what has that got to do with
the ForCES protocol?

>= ; You say it is an issue of configuration. How can something be
> conf= igured if it does
> not exist? For it to be configured, ForCES protoco= l on both FE and CE
> must support

Sure; i meant configuration=20= on both sides.
Pick any protocol, and you need parameters; try to set two=
OSPF capable devices in different areas and you will quickly
run into= issues.

> it. The only way to ensure this is to mandate it.
<= BR>Are you mandating that a ForCES FE MUST have two physical links?
i.e t= he few million devices out there with one physical management link
cannot= be used? Iam afraid that I violently disagree with that.

I am gonna=20= add to my list of "why we need two links":
0) We need two links and two l= inks only because we have ONLY two classes
of traffic: Data and control.=20=
1) separation (using two links)allows security.
2) separation (suing=20= two links) allows prioritization

cheers,
jamal
=
-------------------------------1079307424-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 19:00:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14854 for ; Sun, 14 Mar 2004 19:00:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fWu-0007ow-Tl for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 19:00:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F00S8b030056 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 19:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fWu-0007oh-O4 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 19:00:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14846 for ; Sun, 14 Mar 2004 19:00:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fWr-0002CU-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 19:00:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fVz-00025Q-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 18:59:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2fVS-0001ya-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 18:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fVU-0007lv-O1; Sun, 14 Mar 2004 18:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fUy-0007lc-Vt for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 18:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14751 for ; Sun, 14 Mar 2004 18:58:24 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fUv-0001wR-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fU1-0001q7-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:57:30 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx with esmtp (Exim 4.12) id 1B2fTL-0001fQ-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 18:56:47 -0500 Received: from Aaudu2000@aol.com by imo-d22.mx.aol.com (mail_out_v37.4.) id t.1de.1aae4f29 (16930); Sun, 14 Mar 2004 18:56:12 -0500 (EST) Message-ID: <1de.1aae4f29.2d864b1c@aol.com> Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: avri@acm.org, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079308572" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 18:56:12 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079308572 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FACT uses a heartbeat message to do CE/FE link health checks. We can certainly do the same here too. Regards, Alex. In a message dated 3/14/2004 8:29:29 AM Central Standard Time, avri@acm.org writes: Hi, I am not suggesting that we use LMB. What I am suggesting is that is we have a separate connection that does not fate-share with the control, then we need to have a monitor it. I..e something that monitors that link. a. On 14 mar 2004, at 21.20, Jamal Hadi Salim wrote: > >> 2. Is forcing an ACK for every data packet a sufficient for >> determining >> the health of a separate data channel. I suspect it isn't and >> 'LMP-like' mechanisms such as heartbeat may also be necessary. > > BTW, this topic probably should fall under the issue of Availability > (issue #7). > Havent looked at LMP; I may be going off (#2) topic, but here goes: > I am familiar with other health check/availability schemes like VRRP > which are purely dependent on hearbeats. > The problem with VRRP is it is unidirectional. In this case i would > think from CE to FEs; This provides knowledge to the FEs when CEs go > down but not the other way around. > In our case, a single message from the CE is sent on the multicast > channel every heartbeat period. Netlink2 has ability to selectively > request for ACKs. So on every third heartbeat message to the FEs, a > request for an ACK is made. We arbitrarly selected number 3. However > the > request for ACKs may never be triggered if the state of all FEs is > known > to be healthy (example because of recent route add response from all > the > FEs). > Additionaly (we never implemented this) you could have responses from > the FEs carry health information (such as link states). > A smart ACK implosion scheme also controls how many FEs respond > to reduce traffic to be processed by CE. > -------------------------------1079308572 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
FACT uses a heartbeat message to do CE/FE link health checks.  We=20= can certainly
do the same here too.
 
Regards,
Alex.
 
In a message dated 3/14/2004 8:29:29 AM Central Standard Time, avri@acm= .org writes:
Hi,

I am not suggesting that we use LMB= .  What I am suggesting is that is
we have a separate connection th= at does not fate-share with the
control, then we need to have a monitor=20= it. I..e something that
monitors that link.

a.


On 14 m= ar 2004, at 21.20, Jamal Hadi Salim wrote:

>
>> 2. Is for= cing an ACK for every data packet a sufficient for
>> determining<= BR>>> the health of a separate data channel.  I suspect it isn't=20= and
>> 'LMP-like' mechanisms such as heartbeat may also be necessar= y.
>
> BTW, this topic probably should fall under the issue of A= vailability
> (issue #7).
> Havent looked at LMP; I may be going= off (#2) topic, but here goes:
> I am familiar with other health chec= k/availability schemes like VRRP
> which are purely dependent on hearb= eats.
> The problem with VRRP is it is unidirectional. In this case i=20= would
> think from CE to FEs; This provides knowledge to the FEs when=20= CEs go
> down but not the other way around.
> In our case, a sin= gle message from the CE is sent on the multicast
> channel every heart= beat period. Netlink2 has ability to selectively
> request for ACKs. S= o on every third heartbeat message to the FEs, a
> request for an ACK=20= is made. We arbitrarly selected number 3. However
> the
> reque= st for ACKs may never be triggered if the state of all FEs is
> known=
> to be healthy (example because of recent route add response from al= l
> the
> FEs).
> Additionaly (we never implemented this)= you could have responses from
> the FEs carry health information (suc= h as link states).
> A smart ACK implosion scheme also controls how ma= ny FEs respond
> to reduce traffic to be processed by CE.
>
-------------------------------1079308572-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 19:13:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15301 for ; Sun, 14 Mar 2004 19:13:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fjX-0000AU-I0 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 19:13:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F0DVv5000642 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 19:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fjX-0000AH-BZ for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 19:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15298 for ; Sun, 14 Mar 2004 19:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fjV-0003mr-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 19:13:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fiY-0003gL-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 19:12:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2fi1-0003Za-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 19:11:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fi4-00008o-ET; Sun, 14 Mar 2004 19:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2fhS-0008Vq-TQ for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 19:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15222 for ; Sun, 14 Mar 2004 19:11:18 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2fhP-0003XC-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 19:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2fgR-0003PD-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 19:10:20 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx with esmtp (Exim 4.12) id 1B2ffQ-0003Ax-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 19:09:16 -0500 Received: from Aaudu2000@aol.com by imo-d22.mx.aol.com (mail_out_v37.4.) id r.1e3.1b4558b1 (16930); Sun, 14 Mar 2004 19:08:34 -0500 (EST) Message-ID: <1e3.1b4558b1.2d864e02@aol.com> Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast To: jpickering@creeksidenet.com, alex.audu@alcatel.com CC: dro@zurich.ibm.com, hadi@znyx.com, ellen.m.deleganes@intel.com, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079309314" X-Mailer: 9.0 for Windows sub 5003 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 19:08:34 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079309314 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello Jeff, Certainly using multi-unicast instead of multicast to avoid incidents of ACK implosion, gives us the time dimension to play with. The CE only needs to send out a manageable number of messages at a time. Cheers, Alex. In a message dated 3/12/2004 8:34:10 PM Central Standard Time, jpickering@creeksidenet.com writes: Alex, Using unicast to avoid multicast ack implosion devolves into the worst case of not only a unicast ack for every packet, but also the unicast packet causing the ack. Im afraid we need to accept some level of complexity to enable the scaling we need. Cheers, Jeff Alex Audu wrote: > Hello Patrick, > > Sorry it took me this late to respond. I really don't know what a > "MUST if available" > means. The main issue with multicast is that there are still a lot of > unresolved issues > about it viz: > 1) In a critical environment like the one we are talking about, we > need ACKs to give > a warm-fuzzy feeling that FEs are getting what the CEs are > blasting at them. What is > the implication of this as number of FEs rise into the thousands? > You run the risk > of tons of ACKs comming back and overwhleming the CE. That is > essentially a > flooding attack on the CE. I believe it is called ACK implosion in > literature. A lot > of ways have been proposed to avoid this,..like selective > ACK/NACK,..etc. These > suggested solutions are pretty complex. > > 2) As the number of FEs grows, the chance of packet loss increases in > the network > when doing multicast. You have to fall back on retransmits to > accommodate this. > That essentially whipes out the percieved benefits of mulitcast. > > 3) How do you synchronize your packets and make sure they are recieved > in order at the > the FEs? You have to build something extra into your application > or the FoRCES > protocol to take care of such issues. And if you don't specify > it, there is danger of > different implementations resulting in interoperability issues. > > 4) And there are issues of security to address. > > In short, I am not sure we know enough about multicast to mandate its > use in a > critical envirnonment. If we are not concerned about timing, sure, we > can retransmit > a couple of times untill all the endpoints get the data. But we > resorted to multicast to > save time in the first place. > > Regards, > Alex. -------------------------------1079309314 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello Jeff,
 
Certainly using multi-unicast instead of multicast to avoid incidents o= f ACK implosion,
gives us the time dimension to play with.  The = ;CE only needs to send out a manageable
number of messages at a time.
 
Cheers,
Alex.
 
In a message dated 3/12/2004 8:34:10 PM Central Standard Time, jpickeri= ng@creeksidenet.com writes:
Alex,

Using unicast to avoid multicast=20= ack implosion devolves into the worst
case of  not only
a unicas= t ack for every packet, but also the unicast packet causing the
ack. Im=20= afraid we
need to accept some level of complexity to enable the scaling w= e need.

Cheers,
Jeff


Alex Audu wrote:

> Hello= Patrick,
>
> Sorry it took me this late to respond.  I rea= lly don't know what a
> "MUST if  available"
> means. = ; The main issue with multicast is that there are still a lot of
> un= resolved issues
> about it viz:
> 1) In a critical environment l= ike the one we are talking about,  we
> need ACKs to give
>= ;     a warm-fuzzy feeling that FEs are getting what the CEs=20= are
> blasting at them.  What is
>     the=20= implication of this as number of FEs rise into the thousands? 
>= You run the risk
>     of  tons of ACKs comming b= ack and overwhleming the CE. That is
> essentially a
>  &n= bsp;  flooding attack on the CE. I believe it is called ACK implosion i= n
> literature.  A lot
>      of ways have=20= been proposed to avoid this,..like selective
> ACK/NACK,..etc. These<= BR>>     suggested solutions are pretty complex.
>> 2) As the number of FEs grows, the  chance of packet loss increa= ses in
> the network
>     when doing multicast.=   You have to fall back on retransmits  to
> accommodate th= is.
>      That essentially whipes out the percieved be= nefits of mulitcast.
>
> 3) How do you synchronize your packets=20= and make sure they are recieved
> in order at the
>   = ;  the FEs?  You have to build something extra into  your app= lication
> or the FoRCES
>     protocol to take=20= care of such issues.  And if you don't specify
> it, there is da= nger of
>     different implementations resulting in in= teroperability issues.
>
> 4) And there are issues of security t= o address.
>
> In short, I am not sure we know enough about mult= icast to mandate its
> use in a
> critical envirnonment. If we=20= are not concerned about timing, sure, we
> can retransmit
> a c= ouple of times untill all the endpoints get the data. But we
> resort= ed to multicast  to
> save time in the first place.
>
&g= t; Regards,
> Alex.
-------------------------------1079309314-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 20:14:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16868 for ; Sun, 14 Mar 2004 20:14:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2gfg-0003Tq-U0 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 20:13:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F1DaZI013372 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 20:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2gfg-0003Tb-KH for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 20:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16860 for ; Sun, 14 Mar 2004 20:13:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2gfe-0002Z8-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 20:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2gej-0002SC-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 20:12:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2ge7-0002Kr-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 20:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ge9-0003P0-5b; Sun, 14 Mar 2004 20:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2gdX-0003OC-8X for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 20:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16786 for ; Sun, 14 Mar 2004 20:11:21 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2gdV-0002Iy-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 20:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2gcY-0002Bs-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 20:10:22 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B2gbb-00022U-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 20:09:24 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2gbR-0006e6-38 for forces-protocol@ietf.org; Mon, 15 Mar 2004 01:09:24 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1e1.1b3e6afa.2d8646a0@aol.com> References: <1e1.1b3e6afa.2d8646a0@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5BC8A71F-761D-11D8-BC30-000393CC2112@acm.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 09:09:07 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On 15 mar 2004, at 07.37, Aaudu2000@aol.com wrote: > > It is harder to DOS the C link because it is not exposed to packets=20 > from outside the > NE. Redirected packets are foreign packets (in origin) and are very=20 > succeptible to > manipulation by hostile third parties. Hence D link will be more=20 > vulnerable to attacks. > =A0 While the FE don't need to respond to messages from non authroized=20 elements, in a configuration that includes an external link between the=20= CE and Fe, a malicious system could indeed direct packets at the CE and=20= FE across the C channel. I would assume the risk is the same as with inter-fe traffic when they=20= are on a external link. On an internal link I would not expect that=20 either would be more prone then the other. In fact it is not intuitively obvious to me while the risk on either=20 link is greater then on the other. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 21:33:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19678 for ; Sun, 14 Mar 2004 21:33:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hv0-0007z7-V2 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 21:33:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F2XUG7030694 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 21:33:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hv0-0007yy-P8 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 21:33:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19660 for ; Sun, 14 Mar 2004 21:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2huy-00040Z-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 21:33:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2hu7-0003ts-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 21:32:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2htW-0003nO-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 21:31:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2htZ-0007qj-25; Sun, 14 Mar 2004 21:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2htB-0007q7-9E for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 21:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19589 for ; Sun, 14 Mar 2004 21:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ht8-0003m7-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 21:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2hs3-0003eX-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 21:30:27 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2hrb-0003Yo-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 21:29:59 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031418322681:3885 ; Sun, 14 Mar 2004 18:32:26 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <1aa.213270ea.2d84c068@aol.com> <1079218093.1123.488.camel@jzny.localdomain> <182A376C-7575-11D8-BC30-000393CC2112@acm.org> <1079270434.8019.98.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1079317798.8027.103.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 03/14/2004 06:32:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/14/2004 06:32:28 PM, Serialize complete at 03/14/2004 06:32:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Mar 2004 21:29:58 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2004-03-14 at 08:37, avri@acm.org wrote: > Hi, > > I am not suggesting that we use LMB. What I am suggesting is that is > we have a separate connection that does not fate-share with the > control, then we need to have a monitor it. I..e something that > monitors that link. Agreed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 22:19:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21096 for ; Sun, 14 Mar 2004 22:19:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ick-0002eI-UI for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 22:18:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F3IgXP010179 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 22:18:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ick-0002e6-L6 for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 22:18:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21091 for ; Sun, 14 Mar 2004 22:18:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ich-0001R0-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 22:18:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2ibr-0001Jc-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 22:17:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2ib3-0001BR-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 22:16:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ib5-0002ad-VQ; Sun, 14 Mar 2004 22:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2iae-0002Yk-1g for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 22:16:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21042 for ; Sun, 14 Mar 2004 22:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2iaa-00018d-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 22:16:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2iZr-00012U-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 22:15:44 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2iZ7-0000vf-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 22:14:57 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031419172450:3896 ; Sun, 14 Mar 2004 19:17:24 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Aaudu2000@aol.com Cc: david.putzolu@intel.com, forces-protocol@ietf.org In-Reply-To: <1e1.1b3e6afa.2d8646a0@aol.com> References: <1e1.1b3e6afa.2d8646a0@aol.com> Organization: ZNYX Networks Message-Id: <1079320495.8027.149.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 03/14/2004 07:17:24 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/14/2004 07:17:26 PM, Serialize complete at 03/14/2004 07:17:26 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Mar 2004 22:14:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2004-03-14 at 18:37, Aaudu2000@aol.com wrote: > Hi Jamal, > > Redirected packets are definitely different in terms of payload from > control packets. > In FACT, this is indicated by giving them different message classes > (and types). So no different than GRMP or Netlink2. I.e you take the data packet, wrap a header around it and ship it to the CE. > What is the point being put across with the five links/channels issue? > I really don't understand that. If you had five separate physical links instead of two, could you use all of them? Or would you only use two out of the five? > It is harder to DOS the C link because it is not exposed to packets > from outside the NE. Redirected packets are foreign packets (in > origin) and are very succeptible to manipulation by hostile third > parties. Hence D link will be more vulnerable to attacks. This is a weak but valid point. Assuming of course: a) Assuming a "foreign" (read: multihop ) CE cant be talking to an FE. Or: b) CE and FE are NOT accessible from the outside world. sounds very difficult to me since the NE would be accessible. and/or c) that the dedicated C link is infact within a chasis only. That if you go across chasis or a network you also have these dedicated C channels as in SS7. A very expensive proposition. You realize that people are moving towards unified IP based networks to avoid all these costs, dont you? Infact if memory serves me right SCTP was created so it could carry SS7 traffic initially. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 14 23:28:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22852 for ; Sun, 14 Mar 2004 23:28:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jhR-00074Y-Jt for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 23:27:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F4Rb9g027180 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 23:27:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jhR-00074J-Dt for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 23:27:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22804 for ; Sun, 14 Mar 2004 23:27:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2jhP-0000tU-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:27:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2jgS-0000mz-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:26:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2jfs-0000gd-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jft-00072e-TR; Sun, 14 Mar 2004 23:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jfU-000720-CB for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 23:25:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22758 for ; Sun, 14 Mar 2004 23:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2jfS-0000fc-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:25:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2jeV-0000Yy-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:24:37 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2jdZ-0000Lj-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:23:37 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2F4QxDN001896; Mon, 15 Mar 2004 04:26:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2F4GrOD014796; Mon, 15 Mar 2004 04:16:57 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031420230217453 ; Sun, 14 Mar 2004 20:23:02 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 14 Mar 2004 20:23:02 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40A45.349C6672" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EE98@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQJPQquAwCyrMBsRKGA494grb3oegBB/ZFQ From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 15 Mar 2004 04:23:02.0816 (UTC) FILETIME=[34CE1A00:01C40A45] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 20:23:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40A45.349C6672 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, =20 I don't think security is the correct word to be used here. You could probably say robust. =20 Hormuzd =20 _____ =20 From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Aaudu2000@aol.com Sent: Saturday, March 13, 2004 12:49 PM To: jon.maloy@ericsson.com; alex.audu@alcatel.com Cc: avri@acm.org; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections =20 Hello Jon, =20 We manadate dual channels (one for C and the other D) to guarrantee interoperable secured networking. =20 =20 Why more secure? As soon as CE detects that FE is being DOS'd, it should be able to send control signals easily to mitigate the situation. If the control packets are caught behind a million D packets still in the queue, there is no chance for this to happen quickly. =20 Some have also floated the idea that in a single box environment, maybe we should relax the requirement a bit. Well,..I think as long as CE and FE are separate, the link/channel between them may be a choke point if that link carries both C and D packets. Such C/D packets should be conveyed over different channels (queues,..etc). =20 =20 Regards, Alex. =20 In a message dated 3/12/2004 5:05:36 PM Central Standard Time, jon.maloy@ericsson.com writes: A MUST would imply that we think other solutions are impossible, and=20 would force vendors to add functionality they may consider unecessary. =09 > But what is the implication of that on interoperable secure=20 > operation? If different vendors > make C and FE boxes, the chance that one would support separate C/D=20 > channels while the > other doesn't is greater. That will force the C/FE inter-action to=20 > fall back on the less secure > single channel model.=20 =09 Less reliable, yes, but why less secure ? =09 > I am not sure that is a desireable solution given the increased=20 > attention > on security these days.=20 ------_=_NextPart_001_01C40A45.349C6672 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alex,

 

I don’t think security is the correct word to be used here. You could probably say = robust.

 

Hormuzd

 

From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On Behalf Of Aaudu2000@aol.com
Sent: Saturday, March 13, = 2004 12:49 PM
To: = jon.maloy@ericsson.com; alex.audu@alcatel.com
Cc: avri@acm.org; = forces-protocol@ietf.org
Subject: Re: = [Forces-protocol] Issue 2: Multiple channels/connections

 

Hello Jon,

 

We manadate dual channels (one for C and the other D) = to guarrantee interoperable

secured networking. 

 

Why more secure?  As soon as CE detects that FE is being DOS'd, it should be able

to send control signals easily to mitigate the situation. If the control packets are caught

behind a million D packets still in the queue, there = is no chance for this to happen quickly.

 

Some have also floated the idea that in a single box environment, maybe we should relax

the requirement a bit.  Well,..I think as long = as CE and FE are separate, the link/channel

between them may be a choke point if that link = carries both C and D packets.  Such C/D

packets should be conveyed over different channels (queues,..etc).

 

 

Regards,

Alex.

 

In a message dated 3/12/2004 5:05:36 PM Central = Standard Time, jon.maloy@ericsson.com writes:

A MUST would imply that we think other solutions are impossible, and
would force
vendors to add functionality they may consider unecessary.

> But what is the implication of that on  interoperable secure =
> operation?  If different vendors
> make C and FE boxes, the chance that one would support separate C/D =
> channels while the
> other doesn't is greater.  That will force the C/FE = inter-action to
> fall back on the less secure
> single channel model.

Less reliable, yes, but why less secure ?

> I am not sure that is  a  desireable solution given the increased
> attention
> on security these days.

------_=_NextPart_001_01C40A45.349C6672-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 00:00:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24435 for ; Mon, 15 Mar 2004 00:00:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kCO-0000Uj-Ko for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 23:59:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F4xabl001900 for forces-protocol-archive@odin.ietf.org; Sun, 14 Mar 2004 23:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kCO-0000UZ-GO for forces-protocol-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 23:59:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24418 for ; Sun, 14 Mar 2004 23:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2kCM-0004uS-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:59:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2kBQ-0004oD-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:58:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2kAp-0004iB-00 for forces-protocol-web-archive@ietf.org; Sun, 14 Mar 2004 23:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kAr-0000Sg-9X; Sun, 14 Mar 2004 23:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kAR-0000S7-5E for forces-protocol@optimus.ietf.org; Sun, 14 Mar 2004 23:57:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24370 for ; Sun, 14 Mar 2004 23:57:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2kAO-0004h3-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:57:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2k9a-0004ac-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:56:43 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2k8v-0004Ph-00 for forces-protocol@ietf.org; Sun, 14 Mar 2004 23:56:01 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2F4xPDN013514 for ; Mon, 15 Mar 2004 04:59:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2F4vSfS017631 for ; Mon, 15 Mar 2004 04:57:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031420553111714 for ; Sun, 14 Mar 2004 20:55:31 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 14 Mar 2004 20:55:31 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EEA6@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQJTYYSCNRAcscCQYeGdND21HlFggA99Jpg From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 Mar 2004 04:55:31.0079 (UTC) FILETIME=[BE0F7170:01C40A49] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 20:55:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is why I think we need separate connections/channels for D&C... (BTW, most of these reasons have been pointed out by several WG members in the past) 1. Different reliability requirements - The C channel needs strict reliability, CC, etc. The D channel does not need strict reliability but CC would be needed. For example, TCP for C channel, DCCP for D channel. (I think we will also have reliable multicast in addition to TCP for C connections, but I will defer that discussion for issue#3) =20 2. Efficient delivery of D packets into kernel stack on CE side - pointed out by Steve, also something which we learned from our implementations. In one of our earlier implementations, we have also used IP-in-IP encapsulation for this reason. 3. Performance requirements for D packets - Typically our customers have demanded higher throughput for D channel as compared to C channel, another reason why we need to separate the 2 transports. 4. Single reliable (TCP) connection interference in end-to-end reliability mechanisms for D packets - This has been pointed out by Joel, Steve and other wg members in the past. 5. Take advantage of separate queuing by OS to provide robustness against DoS - Note, I am not saying complete protection although I believe that using a Congestion aware D channel will provide reasonable protection for most DoS attacks. I believe that reasons 1-4 are strong enough for us to go with separate C&D channels/connections using different transports. I do agree with the point that Weiming has raised around ForCES running directly over L2, and for this situation we may either have to just RECOMMEND using different transports or something like TIPC...but this needs to be discussed. However, in case when using IP, we MUST use separate transports for C&D channels/connections...still need to bottom out on those. Does that sound reasonable ? (For IP, in general we should use only MUST in the language for inter-op reasons, for L2 we can be more flexible.) Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 00:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25442 for ; Mon, 15 Mar 2004 00:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ka6-00026P-QV for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 00:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F5O6pV008075 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 00:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ka6-00026A-Jl for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 00:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25432 for ; Mon, 15 Mar 2004 00:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ka4-0000HQ-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 00:24:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2kYh-00007w-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 00:22:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2kY3-00000W-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 00:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kY5-0001tC-CU; Mon, 15 Mar 2004 00:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2kXk-0001rx-Np for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 00:21:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25377 for ; Mon, 15 Mar 2004 00:21:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2kXi-0007nR-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 00:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2kWk-0007gL-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 00:20:39 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2kWK-0007Z3-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 00:20:12 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2F5LsWm021714; Mon, 15 Mar 2004 05:21:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2F5D5OR032522; Mon, 15 Mar 2004 05:13:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031421194120906 ; Sun, 14 Mar 2004 21:19:41 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 14 Mar 2004 21:19:41 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EEB8@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQJEMH4K9n2NeqJSxKxKvL5YXj2VQBOTJyw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 15 Mar 2004 05:19:41.0291 (UTC) FILETIME=[1E743BB0:01C40A4D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 21:19:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avri, This is a good question and one which I spent a lot of time thinking about during FACT work. There are several ways to address this (pointed out by yourself, Jamal, Alex), a) using heartbeats for D connection, b) protocol level responses/acks, c) LMP-(dont know much about this?) For now I think its good that we recognize this as something that needs to be addressed. We should probably have a section on Error Recovery in the protocol which will address the details of what should be done in case of such problems. However, this discussion is something that we can defer for now...and complete resolving the major issues. Is that fine with you ? Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org I have a question. If there is no control traffic on the data link,=20 how will you know if there is a data link failure? Do you just wait=20 for a transport protocol time out? And is that sufficiently timely? Or=20 will you have some other mechanism? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 01:11:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27217 for ; Mon, 15 Mar 2004 01:11:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lJ9-0005ZP-Pq for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 01:10:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F6AdRX021405 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 01:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lJ9-0005ZA-Hh for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 01:10:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27205 for ; Mon, 15 Mar 2004 01:10:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lJ6-0006Bj-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 01:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2lIE-00065E-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 01:09:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2lHX-0005yE-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 01:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lHZ-00057S-8G; Mon, 15 Mar 2004 01:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lHP-00056B-TU for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 01:08:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27188 for ; Mon, 15 Mar 2004 01:08:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lHM-0005xY-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 01:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2lGZ-0005qB-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 01:08:00 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2lFv-0005gv-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 01:07:19 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2F691Wm007122; Mon, 15 Mar 2004 06:09:01 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2F60UOJ016520; Mon, 15 Mar 2004 06:00:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031422064524158 ; Sun, 14 Mar 2004 22:06:45 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 14 Mar 2004 22:06: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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E24EEC3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQH6Ahr0NjHQlGDTb+c0dsUzSqkVQCaThrg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 15 Mar 2004 06:06:45.0544 (UTC) FILETIME=[B1D70A80:01C40A53] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 14 Mar 2004 22:06:45 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, After going thru all the emails, I am still trying to understand why you are opposed to having separate D&C connections using different transports as a MUST for IP ? Do you see some harm if we mandate this for IP ? I understand your reasoning below for non-IP situation and the answer to that might depend on what we decide to do for that case when ForCES is directly running over L2. But other than that, even you agree that separate C&D connections SHOULD be used for IP case. Does changing the SHOULD to a MUST break something ? I think using stronger language in the protocol is helpful for interop. Do you agree ? The only thing that you disagree on is that using separate connections is useful for DoS and that is because of the results of your experimentation. This is very understandable to me, however you must recognize that a) there are other good reasons for having this b) your experiments were based on TCP for C channel and UDP for D channel and clearly I don't think UDP without some form of CC (at app level) is very useful for the D channel. I am Not trying to say that your experimental results are incorrect or you didn't conduct the right experiments...all I am saying is that, other than the DoS issue I don't think we are disagreeing on anything else...pls correct me if I am missing something here. If that is the case, then why are we spending so many cycles debating this issue ? Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Thursday, March 11, 2004 8:06 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] Issue 2: Multiple channels/connections Hi, all I don't know why it suddenly becomes so silent here. To try to speed up the process, pls allow me to activate the Issue 2. I know Hormuzd may be writing something, it just does not conflict. This issue has in fact been quite largely discussed. I (suppose Jamal also ) think what we need to do now is just to find more reasons for such arrangement. Our team idea is: 1. The idea to distinguish the Control packets from Data packets to have them able to be differently processed is very useful for DoS protection as well as for achieving different transport reliability, therefore it MUST be included in ForCES protocol. 2. It seems no use (I suppose Jamal says little use) for us to protect DoS by stretching out such distinguish to physical link (that is to setup two different channels for the two kinds of packets), therefore, it should not be described as a kind of DoS protection means in the protocol. 3. To setup two different channels to achieve different reliability may be practical, but it should not be described as a MUST item in the protocol, instead a "RECOMMEND" is better. This is because we must consider that we have already required the ForCES protocol SHOULD be able to support multiple interconnections, and in some interconnections like some backplanes (we should allow many kinds of backplane connections), we are actually not very sure if a separate channel is available or how it is separated. Actually currently, we only know that over IP network, UDP and TCP can be used for such separation. We also don't have to explicitly list how such separation is implemented. On the other hand, not to use lower reliability channel for Data packet transport actually does not harm too much. As a result, we suggest the protocol description may be look like "If available at transport layer, ForCES protocol RECOMMENS to use two different channels with different reliability to transport Control packets and Data packets, with the lower reliability channel assigned to Data packet, so as to save system resources and improve the Control channel transport performance. Any thoughts? Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 14:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16379 for ; Mon, 15 Mar 2004 14:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xLd-0001SC-Ie for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJ21Le005588 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xLd-0001S3-BM for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14:02:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16364 for ; Mon, 15 Mar 2004 14:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xLb-0004P2-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xKf-0004My-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:01:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2xJi-0004KX-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xJj-0001LB-B0; Mon, 15 Mar 2004 14:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xIj-0001J0-7d for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 13:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16228 for ; Mon, 15 Mar 2004 13:58:58 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xIg-0004HB-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 13:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xHn-0004FL-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 13:58:03 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B2xGy-0004C9-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 13:57:13 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 16 Mar 2004 03:08:06 +0800 Received: from 219.82.185.251 ( [219.82.185.251]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Tue, 16 Mar 2004 03:08:06 +0800 Message-ID: <1079377686.4055ff27e76d3@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections References: <468F3FDA28AA87429AD807992E22D07E24EEC3@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E24EEC3@orsmsx408.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 03:08:06 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hormuzd, To be honest, your email has put me to a quite upset corner. From one side, I just can not find new reasons that can persuade me to believe this is vital for ForCES protocol so that it should use 'MUST'. From the other side, I don't want to let you have a feeling that I am 'pushing on something again and again'(though I have much to say), and moreover, it's only a few days before 20th (as you said, to save cycles). You should notice that what I post for discussion as 'RECOMMEND' has already been considered as a possible compromise among the different views of previous discussions. Actually when I check recent emails and also your newly posted reasons, I have a strong feeling that a word 'MAY' is the best to fit the case. You may also notice that it is not only I who is objective. You may ask why I can either go along with 'NONE', 'MAY' or 'RECOMMEND', it is just like that someone wants to give you something but you think the thing is actually not vitally needed. Since the discussion began, I have a feeling that when we meet things that we can not agree on which is better, being ready to give up something is vitally needed. I think I have done like this, I also appreciate Jamal has done like this. In fact, the 'RECOMMEND' and even the 'MAY' has been very close to what FACT supposes. I think another solution for this issue is to leave the remained (actually only a little) disagreement for further discussion, so that at that time we may have more time to deal with it and based on more understanding of the problem we may reach an agreement. I'd like to hear Jamal and others' idea on this very much. Best Regards, Weiming "Khosravi, Hormuzd M" : > Weiming, > > After going thru all the emails, I am still trying to understand why you > are opposed to having separate D&C connections using different > transports as a MUST for IP ? Do you see some harm if we mandate this > for IP ? > > I understand your reasoning below for non-IP situation and the answer to > that might depend on what we decide to do for that case when ForCES is > directly running over L2. But other than that, even you agree that > separate C&D connections SHOULD be used for IP case. Does changing the > SHOULD to a MUST break something ? I think using stronger language in > the protocol is helpful for interop. Do you agree ? > > The only thing that you disagree on is that using separate connections > is useful for DoS and that is because of the results of your > experimentation. This is very understandable to me, however you must > recognize that a) there are other good reasons for having this b) your > experiments were based on TCP for C channel and UDP for D channel and > clearly I don't think UDP without some form of CC (at app level) is very > useful for the D channel. > > I am Not trying to say that your experimental results are incorrect or > you didn't conduct the right experiments...all I am saying is that, > other than the DoS issue I don't think we are disagreeing on anything > else...pls correct me if I am missing something here. If that is the > case, then why are we spending so many cycles debating this issue ? > > Regards > Hormuzd > ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 14:11:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16949 for ; Mon, 15 Mar 2004 14:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xUK-0002aF-0Z for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJAxFI009925 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xUJ-0002a0-SD for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16852 for ; Mon, 15 Mar 2004 14:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xUH-000511-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:10:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xTI-0004uK-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:09:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2xSN-0004pW-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xSO-00028K-UE; Mon, 15 Mar 2004 14:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2xRk-00026M-QI for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 14:08:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16683 for ; Mon, 15 Mar 2004 14:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2xRi-0004mR-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:08:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2xQj-0004h7-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:07:17 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2xQ4-0004aW-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:06:36 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2FJ9pDN023720; Mon, 15 Mar 2004 19:09:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2FJ7rfQ018951; Mon, 15 Mar 2004 19:07:53 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031511055515704 ; Mon, 15 Mar 2004 11:05:55 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 11:05:55 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQKv7vhvFeCgYvIQ1Ou9QB4cC4BCQAADiJw From: "Putzolu, David" To: , X-OriginalArrivalTime: 15 Mar 2004 19:05:55.0655 (UTC) FILETIME=[8B13DD70:01C40AC0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 11:05:54 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming Wang wrote>=20 > I think another solution for this issue is to leave the=20 > remained (actually only a little) disagreement for=20 > further discussion, so that at that time we may have=20 > more time to deal with it and based on more understanding of=20 > the problem we may reach an agreement. I think this is the best path forward. This seems like one of the more subtle issues and might be better dealt with later. I think someone else (Avri? Jamal?) also mentioned leaving this as an open topic and looking at some of the later issues. Unless someone strongly objects, I suggest we take Weiming's proposed solution and mark this as "needs further discussion" and focus on the remaining issues, coming back to this later. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 14:57:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19492 for ; Mon, 15 Mar 2004 14:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yCt-0006kI-B9 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:57:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FJv38c025929 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 14:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yCt-0006k8-5B for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 14:57:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19473 for ; Mon, 15 Mar 2004 14:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yCq-0000l8-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yBt-0000hx-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:56:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yAu-0000fG-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 14:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yAv-0006dX-NO; Mon, 15 Mar 2004 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yA5-0006XI-MQ for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 14:54:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19414 for ; Mon, 15 Mar 2004 14:54:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yA2-0000c0-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:54:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2y9C-0000ZH-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:53:15 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2y8M-0000WF-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 14:52:22 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031511544334:4524 ; Mon, 15 Mar 2004 11:54:43 -0800 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> Organization: Znyx Networks Message-Id: <1079380332.1033.8.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 03/15/2004 11:54:43 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/15/2004 11:54:50 AM, Serialize complete at 03/15/2004 11:54:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Mar 2004 14:52:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-15 at 14:05, Putzolu, David wrote: [..] > Unless someone strongly objects, I suggest we take Weiming's > proposed solution and mark this as "needs further discussion" > and focus on the remaining issues, coming back to this later. Agreed. Lets close it for now. I think the issue is resolvable; we just need to beat more on it. Lets defer that for later. Shall we close this? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 15:05:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20027 for ; Mon, 15 Mar 2004 15:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yKg-0003qW-LK for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FK555H014748 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yKe-0003pS-1F for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:05:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19951 for ; Mon, 15 Mar 2004 15:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yKb-0001Dc-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yJb-00019Y-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:04:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yId-00015D-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yIf-0001vM-CH; Mon, 15 Mar 2004 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yHs-000191-Nu for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 15:02:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19734 for ; Mon, 15 Mar 2004 15:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yHp-00012z-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yGx-00010S-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:01:16 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2yGd-0000wv-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:00:55 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2FK4JDN031273; Mon, 15 Mar 2004 20:04:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2FJsCO9031021; Mon, 15 Mar 2004 19:54:13 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031512002202454 ; Mon, 15 Mar 2004 12:00:22 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 12:00:22 -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 Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: <468F3FDA28AA87429AD807992E22D07E2EA5F3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQKv7vWYjJByuZsRq+ySA9s6zbdVwABmNaA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 15 Mar 2004 20:00:22.0567 (UTC) FILETIME=[264F1370:01C40AC8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 12:00:22 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, I would like to understand some technical reasons as to why using MUST is not acceptable. I haven't seen any so far. Do you not agree with the 5 reasons that I pointed out ? So far Jamal has been asking for good reasons and I finally got the chance to provide those Last night. I think they are pretty strong and no one has commented on them so far. I don't think this is as much about compromise, as it is about technical reasons. Unless folks don't agree with the reasons that I have pointed out, we should be able=20 to go with MUST for IP and RECOMMEND for non-IP...this one is still to be discussed. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Sent: Monday, March 15, 2004 11:08 AM To: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Hormuzd, To be honest, your email has put me to a quite upset corner. From one side, I=20 just can not find new reasons that can persuade me to believe this is vital for=20 ForCES protocol so that it should use 'MUST'. From the other side, I don't want to let you have a feeling that I am 'pushing on something again and=20 again'(though I have much to say), and moreover, it's only a few days before=20 20th (as you said, to save cycles). You should notice that what I post for=20 discussion as 'RECOMMEND' has already been considered as a possible compromise=20 among the different views of previous discussions. Actually when I check recent=20 emails and also your newly posted reasons, I have a strong feeling that a=20 word 'MAY' is the best to fit the case. You may also notice that it is not only=20 I who is objective.=20 You may ask why I can either go along with 'NONE', 'MAY' or 'RECOMMEND', it is=20 just like that someone wants to give you something but you think the thing is=20 actually not vitally needed. Since the discussion began, I have a feeling that when we meet things that we=20 can not agree on which is better, being ready to give up something is vitally=20 needed. I think I have done like this, I also appreciate Jamal has done like=20 this. In fact, the 'RECOMMEND' and even the 'MAY' has been very close to what=20 FACT supposes. I think another solution for this issue is to leave the remained (actually only=20 a little) disagreement for further discussion, so that at that time we may have=20 more time to deal with it and based on more understanding of the problem we may=20 reach an agreement. I'd like to hear Jamal and others' idea on this very much. Best Regards, Weiming "Khosravi, Hormuzd M" : > Weiming, >=20 > After going thru all the emails, I am still trying to understand why you > are opposed to having separate D&C connections using different > transports as a MUST for IP ? Do you see some harm if we mandate this > for IP ? >=20 > I understand your reasoning below for non-IP situation and the answer to > that might depend on what we decide to do for that case when ForCES is > directly running over L2. But other than that, even you agree that > separate C&D connections SHOULD be used for IP case. Does changing the > SHOULD to a MUST break something ? I think using stronger language in > the protocol is helpful for interop. Do you agree ? >=20 > The only thing that you disagree on is that using separate connections > is useful for DoS and that is because of the results of your > experimentation. This is very understandable to me, however you must > recognize that a) there are other good reasons for having this b) your > experiments were based on TCP for C channel and UDP for D channel and > clearly I don't think UDP without some form of CC (at app level) is very > useful for the D channel. >=20 > I am Not trying to say that your experimental results are incorrect or > you didn't conduct the right experiments...all I am saying is that, > other than the DoS issue I don't think we are disagreeing on anything > else...pls correct me if I am missing something here. If that is the > case, then why are we spending so many cycles debating this issue ? >=20 > Regards > Hormuzd >=20 ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 15:23:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21846 for ; Mon, 15 Mar 2004 15:23:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ybU-0000Xq-6r for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:22:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FKMMnB001988 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ybD-0000UB-UI for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:22:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21735 for ; Mon, 15 Mar 2004 15:21:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yb1-0002CW-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2ya3-00029G-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:20:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yZA-00025h-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yZA-0000B2-4D; Mon, 15 Mar 2004 15:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yYF-0008QL-QR for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 15:19:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21431 for ; Mon, 15 Mar 2004 15:19:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yYE-00020B-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yXE-0001tj-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:18:05 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B2yWF-0001mQ-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:17:03 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2FKGWTN026485; Mon, 15 Mar 2004 14:16:32 -0600 (CST) Message-ID: <40560F1F.7030506@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Putzolu, David" CC: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> In-Reply-To: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> Content-Type: multipart/alternative; boundary="------------060605050208020003090405" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 14:16:31 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060605050208020003090405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I gave further thoughts to the dual channel proposal and how that impacts the ForCES protocol specification. It became clear to me that there are really two parts to the protocol itself: 1) the Core protocol that is independent of the transport 2) the Adaptation layer that resolves issues with specific trasnport mothodology. The debate we have been having, I think has been due to the thought that the we need to specify the core protocol to aslo adapt to one/two-channel transport links. The is the model I see going forward: |------------------| | ForCES Core | | (CE) | |------------------| | Adaptation | | Layer | |------------------| | | transport link | |-----------------| | Adaptation | | Layer | |-----------------| | ForCES Core | | ( FE ) | |-----------------| The ForCES Core is generic and independent of the transport mode. The Adaptation layer is a thin layer that mostly does mapping to/from trasport. This is where dual/single channel issue is resolved. We can also do tunneling here if we want . This allows us to decouple the transport issue from the core protocol. Any comments? Regards, Alex. Putzolu, David wrote: >Weiming Wang wrote> > > >>I think another solution for this issue is to leave the >>remained (actually only a little) disagreement for >>further discussion, so that at that time we may have >>more time to deal with it and based on more understanding of >>the problem we may reach an agreement. >> >> > >I think this is the best path forward. > >This seems like one of the more subtle issues and might >be better dealt with later. I think someone else (Avri? >Jamal?) also mentioned leaving this as an open topic and >looking at some of the later issues. > >Unless someone strongly objects, I suggest we take Weiming's >proposed solution and mark this as "needs further discussion" >and focus on the remaining issues, coming back to this later. > >-David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------060605050208020003090405 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I gave further thoughts to the dual channel proposal and how that impacts the
ForCES protocol specification.  It became clear to me that there are really
two parts to the protocol itself: 
  1) the Core protocol that is independent of the transport
   2) the Adaptation layer that resolves issues with specific trasnport mothodology.

The debate we have been having, I think has been due to the thought that the we need
to specify the core protocol to aslo adapt to one/two-channel transport links.

The is the model I see going forward:

|------------------|
|    ForCES Core |
|        (CE)           |
|------------------|
|       Adaptation   |
|         Layer         |
|------------------|
           |
           |  transport link
           |
|-----------------|
|      Adaptation   |
|        Layer         |
|-----------------|
|   ForCES Core |
|     ( FE )           |
|-----------------|        

The ForCES Core is generic and independent of the transport mode. The Adaptation
layer is a thin layer that mostly does mapping to/from trasport. This is where dual/single
channel issue is resolved.  We can also do tunneling here if we want .  This allows us to
decouple the transport issue from the core protocol.

Any comments?

Regards,
Alex.

Putzolu, David wrote:
Weiming Wang wrote> 
  
I think another solution for this issue is to leave the 
remained (actually only a little) disagreement for 
further discussion, so that at that time we may have 
more time to deal with it and based on more understanding of 
the problem we may reach an agreement.
    

I think this is the best path forward.

This seems like one of the more subtle issues and might
be better dealt with later.  I think someone else (Avri?
Jamal?) also mentioned leaving this as an open topic and
looking at some of the later issues.

Unless someone strongly objects, I suggest we take Weiming's
proposed solution and mark this as "needs further discussion"
and focus on the remaining issues, coming back to this later.

-David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------060605050208020003090405-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 15:35:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22764 for ; Mon, 15 Mar 2004 15:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ynk-00025p-KA for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:35:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FKZ868008042 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yne-00025L-5Q for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:35:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22740 for ; Mon, 15 Mar 2004 15:34:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ync-0003BW-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:35:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yme-00037U-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:34:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2ylg-00030n-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ylh-00021D-1h; Mon, 15 Mar 2004 15:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ykx-0001zT-5h for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 15:32:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22487 for ; Mon, 15 Mar 2004 15:32:13 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ykv-0002ve-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yjz-0002qN-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:31:17 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B2yjA-0002lz-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:30:24 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2FKU4p27131; Mon, 15 Mar 2004 22:30:04 +0200 (EET) X-Scanned: Mon, 15 Mar 2004 22:29:54 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2FKTs55031715; Mon, 15 Mar 2004 22:29:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00rB7TKG; Mon, 15 Mar 2004 22:29:52 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2FKTo116132; Mon, 15 Mar 2004 22:29:50 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 Mar 2004 14:29:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40ACC.42D4080E" Subject: RE: [Forces-protocol] Issue 2: Multiple channels/connections Message-ID: Thread-Topic: [Forces-protocol] Issue 2: Multiple channels/connections Thread-Index: AcQKyxDv3+WyB/6YRmm0AZ6FeETX8gAAICUA To: , Cc: , X-OriginalArrivalTime: 15 Mar 2004 20:29:49.0018 (UTC) FILETIME=[43321BA0:01C40ACC] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 15:29:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40ACC.42D4080E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex, =20 We are not solving the problem by introducing one more level of = indirection and layering. As per your diagram the ForCES core will do = all functional processing and while forwarding it will ship via = appropriate interface (Adaptation layer). May be it would be simpler to = state what needs to be done rather than introducing addition layer... =20 As Hormuzd summarized in earlier emails, I think we should highlight all = those and provide the recommendations accordingly. =20 Regards Ramg =20 -----Original Message----- From: forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Alex Audu Sent: Monday, March 15, 2004 3:17 PM To: Putzolu, David Cc: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections I gave further thoughts to the dual channel proposal and how that = impacts the ForCES protocol specification. It became clear to me that there are = really two parts to the protocol itself: =20 1) the Core protocol that is independent of the transport 2) the Adaptation layer that resolves issues with specific trasnport = mothodology. The debate we have been having, I think has been due to the thought that = the we need to specify the core protocol to aslo adapt to one/two-channel transport = links. The is the model I see going forward: |------------------| | ForCES Core | | (CE) | |------------------| | Adaptation | | Layer | |------------------| | | transport link | |-----------------| | Adaptation | | Layer | |-----------------| | ForCES Core | | ( FE ) | |-----------------| =20 The ForCES Core is generic and independent of the transport mode. The = Adaptation layer is a thin layer that mostly does mapping to/from trasport. This is = where dual/single channel issue is resolved. We can also do tunneling here if we want . = This allows us to decouple the transport issue from the core protocol. Any comments? Regards, Alex. Putzolu, David wrote: Weiming Wang wrote>=20 =20 I think another solution for this issue is to leave the=20 remained (actually only a little) disagreement for=20 further discussion, so that at that time we may have=20 more time to deal with it and based on more understanding of=20 the problem we may reach an agreement. =20 I think this is the best path forward. This seems like one of the more subtle issues and might be better dealt with later. I think someone else (Avri? Jamal?) also mentioned leaving this as an open topic and looking at some of the later issues. Unless someone strongly objects, I suggest we take Weiming's proposed solution and mark this as "needs further discussion" and focus on the remaining issues, coming back to this later. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 ------_=_NextPart_001_01C40ACC.42D4080E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Alex,
 
We are=20 not solving the problem by introducing one more level of indirection and = layering.  As per your diagram the ForCES core will do all = functional=20 processing  and while forwarding it will ship via appropriate = interface=20 (Adaptation layer). May be it would be simpler to = state what needs=20 to be done rather than introducing addition layer...
 
As=20 Hormuzd summarized in earlier emails, I think we should highlight all = those and=20 provide the recommendations accordingly.
 
Regards
Ramg
 
 -----Original Message-----
From: = forces-protocol-admin@ietf.org=20 [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Alex=20 Audu
Sent: Monday, March 15, 2004 3:17 PM
To: = Putzolu,=20 David
Cc: wmwang@mail.hzic.edu.cn;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Issue = 2:=20 Multiple channels/connections

I=20 gave further thoughts to the dual channel proposal and how that = impacts=20 the
ForCES protocol specification.  It became clear to me that = there=20 are really
two parts to the protocol itself: 
  1) = the Core=20 protocol that is independent of the transport
   2) the=20 Adaptation layer that resolves issues with specific trasnport=20 mothodology.

The debate we have been having, I think has been = due to=20 the thought that the we need
to specify the core protocol to aslo = adapt to=20 one/two-channel transport links.

The is the model I see going=20 forward:

|------------------|
|    ForCES = Core=20 |
|       =20 (CE)          =20 |
|------------------|
|      =20 Adaptation   = |
|        =20 Layer        =20 = |
|------------------|
       &n= bsp;  =20 |
           = | =20 transport = link
          =20 |
|-----------------|
|     =20 Adaptation   = |
|       =20 Layer        =20 |
|-----------------|
|   ForCES Core=20 |
|     ( FE=20 )          =20 = |
|-----------------|         =

The ForCES Core is generic and independent of the transport = mode. The=20 Adaptation
layer is a thin layer that mostly does mapping to/from = trasport.=20 This is where dual/single
channel issue is resolved.  We can = also do=20 tunneling here if we want .  This allows us to
decouple the = transport=20 issue from the core protocol.

Any=20 comments?

Regards,
Alex.

Putzolu, David wrote:
Weiming Wang wrote>=20
  
I think another solution =
for this issue is to leave the=20
remained (actually only a little) disagreement for=20
further discussion, so that at that time we may have=20
more time to deal with it and based on more understanding of=20
the problem we may reach an agreement.
    

I think this is the best path forward.

This seems like one of the more subtle issues and might
be better dealt with later.  I think someone else (Avri?
Jamal?) also mentioned leaving this as an open topic and
looking at some of the later issues.

Unless someone strongly objects, I suggest we take Weiming's
proposed solution and mark this as "needs further discussion"
and focus on the remaining issues, coming back to this later.

-David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
------_=_NextPart_001_01C40ACC.42D4080E-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 15:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23265 for ; Mon, 15 Mar 2004 15:47:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yzK-00035p-By for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:47:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FKl596011879 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 15:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yzH-00035R-Qx for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23183 for ; Mon, 15 Mar 2004 15:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yzF-0003oK-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yyL-0003kF-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:46:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yxO-0003gA-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 15:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yxO-000315-M2; Mon, 15 Mar 2004 15:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ywh-0002wp-2a for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 15:44:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23089 for ; Mon, 15 Mar 2004 15:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ywf-0003dP-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:44:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yvj-0003ZI-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:43:24 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B2yvB-0003UD-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 15:42:49 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2FKkEDN027436; Mon, 15 Mar 2004 20:46:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2FKa5OD028489; Mon, 15 Mar 2004 20:36:08 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031512421809465 ; Mon, 15 Mar 2004 12:42:18 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 12:42: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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EA637@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQII0Z8ukfpM5NMR7CEST5isingBQCMSk+g From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 15 Mar 2004 20:42:18.0583 (UTC) FILETIME=[01F8A670:01C40ACE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 12:42:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal There are a few things which I would like to get clarified from you... Are you opposed to having a differentiation on IP basis, rather than 'close proximity' ? The Ads seemed to be suggesting a differentiation on IP basis which is different from what you have stated below.=20 Are you suggesting that Only Multicast must be used in certain cases ? or is it Unicast + Multicast if interconnect support both else only Unicast ? From what I have read in your emails, for netlink2 you have used both Unicast and Multicast, not just multicast but I just want to confirm this. I have some text on this issue, but I would like to get this clarified before I post it so that we are on the same page. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Alex, Sorry I slowed down a little there. =20 On Thu, 2004-03-11 at 16:43, Alex Audu wrote: > Issue 3:=20 >=20 > We can start by agreeing that Unicast is a MUST implement, and MCAST, > BCAST a=20 > SHOULD. >=20 > Any comments? Well I like the AD suggestions, which to quote David: --- "dual mandatory" approach. I.e.: If your underlying interconnect supports multicast, then you MUST implement the following (multicast) method of communication. If your underlying interconnect supports unicast, then you MUST implement the following (unicast) method of communication. This will guarantee interop, although at a potential extra cost (cost being having to potentially support both when both are present). While this isn't optimal, it does at least give some flexibility. ------- In my opinion multicast should be used only within a=20 "close proximity" only. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 16:14:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26404 for ; Mon, 15 Mar 2004 16:14:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zPa-0004uq-EE for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 16:14:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FLEEJN018890 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 16:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zPZ-0004ub-HR for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 16:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26274 for ; Mon, 15 Mar 2004 16:14:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2zPX-0006q3-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zNu-0006YL-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:12:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2zMT-0006Is-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zMT-0004qk-Pf; Mon, 15 Mar 2004 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zM0-0004qE-Bm for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 16:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25782 for ; Mon, 15 Mar 2004 16:10:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2zLy-0006DD-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:10:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zKX-0005yz-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:09:03 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1B2zJe-0005q6-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:08:06 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i2FL7XfX003673 for ; Mon, 15 Mar 2004 15:07:33 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 15:05:32 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 15:06:29 -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 GPWXC2NR; Mon, 15 Mar 2004 16:07:30 -0500 Message-ID: <40561B0D.1070905@ericsson.com> From: Jon Maloy 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 To: "Khosravi, Hormuzd M" CC: avri@acm.org, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <468F3FDA28AA87429AD807992E22D07E24EEB8@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------030000020908070707080603" X-OriginalArrivalTime: 15 Mar 2004 21:05:32.0328 (UTC) FILETIME=[40B54280:01C40AD1] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 16:07:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------030000020908070707080603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See below /jon Khosravi, Hormuzd M wrote: Avri, This is a good question and one which I spent a lot of time thinking about during FACT work. There are several ways to address this (pointed out by yourself, Jamal, Alex), a) using heartbeats for D connection, With heartbeats people normally mean a periodic sending of small messages to confirm that the sender is still alive. If you have a huge network the background load for doing this may become significant, especially if you have more than one connection per FE-CE. I found a way to lessen this load by letting each endpoint keeping track of incoming data messages, and leave a trace (an updated sequence number, but just a flag would do) when a message is received. Then, instead of just blindly sending heartbeats under any circumstances, an endpoint finding that the other end has remained silent too long, send a PROBE message, imlying an order to the peer to immediately respond with a PROBE_REPLY. Of course, the peer sets its 'incoming received' flag when it receives the PROBE. This way, not a single more message than strictly necessary is sent in to keep the endpoints updated about the state of the connection. b) protocol level responses/acks, c) LMP-(dont know much about this?) Responses/acks are only useful when you actually have traffic. In this case we have a situation where there is no traffic, and we must find a mean to find out if this is normal or due to communication failure. Probes are useful here, acks are not. (Of course, hey may be needed for other purposes, eg if the channel is unreliable, but not for connection failure detection.) For now I think its good that we recognize this as something that needs to be addressed. We should probably have a section on Error Recovery in the protocol which will address the details of what should be done in case of such problems. However, this discussion is something that we can defer for now...and complete resolving the major issues. Is that fine with you ? Sure. See this as an input for that later discussion. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [ mailto:forces-protocol-admin@ietf.org ] On Behalf Of avri@acm.org I have a question. If there is no control traffic on the data link, how will you know if there is a data link failure? Do you just wait for a transport protocol time out? And is that sufficiently timely? Or will you have some other mechanism? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------030000020908070707080603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit See below
/jon

Khosravi, Hormuzd M wrote:
Avri,

This is a good question and one which I spent a lot of time thinking
about during FACT work. There are several ways to address this (pointed
out by yourself, Jamal, Alex), a) using heartbeats for D connection,
With heartbeats people normally mean a periodic sending of small messages
to confirm that the sender is still alive. If you have a huge network the background
load for doing this may become significant, especially if you have more than
one connection per FE-CE.
I found a way to lessen this load by letting each endpoint keeping track of incoming
data messages, and leave a trace (an updated sequence number, but just a flag would do)
when a message is received.
Then, instead of just blindly sending heartbeats under any circumstances, an endpoint
finding that the other end has remained silent too long, send a PROBE message,
imlying an order to the peer to immediately respond with a PROBE_REPLY.
Of course, the peer sets its 'incoming received' flag when it receives the
PROBE. 
This way, not  a single more message than strictly necessary is sent in
to keep the endpoints updated about the state of the connection.

 b)
protocol level responses/acks, c) LMP-(dont know much about this?)
Responses/acks are only useful when you actually have traffic. In this case
we have a situation where there is no traffic, and we must find a mean to
find out if this is normal or due to communication failure. Probes are
useful here, acks are not. (Of course, hey may be needed for other purposes,
eg if the channel is unreliable, but not for connection failure detection.)

For now I think its good that we recognize this as something that needs
to be addressed. We should probably have a section on Error Recovery in
the protocol which will address the details of what should be done in
case of such problems. However, this discussion is something that we can
defer for now...and complete resolving the major issues. Is that fine
with you ?
Sure. See this as an input for that later discussion.

Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org

I have a question.  If there is no control traffic on the data link, 
how will you know if there is a data link failure?  Do you just wait 
for a transport protocol time out? And is that sufficiently timely?  Or 
will you have some other mechanism?

a.



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol



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

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------030000020908070707080603-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 16:45:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29916 for ; Mon, 15 Mar 2004 16:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ztV-000734-CW for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 16:45:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FLj9Oe027088 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 16:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ztU-00072p-8x for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 16:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29912 for ; Mon, 15 Mar 2004 16:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2ztS-0002dS-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:45:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zsW-0002bq-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:44:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2zsO-0002aF-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 16:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zsP-00070x-Mz; Mon, 15 Mar 2004 16:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2zrh-0006nM-BE for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 16:43:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29847 for ; Mon, 15 Mar 2004 16:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2zrf-0002Zl-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:43:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2zqx-0002Wj-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:42:31 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B2zqA-0002Rs-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 16:41:42 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031513440759:4644 ; Mon, 15 Mar 2004 13:44:07 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EA637@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E2EA637@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079386898.1031.18.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 03/15/2004 01:44:07 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/15/2004 01:44:10 PM, Serialize complete at 03/15/2004 01:44:10 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Mar 2004 16:41:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, On Mon, 2004-03-15 at 15:42, Khosravi, Hormuzd M wrote: > Jamal > > There are a few things which I would like to get clarified from you... > > Are you opposed to having a differentiation on IP basis, rather than > 'close proximity' ? The Ads seemed to be suggesting a differentiation on > IP basis which is different from what you have stated below. I actually dont want to restrict to just IP. Ethernet, TIPC over X, etc. It makes sense to use multicast on ]close proximity to avoid a lot of complexities that are seen when you need to maintain state on routers across a large network. > Are you suggesting that Only Multicast must be used in certain cases ? > or is it Unicast + Multicast if interconnect support both else only > Unicast ? More of "if available" MUST be used. So if multicast is available, use it. I would think Unicast is always available. This is very similar to what OSPF does. > From what I have read in your emails, for netlink2 you have used both > Unicast and Multicast, not just multicast but I just want to confirm > this. Yes we used both. TCP on one connection and multicast UDP on another. CE transmitted on udp/multicast and retransmitted on TCP. Our metric was COST in both bandwidth and CPU. You send one message onto all FEs if you use Multicast; saving on both CPU and b/width and then you retransmit only on unicast (TCP) because there is no point for other FEs which have ACKed to see the message again and ACK it again > I have some text on this issue, but I would like to get this clarified > before I post it so that we are on the same page. > Hope above helps/clarifies. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 18:37:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07346 for ; Mon, 15 Mar 2004 18:37:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31eA-0005C0-J1 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 18:37:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FNbQxW019954 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 18:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31eA-0005Bd-17 for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 18:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07302 for ; Mon, 15 Mar 2004 18:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31e6-0002oM-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 18:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31d6-0002l2-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 18:36:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B31cl-0002i5-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 18:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31cn-0004ze-5X; Mon, 15 Mar 2004 18:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31cA-0004zG-Bj for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 18:35:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07234 for ; Mon, 15 Mar 2004 18:35:17 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31c7-0002gg-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 18:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31b8-0002dX-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 18:34:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B31aM-0002ai-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 18:33:31 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B31aM-0004zv-F8 for forces-protocol@ietf.org; Mon, 15 Mar 2004 23:33:31 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <40560F1F.7030506@alcatel.com> References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> <40560F1F.7030506@alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <28110E4E-76D9-11D8-BC30-000393CC2112@acm.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 07:33:25 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This definitely agrees with my thoughts. The issue of multiple connections is a transport issue and can safely=20 be deferred. a. On 16 mar 2004, at 04.16, Alex Audu wrote: > The ForCES Core is generic and independent of the transport mode. The=20= > Adaptation > layer is a thin layer that mostly does mapping to/from trasport. This=20= > is where dual/single > channel issue is resolved.=A0 We can also do tunneling here if we = want=20 > .=A0 This allows us to > decouple the transport issue from the core protocol. > > Any comments? > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 19:18:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09380 for ; Mon, 15 Mar 2004 19:18:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32Gz-0008Kj-AU for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 19:17:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G0HWE7031771 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 19:17:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32Gy-0008D9-1s for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 19:17:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09377 for ; Mon, 15 Mar 2004 19:17:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32Gw-0005ko-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 19:17:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32G2-0005gq-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 19:16:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B32FV-0005bP-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 19:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32FV-000878-WA; Mon, 15 Mar 2004 19:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32Ek-00083Q-GC for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 19:15:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09264 for ; Mon, 15 Mar 2004 19:15:11 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32Ei-0005Xg-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 19:15:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32Dn-0005Sh-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 19:14:15 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B32Cs-0005Mg-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 19:13:19 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 16 Mar 2004 08:24:29 +0800 Received: from 219.82.191.133 ( [219.82.191.133]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Tue, 16 Mar 2004 08:24:29 +0800 Message-ID: <1079396669.4056494ea7e5a@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> <40560F1F.7030506@alcatel.com> <28110E4E-76D9-11D8-BC30-000393CC2112@acm.org> In-Reply-To: <28110E4E-76D9-11D8-BC30-000393CC2112@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA09265 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 08:24:29 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Avri, Alex, That's exactly the point. It also definitely agrees with our thoughts.=20 I believe this issue can be solved quite well later when we have more tim= e and=20 gain more mutual technically understanding with each other.=20 I agree to close it. Cheers, Weiming Quoting avri@acm.org: > This definitely agrees with my thoughts. >=20 > The issue of multiple connections is a transport issue and can safely=20 > be deferred. >=20 > a. >=20 > On 16 mar 2004, at 04.16, Alex Audu wrote: >=20 > > The ForCES Core is generic and independent of the transport mode. Th= e=20 > > Adaptation > > layer is a thin layer that mostly does mapping to/from trasport. Thi= s=20 > > is where dual/single > > channel issue is resolved.=A0 We can also do tunneling here if we wa= nt=20 > > .=A0 This allows us to > > decouple the transport issue from the core protocol. > > > > Any comments? > > >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 21:09:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14769 for ; Mon, 15 Mar 2004 21:09:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3419-0006uG-Hi for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 21:09:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G29JfB026538 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 21:09:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3419-0006tv-9P for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 21:09:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14749 for ; Mon, 15 Mar 2004 21:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3416-0006eD-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:09:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B340E-0006bb-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:08:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B33zr-0006ZG-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:07:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B33zt-0006a6-0S for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B33zs-0006l2-Ss; Mon, 15 Mar 2004 21:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B33z7-0006Xr-Uj for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 21:07:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14689 for ; Mon, 15 Mar 2004 21:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B33z5-0006Xf-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:07:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B33y7-0006Uf-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:06:13 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B33xB-0006Pt-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:05:15 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2G24bLc024116 for ; Mon, 15 Mar 2004 20:04:37 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Mar 2004 20:02:42 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 20:03:37 -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 GPWXCLWM; Mon, 15 Mar 2004 21:04:39 -0500 Message-ID: <405660B1.4080108@ericsson.com> From: Jon Maloy 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 To: wmwang@mail.hzic.edu.cn CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> <40560F1F.7030506@alcatel.com> <28110E4E-76D9-11D8-BC30-000393CC2112@acm.org> <1079396669.4056494ea7e5a@mail.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------090400050602080302070307" X-OriginalArrivalTime: 16 Mar 2004 02:02:42.0734 (UTC) FILETIME=[C4754CE0:01C40AFA] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 21:04:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------090400050602080302070307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sounds like an excellent idea. Following the previous discussion would summarize the properties of such a layer: 1- It would hide the specific aspects of, and if necessary compensate the missing functionality of transport protocol actually used, whether it is TCP,UDP, raw Ethernet or something else. 2: It adds negligible or very little overhead to the carrying protocol. 3: It takes the decision whether to use physical multiast or sequenctial unicast for CE-FE control messages, based on which transport is available, and its knowledge about the network (number of and distance to recipients.) 4: It provides different connection types with different priorities and properties (reliable/unreliable) to the ForCES base protocol, so that handling of data messages and control messages can be differentiated. 5: It supervises the channels so that communication failure will be quickly detected. I am sure we will find more to add here as we move along. /Jon wmwang@mail.hzic.edu.cn wrote: Hi Avri, Alex, That's exactly the point. It also definitely agrees with our thoughts. I believe this issue can be solved quite well later when we have more time and gain more mutual technically understanding with each other. I agree to close it. Cheers, Weiming Quoting avri@acm.org: This definitely agrees with my thoughts. The issue of multiple connections is a transport issue and can safely be deferred. a. On 16 mar 2004, at 04.16, Alex Audu wrote: The ForCES Core is generic and independent of the transport mode. The Adaptation layer is a thin layer that mostly does mapping to/from trasport. This is where dual/single channel issue is resolved. We can also do tunneling here if we want . This allows us to decouple the transport issue from the core protocol. Any comments? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------090400050602080302070307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sounds like an excellent idea.
Following the previous discussion would summarize the properties of
such a layer:

1- It would hide the specific aspects of, and if necessary compensate the
    missing functionality of transport protocol actually used, whether it is
    TCP,UDP, raw Ethernet or something else.

2: It adds negligible or very little overhead to the carrying protocol.

3: It takes the decision whether to use physical multiast or sequenctial
    unicast for CE-FE control messages, based on which transport is available,
    and its knowledge about the network (number of and distance to
    recipients.)

4: It provides different connection types with different priorities and properties
   (reliable/unreliable) to the ForCES base protocol, so that
    handling of data messages and control messages can be differentiated.

5: It supervises the channels so that communication failure will be quickly
    detected.

I am sure we will find more to add here as we move along.

/Jon


wmwang@mail.hzic.edu.cn wrote:
Hi Avri, Alex,

That's exactly the point. It also definitely agrees with our thoughts. 

I believe this issue can be solved quite well later when we have more time and 
gain more mutual technically understanding with each other. 

I agree to close it.

Cheers,
Weiming


Quoting avri@acm.org:

  
This definitely agrees with my thoughts.

The issue of multiple connections is a transport issue and can safely 
be deferred.

a.

On 16 mar 2004, at 04.16, Alex Audu wrote:

    
 The ForCES Core is generic and independent of the transport mode. The 
Adaptation
 layer is a thin layer that mostly does mapping to/from trasport. This 
is where dual/single
 channel issue is resolved.  We can also do tunneling here if we want 
.  This allows us to
 decouple the transport issue from the core protocol.

 Any comments?

      
_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol

    




-------------------------------------------------
This mail sent through HUCNIC Webmail system.


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol



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

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------090400050602080302070307-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 21:20:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15319 for ; Mon, 15 Mar 2004 21:20:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Bs-0007gk-Vh for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 21:20:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G2KOHI029555 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 21:20:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34Bs-0007gc-E2 for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 21:20:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15312 for ; Mon, 15 Mar 2004 21:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B34Bp-0007Nf-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:20:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B34At-0007Ki-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:19:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B34AV-0007Hi-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 21:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B34AX-0007Zm-8i; Mon, 15 Mar 2004 21:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B349p-0007YQ-PU for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 21:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15222 for ; Mon, 15 Mar 2004 21:18:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B349n-0007FT-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:18:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B348r-0007CD-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:17:18 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B347w-00075u-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 21:16:21 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2G2JjDN016590; Tue, 16 Mar 2004 02:19:45 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2G2GofS003252; Tue, 16 Mar 2004 02:17:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031518153822139 ; Mon, 15 Mar 2004 18:15:38 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 18:15: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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EA967@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQK1lDWK+jr2D7lTgSCiP7Z9sLBEAAArvmw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 16 Mar 2004 02:15:38.0884 (UTC) FILETIME=[93146440:01C40AFC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 18:15:38 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, Thanks for the clarification. Here is some text around this issue which I think is a reasonable compromise, All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Should/Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol (post-association). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- we can defer on this one till we come back to issue#2) In this text I have tried to accommodate the different approaches of netlink2, GRMP and FACT, at the same time I have made the text strong by using Must/Should to have easy interop. Let me explain this further... Netlink2-uses 1 TCP + 1 Multicast UDP connection FACT-uses 1 TCP+ 1 unicast UDP+CC/DCCP like connection GRMP-uses 1 TCP+ 1 UDP(in some experiments)...also implemented with only TCP. Pls correct me if I am wrong here. The above text tries to accommodate all these approaches as well as the different scenarios or categories in which they are applicable. Here are the basic ForCES Impl Categories... Cat 1: Local (inside box) with reliable,CC multicast support (Example, ATM fabric backplane) No need of IP in this case, ForCES can directly run over L2 or use something like TIPC. Unicast+ multicast connections can be used in this case for communication. Cat 2: Local with No reliable,CC multicast support (Example, Gig-Ethernet backplane) No need of IP in this case, ForCES can directly run over L2 or use something like TIPC. Unicast connections can be used in this case for communication. Cat 3: Non-local (Example, Ethernet wire) ForCES runs over IP/transport protocols in this case. Unicast connections such as TCP, DCCP can be used in this case. Let me know what you guys think ? Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Mon, 2004-03-15 at 15:42, Khosravi, Hormuzd M wrote: > Jamal >=20 > There are a few things which I would like to get clarified from you... >=20 > Are you opposed to having a differentiation on IP basis, rather than > 'close proximity' ? The Ads seemed to be suggesting a differentiation on > IP basis which is different from what you have stated below.=20 I actually dont want to restrict to just IP. Ethernet, TIPC over X, etc. It makes sense to use multicast on ]close proximity to avoid a lot of complexities that are=20 seen when you need to maintain state on routers across=20 a large network. > Are you suggesting that Only Multicast must be used in certain cases ? > or is it Unicast + Multicast if interconnect support both else only > Unicast ? More of "if available" MUST be used. So if multicast is available, use it. I would think Unicast is always available. This is very similar to what OSPF does. > From what I have read in your emails, for netlink2 you have used both > Unicast and Multicast, not just multicast but I just want to confirm > this. Yes we used both. TCP on one connection and multicast UDP on another. CE transmitted on udp/multicast and retransmitted on TCP. Our metric was COST in both bandwidth and CPU. You send one message onto all FEs if you use Multicast; saving on both=20 CPU and b/width and then you retransmit only on unicast (TCP) because there is no point for other FEs which have ACKed to see the message again and ACK it again _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 15 22:39:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19854 for ; Mon, 15 Mar 2004 22:39:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35QS-0004te-29 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 22:39:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G3dWFh018817 for forces-protocol-archive@odin.ietf.org; Mon, 15 Mar 2004 22:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35QR-0004tQ-SJ for forces-protocol-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 22:39:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19851 for ; Mon, 15 Mar 2004 22:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B35QO-0006j8-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 22:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B35PN-0006fW-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 22:38:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B35Ow-0006cX-00 for forces-protocol-web-archive@ietf.org; Mon, 15 Mar 2004 22:37:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35Oy-0004ou-Tb; Mon, 15 Mar 2004 22:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B35OZ-0004hA-Hk for forces-protocol@optimus.ietf.org; Mon, 15 Mar 2004 22:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19797 for ; Mon, 15 Mar 2004 22:37:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B35OW-0006bv-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 22:37:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B35Nf-0006YR-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 22:36:39 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B35N7-0006TY-00 for forces-protocol@ietf.org; Mon, 15 Mar 2004 22:36:05 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031519383131:4944 ; Mon, 15 Mar 2004 19:38:31 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EA967@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E2EA967@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079408162.1041.146.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 03/15/2004 07:38:32 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/15/2004 07:38:33 PM, Serialize complete at 03/15/2004 07:38:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Mar 2004 22:36:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hormuzd, On Mon, 2004-03-15 at 21:15, Khosravi, Hormuzd M wrote: [..] > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. sure. > Furthermore, in case of IP this will be a TCP connection between the CE > and FEs. Lets not say TCP or SCTP at this point; defer this to later. > In addition to this, in case of 'close proximity' between the > CEs and FEs And in case the interconnect between them supports > multicast, the CEs and FEs Should/Must also establish reliable, Why the should? I personally dont think that a single multicast connection would be an efficient thing for a transport. On the same token i dont think a single unicast connection would be efficient. If you have a reliable unicast connection, i see the value of having a semi-reliable multicast connection - at least based on our experiences. Maybe people with other experiences can share. > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol > (post-association). This part we can resolve later. > For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- we can defer on this one till we come back to issue#2) So three classes of connections: 1) totaly reliable unicast 2) probably a range of unreliable, semi-reliable to reliable multicast 3) unreliable UDP-like unicast for data redirection. You also seem to be stating for 2) above you could have more than one connection. Is this accurate? > In this text I have tried to accommodate the different approaches of > netlink2, GRMP and FACT, at the same time I have made the text strong by > using Must/Should to have easy interop. Let me explain this further... > > Netlink2-uses 1 TCP + 1 Multicast UDP connection Just to clarify: We have the concept of wires; you could put as many connections as you want negotiated via FEM/CEM interface. In practice though what we found was we 80-90% of the time used only the multicast UDP and unicast TCP. > FACT-uses 1 TCP+ 1 unicast UDP+CC/DCCP like connection > GRMP-uses 1 TCP+ 1 UDP(in some experiments)...also implemented with only > TCP. > > Pls correct me if I am wrong here. The above text tries to accommodate > all these approaches as well as the different scenarios or categories in > which they are applicable. > > Here are the basic ForCES Impl Categories... > > Cat 1: Local (inside box) with reliable,CC multicast support (Example, > ATM fabric backplane) > No need of IP in this case, ForCES can directly run over L2 or use > something like TIPC. > Unicast+ multicast connections can be used in this case for > communication. > > Cat 2: Local with No reliable,CC multicast support (Example, > Gig-Ethernet backplane) > No need of IP in this case, ForCES can directly run over L2 or use > something like TIPC. > Unicast connections can be used in this case for communication. > > Cat 3: Non-local (Example, Ethernet wire) > ForCES runs over IP/transport protocols in this case. > Unicast connections such as TCP, DCCP can be used in this case. I dont think we should say "no need for IP" but rather we can run without IP. IT should be noted that the close proximity is more than a chasis and could be chasis or next room closeness. Additionaly i think that there would be demarcations between close and non-close proximity where other protocols such as TIPC or L2 direct maybe constrained. There may be tunnels of sorts connecting such demarcations to create a large NE. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 01:21:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28376 for ; Tue, 16 Mar 2004 01:21:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37wQ-0000UB-AT for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 01:20:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G6KgCx001864 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 01:20:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37wQ-0000Tz-1z for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 01:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28321 for ; Tue, 16 Mar 2004 01:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37wN-0006B7-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 01:20:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37vY-00066r-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 01:19:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B37uk-00061R-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 01:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37um-0000Gl-Kz; Tue, 16 Mar 2004 01:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B37uP-0000ES-8r for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 01:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28231 for ; Tue, 16 Mar 2004 01:18:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B37uI-0005zE-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 01:18:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B37tN-0005uG-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 01:17:34 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B37sQ-0005lv-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 01:16:34 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2G6IF0F002226; Tue, 16 Mar 2004 06:18:15 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2G6HwBr027878; Tue, 16 Mar 2004 06:17:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031522155915020 ; Mon, 15 Mar 2004 22:15:59 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 22:16: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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EA9E3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLB9HxSBBAv/VDQpiJ6Zoy3zyWxgAE5ihQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 16 Mar 2004 06:16:00.0007 (UTC) FILETIME=[26BD2170:01C40B1E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Mar 2004 22:15:59 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal Thanks for your comments. In general, I am fine with them, will make the necessary changes. See more comments below... -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > Furthermore, in case of IP this will be a TCP connection between the CE > and FEs.=20 Lets not say TCP or SCTP at this point; defer this to later. [HK] I thought all of us used TCP so we would easily agree on this...but that's fine...deferred for now. > In addition to this, in case of 'close proximity' between the > CEs and FEs And in case the interconnect between them supports > multicast, the CEs and FEs Should/Must also establish reliable, Why the should? [HK] I didn't want to get into a debate between Should/Must, therefore I put both. Personally I am fine with a Must. =20 I personally dont think that a single multicast connection would be an efficient thing for a transport. On the same token i dont think a single unicast connection would be efficient. If you have a reliable unicast connection, i see the value of having a semi-reliable multicast connection - at least based on our experiences. Maybe people with other experiences can share. [HK] Based on our experiences and customer requirements, we have been able to satisfy them with 2 unicast connections. I am not sure what you mean by semi-reliable multicast...can you explain ? I think reliability, CC is important for unicast or multicast if it is used to transport control messages...based on requirements and all the discussions that we have had on the ForCES list on this topic. > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol > (post-association).=20 This part we can resolve later. [HK] That's fine, but this is important in order to use Multicast in an efficient way. > For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- we can defer on this one till we come back to issue#2) So three classes of connections: 1) totaly reliable unicast 2) probably a range of unreliable, semi-reliable to reliable multicast 3) unreliable UDP-like unicast for data redirection. You also seem to be stating for 2) above you could have more than one connection. Is this accurate? [HK] Perfect ! =20 > Here are the basic ForCES Impl Categories... >=20 > Cat 1: Local (inside box) with reliable,CC multicast support (Example, > ATM fabric backplane) > No need of IP in this case, ForCES can directly run over L2 or use > something like TIPC. > Unicast+ multicast connections can be used in this case for > communication. > > Cat 2: Local with No reliable,CC multicast support (Example, > Gig-Ethernet backplane) > No need of IP in this case, ForCES can directly run over L2 or use > something like TIPC. > Unicast connections can be used in this case for communication. >=20 > Cat 3: Non-local (Example, Ethernet wire) > ForCES runs over IP/transport protocols in this case. > Unicast connections such as TCP, DCCP can be used in this case. I dont think we should say "no need for IP" but rather we can run without IP.=20 [HK] Fine. Additionaly i think that there would be demarcations between close and non-close proximity where other protocols such as TIPC or L2 direct maybe constrained. There may be tunnels of sorts connecting such demarcations to create a large NE. [HK] Not sure if I understand this properly...can you explain a bit more ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 06:31:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24585 for ; Tue, 16 Mar 2004 06:31:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CmP-00041G-A3 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 06:30:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GBUfN9015447 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 06:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CmO-000414-Ts for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 06:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24561 for ; Tue, 16 Mar 2004 06:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3CmL-0000Ld-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 06:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ClT-0000IT-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 06:29:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ckj-0000E1-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 06:28:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ckm-0003y6-Tz; Tue, 16 Mar 2004 06:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3CkW-0003xm-4J for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 06:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24423 for ; Tue, 16 Mar 2004 06:28:39 -0500 (EST) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3CkS-0000Cp-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 06:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3CjU-00008e-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 06:27:41 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B3Cj1-00004S-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 06:27:11 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GBR0A19413; Tue, 16 Mar 2004 13:27:00 +0200 (EET) X-Scanned: Tue, 16 Mar 2004 13:26:51 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2GBQp9I020266; Tue, 16 Mar 2004 13:26:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00aUBgWK; Tue, 16 Mar 2004 13:26:50 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GBQms02208; Tue, 16 Mar 2004 13:26:49 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 05:26:47 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLB9HxSBBAv/VDQpiJ6Zoy3zyWxgAE5ihQAAsZ+/A= To: , Cc: X-OriginalArrivalTime: 16 Mar 2004 11:26:47.0451 (UTC) FILETIME=[917B46B0:01C40B49] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 06:26:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Jamal, Hormuzd, Comment are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Tuesday, March 16, 2004 1:16 AM > To: hadi@znyx.com > Cc: forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Issue > 3:Transport/Unicast/Multicast/Broadcast >=20 >=20 > Hi Jamal >=20 > Thanks for your comments. In general, I am fine with them,=20 > will make the > necessary changes. See more comments below... >=20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > > Furthermore, in case of IP this will be a TCP connection between the > CE > > and FEs.=20 >=20 > Lets not say TCP or SCTP at this point; defer this to later. > [HK] I thought all of us used TCP so we would easily agree on=20 > this...but > that's fine...deferred for now. We are defering one issue after another. We should try to close one = issue after another.=20 For unicast its much straightforward choice. As TCP is widely deployed = we should opt for TCP. If we strong compelling reasons for not having TCP that should be = explicitly discussed. IMHO we should try to close each issue rather than deferring. >=20 > > In addition to this, in case of 'close proximity' between the > > CEs and FEs And in case the interconnect between them supports > > multicast, the CEs and FEs Should/Must also establish reliable, >=20 > Why the should? > [HK] I didn't want to get into a debate between Should/Must,=20 > therefore I > put both. Personally I am fine with a Must. must would appropriate here. > =20 > I personally dont think that a single multicast connection would > be an efficient thing for a transport. On the same token i dont > think a single unicast connection would be efficient. > If you have a reliable unicast connection, i see the value > of having a semi-reliable multicast connection - at least based on our > experiences. Maybe people with other experiences can share. >=20 > [HK] Based on our experiences and customer requirements, we have been > able to satisfy them with 2 unicast connections. I am not=20 > sure what you > mean by semi-reliable multicast...can you explain ? I think=20 > reliability, > CC is important for unicast or multicast if it is used to transport > control messages...based on requirements and all the=20 > discussions that we > have had on the ForCES list on this topic. >=20 > > congestion aware Multicast connections. The establishment and > semantics > > of these Multicast connections is negotiated during the > > binding/capability discovery phase in the ForCES protocol > > (post-association).=20 Congestion aware multicast connection ??? Looks like Forces protocol = needs to implement many things here... Do we have already some RFC to support this function? >=20 > This part we can resolve later. Let us summary and then we see whether we want to defer later. > [HK] That's fine, but this is important in order to use=20 > Multicast in an > efficient way. >=20 > > For example, the CE and subset of FEs might > > negotiate on establishing a Multicast connection for=20 > communication of > > IPv4 LFB attributes. These reliable, congestion aware=20 > connections will > > be used to communicate the control messages outlined in RFC 3654 > > (section 6, #6c). (For data messages such as those outlined in RFC > 3654 > > (section 6, #6b), the ForCES protocol Must/Should also support an > > un-reliable but congestion aware Unicast connection between=20 > the CE and > > FEs.- we can defer on this one till we come back to issue#2) >=20 > So three classes of connections: > 1) totaly reliable unicast > 2) probably a range of unreliable, semi-reliable to reliable multicast > 3) unreliable UDP-like unicast for data redirection. >=20 > You also seem to be stating for 2) above you could have more than > one connection. Is this accurate? What is the meaning of semi-reliablie here? > [HK] Perfect ! > =20 > > Here are the basic ForCES Impl Categories... > >=20 > > Cat 1: Local (inside box) with reliable,CC multicast=20 > support (Example, > > ATM fabric backplane) > > No need of IP in this case, ForCES can directly run over L2 or use > > something like TIPC. > > Unicast+ multicast connections can be used in this case for > > communication. > > The statement is not clear to me...=20 Are we recommending that for single box its non-ip. There are systems = that uses IPv6 and also IPv4 within single box... they have unicast mechanism.=20 May be we should have something like this.... for non-IP interconnects = (with in single box) we can use=20 the proposed mechanism.... > > Cat 2: Local with No reliable,CC multicast support (Example, > > Gig-Ethernet backplane) > > No need of IP in this case, ForCES can directly run over L2 or use > > something like TIPC. > > Unicast connections can be used in this case for communication. The above two statement make a case for non-IP interconnects. We should = also consider the case for IP interconnect with single box. > >=20 > > Cat 3: Non-local (Example, Ethernet wire) > > ForCES runs over IP/transport protocols in this case. > > Unicast connections such as TCP, DCCP can be used in this case. >=20 Here we should also consider non-IP physical box. for example ..... = distributed GGSN (or SSGN) connected via l2 swichtes in wireless = interconnect .... Regards Ramg > I dont think we should say "no need for IP" but rather we can run > without IP.=20 > [HK] Fine. >=20 > Additionaly i think that there would be demarcations between close > and non-close proximity where other protocols such as TIPC or=20 > L2 direct > maybe constrained. There may be tunnels of sorts connecting > such demarcations to create a large NE. > [HK] Not sure if I understand this properly...can you explain=20 > a bit more > ? >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 07:38:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27766 for ; Tue, 16 Mar 2004 07:38:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3DpF-0003Qm-NF for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 07:37:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GCbfkj013182 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 07:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3DpE-0003QP-PQ for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 07:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27757 for ; Tue, 16 Mar 2004 07:37:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3DpE-0006Xi-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 07:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3DoI-0006TW-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 07:36:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Dnd-0006Pj-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 07:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Dnd-00036b-Hp; Tue, 16 Mar 2004 07:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3DnP-00036C-W1 for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 07:35:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27672 for ; Tue, 16 Mar 2004 07:35:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3DnP-0006Ok-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 07:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3DmV-0006Jr-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 07:34:52 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Dll-0006EK-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 07:34:05 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031604363001:5237 ; Tue, 16 Mar 2004 04:36:30 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EA9E3@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E2EA9E3@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079440440.1041.205.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 03/16/2004 04:36:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/16/2004 04:36:32 AM, Serialize complete at 03/16/2004 04:36:32 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Mar 2004 07:34:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-03-16 at 01:15, Khosravi, Hormuzd M wrote: > Lets not say TCP or SCTP at this point; defer this to later. > [HK] I thought all of us used TCP so we would easily agree on this...but > that's fine...deferred for now. I think i could say TCP right at this very moment. In other words i dont think this is a contentious issue. SCTP is another protocol that meets those requirements. But lets discuss after. This should not hold us from moving to the next topic. > I personally dont think that a single multicast connection would > be an efficient thing for a transport. On the same token i dont > think a single unicast connection would be efficient. > If you have a reliable unicast connection, i see the value > of having a semi-reliable multicast connection - at least based on our > experiences. Maybe people with other experiences can share. > > [HK] Based on our experiences and customer requirements, we have been > able to satisfy them with 2 unicast connections. I am not sure what you > mean by semi-reliable multicast...can you explain ? I think reliability, I was refering to our experiences in using both together. (BTW, this is also one area we differ slightly). When a message is to be delivered reliably, CE would send frist on multicast; when things were fine we received all FE responses on multicast connection. When things were not fine we didnt receive some responses from some FEs. In this case we resent on TCP only to those FEs that failed to respond. There are various reasons why you would resend on TCP but i dont wannna go into them at the moment. Netlink2 can ask for reliability on a per message level. This helps the underlying transport abstraction decide how to deliver that message. An Add route for example MUST be reliably delivered whereas some heartbeats dont have to. I agree with realibility, congestion control etc being met - but we could simplify a lot. > > congestion aware Multicast connections. The establishment and > semantics > > of these Multicast connections is negotiated during the > > binding/capability discovery phase in the ForCES protocol > > (post-association). > > This part we can resolve later. > [HK] That's fine, but this is important in order to use Multicast in an > efficient way. This could be done in the CEM/FEM plane or negotiated via the CE/FE; we can decide on the merits later. I am not religious about which one should be used. My experiences are with CEM/FEM. > > So three classes of connections: > 1) totaly reliable unicast > 2) probably a range of unreliable, semi-reliable to reliable multicast > 3) unreliable UDP-like unicast for data redirection. > > You also seem to be stating for 2) above you could have more than > one connection. Is this accurate? > [HK] Perfect ! That does seem reasonable to me. To come back to my note from above: We still differ on some specifics. Example we saw value on send-on-multicast-resend-on-unicast. For this to be met, the CE or FE should not care which connection it received the message on. As an example it may receive the hearbeat on 1,2 or 3. Does this sound reasonable? > > Additionaly i think that there would be demarcations between close > and non-close proximity where other protocols such as TIPC or L2 direct > maybe constrained. There may be tunnels of sorts connecting > such demarcations to create a large NE. > [HK] Not sure if I understand this properly...can you explain a bit more If you say use TIPC or something TIPC-like you probably want it to run only within the close proximity case. i.e you most likey dont want such packets to hit a shared network. Same with L2. You could make TIPC think things are in the same chasis by connecting several such chasis across multiple hops interconnected maybe by TCP. This would be like DVMRP "islands" for example in the old mbone days interconnected using IPIP tunnels. OSPF does similar things. If you use L2, you could use something like L2VPN. etc. I have a feeling this maybe a controvesial issue. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 08:10:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29166 for ; Tue, 16 Mar 2004 08:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EKK-0005rx-4a for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GD9mna022551 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EKJ-0005re-VN for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29127 for ; Tue, 16 Mar 2004 08:09:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EKJ-0001Xf-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:09:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EJS-0001Qs-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:08:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3EIc-0001JK-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EIc-0005hX-6u; Tue, 16 Mar 2004 08:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EIK-0005d1-NF for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 08:07:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28938 for ; Tue, 16 Mar 2004 08:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EIJ-0001GB-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:07:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EHK-00018l-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:06:43 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EGT-00012a-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:05:49 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031605081420:5248 ; Tue, 16 Mar 2004 05:08:14 -0800 Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org In-Reply-To: <1079396669.4056494ea7e5a@mail.hzic.edu.cn> References: <52D13A805349A249960B9943E5590BD8029CFEB2@orsmsx409.jf.intel.com> <40560F1F.7030506@alcatel.com> <28110E4E-76D9-11D8-BC30-000393CC2112@acm.org> <1079396669.4056494ea7e5a@mail.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079442323.1039.238.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 03/16/2004 05:08:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/16/2004 05:08:16 AM, Serialize complete at 03/16/2004 05:08:16 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Mar 2004 08:05:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Like they say theres always a first time; in this case a first time I have not disagreed with something in a message from Alex ;-> cheers, jamal On Mon, 2004-03-15 at 19:24, wmwang@mail.hzic.edu.cn wrote: > Hi Avri, Alex, > > That's exactly the point. It also definitely agrees with our thoughts. > > I believe this issue can be solved quite well later when we have more time and > gain more mutual technically understanding with each other. > > I agree to close it. > > Cheers, > Weiming > > > Quoting avri@acm.org: > > > This definitely agrees with my thoughts. > > > > The issue of multiple connections is a transport issue and can safely > > be deferred. > > > > a. > > > > On 16 mar 2004, at 04.16, Alex Audu wrote: > > > > > The ForCES Core is generic and independent of the transport mode. The > > > Adaptation > > > layer is a thin layer that mostly does mapping to/from trasport. This > > > is where dual/single > > > channel issue is resolved. We can also do tunneling here if we want > > > . This allows us to > > > decouple the transport issue from the core protocol. > > > > > > Any comments? > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 08:17:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29457 for ; Tue, 16 Mar 2004 08:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EQz-0006J7-4J for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:16:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GDGfvj024239 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EQy-0006Is-Ue for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 08:16:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29450 for ; Tue, 16 Mar 2004 08:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EQx-0002Bs-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EQB-00027X-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:15:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3EPP-000237-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EPP-0006CP-LV; Tue, 16 Mar 2004 08:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EOz-0006Ak-4N for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 08:14:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29361 for ; Tue, 16 Mar 2004 08:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EOy-0001zi-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:14:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ENz-0001sK-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:13:35 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EN1-0001nq-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:12:35 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031605150042:5258 ; Tue, 16 Mar 2004 05:15:00 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: hormuzd.m.khosravi@intel.com, forces-protocol@ietf.org In-Reply-To: References: Organization: ZNYX Networks Message-Id: <1079442742.1039.246.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 03/16/2004 05:15:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/16/2004 05:15:02 AM, Serialize complete at 03/16/2004 05:15:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Mar 2004 08:12:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ram, On Tue, 2004-03-16 at 06:26, ram.gopal@nokia.com wrote: > We are defering one issue after another. We should try to close one issue > after another. We have to at least see some direction for this first phase. i.e not to agree 100% but say we could resolve later. When we get to details we MUST close the issues. Example the issue of TCP vs SCTP is not gating in my opinion. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 08:57:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29165 for ; Tue, 16 Mar 2004 08:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EKK-0005sD-OY for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GD9mgG022571 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EKK-0005ry-Ji for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 08:09:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29130 for ; Tue, 16 Mar 2004 08:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EKJ-0001Xk-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:09:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EJT-0001R0-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:08:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3EIc-0001JM-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 08:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EIc-0005i3-Lb; Tue, 16 Mar 2004 08:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EIL-0005dM-Gc for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 08:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28941 for ; Tue, 16 Mar 2004 08:07:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EIK-0001GG-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EHN-000197-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:06:46 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3EGW-000135-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 08:05:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031605081745:5249 ; Tue, 16 Mar 2004 05:08:17 -0800 Subject: Issue 7 WAS (Re: [Forces-protocol] Issue 2: Multiple channels/connections From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Jon Maloy Cc: "Khosravi, Hormuzd M" , avri@acm.org, forces-protocol@ietf.org In-Reply-To: <40561B0D.1070905@ericsson.com> References: <468F3FDA28AA87429AD807992E22D07E24EEB8@orsmsx408.jf.intel.com> <40561B0D.1070905@ericsson.com> Organization: ZNYX Networks Message-Id: <1079442336.1039.240.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 03/16/2004 05:08:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/16/2004 05:08:19 AM, Serialize complete at 03/16/2004 05:08:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Mar 2004 08:05:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since this topic keeps coming up and it is more related to topic#7 i have changed the subject. On Mon, 2004-03-15 at 16:07, Jon Maloy wrote: [..] > With heartbeats people normally mean a periodic sending of small > messages to confirm that the sender is still alive. If you have a huge > network the background load for doing this may become significant, > especially if you have more than one connection per FE-CE. So two things whose failures need to be detected in my opinion. 1) The CE/FE. As you say in standard setups, its the sender that issues the heartbeats. In this case probably makes sense heartbeats are coming out of the CE. In our case heartbeats are always sent on multicast (insetad of unicasting to each FE) to reduce CPU and b/width abuse. This leaves out the CE knowing about the health of the FEs while providing good knowledge of the CEs health to FEs. Sending heaartbeats from FEs -> CEs is too burderning. So to compensated, we would request for an ACK from the FEs on occasion and such hearbeat ACKs would also be sent on multicast in case other FEs are interested in the information. The CE could also request over unicast a specific FE to respond. 2) a connection going down. Something like TCP i seasy to figure out. A physical link going down is easy too. connectionless connections (mouthful) are harder. > > I found a way to lessen this load by letting each endpoint keeping > track of incoming data messages, and leave a trace (an updated > sequence number, but just a flag would do) when a message is received. I take it theres time associated with the validity of the flag as well > Then, instead of just blindly sending heartbeats under any > circumstances, an endpoint finding that the other end has remained > silent too long, send a PROBE message, imlying an order to the peer to > immediately respond with a PROBE_REPLY. > > Of course, the peer sets its 'incoming received' flag when it receives > the PROBE. > This way, not a single more message than strictly necessary is sent > in > to keep the endpoints updated about the state of the connection. This is a good optimization. I still think that synchronous heartbeats from CE->FE are a good idea. FE->CE could make use of what you described. Seems to me these are close to what we have on netlink2. i.e NLMSG_NOOP command with NLM_F_ECHO flag when response needed. > > b) > > protocol level responses/acks, c) LMP-(dont know much about this?) > Responses/acks are only useful when you actually have traffic. In this > case > we have a situation where there is no traffic, and we must find a mean > to > find out if this is normal or due to communication failure. Probes are > useful here, acks are not. (Of course, hey may be needed for other > purposes, > eg if the channel is unreliable, but not for connection failure > detection.) Agreed. Additionaly: Theres still issue of redundancy and fault management associated with finding problems. Theres still issue of decidding how much a FE should "know" etc. But we can defer this. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 21:31:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13851 for ; Tue, 16 Mar 2004 21:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Qpv-0005mN-5z for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 21:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H2VFIK022215 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 21:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Qpv-0005mE-02 for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 21:31:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13824 for ; Tue, 16 Mar 2004 21:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Qps-00007e-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:31:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Qoi-00000q-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:30:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Qnj-0007fN-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Qnl-0005jL-2N; Tue, 16 Mar 2004 21:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3QnX-0005j9-3O for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 21:28:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13761 for ; Tue, 16 Mar 2004 21:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3QnU-0007eX-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:28:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Qm6-0007ZQ-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:27:19 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3QlQ-0007T9-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:26:37 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2H2U3tT006775; Wed, 17 Mar 2004 02:30:03 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2H2S0Bv011254; Wed, 17 Mar 2004 02:28:05 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031618260502653 ; Tue, 16 Mar 2004 18:26:05 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 18:26:05 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EB22C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLB9HxSBBAv/VDQpiJ6Zoy3zyWxgAE5ihQAAsZ+/AAH4244A== From: "Deleganes, Ellen M" To: , "Khosravi, Hormuzd M" , Cc: X-OriginalArrivalTime: 17 Mar 2004 02:26:05.0696 (UTC) FILETIME=[331A1000:01C40BC7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 18:26:05 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ram, Ram, Regarding your comment below enclosed in <<< >>> <<>> The team is currently in the phase of determining whether or not it will be possible to "merge" the protocols, not to close all issues. Discussion needs to occur on all of the major issues to determine whether or not consensus can be reached by March 20. This won't be possible if the team attempts to close on all of the issues. Once general consensus is reached, or it is decided that the team will never agree, it is time to move on. I agree that during the design phase, the team must close on every issue that is brought up, but now is not that time. Regards, Ellen _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 16 21:52:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14574 for ; Tue, 16 Mar 2004 21:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RA7-0007QR-5G for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 21:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H2q7D5028542 for forces-protocol-archive@odin.ietf.org; Tue, 16 Mar 2004 21:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RA7-0007QH-06 for forces-protocol-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 21:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14531 for ; Tue, 16 Mar 2004 21:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3RA4-0002ER-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:52:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R96-00026s-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:51:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3R84-0001xP-00 for forces-protocol-web-archive@ietf.org; Tue, 16 Mar 2004 21:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R86-0007MB-Qz; Tue, 16 Mar 2004 21:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R83-0007LX-4B for forces-protocol@optimus.ietf.org; Tue, 16 Mar 2004 21:49:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14421 for ; Tue, 16 Mar 2004 21:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3R80-0001uk-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:49:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R6W-0001nl-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:48:25 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3R66-0001fm-00 for forces-protocol@ietf.org; Tue, 16 Mar 2004 21:47:59 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2H2ng0F017818; Wed, 17 Mar 2004 02:49:42 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2H2nPBr023802; Wed, 17 Mar 2004 02:49:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031618472504813 ; Tue, 16 Mar 2004 18:47:25 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 18:47:25 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EB236@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLB9HxSBBAv/VDQpiJ6Zoy3zyWxgAE5ihQAAsZ+/AAH4244AAAy9hQ From: "Khosravi, Hormuzd M" To: "Deleganes, Ellen M" , , Cc: X-OriginalArrivalTime: 17 Mar 2004 02:47:25.0929 (UTC) FILETIME=[2E2E1D90:01C40BCA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 18:47:25 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ram, I share your concern and am personally not too happy with deferring important issues. However seems like this way of making progress is kinda working so far. I would summarize this approach as "postpone and progress" :-)) Anyways, on a more serious note, Ellen has pointed out some good reasons for this approach, for now. regards Hormuzd -----Original Message----- From: Deleganes, Ellen M=20 Regarding your comment below enclosed in <<< >>> <<>> The team is currently in the phase of determining whether or not it will be possible to "merge" the protocols, not to close all issues. Discussion needs to occur on all of the major issues to determine whether or not consensus can be reached by March 20. This won't be possible if the team attempts to close on all of the issues. Once general consensus is reached, or it is decided that the team will never agree, it is time to move on. I agree that during the design phase, the team must close on every issue that is brought up, but now is not that time. Regards, Ellen _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 02:31:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19041 for ; Wed, 17 Mar 2004 02:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VVs-0006a0-7k for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 02:30:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H7UgUq025189 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 02:30:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VVg-0006WB-IJ for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 02:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18308 for ; Wed, 17 Mar 2004 02:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3VVN-0001r8-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:30:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VUQ-0001cm-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:29:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3VU2-0001WY-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VU5-0006LI-2D; Wed, 17 Mar 2004 02:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VTb-0006EP-Ig for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 02:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16832 for ; Wed, 17 Mar 2004 02:28:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3VTX-0001VT-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VSW-0001Pt-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:27:25 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3VSB-0001Jc-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:27:03 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2H7SkN1014971; Wed, 17 Mar 2004 07:28:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2H7JnbD001248; Wed, 17 Mar 2004 07:20:15 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031623263003454 ; Tue, 16 Mar 2004 23:26:30 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 23:26:31 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLUvjaMQtJh21EQfSo6ONDhy4NggAm64kg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 17 Mar 2004 07:26:31.0019 (UTC) FILETIME=[2B0813B0:01C40BF1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 23:26:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > I personally dont think that a single multicast connection would > be an efficient thing for a transport. On the same token i dont > think a single unicast connection would be efficient. > If you have a reliable unicast connection, i see the value > of having a semi-reliable multicast connection - at least based on our > experiences. Maybe people with other experiences can share. >=20 > [HK] Based on our experiences and customer requirements, we have been > able to satisfy them with 2 unicast connections. I am not sure what you > mean by semi-reliable multicast...can you explain ? I think reliability, I was refering to our experiences in using both together. (BTW, this is also one area we differ slightly). When a message is to be delivered reliably, CE would send frist on multicast; when things were fine we received all FE responses on multicast connection. When things were not fine we didnt receive some responses from some FEs. In this case we resent on TCP only to those FEs that failed to respond. There are various reasons why you would resend on TCP but i dont wannna go into them at the moment.=20 Netlink2 can ask for reliability on a per message level. This helps the underlying transport abstraction decide how to deliver that message. An Add route for example MUST be reliably delivered whereas some heartbeats dont have to. I agree with realibility, congestion control etc being met - but we could simplify a lot.=20 [HK] Alright, so what youre saying is that you first send messages over unreliable UDP multicast and if you don't get a response then you send it over TCP. Have you done this for control/configuration messages or only for heartbeats ? I agree that the Requirements around heartbeats are not as strict as those for control messages. The problem which I can see with using this approach for control is that you cannot have deterministic performance. For example, you cant tell your customer that we can deliver x routes/sec with our protocol implementation, which is what a lot of our customers have asked for (another thing asked is y data packets/sec). This is because in your implementation it will completely depend on the interconnect characteristics as well as load...in the best case your performance will be very good and in the worst case it will be pretty bad, cause all your control messages have to be sent again on the TCP connection after some timeout. Anyways, these are my thoughts...wonder what others have to say about this ??=20 > > congestion aware Multicast connections. The establishment and > semantics > > of these Multicast connections is negotiated during the > > binding/capability discovery phase in the ForCES protocol > > (post-association).=20 >=20 > This part we can resolve later. > [HK] That's fine, but this is important in order to use Multicast in an > efficient way. This could be done in the CEM/FEM plane or negotiated via the CE/FE; we can decide on the merits later. I am not religious about which one should be used. My experiences are with CEM/FEM. [HK] I think have this as part of the protocol binding phase rather than CEM/FEM will be much better for interop. >=20 > So three classes of connections: > 1) totaly reliable unicast > 2) probably a range of unreliable, semi-reliable to reliable multicast > 3) unreliable UDP-like unicast for data redirection. >=20 > You also seem to be stating for 2) above you could have more than > one connection. Is this accurate? > [HK] Perfect ! That does seem reasonable to me. To come back to my note from above: We still differ on some specifics.=20 Example we saw value on send-on-multicast-resend-on-unicast. For this=20 to be met, the CE or FE should not care which connection it received the message on. As an example it may receive the hearbeat on 1,2 or 3. Does this sound reasonable? [HK] As I said heartbeats are special so I am not sure what the best solution for this might be...we might have to send HBs on all 3 connections...that is one possibility...or any of these 3 connections as you are suggesting.=20 >=20 > Additionaly i think that there would be demarcations between close > and non-close proximity where other protocols such as TIPC or L2 direct > maybe constrained. There may be tunnels of sorts connecting > such demarcations to create a large NE. > [HK] Not sure if I understand this properly...can you explain a bit more If you say use TIPC or something TIPC-like you probably want it to run only within the close proximity case. i.e you most likey dont want such packets to hit a shared network. Same with L2. You could make TIPC think things are in the same chasis by connecting several such chasis across multiple hops interconnected maybe by TCP. This would be like DVMRP "islands" for example in the old mbone days interconnected using IPIP tunnels. OSPF does similar things. If you use L2, you could use something like L2VPN. etc. [HK] Lets defer this one, I am not sure if it will be needed. This seems similar to what Alex is suggesting regarding Transport Abstraction...am I off track ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 02:42:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23203 for ; Wed, 17 Mar 2004 02:42:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VgQ-00010E-1h for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 02:42:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H7fZqu003758 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 02:41:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VgF-0000wK-G0 for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 02:41:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23126 for ; Wed, 17 Mar 2004 02:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vfv-000377-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Vf4-00031w-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:40:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vek-0002w6-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 02:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Vem-0000mC-ES; Wed, 17 Mar 2004 02:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VeA-0000eP-3B for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 02:39:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22937 for ; Wed, 17 Mar 2004 02:39:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ve6-0002tR-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Vd9-0002lM-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:38:23 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3VcV-0002cg-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 02:37:43 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2H7fBFU019240; Wed, 17 Mar 2004 07:41:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2H7Urb3006624; Wed, 17 Mar 2004 07:30:58 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031623371304598 ; Tue, 16 Mar 2004 23:37:13 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 23:37:14 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E2EB2C2@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQLB9HxSBBAv/VDQpiJ6Zoy3zyWxgAE5ihQAAsZ+/AAKniKIA== From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 17 Mar 2004 07:37:14.0058 (UTC) FILETIME=[AA500AA0:01C40BF2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 23:37:13 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ram, You have made some interesting comments below on the categories. I think what you would like to see in general is categories based around IP rather than inside-box, outside-box scope which I have outlined. However, seemed to me like most of the folks like the box or close proximity scope rather than IP scope. I am fine with either of the two approaches...what do others think about this ? Regards=20 Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 > =20 > > Here are the basic ForCES Impl Categories... > >=20 > > Cat 1: Local (inside box) with reliable,CC multicast=20 > support (Example, > > ATM fabric backplane) > > No need of IP in this case, ForCES can directly run over L2 or use > > something like TIPC. > > Unicast+ multicast connections can be used in this case for > > communication. > > The statement is not clear to me...=20 Are we recommending that for single box its non-ip. There are systems that uses IPv6 and also IPv4 within single box... they have unicast mechanism.=20 May be we should have something like this.... for non-IP interconnects (with in single box) we can use=20 the proposed mechanism.... > > Cat 2: Local with No reliable,CC multicast support (Example, > > Gig-Ethernet backplane) > > No need of IP in this case, ForCES can directly run over L2 or use > > something like TIPC. > > Unicast connections can be used in this case for communication. The above two statement make a case for non-IP interconnects. We should also consider the case for IP interconnect with single box. > >=20 > > Cat 3: Non-local (Example, Ethernet wire) > > ForCES runs over IP/transport protocols in this case. > > Unicast connections such as TCP, DCCP can be used in this case. >=20 Here we should also consider non-IP physical box. for example ..... distributed GGSN (or SSGN) connected via l2 swichtes in wireless interconnect .... _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 09:54:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09038 for ; Wed, 17 Mar 2004 09:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cQh-0006bB-Cv for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 09:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HErn18025351 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 09:53:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cQX-0006aD-2Y for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 09:53:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08980 for ; Wed, 17 Mar 2004 09:53:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cQG-0006ZW-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 09:53:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cPS-0006T2-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 09:52:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3cOn-0006Lq-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 09:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cOn-0006WO-Kt; Wed, 17 Mar 2004 09:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cOK-0006Qe-WC for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 09:51:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08851 for ; Wed, 17 Mar 2004 09:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cOI-0006Ik-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 09:51:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cNQ-0006AM-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 09:50:36 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3cMf-000635-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 09:49:49 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031706521281:6489 ; Wed, 17 Mar 2004 06:52:12 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079534985.1031.35.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 03/17/2004 06:52:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/17/2004 06:52:15 AM, Serialize complete at 03/17/2004 06:52:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 17 Mar 2004 09:49:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-17 at 02:26, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] [..] > > [HK] Alright, so what youre saying is that you first send messages over > unreliable UDP multicast and if you don't get a response then you send The UDP multicast is still capable of being reliable. For it to discover that a message was not ACKed it needs that (reliability) feature. The real advantage is being able to update multiple FEs. The problem with retransmitting on the multicast channel is that there maybe other FEs that have responded. Retransmit gets to them and they have to process it (even if they dont respond to it). Besides reprocessing the mesaage, there is ambiguity: the FE is not sure why its receiving the message a second time i.e is it because the ACK it sent got lost? (You could remove this ambiguity by adding a list of all FEs that responded to the message, but that adds b/width cost). So the safest thing is to retransmit on the unicast. > it over TCP. Have you done this for control/configuration messages or > only for heartbeats ? All clases of messages that need to be delivered reliably; heartbeats are a speacial case because you may not care about some heartbeats being delivered reliably. > I agree that the Requirements around heartbeats > are not as strict as those for control messages. The problem which I can > see with using this approach for control is that you cannot have > deterministic performance. For example, you cant tell your customer that > we can deliver x routes/sec with our protocol implementation, which is > what a lot of our customers have asked for (another thing asked is y > data packets/sec). You can only give those numbers when you are sure about congestion levels (of bandwidth and CPU) really. Typically this is where the MLFR (Max Loss Free Rate) is measured. Our experience shows you have much much higher MLFR for updates/sec with this scheme. The multicast to FEs is infact driven by desire to have a high MLFR. As the numbers of FEs grow, so does the MLFR. > This is because in your implementation it will > completely depend on the interconnect characteristics as well as > load...in the best case your performance will be very good and in the > worst case it will be pretty bad, cause all your control messages have > to be sent again on the TCP connection after some timeout. Anyways, > these are my thoughts...wonder what others have to say about this ?? If you have congested CPUs this applies to TCP or pigeons as transport. i.e retransmits will happen regardless when messages are lost. With multicast first, the cost of retransmits is reduced. chopping email here for readability. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 10:06:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09793 for ; Wed, 17 Mar 2004 10:06:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cbx-0001N6-7T for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 10:05:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HF5b1m005263 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 10:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cbx-0001Mh-0v for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 10:05:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09748 for ; Wed, 17 Mar 2004 10:05:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cbu-0000HP-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 10:05:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cb6-0000BH-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 10:04:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3caN-00003p-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 10:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3caO-0000xS-4X; Wed, 17 Mar 2004 10:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cZx-0000in-3H for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 10:03:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09521 for ; Wed, 17 Mar 2004 10:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cZu-00001h-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 10:03:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cZ0-0007hj-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 10:02:34 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3cY0-0007ZU-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 10:01:32 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031707035581:6512 ; Wed, 17 Mar 2004 07:03:55 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079535688.1032.47.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 03/17/2004 07:03:56 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/17/2004 07:03:58 AM, Serialize complete at 03/17/2004 07:03:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 17 Mar 2004 10:01:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-17 at 02:26, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > This could be done in the CEM/FEM plane or negotiated via the CE/FE; > we can decide on the merits later. I am not religious about which one > should be used. My experiences are with CEM/FEM. > > [HK] I think have this as part of the protocol binding phase rather than > CEM/FEM will be much better for interop. Then we need to allow rebinding during the protocol run. Example i should be able to add another multicast connection without having to restart the application. > To come back to my note from above: We still differ on some specifics. > Example we saw value on send-on-multicast-resend-on-unicast. For this > to be met, the CE or FE should not care which connection it received the > message on. As an example it may receive the hearbeat on 1,2 or 3. > Does this sound reasonable? > > [HK] As I said heartbeats are special so I am not sure what the best > solution for this might be...we might have to send HBs on all 3 > connections...that is one possibility...or any of these 3 connections as > you are suggesting. Refer to my previous email. This is not specific to heartbeats. I suspect we will never send unicast on the data redirector connection but there should be nothing blocking that. This maybe related or resolvable via the transport abstraction path. > > > > Additionaly i think that there would be demarcations between close > > and non-close proximity where other protocols such as TIPC or L2 > direct > > maybe constrained. There may be tunnels of sorts connecting > > such demarcations to create a large NE. > > [HK] Not sure if I understand this properly...can you explain a bit > more > > If you say use TIPC or something TIPC-like you probably want it to run > only within the close proximity case. i.e you most likey dont want such > packets to hit a shared network. Same with L2. > You could make TIPC think things are in the same chasis by connecting > several such chasis across multiple hops interconnected maybe by TCP. > This would be like DVMRP "islands" for example in the old mbone days > interconnected using IPIP tunnels. OSPF does similar things. > If you use L2, you could use something like L2VPN. etc. > > [HK] Lets defer this one, I am not sure if it will be needed. This seems > similar to what Alex is suggesting regarding Transport Abstraction...am > I off track ? Yes. We can defer this. I noticed Ram may have other thoughts on the subject as well - i am not gonna respond to his email so we can move on. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 11:47:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19931 for ; Wed, 17 Mar 2004 11:47:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dfN-0002BT-HM for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 11:13:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGD3Uk008358 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 11:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dfC-0002AC-Vl for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 11:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15676 for ; Wed, 17 Mar 2004 11:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dex-0002r1-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 11:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dc4-0002Bh-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 11:09:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3daw-0001qQ-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 11:08:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3dWU-0002bF-4d for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 11:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dWT-0001ON-Th; Wed, 17 Mar 2004 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dW3-0001Ne-ID for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 11:03:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14996 for ; Wed, 17 Mar 2004 11:03:31 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dW0-0001HK-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 11:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dV8-0001BH-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 11:02:38 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B3dUa-00014t-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 11:02:05 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 18 Mar 2004 00:13:26 +0800 Received: from 219.82.191.138 ( [219.82.191.138]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Thu, 18 Mar 2004 00:13:26 +0800 Message-ID: <1079540006.405879385db31@mail.hzic.edu.cn> To: forces-protocol@ietf.org Cc: wangwm@hzcnc.com Subject: Re: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 00:13:26 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Jamal, and all, Let me try to view this issue from a little bit different viewpoint. I would prefer to consider the issue at the two different layers: 1. At the Forces protocol layer (as Alex said the Forces core layer), support for Unicast/Multicast/Broadcast should be all described as 'MUST'. 2. At the transport (adapation) layer, only a basic connection scheme for unicast is explicitly defined as 'MUST' for every different interconnection means, leaving other possible implementation schemes for Unicast/Multicast/Broadcast as well as for reliability (as the Categories as you posted) all as 'MAY'. Based on the 'MUST' supported unicast connection, a negotiation can be made between the CEs and FEs for them to choose a both acceptable scheme for transport layer support of U/M/B as well as reliability ( this idea was presented by Avri when we had a disscusion on Master-Slave model). This process can be done by FEM/CEM as Netlink2 proposed, or also can be done during the post-association phase. Hormuzd, I'm afraid what you just listed below for the approaches of three protocols are not also imcomplete for GRMP as well as for Netlink2. In fact, like Netlink2, GRMP can also support much more connection schemes for CE and FE. We can also allow to have many TCPs, Uni/Multicast UDPs, and many others, if only vendors would like to do like this. Why? because in GRMP we in fact have not explicitly limited how a connection scheme should be adpoted by vendors, leaving it to be flexibly implemented. This actually has shown one different design idea between us (I suppose also between Netlink2). Our idea is trying to make transport adapation more flexible to implementations, because as ForCES being a complex distributed system, we think it may be unwise and difficult to try to list out ( also become a limit when being listed out) all possible schemes for IPC for such a system. Speaking of this, I'm afraid your idea on GRMP against two channels may also be imcomplete. We are definitely not saying we want to only have one TCP channel so as to object two (UDP/TCP) channels. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Cc: Sent: Tuesday, March 16, 2004 10:15 AM Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Jamal, Thanks for the clarification. Here is some text around this issue which I think is a reasonable compromise, All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Should/Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol (post-association). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- we can defer on this one till we come back to issue#2) In this text I have tried to accommodate the different approaches of netlink2, GRMP and FACT, at the same time I have made the text strong by using Must/Should to have easy interop. Let me explain this further... Netlink2-uses 1 TCP + 1 Multicast UDP connection FACT-uses 1 TCP+ 1 unicast UDP+CC/DCCP like connection GRMP-uses 1 TCP+ 1 UDP(in some experiments)...also implemented with only TCP. Pls correct me if I am wrong here. The above text tries to accommodate all these approaches as well as the different scenarios or categories in which they are applicable. Here are the basic ForCES Impl Categories... Cat 1: Local (inside box) with reliable,CC multicast support (Example, ATM fabric backplane) No need of IP in this case, ForCES can directly run over L2 or use something like TIPC. Unicast+ multicast connections can be used in this case for communication. Cat 2: Local with No reliable,CC multicast support (Example, Gig-Ethernet backplane) No need of IP in this case, ForCES can directly run over L2 or use something like TIPC. Unicast connections can be used in this case for communication. Cat 3: Non-local (Example, Ethernet wire) ForCES runs over IP/transport protocols in this case. Unicast connections such as TCP, DCCP can be used in this case. Let me know what you guys think ? Regards Hormuzd ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 14:01:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29486 for ; Wed, 17 Mar 2004 14:01:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gHS-0000AG-Nd for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 14:00:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HJ0gb3000631 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 14:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gHS-0000A6-8N for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 14:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29474 for ; Wed, 17 Mar 2004 14:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gHQ-0007Ie-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 14:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gGW-0007Cb-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 13:59:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3gFp-000763-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 13:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gFp-0008NB-Pa; Wed, 17 Mar 2004 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gEt-0008Kk-LK for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 13:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29416 for ; Wed, 17 Mar 2004 13:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gEg-0006zG-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 13:57:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gDo-0006s4-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 13:56:57 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3gDJ-0006hg-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 13:56:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2HIw1N1020324; Wed, 17 Mar 2004 18:58:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2HIvlSb003784; Wed, 17 Mar 2004 18:57:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031710554227610 ; Wed, 17 Mar 2004 10:55:42 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 10:55: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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E377622@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQMMLxxM3VJP1ijROCGypwXVuRIBAAIDtUw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 17 Mar 2004 18:55:42.0720 (UTC) FILETIME=[7290E800:01C40C51] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 10:55:42 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wed, 2004-03-17 at 02:26, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > >=20 > This could be done in the CEM/FEM plane or negotiated via the CE/FE; > we can decide on the merits later. I am not religious about which one > should be used. My experiences are with CEM/FEM. >=20 > [HK] I think have this as part of the protocol binding phase rather than > CEM/FEM will be much better for interop. Then we need to allow rebinding during the protocol run. Example i should be able to add another multicast connection without having to restart the application. [HK] Agreed, infact we will definitely need the capability of adding=20 Multicast connections on the fly. > To come back to my note from above: We still differ on some specifics. > Example we saw value on send-on-multicast-resend-on-unicast. For this=20 > to be met, the CE or FE should not care which connection it received the > message on. As an example it may receive the hearbeat on 1,2 or 3. > Does this sound reasonable? >=20 > [HK] As I said heartbeats are special so I am not sure what the best > solution for this might be...we might have to send HBs on all 3 > connections...that is one possibility...or any of these 3 connections as > you are suggesting.=20 Refer to my previous email. This is not specific to heartbeats. I suspect we will never send unicast on the data redirector connection but there should be nothing=20 blocking that.=20 This maybe related or resolvable via the transport abstraction path. [HK] Agree. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 17 15:25:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05032 for ; Wed, 17 Mar 2004 15:25:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hap-0006ns-Fo for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 15:24:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HKOlJ8026146 for forces-protocol-archive@odin.ietf.org; Wed, 17 Mar 2004 15:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hao-0006nR-Tv for forces-protocol-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 15:24:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04975 for ; Wed, 17 Mar 2004 15:24:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3han-0003LX-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 15:24:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hZx-0003EW-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 15:23:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3hZ6-00036x-00 for forces-protocol-web-archive@ietf.org; Wed, 17 Mar 2004 15:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hZ6-0006IF-RK; Wed, 17 Mar 2004 15:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hYv-00066M-Oq for forces-protocol@optimus.ietf.org; Wed, 17 Mar 2004 15:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04795 for ; Wed, 17 Mar 2004 15:22:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hYu-00035l-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 15:22:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hY3-0002yg-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 15:21:56 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B3hXg-0002nX-00 for forces-protocol@ietf.org; Wed, 17 Mar 2004 15:21:32 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2HKL1TN004112; Wed, 17 Mar 2004 14:21:01 -0600 (CST) Message-ID: <4058B32B.8080407@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" CC: hadi@znyx.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E2EB2BC@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------050106020805000400010502" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 14:20:59 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050106020805000400010502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hormuzd, I think you've just raised a very crucial flaw about this multicast scheme. A scheme that works some time and fails the rest of time is really useless (in my view) in a critical system. Dependability and consistency are attributes of a well designed protocol. Regards, Alex. Khosravi, Hormuzd M wrote: >-----Original Message----- >From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > >>I personally dont think that a single multicast connection would >>be an efficient thing for a transport. On the same token i dont >>think a single unicast connection would be efficient. >>If you have a reliable unicast connection, i see the value >>of having a semi-reliable multicast connection - at least based on our >>experiences. Maybe people with other experiences can share. >> >>[HK] Based on our experiences and customer requirements, we have been >>able to satisfy them with 2 unicast connections. I am not sure what >> >> >you > > >>mean by semi-reliable multicast...can you explain ? I think >> >> >reliability, > >I was refering to our experiences in using both together. >(BTW, this is also one area we differ slightly). >When a message is to be delivered reliably, CE would send frist on >multicast; when things were fine we received all FE responses on >multicast connection. When things were not fine we didnt receive some >responses from some FEs. In this case we resent on TCP only to those FEs >that failed to respond. There are various reasons why you would resend >on TCP but i dont wannna go into them at the moment. >Netlink2 can ask for reliability on a per message level. This helps >the underlying transport abstraction decide how to deliver that message. >An Add route for example MUST be reliably delivered whereas some >heartbeats dont have to. >I agree with realibility, congestion control etc being met - but >we could simplify a lot. > >[HK] Alright, so what youre saying is that you first send messages over >unreliable UDP multicast and if you don't get a response then you send >it over TCP. Have you done this for control/configuration messages or >only for heartbeats ? I agree that the Requirements around heartbeats >are not as strict as those for control messages. The problem which I can >see with using this approach for control is that you cannot have >deterministic performance. For example, you cant tell your customer that >we can deliver x routes/sec with our protocol implementation, which is >what a lot of our customers have asked for (another thing asked is y >data packets/sec). This is because in your implementation it will >completely depend on the interconnect characteristics as well as >load...in the best case your performance will be very good and in the >worst case it will be pretty bad, cause all your control messages have >to be sent again on the TCP connection after some timeout. Anyways, >these are my thoughts...wonder what others have to say about this ?? > > > > --------------050106020805000400010502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hormuzd,

I think you've just raised a very crucial flaw about this multicast scheme. A scheme that
works some time and fails the rest of time  is really useless (in my view) in a critical system.
Dependability and consistency are attributes of a well designed protocol.

Regards,
Alex.

Khosravi, Hormuzd M wrote:
-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] 

  
I personally dont think that a single multicast connection would
be an efficient thing for a transport. On the same token i dont
think a single unicast connection would be efficient.
If you have a reliable unicast connection, i see the value
of having a semi-reliable multicast connection - at least based on our
experiences. Maybe people with other experiences can share.

[HK] Based on our experiences and customer requirements, we have been
able to satisfy them with 2 unicast connections. I am not sure what
    
you
  
mean by semi-reliable multicast...can you explain ? I think
    
reliability,

I was refering to our experiences in using both together.
(BTW, this is also one area we differ slightly).
When a message is to be delivered reliably, CE would send frist on
multicast; when things were fine we received all FE responses on
multicast connection. When things were not fine we didnt receive some
responses from some FEs. In this case we resent on TCP only to those FEs
that failed to respond. There are various reasons why you would resend
on TCP but i dont wannna go into them at the moment. 
Netlink2 can ask for reliability on a per message level. This helps
the underlying transport abstraction decide how to deliver that message.
An Add route for example MUST be reliably delivered whereas some
heartbeats dont have to.
I agree with realibility, congestion control etc being met - but
we could simplify a lot. 

[HK] Alright, so what youre saying is that you first send messages over
unreliable UDP multicast and if you don't get a response then you send
it over TCP. Have you done this for control/configuration messages or
only for heartbeats ? I agree that the Requirements around heartbeats
are not as strict as those for control messages. The problem which I can
see with using this approach for control is that you cannot have
deterministic performance. For example, you cant tell your customer that
we can deliver x routes/sec with our protocol implementation, which is
what a lot of our customers have asked for (another thing asked is y
data packets/sec). This is because in your implementation it will
completely depend on the interconnect characteristics as well as
load...in the best case your performance will be very good and in the
worst case it will be pretty bad, cause all your control messages have
to be sent again on the TCP connection after some timeout. Anyways,
these are my thoughts...wonder what others have to say about this ??

--------------050106020805000400010502-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 02:34:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24496 for ; Thu, 18 Mar 2004 02:34:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3s2l-0006Yg-Fj for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 02:34:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I7YJ0r025197 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 02:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3s2i-0006YG-6R for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 02:34:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24483 for ; Thu, 18 Mar 2004 02:34:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3s2e-0005lS-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 02:34:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3s1g-0005eS-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 02:33:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3s1S-0005Xc-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 02:32:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3s1V-0006TE-4l; Thu, 18 Mar 2004 02:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3s0g-0006Q8-7M for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 02:32:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24397 for ; Thu, 18 Mar 2004 02:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3s0c-0005VO-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 02:32:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3rzd-0005Nc-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 02:31:06 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B3rym-000525-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 02:30: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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2I7Xd2T003086; Thu, 18 Mar 2004 07:33:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2I7NKrs027954; Thu, 18 Mar 2004 07:23:20 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031723293420263 ; Wed, 17 Mar 2004 23:29:34 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Mar 2004 23:29: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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E377BDB@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQMLxk73+6Pbi0SSOWEtK/iP1/GvQAh1Kpw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 18 Mar 2004 07:29:34.0407 (UTC) FILETIME=[C2C09D70:01C40CBA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 23:29:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal As I have said before, I am not opposed to multicast. However, if we use it for control messages, it should be reliable, congestion aware, etc. to meet the Requirements. The scheme you have described below, will work under normal conditions...however I do see some interesting race conditions in addition to the performance issue that I pointed out.=20 In any case, I thought you had agreed in some of your previous emails and even on the forces list that reliability, CC is a must for control...are we still in agreement on this ? If yes, then whether we provide reliability by building such mechanisms into the ForCES protocol or whether we use the underlying transport is a separate issue. The discussion around UDP seems to be getting into the details of that issue, which we could defer for now. Do you agree ? Just one clarification related to your scheme, do you send the protocol Responses or as you term ACKs from FE to CE back on the unicast connection or multicast it. I thought I heard Jeff saying that it is sent back on the unicast connection, but I just wanted to confirm. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, March 17, 2004 6:50 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast On Wed, 2004-03-17 at 02:26, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 [..] >=20 > [HK] Alright, so what youre saying is that you first send messages over > unreliable UDP multicast and if you don't get a response then you send The UDP multicast is still capable of being reliable. For it to discover that a message was not ACKed it needs that (reliability) feature. The real advantage is being able to update multiple FEs. The problem with retransmitting on the multicast channel is that there maybe other FEs that have responded. Retransmit gets to them and they have to process it (even if they dont respond to it). Besides reprocessing the mesaage, there is ambiguity: the FE is not sure why its receiving the message a second time i.e is it because the ACK it sent got lost? (You could remove this ambiguity by adding a list of all FEs that responded to the message, but that adds b/width cost). So the safest thing is to retransmit on the unicast. > it over TCP. Have you done this for control/configuration messages or > only for heartbeats ?=20 All clases of messages that need to be delivered reliably; heartbeats are a speacial case because you may not care about some heartbeats being delivered reliably. > I agree that the Requirements around heartbeats > are not as strict as those for control messages. The problem which I can > see with using this approach for control is that you cannot have > deterministic performance. For example, you cant tell your customer that > we can deliver x routes/sec with our protocol implementation, which is > what a lot of our customers have asked for (another thing asked is y > data packets/sec).=20 You can only give those numbers when you are sure about congestion levels (of bandwidth and CPU) really. Typically this is where the MLFR (Max Loss Free Rate) is measured. Our experience shows you have much much higher MLFR for updates/sec with this scheme. The multicast to FEs is infact driven by desire to have a high MLFR. As the numbers of FEs grow, so does the MLFR. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 03:48:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27665 for ; Thu, 18 Mar 2004 03:48:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tCN-0003a2-QE for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 03:48:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I8mJ1S013761 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 03:48:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tCN-0003Zs-GE for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 03:48:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27637 for ; Thu, 18 Mar 2004 03:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tCL-0000E2-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 03:48:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tBR-00006h-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 03:47:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3tB5-0007mG-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 03:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tB7-0003VK-CR; Thu, 18 Mar 2004 03:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tAI-0003Sl-C1 for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 03:46:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27479 for ; Thu, 18 Mar 2004 03:46:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tAG-0007ii-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 03:46:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3t9I-0007a3-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 03:45:09 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B3t8K-0007MD-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 03:44:08 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 18 Mar 2004 16:55:09 +0800 Message-ID: <179701c40cc4$c7640240$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E377BDB@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 16:41:17 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Hi Hormuzd, Though you asked Jamal for this, I would also like to make a reply. I think a built-in mechanism adpoted to garuantee reliability should not be excluded even when the transport network is IP based. I don't think it is unacceptable to mulitcast using UDP first then for receivers to respond using unicast UDP and even for sender to retransmit using unicast UDP with the unicast UDP supported by built-in mechanism for reliability. In this way, the multicast is actually reliable. I'm afraid the word 'semi-reliable' is not proper to describe multicast. Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Cc: Sent: Thursday, March 18, 2004 3:29 PM Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Hi Jamal As I have said before, I am not opposed to multicast. However, if we use it for control messages, it should be reliable, congestion aware, etc. to meet the Requirements. The scheme you have described below, will work under normal conditions...however I do see some interesting race conditions in addition to the performance issue that I pointed out. In any case, I thought you had agreed in some of your previous emails and even on the forces list that reliability, CC is a must for control...are we still in agreement on this ? If yes, then whether we provide reliability by building such mechanisms into the ForCES protocol or whether we use the underlying transport is a separate issue. The discussion around UDP seems to be getting into the details of that issue, which we could defer for now. Do you agree ? Just one clarification related to your scheme, do you send the protocol Responses or as you term ACKs from FE to CE back on the unicast connection or multicast it. I thought I heard Jeff saying that it is sent back on the unicast connection, but I just wanted to confirm. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: Wednesday, March 17, 2004 6:50 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast On Wed, 2004-03-17 at 02:26, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] [..] > > [HK] Alright, so what youre saying is that you first send messages over > unreliable UDP multicast and if you don't get a response then you send The UDP multicast is still capable of being reliable. For it to discover that a message was not ACKed it needs that (reliability) feature. The real advantage is being able to update multiple FEs. The problem with retransmitting on the multicast channel is that there maybe other FEs that have responded. Retransmit gets to them and they have to process it (even if they dont respond to it). Besides reprocessing the mesaage, there is ambiguity: the FE is not sure why its receiving the message a second time i.e is it because the ACK it sent got lost? (You could remove this ambiguity by adding a list of all FEs that responded to the message, but that adds b/width cost). So the safest thing is to retransmit on the unicast. > it over TCP. Have you done this for control/configuration messages or > only for heartbeats ? All clases of messages that need to be delivered reliably; heartbeats are a speacial case because you may not care about some heartbeats being delivered reliably. > I agree that the Requirements around heartbeats > are not as strict as those for control messages. The problem which I can > see with using this approach for control is that you cannot have > deterministic performance. For example, you cant tell your customer that > we can deliver x routes/sec with our protocol implementation, which is > what a lot of our customers have asked for (another thing asked is y > data packets/sec). You can only give those numbers when you are sure about congestion levels (of bandwidth and CPU) really. Typically this is where the MLFR (Max Loss Free Rate) is measured. Our experience shows you have much much higher MLFR for updates/sec with this scheme. The multicast to FEs is infact driven by desire to have a high MLFR. As the numbers of FEs grow, so does the MLFR. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 06:55:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04799 for ; Thu, 18 Mar 2004 06:55:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w7O-0005hJ-7b for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 06:55:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBtM7V021895 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 06:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w7O-0005h4-0T for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:55:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04795 for ; Thu, 18 Mar 2004 06:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3w7J-0007Zl-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 06:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3w6Z-0007TR-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 06:54:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3w61-0007Ma-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 06:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w64-0005fI-Ie; Thu, 18 Mar 2004 06:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w5Q-0005eI-7O for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 06:53:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04722 for ; Thu, 18 Mar 2004 06:53:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3w5M-0007Jw-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 06:53:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3w4R-0007Bs-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 06:52:20 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B3w3c-00074D-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 06:51:28 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031803535237:7566 ; Thu, 18 Mar 2004 03:53:52 -0800 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E377BDB@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E377BDB@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079610683.1043.228.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 03/18/2004 03:53:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2004 03:53:55 AM, Serialize complete at 03/18/2004 03:53:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 18 Mar 2004 06:51:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hormuzd, On Thu, 2004-03-18 at 02:29, Khosravi, Hormuzd M wrote: > Hi Jamal > > As I have said before, I am not opposed to multicast. However, if we use > it for control messages, it should be reliable, congestion aware, etc. > to meet the Requirements. The scheme you have described below, will work > under normal conditions... Messages that need to be delivered reliably MUST be reliably delivered[1]. I did say infact that the multicast channel is capable of doing reliable delivery. For example the discovery that a retransmit is needed is through the multicast channel. The retransmit could be done through the multicast channel but that would complicate the messaging if you want to remove ambiguity. One way i described how to remove ambiguity is to have within the message a list of IDs for all nodes that have responded. This way a node seeing itself listed doesnt respond. > however I do see some interesting race > conditions in addition to the performance issue that I pointed out. The performance issues are against our experience and intuition for that matter. There are no race conditions if you assume all connections belong to the device and the differentiation of the messages based on priorities. But this brings a good point: this is why it shouldnt matter which connection the message is sent or received on. Then people wanting to implement the way you or i describe should have no issues (while fully interoperating). Then lets have a few benchmarks. > In any case, I thought you had agreed in some of your previous emails > and even on the forces list that reliability, CC is a must for > control...are we still in agreement on this ? Absolutely. Although i think you may be looking too closely at the connection detail as opposed to the mile high view. The blackbox view is that the message gets delivered reliably, and that CC is obeyed on a per link basis. Even though the multicast connection is reliable as i said only partial capabilities of reliability are used (example retransmit doesnt happen on it). In the above scenario it actually doesnt matter whether the send is on a multicast and ACK on one of the two other connections. I think where we differ is you are advocating a specific connection to be used for specific messages, correct? And i am saying there is no such restriction. > If yes, then whether we provide reliability by building such mechanisms > into the ForCES protocol or whether we use the underlying transport is a > separate issue. The discussion around UDP seems to be getting into the > details of that issue, which we could defer for now. Do you agree ? Lets defer it and close this issue. > Just one clarification related to your scheme, do you send the protocol > Responses or as you term ACKs from FE to CE back on the unicast > connection or multicast it. I thought I heard Jeff saying that it is > sent back on the unicast connection, but I just wanted to confirm. For reliability purposes, it doesnt matter which connection the ACK comes back on, IMO. The main reason you want the ACK to come back on the multicast is so that an FE tracking another gets a free ride of knowing of its state (such as the fact it is still alive, what table entries it is accepting, etc). But this is a detail that belongs to #7. I think we should move on to topic #4 and #5 since they are related to this discussion. cheers, jamal [1] I liked some text that Weiming used to describe this in an email he had earlier but cant seem to locate it now, _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 09:16:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12196 for ; Thu, 18 Mar 2004 09:16:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJE-0000zt-Ht for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 09:15:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEFi3m003829 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 09:15:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJE-0000zg-CS for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12146 for ; Thu, 18 Mar 2004 09:15:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yJC-0003HP-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 09:15:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yIJ-00038P-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 09:14:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHZ-0002yR-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 09:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHa-0000k9-RP; Thu, 18 Mar 2004 09:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHI-0000iG-Sb for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 09:13:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11970 for ; Thu, 18 Mar 2004 09:13:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHH-0002xm-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 09:13:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yGK-0002pL-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 09:12:45 -0500 Received: from ms-smtp-03-lbl.southeast.rr.com ([24.25.9.102] helo=ms-smtp-03-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1B3yFl-0002gA-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 09:12:09 -0500 Received: from creeksidenet.com (cpe-024-163-075-077.nc.rr.com [24.163.75.77]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i2IEC6s1021850; Thu, 18 Mar 2004 09:12:07 -0500 (EST) Message-ID: <4059AE45.5010907@creeksidenet.com> From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com CC: "Khosravi, Hormuzd M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E377BDB@orsmsx408.jf.intel.com> <1079610683.1043.228.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 09:12:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the "race condition" issue brought up when sending on two channels (mcast/ucast) only arises if the retransmit (unicast) is received before the original (multicast). This could be avoided by not retransmitting on unicast unless at least one FE had acked the multicast. Jeff Jamal Hadi Salim wrote: >Hi Hormuzd, > >On Thu, 2004-03-18 at 02:29, Khosravi, Hormuzd M wrote: > > >>Hi Jamal >> >>As I have said before, I am not opposed to multicast. However, if we use >>it for control messages, it should be reliable, congestion aware, etc. >>to meet the Requirements. The scheme you have described below, will work >>under normal conditions... >> >> > >Messages that need to be delivered reliably MUST be reliably >delivered[1]. >I did say infact that the multicast channel is capable of doing >reliable delivery. For example the discovery that a retransmit is needed >is through the multicast channel. The retransmit could be done through >the multicast channel but that would complicate the messaging if you >want to remove ambiguity. One way i described how to remove ambiguity is >to have within the message a list of IDs for all nodes that have >responded. This way a node seeing itself listed doesnt respond. > > > >>however I do see some interesting race >>conditions in addition to the performance issue that I pointed out. >> >> > >The performance issues are against our experience and intuition for that >matter. There are no race conditions if you assume all connections >belong to the device and the differentiation of the messages based on >priorities. > >But this brings a good point: this is why it shouldnt matter which >connection the message is sent or received on. Then people wanting >to implement the way you or i describe should have no issues (while >fully interoperating). Then lets have a few benchmarks. > > > >>In any case, I thought you had agreed in some of your previous emails >>and even on the forces list that reliability, CC is a must for >>control...are we still in agreement on this ? >> >> > >Absolutely. >Although i think you may be looking too closely at the connection detail >as opposed to the mile high view. >The blackbox view is that the message gets delivered reliably, and that >CC is obeyed on a per link basis. Even though the multicast connection >is reliable as i said only partial capabilities of reliability are used >(example retransmit doesnt happen on it). >In the above scenario it actually doesnt matter whether the send is on >a multicast and ACK on one of the two other connections. > >I think where we differ is you are advocating a specific connection to >be used for specific messages, correct? And i am saying there is no such >restriction. > > > >>If yes, then whether we provide reliability by building such mechanisms >>into the ForCES protocol or whether we use the underlying transport is a >>separate issue. The discussion around UDP seems to be getting into the >>details of that issue, which we could defer for now. Do you agree ? >> >> > >Lets defer it and close this issue. > > > >>Just one clarification related to your scheme, do you send the protocol >>Responses or as you term ACKs from FE to CE back on the unicast >>connection or multicast it. I thought I heard Jeff saying that it is >>sent back on the unicast connection, but I just wanted to confirm. >> >> > >For reliability purposes, it doesnt matter which connection the ACK >comes back on, IMO. >The main reason you want the ACK to come back on the multicast is so >that an FE tracking another gets a free ride of knowing of its >state (such as the fact it is still alive, what table entries it is >accepting, etc). But this is a detail that belongs to #7. > >I think we should move on to topic #4 and #5 since they are related to >this discussion. > >cheers, >jamal > >[1] I liked some text that Weiming used to describe this in an email he >had earlier but cant seem to locate it now, > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 10:59:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21531 for ; Thu, 18 Mar 2004 10:59:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zvY-0007r6-Fw for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 10:59:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFxO9J030195 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 10:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zvY-0007qw-Al for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:59:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21518 for ; Thu, 18 Mar 2004 10:59:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zvV-0007jF-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 10:59:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zua-0007eg-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 10:58:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ztc-0007Zz-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 10:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ztT-0007jE-Pc; Thu, 18 Mar 2004 10:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zsg-0007hj-Qs for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 10:56:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21362 for ; Thu, 18 Mar 2004 10:56:21 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zsd-0007XZ-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 10:56:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zrj-0007Vk-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 10:55:28 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B3zqt-0007TA-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 10:54:36 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 19 Mar 2004 00:06:03 +0800 Received: from 219.82.191.226 ( [219.82.191.226]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Fri, 19 Mar 2004 00:06:03 +0800 Message-ID: <1079625963.4059c8fe38183@mail.hzic.edu.cn> To: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Subject: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 00:06:03 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, To speed up, pls allow me to activate these issues. Actually we have had quite a lot discussions related to these topics. I just try to first list some items. Pls add some more. * For DoS Protection and Congestion control 1. The idea to distinguish packets by Data packets and Control packets should be used to protect against DoS and control congestion, where Data packets are actually redirected packets by FE to CE. 2. To further protect DoS and control congestion, something like a FE DoS Protection & Congestion Control Policy should be included in ForCES protocol. The policy may include that like priorities and rate limiting parameters for both C and D packet streams, and may be mapped to ForCES protocol layer scheduler or OS layer scheduler (need more discussion on which is better). For D packet stream, because it is a dataflow in FE model before being encapsulated as a ForCES message, it is possible an LFB be adpoted to do such rate limiting. For C packet stream, it is surely done out of the FE model scope. 3. A DoS (or Congestion) alert mechanism is necessary for ForCES protocol. 4. Even without DoS, congestion can also happen, for sometimes there may be too many C packets that need to be transmitted. 5. Do we need to consider congestion at the CE side? (Avri raised this question to me). * For reliability 1. A built-in mechanism for reliability like ACK, Checksum, and Dual-phase commit must be included in the protocol specification. 2. Differentiation of reliability for different protocol messages may be achieved at the transport layer and/or at the protocol (core) layer. I just stop here currently. Pls move forward quickly. Regards, Weiming ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 13:53:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00476 for ; Thu, 18 Mar 2004 13:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42dT-0001um-00 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 13:52:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IIqsKd007348 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 13:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42dR-0001uR-Ep for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:52:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00429 for ; Thu, 18 Mar 2004 13:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42dP-0002rm-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 13:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42cR-0002lA-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 13:51:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B42bb-0002gJ-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 13:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42bc-0001pN-LC; Thu, 18 Mar 2004 13:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42bB-0001nY-VR for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 13:50:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00242 for ; Thu, 18 Mar 2004 13:50:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42b9-0002dp-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 13:50:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42a9-0002a5-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 13:49:30 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1B42Yh-0002UO-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 13:47:59 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2IIlQ8d005025; Thu, 18 Mar 2004 12:47:27 -0600 (CST) Message-ID: <4059EEBD.2090001@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wmwang@mail.hzic.edu.cn CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability References: <1079625963.4059c8fe38183@mail.hzic.edu.cn> In-Reply-To: <1079625963.4059c8fe38183@mail.hzic.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 12:47:25 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Weiming, I don't think it is possible for us to come up with a mechanism to determine if an FE is being DOS'd. The final determination of that may depend on situation at hand, since attack signatures are typically different for different DOS attacks. I think the final decision as to if a DOS is really occuring is best left to policy on the NE. This is outside ForCES scope. But we can have FE report resource usage status to CE. I think FACT already has such report. Regards, Alex. wmwang@mail.hzic.edu.cn wrote: >Hi all, > >[snip] > >3. A DoS (or Congestion) alert mechanism is necessary for ForCES protocol. > >4. Even without DoS, congestion can also happen, for sometimes there may be too >many C packets that need to be transmitted. > >5. Do we need to consider congestion at the CE side? (Avri raised this question >to me). > >* For reliability > >1. A built-in mechanism for reliability like ACK, Checksum, and Dual-phase >commit must be included in the protocol specification. > >2. Differentiation of reliability for different protocol messages may be >achieved at the transport layer and/or at the protocol (core) layer. > >I just stop here currently. Pls move forward quickly. > >Regards, >Weiming > > > >------------------------------------------------- >This mail sent through HUCNIC Webmail system. > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 14:26:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02044 for ; Thu, 18 Mar 2004 14:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B439M-0004Iz-Co for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 14:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IJPgXH016536 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 14:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B439B-0004I5-RI for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 14:25:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02028 for ; Thu, 18 Mar 2004 14:25:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4390-0004qo-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 14:25:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4388-0004oW-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 14:24:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B437X-0004mh-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 14:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B437Z-0004D2-C0; Thu, 18 Mar 2004 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B436d-00049s-An for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 14:23:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01891 for ; Thu, 18 Mar 2004 14:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B436a-0004i4-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 14:23:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B435c-0004cU-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 14:22:01 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B434p-0004UB-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 14:21:11 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2IJMeRX012216; Thu, 18 Mar 2004 19:22:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2IJMEm8029519; Thu, 18 Mar 2004 19:22:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031811202414963 ; Thu, 18 Mar 2004 11:20:24 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 11:20:24 -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 Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Message-ID: <468F3FDA28AA87429AD807992E22D07E377F84@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast Thread-Index: AcQM31wHe5po/o1FQ8Cir2tutnCNHgAO4XmQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 18 Mar 2004 19:20:24.0829 (UTC) FILETIME=[10628AD0:01C40D1E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 11:20:23 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal, Glad to hear that we are in sync on some of the basics below. One question, you say that Reliability is a MUST, do you also agree that the Multicast connections should be Congestion Aware ? I think you do, but just want to confirm this. Also, I think its important to specify which messages are delivered on which connections in order to have interoperable solutions. I fear that if we have too many SHOULD/MAYs in the protocol in order to satisfy everyone on this team, we will never have a truly interoperable IETF protocol. I will send more comments on some of the points you have mentioned below in context with issue#4,5. Is that fine ? Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > As I have said before, I am not opposed to multicast. However, if we use > it for control messages, it should be reliable, congestion aware, etc. > to meet the Requirements. The scheme you have described below, will work > under normal conditions... Messages that need to be delivered reliably MUST be reliably delivered[1]. I did say infact that the multicast channel is capable of doing reliable delivery. For example the discovery that a retransmit is needed is through the multicast channel. The retransmit could be done through the multicast channel but that would complicate the messaging if you want to remove ambiguity. One way i described how to remove ambiguity is to have within the message a list of IDs for all nodes that have responded. This way a node seeing itself listed doesnt respond. > however I do see some interesting race > conditions in addition to the performance issue that I pointed out.=20 The performance issues are against our experience and intuition for that matter. There are no race conditions if you assume all connections belong to the device and the differentiation of the messages based on priorities. But this brings a good point: this is why it shouldnt matter which connection the message is sent or received on. Then people wanting to implement the way you or i describe should have no issues (while fully interoperating). Then lets have a few benchmarks. > In any case, I thought you had agreed in some of your previous emails > and even on the forces list that reliability, CC is a must for > control...are we still in agreement on this ? Absolutely.=20 Although i think you may be looking too closely at the connection detail as opposed to the mile high view.=20 The blackbox view is that the message gets delivered reliably, and that=20 CC is obeyed on a per link basis. Even though the multicast connection is reliable as i said only partial capabilities of reliability are used (example retransmit doesnt happen on it). In the above scenario it actually doesnt matter whether the send is on a multicast and ACK on one of the two other connections.=20 I think where we differ is you are advocating a specific connection to be used for specific messages, correct? And i am saying there is no such restriction. > If yes, then whether we provide reliability by building such mechanisms > into the ForCES protocol or whether we use the underlying transport is a > separate issue. The discussion around UDP seems to be getting into the > details of that issue, which we could defer for now. Do you agree ? Lets defer it and close this issue. > Just one clarification related to your scheme, do you send the protocol > Responses or as you term ACKs from FE to CE back on the unicast > connection or multicast it. I thought I heard Jeff saying that it is > sent back on the unicast connection, but I just wanted to confirm. For reliability purposes, it doesnt matter which connection the ACK comes back on, IMO. The main reason you want the ACK to come back on the multicast is so that an FE tracking another gets a free ride of knowing of its state (such as the fact it is still alive, what table entries it is accepting, etc). But this is a detail that belongs to #7. I think we should move on to topic #4 and #5 since they are related to this discussion. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 16:44:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10411 for ; Thu, 18 Mar 2004 16:44:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45Ij-00088j-56 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 16:43:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ILhfYB031286 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 16:43:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45Ii-00088X-VL for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 16:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10393 for ; Thu, 18 Mar 2004 16:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B45Ig-00077C-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 16:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B45Hq-00073l-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 16:42:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B45H5-000705-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 16:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45H7-00081i-1d; Thu, 18 Mar 2004 16:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45Gv-00080l-N8 for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 16:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10275 for ; Thu, 18 Mar 2004 16:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B45Gt-0006yF-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 16:41:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B45Fy-0006u5-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 16:40:51 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B45FZ-0006pi-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 16:40:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2ILha2T001623; Thu, 18 Mar 2004 21:43:37 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2ILXBru020120; Thu, 18 Mar 2004 21:33:14 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031813393504873 ; Thu, 18 Mar 2004 13:39:35 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 13:39:35 -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 Subject: RE: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability Message-ID: <468F3FDA28AA87429AD807992E22D07E378135@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability Thread-Index: AcQNAeQNNOZr+SMjSeGcMl1y58pPGAAHF9Zw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 18 Mar 2004 21:39:35.0601 (UTC) FILETIME=[81D53A10:01C40D31] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 13:39:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, Thanks for getting these issues started. Here are my thoughts... #4- Congestion Control: Congestion control is important for the ForCES protocol in order to meet the Scalability requirements. As we start going from 10s of FEs to 100s and even thousands of FEs, we will need to have congestion control mechanisms in the protocol. There was a general agreement on this topic on the ForCES mailing list, when we had the discussion around multicast. I think we should separate the discussion around Congestion Control from the DoS protection discussion. So to address your email, the answer to #4,5 below is 'Yes, CC is important for both control and data messages'. Also, I am fine with #3 below but we should discuss the specifics of that issue later. Is that fine ? What do others think about this ? #5- Reliability: Couple of questions need to be answered here... What exactly does everyone mean by Reliability ? Do they mean 'strict reliability' as defined in the Requirements ? I assume the answer is yes to this one, but just want to clarify it. The second question is whether the Reliability/CC mechanisms should be built into the protocol or reused from existing transports ? There are a couple of cases here and the answer would depend on the case... 1. ForCES over IP: We can easily reuse existing Transports such as TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the protocol simple and don't spend our energies in re-inventing the wheel. 2. ForCES over L2: Here we could either build reliability mechanisms into the protocol in an optional TLV/encapsulation header or use protocols such as TIPC to provide this functionality. In any case, it will be useful to have a separate section/draft which will address these mappings (similar to GSMP/GRMP, etc) So in context with your email below, I partially agree with what you are suggesting but providing ways to break up and conquer this issue. Let me know what you guys think ? Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Hi all, To speed up, pls allow me to activate these issues. Actually we have had quite=20 a lot discussions related to these topics. I just try to first list some items.=20 Pls add some more. * For DoS Protection and Congestion control 1. The idea to distinguish packets by Data packets and Control packets should=20 be used to protect against DoS and control congestion, where Data packets are=20 actually redirected packets by FE to CE. 2. To further protect DoS and control congestion, something like a FE DoS=20 Protection & Congestion Control Policy should be included in ForCES protocol.=20 The policy may include that like priorities and rate limiting parameters for=20 both C and D packet streams, and may be mapped to ForCES protocol layer=20 scheduler or OS layer scheduler (need more discussion on which is better). For=20 D packet stream, because it is a dataflow in FE model before being encapsulated=20 as a ForCES message, it is possible an LFB be adpoted to do such rate limiting.=20 For C packet stream, it is surely done out of the FE model scope.=20 3. A DoS (or Congestion) alert mechanism is necessary for ForCES protocol.=20 4. Even without DoS, congestion can also happen, for sometimes there may be too=20 many C packets that need to be transmitted.=20 5. Do we need to consider congestion at the CE side? (Avri raised this question=20 to me).=20 * For reliability 1. A built-in mechanism for reliability like ACK, Checksum, and Dual-phase=20 commit must be included in the protocol specification.=20 2. Differentiation of reliability for different protocol messages may be achieved at the transport layer and/or at the protocol (core) layer.=20 I just stop here currently. Pls move forward quickly. Regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 18:38:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17088 for ; Thu, 18 Mar 2004 18:38:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4753-0005pr-Sn for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 18:37:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2INbf5G022420 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 18:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4753-0005pR-DC for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 18:37:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17063 for ; Thu, 18 Mar 2004 18:37:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4750-0007ck-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 18:37:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B474C-0007ag-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 18:36:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B473P-0007Yf-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 18:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B473R-0005h5-TG; Thu, 18 Mar 2004 18:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4736-0005g7-Rv for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 18:35:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17027 for ; Thu, 18 Mar 2004 18:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4733-0007XJ-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 18:35:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4727-0007VC-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 18:34:40 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B471Z-0007Rw-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 18:34:05 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2INZcRX017401 for ; Thu, 18 Mar 2004 23:35:39 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2INQXs6009694 for ; Thu, 18 Mar 2004 23:27:00 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031815332025019 for ; Thu, 18 Mar 2004 15:33:20 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 15:33: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 Message-ID: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> Thread-Topic: Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQNQWYF9ihaGwoFTveha9d0a/Fzgg== From: "Putzolu, David" To: X-OriginalArrivalTime: 18 Mar 2004 23:33:21.0036 (UTC) FILETIME=[661BF4C0:01C40D41] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 15:33:20 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all. Just a small clarification on the reliability and congestion control discussion based on what several ADs told me in Korea in no uncertain terms. Any IP-based implementation of ForCES will be forced=20 to use a RFC2914-compliant transport for all its=20 packets. That pretty much disallows use of UDP at=20 all in the ForCESoverIP case and leaves TCP, SCTP, and possible RMT as the only transports ForCES can use over IP. Both myself and Jon Maloy pushed back on this, saying that one might want to use UDP in a purely local scenario for various reasons. The ADs where adamant, arguing that one can never guarantee that IP will stay local, and the IETF would not standardize=20 using a non-2914 compliant IP protocol (e.g. UDP). The ADs pointed to iSCSI as a precedent. This isn't to say that multicast cannot be used - I am a fan of the transport abstraction approach that says that the ForCES protocol will just assume it has a multicast transport and a unicast transport, and that the transport layer mapping ala GSMP will take care of it. Below is a URL to some text and drawings based on Alex=20 and other's comments - what do you think? Is this an acceptable solution to transport/multicast/unicast/ retransmit/etc.? http://www.sstanamera.com/~forces/proto/ForCESLayered.htm -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 20:47:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22499 for ; Thu, 18 Mar 2004 20:47:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B495x-0005Ej-Vs for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 20:46:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J1kjN4020123 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 20:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B495x-0005EU-M8 for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 20:46:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22485 for ; Thu, 18 Mar 2004 20:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B495v-0000Wb-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 20:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4950-0000UM-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 20:45:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B494F-0000Rr-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 20:44:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B494H-0005A2-0i; Thu, 18 Mar 2004 20:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4941-00059g-AY for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 20:44:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22460 for ; Thu, 18 Mar 2004 20:44:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B493z-0000R1-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 20:44:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B493E-0000Ou-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 20:43:57 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B492t-0000LX-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 20:43:35 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2J1gtLc010458 for ; Thu, 18 Mar 2004 19:42:55 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 19:40:55 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 19:43:00 -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 GPWX1AC7; Thu, 18 Mar 2004 20:42:56 -0500 Message-ID: <405A501B.2050201@ericsson.com> From: Jon Maloy 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 To: "Putzolu, David" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES References: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2004 01:40:55.0328 (UTC) FILETIME=[386C3A00:01C40D53] Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 20:42:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This looks very reasonable. I still have some questions: Will the TML be presenting one uniform API towards the protocol layer ? If so, what are we going to do when the protocols have different address formats, and even completely different address abstractions ? Do we invent our own address format and model, as a least common denominator of the used transports ? We probably need only three types of addresses: 1: An opaque unicast address that is mapped down to an Ip-address/port tuple, an ethernet address, or a TIPC port name, depending on transport. 2: A multicast address that is mapped down to ditto addresses in the different transports. 3: A "multicast group" abstraction that is mapped down to multicast group addresses on IP, Ethernet, or a port name sequence on TIPC. With TIPC, it will somewhat reduce the flexibility of the port name sequence concept, which makes it possible for the CE:s to define "multicast groups for the occasion", but it should be easily mappable to a more static multicast group concept, if this is sufficient. As David stated, the TML layer for L2 would be virtually empty if mapped down to TIPC, and would give us an early available implementation of ForCES over L2. Speaking from experience, implementing a stable and performant transport layer with retransmission, node- and process supervision, media load sharing and failover etc, not to speak about reliable multicast, is far from trivial, and we may risk to never see such a protocol come into existence => we would be confined to TCP, SCTP and the properties those protocols can offer. Cheers /jon Putzolu, David wrote: >Hi all. > >Just a small clarification on the reliability and >congestion control discussion based on what several >ADs told me in Korea in no uncertain terms. > >Any IP-based implementation of ForCES will be forced >to use a RFC2914-compliant transport for all its >packets. That pretty much disallows use of UDP at >all in the ForCESoverIP case and leaves TCP, SCTP, >and possible RMT as the only transports ForCES can >use over IP. > >Both myself and Jon Maloy pushed back on this, saying >that one might want to use UDP in a purely local >scenario for various reasons. The ADs where adamant, >arguing that one can never guarantee that IP will >stay local, and the IETF would not standardize >using a non-2914 compliant IP protocol (e.g. UDP). >The ADs pointed to iSCSI as a precedent. > >This isn't to say that multicast cannot be used - I >am a fan of the transport abstraction approach that >says that the ForCES protocol will just assume it has >a multicast transport and a unicast transport, and >that the transport layer mapping ala GSMP will take >care of it. > >Below is a URL to some text and drawings based on Alex >and other's comments - what do you think? Is this an >acceptable solution to transport/multicast/unicast/ >retransmit/etc.? > >http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > >-David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 21:24:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23646 for ; Thu, 18 Mar 2004 21:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49fp-0000Yy-2d for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 21:23:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J2Nngt002164 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 21:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49fo-0000Yp-TU for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 21:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23627 for ; Thu, 18 Mar 2004 21:23:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49fm-0003Dv-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49eu-00039t-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:22:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B49e3-00035y-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49e5-0000RS-9K; Thu, 18 Mar 2004 21:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49do-0000Qg-8v for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 21:21:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23545 for ; Thu, 18 Mar 2004 21:21:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49dl-00033Q-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:21:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49cr-000300-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:20:45 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B49c0-0002ws-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:19:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031818221462:8443 ; Thu, 18 Mar 2004 18:22:14 -0800 Subject: RE: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E378135@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E378135@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079662786.1042.75.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 03/18/2004 06:22:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2004 06:22:18 PM, Serialize complete at 03/18/2004 06:22:18 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 18 Mar 2004 21:19:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, Skipped your other email since i am trying to catchup and this one references Weimings. On Thu, 2004-03-18 at 16:39, Khosravi, Hormuzd M wrote: > Weiming, > > Thanks for getting these issues started. > Here are my thoughts... > > #4- Congestion Control: > Congestion control is important for the ForCES protocol in order to meet > the Scalability requirements. As we start going from 10s of FEs to 100s > and even thousands of FEs, we will need to have congestion control > mechanisms in the protocol. There was a general agreement on this topic > on the ForCES mailing list, when we had the discussion around multicast. > I think we should separate the discussion around Congestion Control from > the DoS protection discussion. I think that congestion control MUST be met. Perhaps we should look at some of the ideas of DCCP for pluggable congestion algorithms. I think i have an idea on how to resolve Weimings thoughts on DOS protection: If we look at DOS indicator as an explicit congestion notification, then we could squeeze it under those auspicies. Ability to provide intelligent explicit feedback for congestion control would be useful in general. Of course DOS being one item of a bigger set of issues that create congestion. I am not sure i like the way GRMP is doing it, but i also think we should be able to satisfy this desire under the auspicies of Explicit Congestion notification. > > #5- Reliability: > Couple of questions need to be answered here... > What exactly does everyone mean by Reliability ? Do they mean 'strict > reliability' as defined in the Requirements ? I assume the answer is yes > to this one, but just want to clarify it. I am always thinking of the academic definition. Sorry, I had to cutnpaste from an old posting i made. 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. > The second question is whether the Reliability/CC mechanisms should be > built into the protocol or reused from existing transports ? There are a > couple of cases here and the answer would depend on the case... > 1. ForCES over IP: We can easily reuse existing Transports such as > TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the > protocol simple and don't spend our energies in re-inventing the wheel. Note that even when you use TCP or SCTP the reliability is to be defined at the application/ForCES layer. Reusing above transports should help. > 2. ForCES over L2: Here we could either build reliability mechanisms > into the protocol in an optional TLV/encapsulation header or use > protocols such as TIPC to provide this functionality. In any case, it > will be useful to have a separate section/draft which will address these > mappings (similar to GSMP/GRMP, etc) Lets not rush into separating them for now. To be honest there is no one transport that can satisfy all the needs thats why we need all those connections. Hence the idea of a transport abstraction is sane. If we leave say the responsibility of conegstion control, reliability, security, avaliability to this abstraction layer we can make good progress. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 21:37:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24082 for ; Thu, 18 Mar 2004 21:37:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49sM-0001G1-8a for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 21:36:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J2akrp004827 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 21:36:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49sL-0001Fm-Ph for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 21:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24073 for ; Thu, 18 Mar 2004 21:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49sJ-00041I-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49rQ-0003z6-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:35:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B49qf-0003wL-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 21:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49qh-0001AU-3J; Thu, 18 Mar 2004 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49qc-00019h-SC for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 21:34:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24025 for ; Thu, 18 Mar 2004 21:34:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49qa-0003vm-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:34:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49pj-0003r9-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:34:03 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B49ok-0003mZ-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 21:33:02 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031818352746:8454 ; Thu, 18 Mar 2004 18:35:27 -0800 Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079663579.1045.89.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 03/18/2004 06:35:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2004 06:35:28 PM, Serialize complete at 03/18/2004 06:35:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 18 Mar 2004 21:32:59 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-18 at 18:33, Putzolu, David wrote: > Hi all. > > Just a small clarification on the reliability and > congestion control discussion based on what several > ADs told me in Korea in no uncertain terms. > > Any IP-based implementation of ForCES will be forced > to use a RFC2914-compliant transport for all its > packets. That pretty much disallows use of UDP at > all in the ForCESoverIP case huh? DCCP aka UDP with CC built in? We could select different CC algos depending on the scope being used. > and leaves TCP, SCTP, > and possible RMT as the only transports ForCES can > use over IP. > Both myself and Jon Maloy pushed back on this, saying > that one might want to use UDP in a purely local > scenario for various reasons. The ADs where adamant, > arguing that one can never guarantee that IP will > stay local, and the IETF would not standardize > using a non-2914 compliant IP protocol (e.g. UDP). > The ADs pointed to iSCSI as a precedent. > > This isn't to say that multicast cannot be used - I > am a fan of the transport abstraction approach that > says that the ForCES protocol will just assume it has > a multicast transport and a unicast transport, and > that the transport layer mapping ala GSMP will take > care of it. Is there a draft/RFC which talks transport layer mapping at GSMP level? > Below is a URL to some text and drawings based on Alex > and other's comments - what do you think? Is this an > acceptable solution to transport/multicast/unicast/ > retransmit/etc.? > > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > I will study this some more and give better responses. >From the outset it does look reasonable. I am assuming that the TML serializes the data to the Forces PL? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Mar 18 23:06:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27487 for ; Thu, 18 Mar 2004 23:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4BGe-0005PT-Vw for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 23:05:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J45uuQ020795 for forces-protocol-archive@odin.ietf.org; Thu, 18 Mar 2004 23:05:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4BGe-0005PK-Kq for forces-protocol-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 23:05:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27460 for ; Thu, 18 Mar 2004 23:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4BGa-0002Mo-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 23:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4BFR-0002G2-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 23:04:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4BDl-0002Bz-00 for forces-protocol-web-archive@ietf.org; Thu, 18 Mar 2004 23:02:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4BDo-0005KI-JL; Thu, 18 Mar 2004 23:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4BD2-0005Hm-HY for forces-protocol@optimus.ietf.org; Thu, 18 Mar 2004 23:02:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27246 for ; Thu, 18 Mar 2004 23:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4BCz-00026q-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 23:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4BBy-000202-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 23:01:07 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4BB7-0001uj-00 for forces-protocol@ietf.org; Thu, 18 Mar 2004 23:00:13 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031820023751:8498 ; Thu, 18 Mar 2004 20:02:37 -0800 Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Jon Maloy Cc: "Putzolu, David" , forces-protocol@ietf.org In-Reply-To: <405A501B.2050201@ericsson.com> References: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> <405A501B.2050201@ericsson.com> Organization: ZNYX Networks Message-Id: <1079668805.1040.152.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 03/18/2004 08:02:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2004 08:02:39 PM, Serialize complete at 03/18/2004 08:02:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 18 Mar 2004 23:00:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I looked a little more at the URL posted and i think it is a very good start; things need to be fleshed out still but we can start from there. On Thu, 2004-03-18 at 20:42, Jon Maloy wrote: > This looks very reasonable. > I still have some questions: Will the TML be presenting one > uniform API towards the protocol layer ? I would think so. > If so, what are we going to do when the protocols have different > address formats, and even > completely different address abstractions ? Shouldnt we only care about the Forces address (aka ID which was hotly debated a while back)? Underneath whatever the TML layer does in terms of addressing should be transparent to the PL. > Do we invent our own > address format and model, as a least common denominator of the > used transports ? Refer to note above. > We probably need only three types of addresses: > > 1: An opaque unicast address that is mapped down to an Ip-address/port > tuple, an ethernet address, or a TIPC port name, depending on transport. > > 2: A multicast address that is mapped down to ditto addresses in > the different transports. > > 3: A "multicast group" abstraction that is mapped down to multicast > group addresses on IP, Ethernet, or a port name sequence on TIPC. This brings back the notion of IDs we discussed in issue #0. We have all addressing abstractions of the types you refer to above. > With TIPC, it will somewhat reduce the flexibility of the port name > sequence concept, which makes it possible for the CE:s to define > "multicast groups for the occasion", but it should be easily mappable > to a more static multicast group concept, if this is sufficient. > > As David stated, the TML layer for L2 would be virtually empty > if mapped down to TIPC, and would give us an early available > implementation of ForCES over L2. Speaking from experience, > implementing a stable and performant transport layer with retransmission, > node- and process supervision, media load sharing and failover etc, not > to speak > about reliable multicast, is far from trivial, and we may risk to never > see > such a protocol come into existence => we would be confined to TCP, SCTP > and the properties those protocols can offer. > Agreed. The TML should take care of reliability, congestion control, availability/failover; interfacing to xEM etc. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 02:52:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20856 for ; Fri, 19 Mar 2004 02:52:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EnO-0003Xr-QV for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 02:51:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J7pwVF013624 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 02:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EnN-0003Xf-3c for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:51:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20832 for ; Fri, 19 Mar 2004 02:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4EnJ-0003Rh-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:51:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4EmM-0003OT-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:50:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4ElT-0003Lb-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:49:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ElW-0003SX-6Q; Fri, 19 Mar 2004 02:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Eka-0003QF-6n for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 02:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20732 for ; Fri, 19 Mar 2004 02:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4EkW-0003Gx-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4EjW-0003DM-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:47:58 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4Eie-00039X-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:47:05 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 19 Mar 2004 15:58:23 +0800 Message-ID: <181c01c40d86$01d34be0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <1079625963.4059c8fe38183@mail.hzic.edu.cn> <4059EEBD.2090001@alcatel.com> Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 15:44:27 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Hello Alex, I think what you said is exactly what I meant. That is, something like 'DoS Alert Policy' as called in GRMP should be used to determine when a DoS is considered and an alert event is sent from FE to CE. Actually I don't think to manage this policy is outside the scope of ForCES, it can surely be set up as a kind of FE attribute to FE by CE. And moreover, I'm afraid a pure resource usage status report is not enough for DoS alert purpose. On the other hand, I have to say what set in current GRMP for 'DoS alert policy' seems a little naive. We need improvement on this, that is, to find a better and more efficient description for the policy. Thank you. Weiming ----- Original Message ----- From: "Alex Audu" To: Cc: Sent: Friday, March 19, 2004 2:47 AM Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability > Hello Weiming, > > I don't think it is possible for us to come up with a mechanism to > determine if an FE is being > DOS'd. The final determination of that may depend on situation at hand, > since attack > signatures are typically different for different DOS attacks. I think > the final decision as to > if a DOS is really occuring is best left to policy on the NE. This is > outside ForCES scope. > But we can have FE report resource usage status to CE. I think FACT > already has > such report. > > Regards, > Alex. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 02:59:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21069 for ; Fri, 19 Mar 2004 02:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Eu8-00041X-9v for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 02:58:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J7wute015465 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 02:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Eu7-00041M-Kt for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21062 for ; Fri, 19 Mar 2004 02:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Eu3-0003sG-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:58:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Et6-0003pG-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:57:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4EsD-0003mI-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 02:56:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EsG-0003oe-QG; Fri, 19 Mar 2004 02:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EsD-0003oS-1L for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 02:56:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21018 for ; Fri, 19 Mar 2004 02:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Es9-0003lY-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:56:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ErE-0003iQ-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:55:57 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4EqL-0003bo-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 02:55:02 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2J7wWJ2011580; Fri, 19 Mar 2004 07:58:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2J7m4CI006140; Fri, 19 Mar 2004 07:48:08 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031823543030899 ; Thu, 18 Mar 2004 23:54:30 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 23:54:30 -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 Subject: RE: [Forces-protocol] Issue 4&5: Congestion control, DoSprotection, and Reliability Message-ID: <468F3FDA28AA87429AD807992E22D07E37849E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Issue 4&5: Congestion control, DoSprotection, and Reliability Thread-Index: AcQNWMpgVTtquUOATlyX3A/Xc07sKAALQWKQ From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 19 Mar 2004 07:54:30.0600 (UTC) FILETIME=[68F74C80:01C40D87] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 23:54:30 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > #4- Congestion Control: > Congestion control is important for the ForCES protocol in order to meet > the Scalability requirements. As we start going from 10s of FEs to 100s > and even thousands of FEs, we will need to have congestion control > mechanisms in the protocol. There was a general agreement on this topic > on the ForCES mailing list, when we had the discussion around multicast. > I think we should separate the discussion around Congestion Control from > the DoS protection discussion. I think that congestion control MUST be met. Perhaps we should look at some of the ideas of DCCP for pluggable congestion algorithms. I think i have an idea on how to resolve Weimings thoughts on DOS protection: If we look at DOS indicator as an explicit congestion notification, then we could squeeze it under those auspicies. Ability to provide intelligent explicit feedback for congestion control would be useful in general. Of course DOS being one item of a bigger set of issues that create congestion.=20 I am not sure i like the way GRMP is doing it, but i also think we should be able to satisfy this desire under the auspicies of Explicit Congestion notification. [HK] We do need an asynchronous notification message to report some event like this. However, it should be triggered by the FE and not the protocol. Do you agree ? >=20 > #5- Reliability: > Couple of questions need to be answered here... > What exactly does everyone mean by Reliability ? Do they mean 'strict > reliability' as defined in the Requirements ? I assume the answer is yes > to this one, but just want to clarify it. I am always thinking of the academic definition. Sorry, I had to cutnpaste from an old posting i made. 1) Message is delivered with integrity.=20 This means the mesage is delivered identical to what was sent. Additionaly only _one_ copy is delivered. [HK] What about in order delivery ? I think this is also covered by this point but just wanted to confirm. 2) A valid message is delivered.=20 And in this portion a timeliness connotation comes in.=20 The "valid" part infact defines a time limit where the message is considered useful.=20 [HK] Agreed, here is where a protocol level response or ack is useful. > The second question is whether the Reliability/CC mechanisms should be > built into the protocol or reused from existing transports ? There are a > couple of cases here and the answer would depend on the case... > 1. ForCES over IP: We can easily reuse existing Transports such as > TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the > protocol simple and don't spend our energies in re-inventing the wheel. Note that even when you use TCP or SCTP the reliability is to be defined at the application/ForCES layer. Reusing above transports should help. [HK] The only other thing needed is protocol level Response or ACK. Is this what you mean ? > 2. ForCES over L2: Here we could either build reliability mechanisms > into the protocol in an optional TLV/encapsulation header or use > protocols such as TIPC to provide this functionality. In any case, it > will be useful to have a separate section/draft which will address these > mappings (similar to GSMP/GRMP, etc) Lets not rush into separating them for now. To be honest there is no one transport that can satisfy all the needs thats why we need all those connections. Hence the idea of a transport abstraction is sane. If we leave say the responsibility of conegstion control, reliability, security, avaliability to this abstraction layer we can make good progress. [HK] Agreed, I like the idea of Transport Abstraction as well. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 03:17:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21795 for ; Fri, 19 Mar 2004 03:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4FBa-0005LI-UK for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 03:16:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J8Gwhb020530 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 03:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4FBa-0005L3-E1 for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 03:16:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21774 for ; Fri, 19 Mar 2004 03:16:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4FBY-0005IV-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 03:16:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4FAa-0005EF-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 03:15:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4F9g-0005AB-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 03:15:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F9h-0005Ct-Q4; Fri, 19 Mar 2004 03:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F97-0005Be-IH for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 03:14:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21683 for ; Fri, 19 Mar 2004 03:14:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4F95-00056d-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 03:14:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4F8N-00050g-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 03:13:40 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4F7a-0004pA-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 03:12:50 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2J8EXt7013560; Fri, 19 Mar 2004 08:14:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2J85qCI014746; Fri, 19 Mar 2004 08:05:54 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031900121600452 ; Fri, 19 Mar 2004 00:12:16 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 00:12:16 -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 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Message-ID: <468F3FDA28AA87429AD807992E22D07E37849F@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQNU8+RcyvvA8uoTPqZPuy3Tp1R5wANWYbw From: "Khosravi, Hormuzd M" To: "Jon Maloy" , "Putzolu, David" Cc: X-OriginalArrivalTime: 19 Mar 2004 08:12:16.0282 (UTC) FILETIME=[E42977A0:01C40D89] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 00:12:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jon, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jon Maloy With TIPC, it will somewhat reduce the flexibility of the port name sequence concept, which makes it possible for the CE:s to define "multicast groups for the occasion", but it should be easily mappable to a more static multicast group concept, if this is sufficient. As David stated, the TML layer for L2 would be virtually empty if mapped down to TIPC, and would give us an early available implementation of ForCES over L2. Speaking from experience, implementing a stable and performant transport layer with retransmission, node- and process supervision, media load sharing and failover etc, not=20 to speak about reliable multicast, is far from trivial, and we may risk to never see such a protocol come into existence =3D> we would be confined to TCP, SCTP and the properties those protocols can offer. [HK] Agree, I think it would be a good idea to use TIPC in the non-IP case, running ForCES over L2. It will take care of a lot of issues that you have pointed out and help us concentrate our energies on designing at the PL rather than TML. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 07:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28877 for ; Fri, 19 Mar 2004 07:24:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4J2j-0005K3-SE for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JCO5Zu020455 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4J2j-0005Jq-KY for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 07:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28837 for ; Fri, 19 Mar 2004 07:24:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4J2j-0002dY-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:24:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4J1h-0002ZU-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:23:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4J0j-0002Tw-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4J0j-0005EU-0k; Fri, 19 Mar 2004 07:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4J05-0005DC-12 for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 07:21:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28770 for ; Fri, 19 Mar 2004 07:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4J04-0002Q2-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:21:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4IzB-0002KR-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:20:28 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4IyH-0002F6-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:19:29 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031904215192:8750 ; Fri, 19 Mar 2004 04:21:51 -0800 Subject: RE: [Forces-protocol] Issue 4&5: Congestion control, DoSprotection, and Reliability From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E37849E@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E37849E@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079698757.1045.196.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 03/19/2004 04:21:52 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 04:21:54 AM, Serialize complete at 03/19/2004 04:21:54 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 07:19:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hormuzd, On Fri, 2004-03-19 at 02:54, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] [..] > [HK] We do need an asynchronous notification message to report some > event like this. However, it should be triggered by the FE and not the > protocol. Do you agree ? I am begginging to worry that this is going to get very complex in order to reach a middle ground;-< I think we need a class of messages under the banner of "Forces Control" messages within the protocol where this will fit in; this is in the same vein as ICMP is the IP control protocol. I dont think we need an extra protocol such as ICMP. Message should be able to come from either FE or CE. Coming from the FE should be to tell the CE whats going on and have it make a call. Coming from an CE i would think is for a policy installation to mitigate a congestion problem at either CE or FE. There is an ICMP message (currently deprecated) called Source Quench which is sent when an IP node is overwhelmed such as when its queues are getting overloaded. We could adopt something along the same lines. We just need to have more than one reason for why a node is getting overwhelmed and maybe when possible have the message define a course of action. Note again, I am trying to reach a middle ground so we can move on. > > #5- Reliability: > 1) Message is delivered with integrity. > This means the mesage is delivered identical to what was sent. > Additionaly only _one_ copy is delivered. > [HK] What about in order delivery ? I think this is also covered by this > point but just wanted to confirm. Good catch: Ordering is typically not defined in reliability. You could have reliable protocols which deliver unordered messages eg SCTP provides such an option. Note however: Since we are looking at this at the Forces level, the message becomes a complete Force message then ordering is implied. This is actually the reason i posed the question to David on his diagram on whether the TML->PL is serialized in terms of message delivery. We could have ordering as a separate topic or we could assume the above. > 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. > [HK] Agreed, here is where a protocol level response or ack is useful. Yes, the sender needs to be provided with assurances that the message made it, and that it made it fine within a valid time. So Forces level ACKs, checksum and timeout would be the right things to have. > > The second question is whether the Reliability/CC mechanisms should be > > built into the protocol or reused from existing transports ? There are > a > > couple of cases here and the answer would depend on the case... > > 1. ForCES over IP: We can easily reuse existing Transports such as > > TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the > > protocol simple and don't spend our energies in re-inventing the > wheel. > > Note that even when you use TCP or SCTP the reliability is to be defined > at the application/ForCES layer. Reusing above transports should help. > [HK] The only other thing needed is protocol level Response or ACK. Is > this what you mean ? and checksums; i think timeouts may need to explicitly be called in the text but we could leave that to the TML. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 07:34:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29230 for ; Fri, 19 Mar 2004 07:34:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JBz-0005eL-3a for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:33:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JCXdGJ021710 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:33:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JBy-0005e5-TY for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 07:33:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29219 for ; Fri, 19 Mar 2004 07:33:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JBy-0003Oe-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:33:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JBB-0003K8-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:32:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4JAO-0003F1-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JAO-0005XQ-F6; Fri, 19 Mar 2004 07:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4J9u-0005X0-26 for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 07:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29107 for ; Fri, 19 Mar 2004 07:31:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4J9t-0003CS-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:31:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4J8i-00036H-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:30:19 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4J7y-00031M-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:29:30 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031904315374:8752 ; Fri, 19 Mar 2004 04:31:53 -0800 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Jon Maloy , "Putzolu, David" , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E37849F@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E37849F@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079699360.1041.207.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 03/19/2004 04:31:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 04:31:55 AM, Serialize complete at 03/19/2004 04:31:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 07:29:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-19 at 03:12, Khosravi, Hormuzd M wrote: > [HK] Agree, I think it would be a good idea to use TIPC in the non-IP > case, running ForCES over L2. It will take care of a lot of issues that > you have pointed out and help us concentrate our energies on designing > at the PL rather than TML. I think TIPC should be one of the TML but not the only TML for L2 - so lets not rush to making this judgement. I know i will implement over TIPC (as one of n TMLs). The abstraction layer provides us opportunities, so lets not kill those. Example, I have customers who think that they have the greatest clustering protocol invented and with the abstraction layer i can now tell them what API i need provided to the PL level. As long as their TML runs within their NEs this should be fine in my opinion. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 07:40:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29413 for ; Fri, 19 Mar 2004 07:40:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JIK-00068b-6P for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JCeBUI023576 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 07:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JII-00068B-VE for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 07:40:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29410 for ; Fri, 19 Mar 2004 07:40:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JII-0003ov-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:40:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JHO-0003m4-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:39:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4JHA-0003j2-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JHA-00065H-SW; Fri, 19 Mar 2004 07:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JGP-00064B-EG for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 07:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29367 for ; Fri, 19 Mar 2004 07:38:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JGO-0003hy-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:38:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JFd-0003eG-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:37:28 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4JES-0003aD-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:36:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031904383581:8757 ; Fri, 19 Mar 2004 04:38:35 -0800 Subject: Good reference: for [Forces-protocol] Issue 4&5: Congestion control, DoSprotection, and Reliability From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <1079698757.1045.196.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E37849E@orsmsx408.jf.intel.com> <1079698757.1045.196.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1079699768.1042.213.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 03/19/2004 04:38:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 04:38:37 AM, Serialize complete at 03/19/2004 04:38:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 07:36:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-19 at 07:19, Jamal Hadi Salim wrote: > Hi Hormuzd, > > > > #5- Reliability: A friend of mine sent me a very good URL which talks about this topic in a slightly different context. http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0164.html cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 08:01:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01279 for ; Fri, 19 Mar 2004 08:01:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JcP-0006to-6J for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 08:00:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JD0vmK026515 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 08:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JcO-0006tW-Tl for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 08:00:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01225 for ; Fri, 19 Mar 2004 08:00:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JP2-0004N9-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:47:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JNy-0004H8-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:46:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4JMz-0004Bf-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 07:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JMz-0006I0-P3; Fri, 19 Mar 2004 07:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JMH-0006Ei-O8 for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 07:44:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29565 for ; Fri, 19 Mar 2004 07:44:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JMG-000490-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:44:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JLL-00043J-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:43:22 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4JKJ-0003y8-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 07:42:15 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031904443853:8762 ; Fri, 19 Mar 2004 04:44:38 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org In-Reply-To: <1078753355.1036.426.camel@jzny.localdomain> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1079700131.1044.219.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 03/19/2004 04:44:38 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 04:44:39 AM, Serialize complete at 03/19/2004 04:44:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Re: Issues list Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 07:42:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Last day before a response is due to the WG. I think we made some great progress and i have no doubt givent the current atmosphere consensus will be reached. Do we have to give a detailed response to the WG or can we just say "consensus for a merger has been reached"? cheers, jamal On Mon, 2004-03-08 at 08:42, Jamal Hadi Salim wrote: > 0) ID on the header. > 1) Encoding > 2) Multiple channels/connections > 3) Transport: unicast/multicast/broadcast > { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} > 4) Congestion control > 5) Reliability > 6) Security > 7) High availability > 8) Capability exchange > 9) The FEM/CEM interface > 10) Support for vendor functions > 11) Cross check with model draft before it is published > 12) Master Slave or peer-peer? > > I personally dont think we should care what the model or > requirements draft says. What we want to have is a good > protocol (as an example there are a few issues not mentioned > in the requirements already on the list above). > For this reason i feel like scratching issue 11 from the list. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 08:34:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02553 for ; Fri, 19 Mar 2004 08:34:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4K8k-0000kI-SI for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 08:34:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JDYMdi002863 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 08:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4K8k-0000k6-K0 for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 08:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02528 for ; Fri, 19 Mar 2004 08:34:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4K8j-0000J5-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 08:34:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4K7x-0000FZ-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 08:33:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4K7Q-0000Bk-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 08:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4K7R-0000fO-C4; Fri, 19 Mar 2004 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4K6X-0000di-2A for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 08:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02468 for ; Fri, 19 Mar 2004 08:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4K6V-00009l-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 08:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4K5X-00004x-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 08:31:06 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4K4U-0007m4-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 08:30:09 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 19 Mar 2004 21:41:20 +0800 Message-ID: <189201c40db5$e9d81270$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E37849E@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoSprotection, and Reliability 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 21:27:23 +0800 Hi Jamal, Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > #4- Congestion Control: > Congestion control is important for the ForCES protocol in order to meet > the Scalability requirements. As we start going from 10s of FEs to 100s > and even thousands of FEs, we will need to have congestion control > mechanisms in the protocol. There was a general agreement on this topic > on the ForCES mailing list, when we had the discussion around multicast. > I think we should separate the discussion around Congestion Control from > the DoS protection discussion. I think that congestion control MUST be met. Perhaps we should look at some of the ideas of DCCP for pluggable congestion algorithms. I think i have an idea on how to resolve Weimings thoughts on DOS protection: If we look at DOS indicator as an explicit congestion notification, then we could squeeze it under those auspicies. Ability to provide intelligent explicit feedback for congestion control would be useful in general. Of course DOS being one item of a bigger set of issues that create congestion. [Weiming] Absolutely. I am not sure i like the way GRMP is doing it, but i also think we should be able to satisfy this desire under the auspicies of Explicit Congestion notification. [HK] We do need an asynchronous notification message to report some event like this. However, it should be triggered by the FE and not the protocol. Do you agree ? [Weiming] Yes, a rate limiting like LFB should be used to detect as well as to limit the D packet stream. But two reasons that make me believe we should have it defined in the protocol scope: 1) To decide if there is a congestion or a DoS on D packet stream is also highly related to C packet stream status. That is, even if someone is actually making an attack, but before it has threatened the C packet stream with a danger of congestion, it may not be considered a DoS attack, and we'd better not to start the rate limiting for D packet stream. This means a DoS or congestion event report is better to be generated by detecting the status of C stream instead of D stream. 2) DoS and Congestion control should be considered as a MUST item. If we leave it defined by use of LFB, we actually make it a kind of optional and vendor-specific item. This has also made the interoperability regarding the DoS and congestion mechanism very bad. But anyway, to see the neccessary of such a congestion notification ( alert) is the main purpose for our discussion. We may leave how to implement it to later discussion. > > #5- Reliability: > Couple of questions need to be answered here... > What exactly does everyone mean by Reliability ? Do they mean 'strict > reliability' as defined in the Requirements ? I assume the answer is yes > to this one, but just want to clarify it. I am always thinking of the academic definition. Sorry, I had to cutnpaste from an old posting i made. 1) Message is delivered with integrity. This means the mesage is delivered identical to what was sent. Additionaly only _one_ copy is delivered. [HK] What about in order delivery ? I think this is also covered by this point but just wanted to confirm. 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. [HK] Agreed, here is where a protocol level response or ack is useful. > The second question is whether the Reliability/CC mechanisms should be > built into the protocol or reused from existing transports ? There are a > couple of cases here and the answer would depend on the case... > 1. ForCES over IP: We can easily reuse existing Transports such as > TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the > protocol simple and don't spend our energies in re-inventing the wheel. Note that even when you use TCP or SCTP the reliability is to be defined at the application/ForCES layer. Reusing above transports should help. [HK] The only other thing needed is protocol level Response or ACK. Is this what you mean ? > 2. ForCES over L2: Here we could either build reliability mechanisms > into the protocol in an optional TLV/encapsulation header or use > protocols such as TIPC to provide this functionality. In any case, it > will be useful to have a separate section/draft which will address these > mappings (similar to GSMP/GRMP, etc) Lets not rush into separating them for now. To be honest there is no one transport that can satisfy all the needs thats why we need all those connections. Hence the idea of a transport abstraction is sane. If we leave say the responsibility of conegstion control, reliability, security, avaliability to this abstraction layer we can make good progress. [HK] Agreed, I like the idea of Transport Abstraction as well. [Weiming] Me too. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 09:56:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05929 for ; Fri, 19 Mar 2004 09:56:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LQ4-0006KX-Lc for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 09:56:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JEuK9u024332 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 09:56:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LQ4-0006KN-H3 for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 09:56:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05924 for ; Fri, 19 Mar 2004 09:56:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LQ2-0007Ah-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 09:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LPX-000771-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 09:55:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4LOm-000726-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 09:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LOn-0006I2-N0; Fri, 19 Mar 2004 09:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LO1-0006HE-0x for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 09:54:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05829 for ; Fri, 19 Mar 2004 09:54:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LNz-0006zm-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 09:54:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LN3-0006vP-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 09:53:16 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4LMA-0006mn-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 09:52:19 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 19 Mar 2004 23:03:29 +0800 Message-ID: <18c801c40dc1$63fb0160$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 22:49:32 +0800 Hi David, From the GRMP design idea, we can not agree on the idea of PL and TML any more. Of course, we need to have much more discussions on kinds of TML specifications. Just one comment put inline. Thank you. Weiming ----- Original Message ----- From: "Putzolu, David" Hi all. Just a small clarification on the reliability and congestion control discussion based on what several ADs told me in Korea in no uncertain terms. Any IP-based implementation of ForCES will be forced to use a RFC2914-compliant transport for all its packets. That pretty much disallows use of UDP at all in the ForCESoverIP case and leaves TCP, SCTP, and possible RMT as the only transports ForCES can use over IP. Both myself and Jon Maloy pushed back on this, saying that one might want to use UDP in a purely local scenario for various reasons. The ADs where adamant, arguing that one can never guarantee that IP will stay local, and the IETF would not standardize using a non-2914 compliant IP protocol (e.g. UDP). The ADs pointed to iSCSI as a precedent. [Weiming] I just presumptously wonder if iSCSI might have some speed improvement when a UDP+built-in reliability scheme were also adpoted. This isn't to say that multicast cannot be used - I am a fan of the transport abstraction approach that says that the ForCES protocol will just assume it has a multicast transport and a unicast transport, and that the transport layer mapping ala GSMP will take care of it. Below is a URL to some text and drawings based on Alex and other's comments - what do you think? Is this an acceptable solution to transport/multicast/unicast/ retransmit/etc.? http://www.sstanamera.com/~forces/proto/ForCESLayered.htm -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 10:07:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06622 for ; Fri, 19 Mar 2004 10:07:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Lad-0001ba-KR for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 10:07:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JF7FZk006156 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 10:07:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Lad-0001bD-3U for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 10:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06576 for ; Fri, 19 Mar 2004 10:07:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Lab-0000B6-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:07:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LZq-000072-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:06:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4LZQ-00003B-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LZS-0001E8-13; Fri, 19 Mar 2004 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LYc-00010p-BH for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 10:05:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06340 for ; Fri, 19 Mar 2004 10:05:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LYa-00000m-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:05:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LXn-0007kK-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:04:22 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4LWq-0007g5-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:03:20 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Fri, 19 Mar 2004 23:14:52 +0800 Message-ID: <18d301c40dc2$fb78c8f0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> <1079700131.1044.219.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: Issues list 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 23:00:56 +0800 I suggest first try to just say it, then if there are several differences, we may need to go to details to judge it. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > Last day before a response is due to the WG. > I think we made some great progress and i have no doubt givent the > current atmosphere consensus will be reached. > Do we have to give a detailed response to the WG or can we > just say "consensus for a merger has been reached"? > > cheers, > jamal > > On Mon, 2004-03-08 at 08:42, Jamal Hadi Salim wrote: > > > 0) ID on the header. > > 1) Encoding > > 2) Multiple channels/connections > > 3) Transport: unicast/multicast/broadcast > > { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} > > 4) Congestion control > > 5) Reliability > > 6) Security > > 7) High availability > > 8) Capability exchange > > 9) The FEM/CEM interface > > 10) Support for vendor functions > > 11) Cross check with model draft before it is published > > 12) Master Slave or peer-peer? > > > > I personally dont think we should care what the model or > > requirements draft says. What we want to have is a good > > protocol (as an example there are a few issues not mentioned > > in the requirements already on the list above). > > For this reason i feel like scratching issue 11 from the list. > > > > cheers, > > jamal > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 10:49:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08936 for ; Fri, 19 Mar 2004 10:49:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MFF-0007qG-3N for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 10:49:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JFnDU4030141 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 10:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MFE-0007q3-Mb for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 10:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08923 for ; Fri, 19 Mar 2004 10:49:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MFC-00042Z-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:49:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MEG-0003wL-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:48:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4MD5-0003mj-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 10:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MD7-0007ab-2l; Fri, 19 Mar 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MCP-0007a2-Hm for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 10:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08852 for ; Fri, 19 Mar 2004 10:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MCN-0003k1-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:46:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MBO-0003e9-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:45:17 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4MAW-0003Yo-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 10:44:21 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031907464370:8892 ; Fri, 19 Mar 2004 07:46:43 -0800 Subject: Re: [Forces-protocol] Re: Issues list From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <18d301c40dc2$fb78c8f0$845c21d2@Necom.hzic.edu.cn> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> <1079700131.1044.219.camel@jzny.localdomain> <18d301c40dc2$fb78c8f0$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1079711057.1032.55.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 03/19/2004 07:46:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 07:46:45 AM, Serialize complete at 03/19/2004 07:46:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 10:44:17 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-19 at 10:00, Wang,Weiming wrote: > I suggest first try to just say it, then if there are several differences, we > may need to go to details to judge it. This is also my line of thinking. No point in being too verbose especially if we are still disecting things. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 11:04:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09444 for ; Fri, 19 Mar 2004 11:04:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MTm-0008V4-BB for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:04:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JG4E3f032674 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:04:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MTl-0008Ut-ON for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:04:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09435 for ; Fri, 19 Mar 2004 11:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MTj-0005BO-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MSy-00058D-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:03:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4MSZ-00054Z-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MSa-0008TT-Uj; Fri, 19 Mar 2004 11:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MRn-0008Pu-4S for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 11:02:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09350 for ; Fri, 19 Mar 2004 11:02:07 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MRk-00053B-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MQm-0004yf-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:01:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4MPo-0004uK-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:00:08 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4MPn-0006N4-Fk for forces-protocol@ietf.org; Fri, 19 Mar 2004 16:00:07 +0000 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <1079711057.1032.55.camel@jzny.localdomain> References: <9B3E0FAE-70F2-11D8-B109-000393CC2112@acm.org> <1078753355.1036.426.camel@jzny.localdomain> <1079700131.1044.219.camel@jzny.localdomain> <18d301c40dc2$fb78c8f0$845c21d2@Necom.hzic.edu.cn> <1079711057.1032.55.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B3E7764-79BE-11D8-BC30-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: Issues list To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Mar 2004 01:00:02 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think it may be worth saying that the groups believes it can reach a merge (assuming everyone in the team thinks so and is willing) and then following up with a report of where consensus is being reached and where there are open issues. Could be good to see some discussion of some of the thornier issues on the full list. And then of course there is the issue of figuring out how to do the merge and then doing it. a. On 20 mar 2004, at 00.44, Jamal Hadi Salim wrote: > On Fri, 2004-03-19 at 10:00, Wang,Weiming wrote: >> I suggest first try to just say it, then if there are several >> differences, we >> may need to go to details to judge it. > > This is also my line of thinking. No point in being too verbose > especially if we are still disecting things. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 11:28:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10339 for ; Fri, 19 Mar 2004 11:28:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mr5-00026i-1W for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:28:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JGSIcP008097 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:28:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mr4-00026V-6j for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:28:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10311 for ; Fri, 19 Mar 2004 11:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Mr3-0007S6-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MqD-0007N5-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:27:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4MpS-0007HI-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:26:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MpI-0001lZ-Sc; Fri, 19 Mar 2004 11:26:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mo9-0001i8-LD for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 11:25:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10243 for ; Fri, 19 Mar 2004 11:25:15 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Mo8-00078V-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MnJ-00072T-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:24:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4MmT-0006vV-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:23:33 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4MmU-0003qT-4S for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:23:34 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 20 Mar 2004 00:34:22 +0800 Received: from 219.82.170.228 ( [219.82.170.228]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 20 Mar 2004 00:34:22 +0800 Message-ID: <1079714062.405b21221a4fa@mail.hzic.edu.cn> To: david.putzolu@intel.com Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Mar 2004 00:34:22 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit So sorry for the mistake. We just definitely agree on it. Thank you very much. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Wang,Weiming" Sent: Friday, March 19, 2004 11:49 PM Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES > Weiming, > > On Fri, 2004-03-19 at 09:49, Wang,Weiming wrote: > > Hi David, > > > > From the GRMP design idea, we can not agree on the idea of PL and TML any more. > > Did you mean you agree with need for TML or not? > Is this a typo? > > cheers, > jamal > > > ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 11:44:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10803 for ; Fri, 19 Mar 2004 11:44:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4N6Y-0006Ei-Pf for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:44:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JGiISd023972 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 11:44:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4N6X-0006EO-6I for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:44:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10791 for ; Fri, 19 Mar 2004 11:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4N6W-00012m-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:44:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4N5i-0000yy-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:43:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4N5I-0000ud-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 11:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4N5I-000694-Pc; Fri, 19 Mar 2004 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4N4W-00064N-Ka for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 11:42:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10734 for ; Fri, 19 Mar 2004 11:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4N4V-0000s5-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4N3Y-0000mo-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:41:13 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4N2j-0000eL-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 11:40:21 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JGfnt7004041; Fri, 19 Mar 2004 16:41:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JGWQCW012649; Fri, 19 Mar 2004 16:33:08 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031908392920759 ; Fri, 19 Mar 2004 08:39:29 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 08:39:30 -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 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES Message-ID: <52D13A805349A249960B9943E5590BD802B2CF7E@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQNWoIRZip6wEKfQfK0S0lrsNWsZAAdUQsQ From: "Putzolu, David" To: Cc: X-OriginalArrivalTime: 19 Mar 2004 16:39:30.0089 (UTC) FILETIME=[C01FE190:01C40DD0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 08:39:29 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jamal - response inline. Jamal wrote > > huh? DCCP aka UDP with CC built in? We could select > different CC algos depending on the scope being used. I think the ADs would be fine with DCCP - but I confess that I don't know how well DCCP can be used with multicast transports. Jamal wrote > > Is there a draft/RFC which talks transport layer mapping=20 > at GSMP level? Avri is the expert, I'll defer to her :) Jamal wrote > > From the outset it does look reasonable. I am assuming that > the TML serializes the data to the Forces PL? The abstract TML provides some defined level of service. I am pretty sure the abstract TML needs to provide a service where at least one wire that serializes data (don't=20 want overlapping add routes or worse ACL entries reordered). =20 Whether all TML wires need to be ordered would be up to the=20 team to decide - what is the minimum good tranport service=20 desired at the ForCES protocol layer? The TML implementations would need to provide the requested level of service. Some might be overachievers, i.e. the abstract TML might provide guaranteed ordered wires and wires that do not guarantee ordering. If the IP TML team where to decide to use TCP for all wires, then the IP TML would provide every wire ordered (exceeding the requested level of service). The key is every TML implementation has to at least meet the expected level of service. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 14:19:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16674 for ; Fri, 19 Mar 2004 14:19:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PWa-0007dM-9J for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:19:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJJKa4029342 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PWa-0007dB-3f for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16669 for ; Fri, 19 Mar 2004 14:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PWX-0006zp-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:19:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PVf-0006wI-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:18:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4PVG-0006s8-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PVI-0007Wy-OW; Fri, 19 Mar 2004 14:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4PUc-0007V6-Mb for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 14:17:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16545 for ; Fri, 19 Mar 2004 14:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PUa-0006pg-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:17:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PTa-0006ip-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:16:15 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4PSd-0006a1-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:15:15 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JJGqt7006448; Fri, 19 Mar 2004 19:16:53 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JJFtSl009807; Fri, 19 Mar 2004 19:16:38 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031911143522468 ; Fri, 19 Mar 2004 11:14:35 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 11:14:35 -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 Subject: RE: [Forces-protocol] Re: Issues list Message-ID: <468F3FDA28AA87429AD807992E22D07E3FE55D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Re: Issues list Thread-Index: AcQNy654R08t2WZ8QuCLP/G3Z6rSVwAGkn+A From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 19 Mar 2004 19:14:35.0534 (UTC) FILETIME=[6A9A1AE0:01C40DE6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 11:14:34 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree, it will be good to send out a summary. I am working on some text and will forward it to all of you for review shortly.=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Friday, March 19, 2004 8:00 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Re: Issues list I think it may be worth saying that the groups believes it can reach a=20 merge (assuming everyone in the team thinks so and is willing) and then=20 following up with a report of where consensus is being reached and=20 where there are open issues. Could be good to see some discussion of=20 some of the thornier issues on the full list. And then of course there is the issue of figuring out how to do the=20 merge and then doing it. a. On 20 mar 2004, at 00.44, Jamal Hadi Salim wrote: > On Fri, 2004-03-19 at 10:00, Wang,Weiming wrote: >> I suggest first try to just say it, then if there are several=20 >> differences, we >> may need to go to details to judge it. > > This is also my line of thinking. No point in being too verbose > especially if we are still disecting things. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 14:40:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18005 for ; Fri, 19 Mar 2004 14:40:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pr4-00015z-4z for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:40:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJeTDn004205 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:40:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pr3-00015k-No for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:40:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17958 for ; Fri, 19 Mar 2004 14:40:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pr1-0001Tw-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:40:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PqA-0001OZ-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:39:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ppb-0001Iq-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ppd-0000z9-9w; Fri, 19 Mar 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pp0-0000rB-MW for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 14:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17849 for ; Fri, 19 Mar 2004 14:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pox-0001F3-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Po8-00019r-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:37:29 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1B4PnV-00011z-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:36:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2JJaI8d013038; Fri, 19 Mar 2004 13:36:18 -0600 (CST) Message-ID: <405B4BB1.7080309@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Putzolu, David" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES References: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> In-Reply-To: <52D13A805349A249960B9943E5590BD802B2CD94@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 13:36:17 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The PL over TML is a workable model. My concern is the wire concept plays well with TCP, but I am not sure it does so with SCTP. I suggest we use streams instead. Also, the liveness checking by TML can only guarrantee the TML->transport->peerTML connectivity. To make sure PL is in the loop, PL should have its own scheme (e.g. ACKs, heartbeat,..). That checks the PL->TML->transport->peerTML->peerPL connectivity. This helps ensure the PL is not off in the weeds or removed or crashed while the transport is fine. It also helps problem isolation. It should be noted also that: 1) the burden rests on TML to implement some reliability scheme in case of unreliable transport. This is a tall order. It amounts to re-inventing TCP on this layer. 2) There is something called IPover Ethernet (IPoE),..and this may be leveraged here. It will save us from running directly over ethernet. Regards, Alex. Putzolu, David wrote: >Hi all. > >Just a small clarification on the reliability and >congestion control discussion based on what several >ADs told me in Korea in no uncertain terms. > >Any IP-based implementation of ForCES will be forced >to use a RFC2914-compliant transport for all its >packets. That pretty much disallows use of UDP at >all in the ForCESoverIP case and leaves TCP, SCTP, >and possible RMT as the only transports ForCES can >use over IP. > >Both myself and Jon Maloy pushed back on this, saying >that one might want to use UDP in a purely local >scenario for various reasons. The ADs where adamant, >arguing that one can never guarantee that IP will >stay local, and the IETF would not standardize >using a non-2914 compliant IP protocol (e.g. UDP). >The ADs pointed to iSCSI as a precedent. > >This isn't to say that multicast cannot be used - I >am a fan of the transport abstraction approach that >says that the ForCES protocol will just assume it has >a multicast transport and a unicast transport, and >that the transport layer mapping ala GSMP will take >care of it. > >Below is a URL to some text and drawings based on Alex >and other's comments - what do you think? Is this an >acceptable solution to transport/multicast/unicast/ >retransmit/etc.? > >http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > >-David > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 14:41:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18048 for ; Fri, 19 Mar 2004 14:41:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ps0-00019F-5F for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:41:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JJfSgH004407 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 14:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Prz-000190-SG for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 14:41:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18044 for ; Fri, 19 Mar 2004 14:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Prx-0001ZO-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PrA-0001VD-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:40:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pqa-0001Pb-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 14:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pqb-00014s-Vw; Fri, 19 Mar 2004 14:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pq0-00010p-JN for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 14:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17901 for ; Fri, 19 Mar 2004 14:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ppx-0001Md-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PpB-0001Gh-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:38:33 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4PoY-00019C-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 14:37:54 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JJfEJ2021127 for ; Fri, 19 Mar 2004 19:41:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JJawTx021489 for ; Fri, 19 Mar 2004 19:39:15 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031911371226118 for ; Fri, 19 Mar 2004 11:37:12 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 11:37: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 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Message-ID: <468F3FDA28AA87429AD807992E22D07E3FE5B3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQNQWYF9ihaGwoFTveha9d0a/FzggAQYe2g From: "Khosravi, Hormuzd M" To: "Putzolu, David" , X-OriginalArrivalTime: 19 Mar 2004 19:37:12.0667 (UTC) FILETIME=[93842AB0:01C40DE9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 11:37:12 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi David Thanks for this clarification. It is very helpful to bring us back on track. I think it's a good idea to use existing transports like TCP, SCTP with IP and define our mappings in the non-IP case via TML. This way we can have an easy interop over IP and also optimize for local case, by running ForCES directly over TIPC/L2, etc. Also, I looked at the URL below and agree with Jon and Jamal...it looks very good. I like the idea of TML as well. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Thursday, March 18, 2004 3:33 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Hi all. Just a small clarification on the reliability and congestion control discussion based on what several ADs told me in Korea in no uncertain terms. Any IP-based implementation of ForCES will be forced=20 to use a RFC2914-compliant transport for all its=20 packets. That pretty much disallows use of UDP at=20 all in the ForCESoverIP case and leaves TCP, SCTP, and possible RMT as the only transports ForCES can use over IP. Both myself and Jon Maloy pushed back on this, saying that one might want to use UDP in a purely local scenario for various reasons. The ADs where adamant, arguing that one can never guarantee that IP will stay local, and the IETF would not standardize=20 using a non-2914 compliant IP protocol (e.g. UDP). The ADs pointed to iSCSI as a precedent. This isn't to say that multicast cannot be used - I am a fan of the transport abstraction approach that says that the ForCES protocol will just assume it has a multicast transport and a unicast transport, and that the transport layer mapping ala GSMP will take care of it. Below is a URL to some text and drawings based on Alex=20 and other's comments - what do you think? Is this an acceptable solution to transport/multicast/unicast/ retransmit/etc.? http://www.sstanamera.com/~forces/proto/ForCESLayered.htm -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 15:06:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19178 for ; Fri, 19 Mar 2004 15:06:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QG7-0008Tq-TZ for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 15:06:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JK6NG7032594 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 15:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QG7-0008Td-BS for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 15:06:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19132 for ; Fri, 19 Mar 2004 15:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4QG4-0003lf-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 15:06:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4QF9-0003hf-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 15:05:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4QEk-0003db-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 15:04:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QEm-0007mz-Rj; Fri, 19 Mar 2004 15:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4QE7-0007SA-0Y for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 15:04:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18940 for ; Fri, 19 Mar 2004 15:04:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4QE4-0003bk-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 15:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4QD5-0003Xl-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 15:03:16 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1B4QC7-0003Q1-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 15:02:15 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2JK1h8d018185; Fri, 19 Mar 2004 14:01:44 -0600 (CST) Message-ID: <405B51A6.2020302@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability References: <1079625963.4059c8fe38183@mail.hzic.edu.cn> <4059EEBD.2090001@alcatel.com> <181c01c40d86$01d34be0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <181c01c40d86$01d34be0$845c21d2@Necom.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------010306090104000209010405" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 14:01:42 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------010306090104000209010405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Weiming, That is good, but what I am saying is, you can't make a general characterization that every high resource usage is a DOS scenario. It may just be that the FE is just being overloaded with good traffic. Cheers, Alex. Wang,Weiming wrote: >Hello Alex, > >I think what you said is exactly what I meant. That is, something like 'DoS >Alert Policy' as called in GRMP should be used to determine when a DoS is >considered and an alert event is sent from FE to CE. Actually I don't think to >manage this policy is outside the scope of ForCES, it can surely be set up as a >kind of FE attribute to FE by CE. And moreover, I'm afraid a pure resource usage >status report is not enough for DoS alert purpose. > >On the other hand, I have to say what set in current GRMP for 'DoS alert policy' >seems a little naive. We need improvement on this, that is, to find a better and >more efficient description for the policy. > >Thank you. > >Weiming > >----- Original Message ----- >From: "Alex Audu" >To: >Cc: >Sent: Friday, March 19, 2004 2:47 AM >Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, >and Reliability > > > > >>Hello Weiming, >> >>I don't think it is possible for us to come up with a mechanism to >>determine if an FE is being >>DOS'd. The final determination of that may depend on situation at hand, >>since attack >>signatures are typically different for different DOS attacks. I think >>the final decision as to >>if a DOS is really occuring is best left to policy on the NE. This is >>outside ForCES scope. >>But we can have FE report resource usage status to CE. I think FACT >>already has >>such report. >> >>Regards, >>Alex. >> >> >> > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > --------------010306090104000209010405 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Weiming,

That is good, but what I am saying is, you can't make a general characterization that
every high resource usage is a DOS scenario. It may just be that the FE is just being
overloaded with good traffic.

Cheers,
Alex.

Wang,Weiming wrote:
Hello Alex,

I think what you said is exactly what I meant. That is, something like 'DoS
Alert Policy' as called in GRMP should be used to determine when a DoS is
considered and an alert event is sent from FE to CE. Actually I don't think to
manage this policy is outside the scope of ForCES, it can surely be set up as a
kind of FE attribute to FE by CE. And moreover, I'm afraid a pure resource usage
status report is not enough for DoS alert purpose.

On the other hand, I have to say what set in current GRMP for 'DoS alert policy'
seems a little naive. We need improvement on this, that is, to find a better and
more efficient description for the policy.

Thank you.

Weiming

----- Original Message -----
From: "Alex Audu" <alex.audu@alcatel.com>
To: <wmwang@mail.hzic.edu.cn>
Cc: <forces-protocol@ietf.org>
Sent: Friday, March 19, 2004 2:47 AM
Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection,
and Reliability


  
Hello Weiming,

I don't think it is possible for us to come up with a mechanism to
determine if an FE is being
DOS'd. The final determination of that may depend on situation at hand,
since attack
signatures are typically different for different DOS attacks. I think
the final decision as to
if a DOS is really occuring is best left to policy on the NE. This is
outside ForCES scope.
But we can have FE report resource usage status to CE. I think FACT
already has
such report.

Regards,
Alex.

    



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
--------------010306090104000209010405-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 16:44:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25936 for ; Fri, 19 Mar 2004 16:44:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmE-0002zr-Pp for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLhcAj011513 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmE-0002zc-GH for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:43:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25806 for ; Fri, 19 Mar 2004 16:43:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RmC-0006PW-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 16:43:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RlE-0006D7-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 16:42:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4RkV-00066R-02 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 16:41:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4Rik-00082X-7n for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 16:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rij-0002ez-TJ; Fri, 19 Mar 2004 16:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ri7-0002Yg-Ix for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 16:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25695 for ; Fri, 19 Mar 2004 16:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ri5-0005uq-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 16:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RhA-0005qy-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 16:38:24 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Rgf-0005mt-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 16:37:53 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JLfMJ2007167; Fri, 19 Mar 2004 21:41:22 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JLcBSv030679; Fri, 19 Mar 2004 21:39:22 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031913371911773 ; Fri, 19 Mar 2004 13:37:19 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 13:37:19 -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 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Message-ID: <52D13A805349A249960B9943E5590BD802B2D19D@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQN6YeBHtGKlqjtT4+Ht5JXNrssFAAD72jw From: "Putzolu, David" To: Cc: X-OriginalArrivalTime: 19 Mar 2004 21:37:19.0681 (UTC) FILETIME=[5B3B3B10:01C40DFA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 13:37:19 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alex - my response inline. Alex wrote> > The PL over TML is a workable model. My concern is the wire concept=20 > plays well with TCP, but I am not sure it does so with SCTP. I suggest we=20 > use streams instead. I was using wire as a virtual connection of sorts with certain levels of service associated with it. The underlying TML could then be defined to use SCTP streams for different wires maybe? However, main point is to first define the services the FP layer needs from the abstract TML, then each TML spec would decide how to achieve those services. TCP was just an example of what the IP TML might choose, SCTP is definitely another alternative. Alex wrote> > Also, the liveness checking by TML can only guarrantee the=20 > TML->transport->peerTML connectivity. To make sure PL is=20 > in the loop, PL should have its own scheme (e.g. ACKs, > heartbeat,..). That checks the PL->TML->transport->peerTML->peerPL=20 > connectivity. This helps ensure the PL is not off in the weeds or removed=20 > or crashed while the transport is fine. It also helps problem isolation. Having a PL <-> PL heartbeat, to make sure the PL is alive, makes sense. I agree that this is separate from TML liveness. > It should be noted also that: > 1) the burden rests on TML to implement some reliability=20 > scheme in case of unreliable > transport. This is a tall order. It amounts to=20 > re-inventing TCP on this layer. I agree that it is for the TML to implement reliability, not the PL. The PL simply will define the abstract TML requirements, i.e. that all TML implementations must provide channels with certain reliability characteristics. I agree with your and Jon's point that implementing a reliable connection is non-trivial. TIPC has done=20 this I think.=20 > 2) There is something called IPover Ethernet (IPoE),..and this may be=20 > leveraged here. > It will save us from running directly over ethernet. If we use IP we are right back with being forced to use SCTP, TCP, DCCP, etc. We then have no choice: If IP packets are being exchanged, what runs over them must be a RFC2914 congestion aware transport - which is why I was proposing getting away from IP in the very close scenario. Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 17:27:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27977 for ; Fri, 19 Mar 2004 17:27:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SSg-0005gV-JI for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 17:27:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JMRUvw021844 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 17:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SSg-0005gF-El for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 17:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27967 for ; Fri, 19 Mar 2004 17:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4SSe-0003Aj-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:27:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4SRj-00035G-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:26:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4SRD-00030M-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SRF-0005aJ-3I; Fri, 19 Mar 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SQe-0005YD-Bh for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 17:25:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27864 for ; Fri, 19 Mar 2004 17:25:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4SQb-0002yr-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:25:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4SPf-0002ts-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:24:24 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4SOn-0002ko-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:23:30 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JMPAXO020322 for ; Fri, 19 Mar 2004 22:25:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JMOkSN024074 for ; Fri, 19 Mar 2004 22:24:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031914224501001 for ; Fri, 19 Mar 2004 14:22:46 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 14:21:47 -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 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FE7BE@orsmsx408.jf.intel.com> Thread-Topic: summary of discussions so far... (part 1) Thread-Index: AcP/n308GweMyOGoRPGFAjNQHSLVogAg/70gAEf1lsADLvXxwA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 19 Mar 2004 22:21:47.0012 (UTC) FILETIME=[9115A440:01C40E00] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] summary of discussions so far... (part 1) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 14:21:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All Here is a list of high level design ideas/principles that we all agreed on... All ForCES protocol messages should consist of a common fixed size header and variable size payload fields.=20 All ForCES protocol messages should be 32-bit aligned. The ForCES protocol payload consists of a number of variable size TLVs i.e. all ForCES messages must use TLV encoding. The TLVs should also be 32-bit aligned. The ForCES protocol must support the discovery of static capabilities of an FE. The protocol may also support dynamic capabilities when they are supported by the FEs. The ForCES protocol should support logical addressing for multicast, broadcast in addition to unicast. The ForCES protocol will mandate a minimum set of transports for data and control communication for interoperability reasons. The ForCES protocol will take advantage of underlying transports/interconnects to provide features such as reliability, security to keep the protocol design itself simple. The ForCES protocol will run directly over layer 2 interconnects. It can either use additional TLVs or encapsulation headers or transports such as TIPC to provide the missing functionality such as reliability, fragmentation, etc. I have incorporated comments from Jamal, others that I received on the original text. I will send out a summary of each issue shortly. Let me know what you guys think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 17:28:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28014 for ; Fri, 19 Mar 2004 17:28:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4STb-0005jG-Dp for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 17:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JMSRdo022016 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 17:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4STb-0005j1-9Y for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 17:28:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28004 for ; Fri, 19 Mar 2004 17:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4STZ-0003Fo-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4SSj-0003Be-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:27:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4SSA-00035z-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 17:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SSC-0005cL-GM; Fri, 19 Mar 2004 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4SRg-0005bd-6K for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 17:26:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27946 for ; Fri, 19 Mar 2004 17:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4SRd-00034L-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:26:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4SQf-0002zS-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:25:26 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4SPm-0002qF-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 17:24:30 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2JMRgJ2017832; Fri, 19 Mar 2004 22:27:42 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2JMOTSb023880; Fri, 19 Mar 2004 22:25:41 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031914233801133 ; Fri, 19 Mar 2004 14:23:38 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 14:23: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 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES Message-ID: <468F3FDA28AA87429AD807992E22D07E3FE7C9@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES Thread-Index: AcQNrdXwzMg4sePOQFOGQBHSmdHi5AAUtM7g From: "Khosravi, Hormuzd M" To: Cc: "Jon Maloy" , X-OriginalArrivalTime: 19 Mar 2004 22:23:38.0014 (UTC) FILETIME=[D33F33E0:01C40E00] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 14:23:37 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > [HK] Agree, I think it would be a good idea to use TIPC in the non-IP > case, running ForCES over L2. It will take care of a lot of issues that > you have pointed out and help us concentrate our energies on designing > at the PL rather than TML. I think TIPC should be one of the TML but not the only TML for L2 - so lets not rush to making this judgement.=20 I know i will implement over TIPC (as one of n TMLs). The abstraction layer provides us opportunities, so lets not kill those. Example, I have customers who think that they have the greatest clustering protocol invented and with the abstraction layer i can now tell them what API i need provided to the PL level. As long as their TML runs within their NEs this should be fine in my opinion. [HK] Sure, I am fine with that. I believe we will have some flexibility=20 in the L2 case. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 18:05:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29271 for ; Fri, 19 Mar 2004 18:05:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4T2a-0001Ja-Uv for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 18:04:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JN4aMI005054 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 18:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4T2a-0001JR-Nb for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 18:04:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29221 for ; Fri, 19 Mar 2004 18:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4T2X-00065w-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 18:04:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4T1Z-00060Q-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 18:03:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4T11-0005v6-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 18:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4T13-0000sx-7r; Fri, 19 Mar 2004 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4T0b-0000PJ-9O for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 18:02:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29009 for ; Fri, 19 Mar 2004 18:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4T0Y-0005tK-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 18:02:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4SzZ-0005nQ-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 18:01:30 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B4Syo-0005eW-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 18:00:42 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2JN06Lc001243 for ; Fri, 19 Mar 2004 17:00:06 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 16:58:03 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 17:00:09 -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 GPWX1SH9; Fri, 19 Mar 2004 18:00:07 -0500 Message-ID: <405B7B73.4070407@ericsson.com> From: Jon Maloy 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 To: "Putzolu, David" CC: alex.audu@alcatel.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES References: <52D13A805349A249960B9943E5590BD802B2D19D@orsmsx409.jf.intel.com> Content-Type: multipart/alternative; boundary="------------090907080806010805040908" X-OriginalArrivalTime: 19 Mar 2004 22:58:03.0453 (UTC) FILETIME=[A2582ED0:01C40E05] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 18:00:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------090907080806010805040908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit /jon Putzolu, David wrote: Hi Alex - my response inline. Alex wrote> The PL over TML is a workable model. My concern is the wire concept plays well with TCP, but I am not sure it does so with SCTP. I suggest we use streams instead. I was using wire as a virtual connection of sorts with certain levels of service associated with it. The underlying TML could then be defined to use SCTP streams for different wires maybe? This can be done, but we are stuck with the same limitation as with TCP: all streams have the same properties, and can not be given individual characteristics such as congestion priorities. However, main point is to first define the services the FP layer needs from the abstract TML, then each TML spec would decide how to achieve those services. TCP was just an example of what the IP TML might choose, SCTP is definitely another alternative. Alex wrote> Also, the liveness checking by TML can only guarrantee the TML->transport->peerTML connectivity. To make sure PL is in the loop, PL should have its own scheme (e.g. ACKs, heartbeat,..). That checks the PL->TML->transport->peerTML->peerPL connectivity. This helps ensure the PL is not off in the weeds or removed or crashed while the transport is fine. It also helps problem isolation. Having a PL <-> PL heartbeat, to make sure the PL is alive, makes sense. I agree that this is separate from TML liveness. Both are needed, but the PL supervision can (and should be) made much more selective, i.e. the heartbeat frequency must be set depending on the importance of the user. We are talking about potentally hundreds of nodes here, and having multiple-level heartbeats on multiple connections between each CE and all FE:s, which I assume is a realistic scenario, may easily amount to a significant background load. There is an example in my draft where I calculate the background load for supervising a 2000-node cluster, and this shows that this algorithm must be designed with great care, and preferrably made hierarchical. It should be noted also that: 1) the burden rests on TML to implement some reliability scheme in case of unreliable transport. This is a tall order. It amounts to re-inventing TCP on this layer. I agree that it is for the TML to implement reliability, not the PL. The PL simply will define the abstract TML requirements, i.e. that all TML implementations must provide channels with certain reliability characteristics. I agree with your and Jon's point that implementing a reliable connection is non-trivial. TIPC has done this I think. 2) There is something called IPover Ethernet (IPoE),..and this may be leveraged here. It will save us from running directly over ethernet. If we use IP we are right back with being forced to use SCTP, TCP, DCCP, etc. We then have no choice: If IP packets are being exchanged, what runs over them must be a RFC2914 congestion aware transport - which is why I was proposing getting away from IP in the very close scenario. Agree. The options are SCTP, TCP, DCCP, and/or a non-IP protocol. So, if we want something better than the available IP-protocols can provide, we must have at least one non-IP alternative. (And let me repeat, TIPC can also be carried efficiently over these three IP-protocols, so it is in reality the only TML we need) Cheers, David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------090907080806010805040908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit /jon

Putzolu, David wrote:
Hi Alex - my response inline.


Alex wrote>
  
The PL over TML is a workable model.  My concern is the wire concept 
plays well with TCP, but I am not sure it does so with SCTP.  I
    
suggest we 
  
use streams instead.
    

I was using wire as a virtual connection of sorts with certain
levels of service associated with it.  The underlying TML could
then be defined to use SCTP streams for different wires maybe?
This can be done, but we are stuck with the same limitation as with TCP:
all streams have the same properties, and can not be given individual
characteristics such as congestion priorities.

However, main point is to first define the services the FP layer
needs from the abstract TML, then each TML spec would decide
how to achieve those services.  TCP was just an example of what
the IP TML might choose, SCTP is definitely another alternative.


Alex wrote>
  
Also, the liveness checking by TML can only guarrantee the 
TML->transport->peerTML connectivity.  To make sure PL is 
in the loop, PL should have its own scheme (e.g. ACKs,
heartbeat,..).  That checks the PL->TML->transport->peerTML->peerPL 
connectivity. This helps ensure the PL is not off in the weeds or
    
removed 
  
or crashed while the transport is fine.  It also helps problem
    
isolation.

Having a PL <-> PL heartbeat, to make sure the PL is alive,
makes sense.  I agree that this is separate from TML liveness.
Both are needed, but the PL supervision can (and should be) made much
more selective, i.e. the heartbeat frequency must be set depending on
the importance of the user.  We are talking about potentally hundreds
of nodes here, and having multiple-level heartbeats on multiple connections
between each CE and all FE:s, which I assume is a realistic scenario, may
easily amount to a significant background load. There is an example in
my draft where I calculate  the background load for supervising a 2000-node
cluster, and this shows that this algorithm must be designed with great care,
and preferrably made hierarchical.
  
It should be noted also that:
1) the burden rests on TML to implement some reliability 
scheme in case of unreliable
transport.  This is a tall order. It amounts to 
re-inventing TCP on this layer.
    

I agree that it is for the TML to implement reliability,
not the PL. The PL simply will define the abstract TML
requirements, i.e. that all TML implementations must
provide channels with certain reliability characteristics.

I agree with your and Jon's point that implementing
a reliable connection is non-trivial.  TIPC has done 
this I think. 


  
2) There is something called IPover Ethernet (IPoE),..and this may be 
leveraged here.
     It will save us from running directly over ethernet.
    

If we use IP we are right back with being forced to use
SCTP, TCP, DCCP, etc.  We then have no choice: If IP packets
are being exchanged, what runs over them must be a RFC2914
congestion aware transport - which is why I was proposing
getting away from IP in the very close scenario.
Agree. The options are  SCTP, TCP, DCCP, and/or a non-IP protocol.
So, if we want something better than the available IP-protocols can provide,
we must have at least one non-IP alternative. (And let me repeat, TIPC can
also be carried efficiently over these three IP-protocols, so it is in reality
the only TML we need)

Cheers,
David

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol



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

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. --------------090907080806010805040908-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 19:46:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03873 for ; Fri, 19 Mar 2004 19:46:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4UdD-0001Vi-WD for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 19:46:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K0kV45005800 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 19:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4UdD-0001VT-RU for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 19:46:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03860 for ; Fri, 19 Mar 2004 19:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4UdC-00000e-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 19:46:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4UcJ-0007jp-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 19:45:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ubl-0007f1-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 19:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ubm-0001PB-Gi; Fri, 19 Mar 2004 19:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4UbC-0001NH-Ky for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 19:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03784 for ; Fri, 19 Mar 2004 19:44:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4UbA-0007d4-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 19:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4UaE-0007YZ-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 19:43:27 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B4UZK-0007Pc-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 19:42:30 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2K0hxXO009286 for ; Sat, 20 Mar 2004 00:43:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2K0gDT3014187 for ; Sat, 20 Mar 2004 00:43:45 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004031916414123575 for ; Fri, 19 Mar 2004 16:41:41 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Mar 2004 16:41:41 -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 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FE964@orsmsx408.jf.intel.com> Thread-Topic: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+Q From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 20 Mar 2004 00:41:41.0163 (UTC) FILETIME=[1C636FB0:01C40E14] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Summary for issues 0-5 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Mar 2004 16:41:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All Here is a brief summary of all the major issues that the team discussed. Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 3 bits for Priority. (The semantics/length of this is TBD) TypeID: TBD, no consensus on whether it is needed or not Issue# 2 Multiple channels/connections:- There was a lot of discussion on this topic as well. There was agreement on the fact that there MUST be a way to prioritize and separate Control and Data traffic. There was no clear consensus around mandating using separate channels or connections (better term) for Data and Control in order to provide this separation. There were reasons presented regarding the ineffectiveness of separate connections to help during DoS attacks as well as the reasons for using reliable and unreliable connections for Control and Data respectively. The use of separate transports/connections is TBD. Issue# 3 Transport: unicast/multicast/broadcast:- There was some consensus around this text to describe this issue... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association (TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) David provided some clarification to the group on this issue via his email below... https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren t/msg00317.html There seems to be consensus around the approaches outlined by David in his email. There was also general consensus about separation of the ForCES PL (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm Issue# 4 Congestion control:- General consensus was that Congestion Control (CC) is a MUST for the protocol for all messages, whether Control or Data in order to meet the basic scalability requirement. There was also some discussion around DoS protection in context with CC, but this is still being discussed. Issue# 5 Reliability:- General consensus was that Reliability is a MUST for all control messages. The separation of TML from PL has provided the team the opportunity to make progress on the PL and defer the details of the TML for now. This issue is also closely related to issue# 3 and both were discussed in parallel to some extent. In general, I believe we made a lot of good progress :-) Let me know if you guys have any comments on this summary ? Thanks to everyone for their contributions! Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 20:43:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05048 for ; Fri, 19 Mar 2004 20:43:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VVT-0004M5-Bt for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 20:42:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K1gZp5016735 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 20:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VVT-0004Lq-5z for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 20:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05036 for ; Fri, 19 Mar 2004 20:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4VVR-0004ih-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 20:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4VUV-0004dc-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 20:41:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4VTw-0004Yl-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 20:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VTx-0004K5-S5; Fri, 19 Mar 2004 20:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VTX-0004It-5T for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 20:40:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04976 for ; Fri, 19 Mar 2004 20:40:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4VTU-0004Xa-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:40:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4VSY-0004Sy-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:39:35 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4VS3-0004OF-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:39:03 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031917412652:9386 ; Fri, 19 Mar 2004 17:41:26 -0800 Subject: RE: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance &use of TCP/SCTP/UDP/IP in ForCES From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Putzolu, David" Cc: forces-protocol@ietf.org In-Reply-To: <52D13A805349A249960B9943E5590BD802B2CF7E@orsmsx409.jf.intel.com> References: <52D13A805349A249960B9943E5590BD802B2CF7E@orsmsx409.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079746740.1037.36.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 03/19/2004 05:41:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 05:41:28 PM, Serialize complete at 03/19/2004 05:41:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 20:39:01 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, On Fri, 2004-03-19 at 11:39, Putzolu, David wrote: > I think the ADs would be fine with DCCP - but I confess > that I don't know how well DCCP can be used with multicast > transports. My concern was more it sounded evil to be associated with udp. So i pointed DCCP as something that used that evil UDP. I know you didnt mean to say that but it sounded like "if you dont run on top of IP it is ok to use something evil as that smelly udp". We should still be able to use UDP on the local/close proximity scope. Lets leave this discussion to later. > Jamal wrote > > > From the outset it does look reasonable. I am assuming that > > the TML serializes the data to the Forces PL? > > The abstract TML provides some defined level of service. > I am pretty sure the abstract TML needs to provide a > service where at least one wire that serializes data (don't > want overlapping add routes or worse ACL entries reordered). I was more thinking the PL layer doesnt need to know anything about the wires. It just receives messages from the TML layer which are serialized. It may not be valuable if the PL gets to know all the details of the transport. > Whether all TML wires need to be ordered would be up to the > team to decide - what is the minimum good tranport service > desired at the ForCES protocol layer? I see the TML-PL interface as local mostly. Maybe TCP if the two reside on separate nodes. > The TML implementations would need to provide the requested > level of service. Some might be overachievers, i.e. the > abstract TML might provide guaranteed ordered wires and > wires that do not guarantee ordering. If the IP TML team > where to decide to use TCP for all wires, then the IP TML > would provide every wire ordered (exceeding the requested > level of service). The key is every TML implementation > has to at least meet the expected level of service. I think we oughta list all the requirements the differemt TMLs. reliability, availability, congestion control, security - and then we need to define the API or the messaging. We may be going a little overboard. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 21:01:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05858 for ; Fri, 19 Mar 2004 21:01:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vms-0005Qe-44 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:00:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K20XQi020869 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vmq-0005QU-7Q for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 21:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05847 for ; Fri, 19 Mar 2004 21:00:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vmn-0006cT-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vlv-0006YI-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 20:59:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4VlK-0006Tj-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 20:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VlM-0005HF-0y; Fri, 19 Mar 2004 20:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vkw-0005Gr-MZ for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 20:58:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05776 for ; Fri, 19 Mar 2004 20:58:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vku-0006SK-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:58:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vk0-0006Mz-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:57:36 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Vj7-0006HF-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 20:56:42 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031917590588:9392 ; Fri, 19 Mar 2004 17:59:05 -0800 Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Jon Maloy Cc: "Putzolu, David" , alex.audu@alcatel.com, forces-protocol@ietf.org In-Reply-To: <405B7B73.4070407@ericsson.com> References: <52D13A805349A249960B9943E5590BD802B2D19D@orsmsx409.jf.intel.com> <405B7B73.4070407@ericsson.com> Organization: ZNYX Networks Message-Id: <1079747800.1035.47.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 03/19/2004 05:59:06 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 05:59:07 PM, Serialize complete at 03/19/2004 05:59:07 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 20:56:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-19 at 18:00, Jon Maloy wrote: [..] > There is an example in > my draft where I calculate the background load for supervising a > 2000-node > cluster, and this shows that this algorithm must be designed with > great care, > and preferrably made hierarchical. Protocols like MBUS have some interesting tricks. http://www.ietf.org/rfc/rfc3259.txt Look at section 8.1.1 We adopted that algorithm > > If we use IP we are right back with being forced to use > > SCTP, TCP, DCCP, etc. We then have no choice: If IP packets > > are being exchanged, what runs over them must be a RFC2914 > > congestion aware transport - which is why I was proposing > > getting away from IP in the very close scenario. > > Agree. Sorry, folks - I would have to disagree. There could be a TML which is very simple and based on just TCP and UDP. It is upto the TML to take care of the reliability, cc, etc. CC MUST emulate RFC2914 if not running over RFC2914 capable protocol; perhaps borrowing some of the algorithms from DCCP would not be a bad idea if DCCP is not ready. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 21:10:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06183 for ; Fri, 19 Mar 2004 21:10:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VvZ-0005xV-Hv for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:09:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K29XUN022899 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4VvZ-0005xG-Bt for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 21:09:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06176 for ; Fri, 19 Mar 2004 21:09:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4VvW-0007Pp-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:09:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vuc-0007Lb-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:08:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vu3-0007HD-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vu5-0005tE-6h; Fri, 19 Mar 2004 21:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Vth-0005mA-32 for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 21:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06105 for ; Fri, 19 Mar 2004 21:07:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Vte-0007GD-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:07:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Vsm-0007A7-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:06:41 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Vrs-000757-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:05:44 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004031918080792:9399 ; Fri, 19 Mar 2004 18:08:07 -0800 Subject: Re: [Forces-protocol] Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E3FE964@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E3FE964@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079748342.1039.60.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 03/19/2004 06:08:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/19/2004 06:08:09 PM, Serialize complete at 03/19/2004 06:08:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Mar 2004 21:05:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hormuzd, I think issues 2-5 can mow be described with the TML separation. i.e the TML layer will take care of: - management of Multiple channels/connections - Transport: unicast/multicast/broadcast - Congestion control - Reliability We may as well add: security, availability. Thoughts? cheers, jamal On Fri, 2004-03-19 at 19:41, Khosravi, Hormuzd M wrote: > Hi All > > Here is a brief summary of all the major issues that the team discussed. > > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 3 bits for Priority. (The semantics/length of > this is TBD) > > TypeID: TBD, no consensus on whether it is needed or not > > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. > > Issue# 3 Transport: unicast/multicast/broadcast:- > There was some consensus around this text to describe this issue... > > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) > > David provided some clarification to the group on this issue via his > email below... > https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren > t/msg00317.html > There seems to be consensus around the approaches outlined by David in > his email. > > There was also general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. > > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. > > > In general, I believe we made a lot of good progress :-) > Let me know if you guys have any comments on this summary ? > > Thanks to everyone for their contributions! > Hormuzd > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Mar 19 21:57:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08179 for ; Fri, 19 Mar 2004 21:57:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Wf6-0008Dz-IM for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:56:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K2ua3I031609 for forces-protocol-archive@odin.ietf.org; Fri, 19 Mar 2004 21:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Wf6-0008Dk-DG for forces-protocol-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 21:56:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08170 for ; Fri, 19 Mar 2004 21:56:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Wf3-0004bx-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:56:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4We4-0004XR-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:55:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4WdZ-0004TJ-00 for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:55:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4Wda-0000nf-PI for forces-protocol-web-archive@ietf.org; Fri, 19 Mar 2004 21:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Wdb-00089Z-2p; Fri, 19 Mar 2004 21:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Wd5-00088y-R8 for forces-protocol@optimus.ietf.org; Fri, 19 Mar 2004 21:54:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08139 for ; Fri, 19 Mar 2004 21:54:28 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Wd2-0004SP-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:54:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Wc6-0004O1-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:53:30 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4Wb8-0004F3-00 for forces-protocol@ietf.org; Fri, 19 Mar 2004 21:52:35 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 20 Mar 2004 11:03:11 +0800 Received: from 219.82.178.219 ( [219.82.178.219]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 20 Mar 2004 11:03:11 +0800 Message-ID: <1079751791.405bb4835c6ca@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Mar 2004 11:03:11 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Alex, You are right, but I would perfer to define it as DoS/Congestion when the D packet stream has actually threatened the proper transmission of C packet stream. I mentioned this in the reply to Hormuzd on these issues. Cheers, Weiming ----- Original Message ----- From: Alex Audu To: Wang,Weiming Cc: forces-protocol@ietf.org Sent: Saturday, March 20, 2004 4:01 AM Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability Hello Weiming, That is good, but what I am saying is, you can't make a general characterization that every high resource usage is a DOS scenario. It may just be that the FE is just being overloaded with good traffic. Cheers, Alex. Wang,Weiming wrote: Hello Alex, I think what you said is exactly what I meant. That is, something like 'DoS Alert Policy' as called in GRMP should be used to determine when a DoS is considered and an alert event is sent from FE to CE. Actually I don't think to manage this policy is outside the scope of ForCES, it can surely be set up as a kind of FE attribute to FE by CE. And moreover, I'm afraid a pure resource usage status report is not enough for DoS alert purpose. On the other hand, I have to say what set in current GRMP for 'DoS alert policy' seems a little naive. We need improvement on this, that is, to find a better and more efficient description for the policy. Thank you. Weiming ----- Original Message ----- From: "Alex Audu" To: Cc: Sent: Friday, March 19, 2004 2:47 AM Subject: Re: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability Hello Weiming, I don't think it is possible for us to come up with a mechanism to determine if an FE is being DOS'd. The final determination of that may depend on situation at hand, since attack signatures are typically different for different DOS attacks. I think the final decision as to if a DOS is really occuring is best left to policy on the NE. This is outside ForCES scope. But we can have FE report resource usage status to CE. I think FACT already has such report. Regards, Alex. ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 20 01:24:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15061 for ; Sat, 20 Mar 2004 01:24:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZtT-0004Ox-94 for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 01:23:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K6Ndah016915 for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 01:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZtT-0004Ok-4X for forces-protocol-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 01:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15048 for ; Sat, 20 Mar 2004 01:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZtQ-0001kO-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:23:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ZsU-0001fk-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:22:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Zrq-0001ai-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Zrt-0004IR-7k; Sat, 20 Mar 2004 01:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Zrj-0004I3-82 for forces-protocol@optimus.ietf.org; Sat, 20 Mar 2004 01:21:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15035 for ; Sat, 20 Mar 2004 01:21:49 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Zrg-0001aT-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:21:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Zqn-0001Ue-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:20:53 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4ZqQ-0001Nz-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:20:31 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 20 Mar 2004 14:32:04 +0800 Received: from 219.82.178.219 ( [219.82.178.219]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 20 Mar 2004 14:32:03 +0800 Message-ID: <1079764323.405be577c329d@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] summary of discussions so far... (part 1) MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Mar 2004 14:32:03 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All ..... The ForCES protocol payload consists of a number of variable size TLVs i.e. all ForCES messages must use TLV encoding. The TLVs should also be 32-bit aligned. [Weiming Re] I'm afraid this sub-issue has not completely come to an agreement. I actually agree to use TLVs in ForCES protocol. The only question is why it should be MUST. I think we only need to use it when we actually need it. Talking about this, I'm afraid I have to kindly mention FACT again. I have just found that in many cases inside FACT where the first layer 'Tag' and 'Length' field are used, after these fields have been moved away while without any other changes, the protocol still can run very well . Please allow me to take one from FACT as an examples as below (FACT P.18): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x04) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When we just use: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It still can work well. In this way, we actually have taken the 'reason' field as a field inside the large ForCES message TLV( the message type as the T, the message length as the L). To compare with, I would more appreciate the way the TLV is used in Netlink2, in which I think it has not strictly tried to use TLV when not necessary. For example, the Netlink2 ACK message (Netlink2 P.28): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netlink2 message header | | type = NLMSG_ERROR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | error code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLD Netlink2 message header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the error code and old message header part are explicitly expressed instead by TLVs. Actually GRMP has taken the way like this to use TLV. That is to use TLV only when necessary. Another problem related to strictly and uniformly use TLV in the payload of the message body is, then we have to define the TLV's Tag field globally even when the TLV is a very micro item (as above example where the Tag (0x04) is glabal), which may result in so many types of TLV we need to define, as a result, I'm not sure if the 16 bits space will become exausted or not in the future. As a result, I would prefer to use TLVs as follows: 1. All items (parameters) that have variable length and are mostly defined by FE models Must be defined as TLVs. 2. All items that actually have global meanings for more than one kind of ForCES messages is better to be defined as TLVs. 3. All items that are optional to a message payload is better been described as TLV(just like IP, TCP, etc do) Anyway, I just want to say that it may be too early to decide "all ForCES messages must use TLV encoding". We may need to gain more experiences (when we actually begin to encode the ForCES messages), then to decide it. I don't think to do in this way has any harm to all of us. Yours, Weiming ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 20 01:40:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15329 for ; Sat, 20 Mar 2004 01:40:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4a93-0005hB-KW for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 01:39:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K6djhD021887 for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 01:39:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4a93-0005gu-FO for forces-protocol-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 01:39:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15323 for ; Sat, 20 Mar 2004 01:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4a90-00034S-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:39:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4a84-0002zb-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:38:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4a7L-0002uA-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 01:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4a7N-0005Lj-CX; Sat, 20 Mar 2004 01:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4a73-0005CK-Cu for forces-protocol@optimus.ietf.org; Sat, 20 Mar 2004 01:37:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15279 for ; Sat, 20 Mar 2004 01:37:39 -0500 (EST) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4a70-0002t2-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:37:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4a63-0002nm-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:36:40 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4a5I-0002ek-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 01:35:56 -0500 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 20 Mar 2004 14:46:37 +0800 Received: from 219.82.178.219 ( [219.82.178.219]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Sat, 20 Mar 2004 14:46:37 +0800 Message-ID: <1079765197.405be8e19cc88@mail.hzic.edu.cn> To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary for issues 0-5 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 20 Mar 2004 14:46:37 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Thank you for your work on the summary. Please see some replies inline. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All Here is a brief summary of all the major issues that the team discussed. Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD [Weiming] I think we have also reached agreement on using LFB ID and LFB Instance ID for addressing. Do you agree? Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 3 bits for Priority. (The semantics/length of this is TBD) TypeID: TBD, no consensus on whether it is needed or not [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits, and the semantics) need to be discussed further). Issue# 2 Multiple channels/connections:- There was a lot of discussion on this topic as well. There was agreement on the fact that there MUST be a way to prioritize and separate Control and Data traffic. There was no clear consensus around mandating using separate channels or connections (better term) for Data and Control in order to provide this separation. There were reasons presented regarding the ineffectiveness of separate connections to help during DoS attacks as well as the reasons for using reliable and unreliable connections for Control and Data respectively. The use of separate transports/connections is TBD. [Agreed] Issue# 3 Transport: unicast/multicast/broadcast:- There was some consensus around this text to describe this issue... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association (TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) David provided some clarification to the group on this issue via his email below... https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren t/msg00317.html There seems to be consensus around the approaches outlined by David in his email. There was also general consensus about separation of the ForCES PL (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm Issue# 4 Congestion control:- General consensus was that Congestion Control (CC) is a MUST for the protocol for all messages, whether Control or Data in order to meet the basic scalability requirement. There was also some discussion around DoS protection in context with CC, but this is still being discussed. [Weiming ] Haven't we achieved anything on DoS? Issue# 5 Reliability:- General consensus was that Reliability is a MUST for all control messages. The separation of TML from PL has provided the team the opportunity to make progress on the PL and defer the details of the TML for now. This issue is also closely related to issue# 3 and both were discussed in parallel to some extent. In general, I believe we made a lot of good progress :-) Let me know if you guys have any comments on this summary ? Thanks to everyone for their contributions! Hormuzd ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Mar 20 18:22:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00343 for ; Sat, 20 Mar 2004 18:22:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4pnB-0006yo-LD for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 18:22:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2KNMD6A026824 for forces-protocol-archive@odin.ietf.org; Sat, 20 Mar 2004 18:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4pnB-0006yW-Dr for forces-protocol-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 18:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00340 for ; Sat, 20 Mar 2004 18:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4pn8-0007Mx-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 18:22:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4pmD-0007Hh-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 18:21:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4plz-0007CV-00 for forces-protocol-web-archive@ietf.org; Sat, 20 Mar 2004 18:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4pm1-0006vy-7h; Sat, 20 Mar 2004 18:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4plG-0006uq-HW for forces-protocol@optimus.ietf.org; Sat, 20 Mar 2004 18:20:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00277 for ; Sat, 20 Mar 2004 18:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4plD-0007B5-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 18:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4pkT-00075I-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 18:19:26 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B4pjU-0006yF-00 for forces-protocol@ietf.org; Sat, 20 Mar 2004 18:18:24 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032015203598:9861 ; Sat, 20 Mar 2004 15:20:35 -0800 Subject: Re: [Forces-protocol] Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org In-Reply-To: <1079765197.405be8e19cc88@mail.hzic.edu.cn> References: <1079765197.405be8e19cc88@mail.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1079824690.1037.94.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 03/20/2004 03:20:36 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2004 03:20:48 PM, Serialize complete at 03/20/2004 03:20:48 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 20 Mar 2004 18:18:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can we just say to the WG that there is consensus for a merger without providing details? Looking at this and previous email from Weiming as well as my previous concerns in the last email i posted, i think we dont loose anything by not providing details. Instead lets reserve the energy for coming up with the protocol and other related details. cheers, jamal On Sat, 2004-03-20 at 01:46, wmwang@mail.hzic.edu.cn wrote: > Hi Hormuzd, > > Thank you for your work on the summary. > Please see some replies inline. > > Weiming > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Hi All > > Here is a brief summary of all the major issues that the team discussed. > > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD > > [Weiming] I think we have also reached agreement on using LFB ID and LFB > Instance ID for addressing. Do you agree? > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 3 bits for Priority. (The semantics/length of > this is TBD) > > TypeID: TBD, no consensus on whether it is needed or not > > [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits, > and the semantics) need to be discussed further). > > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. > > [Agreed] > > Issue# 3 Transport: unicast/multicast/broadcast:- > There was some consensus around this text to describe this issue... > > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) > > David provided some clarification to the group on this issue via his > email below... > https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren > t/msg00317.html > There seems to be consensus around the approaches outlined by David in > his email. > > There was also general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. > > [Weiming ] Haven't we achieved anything on DoS? > > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. > > In general, I believe we made a lot of good progress :-) > Let me know if you guys have any comments on this summary ? > > Thanks to everyone for their contributions! > Hormuzd > > > > > ------------------------------------------------- > This mail sent through HUCNIC Webmail system. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 01:25:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14895 for ; Sun, 21 Mar 2004 01:25:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wOk-00043J-VX for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 01:25:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L6PQb7015571 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 01:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wOk-000433-Pm for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 01:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14889 for ; Sun, 21 Mar 2004 01:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4wOh-000136-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:25:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4wNr-0000xt-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:24:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4wNK-0000sW-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wNN-0003zp-59; Sun, 21 Mar 2004 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wMp-0003xF-Ar for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 01:23:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14819 for ; Sun, 21 Mar 2004 01:23:25 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4wMm-0000qj-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:23:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4wLv-0000l3-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:22:33 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx with esmtp (Exim 4.12) id 1B4wLL-0000d1-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:21:55 -0500 Received: from Aaudu2000@aol.com by imo-d22.mx.aol.com (mail_out_v37_r1.2.) id l.f6.3831a9de (4468); Sun, 21 Mar 2004 01:20:55 -0500 (EST) Message-ID: Subject: Re: [Forces-protocol] Summary for issues 0-5 To: hadi@znyx.com, wmwang@mail.hzic.edu.cn CC: forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079850054" X-Mailer: 9.0 for Windows sub 5017 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 01:20:54 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079850054 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi All, Definitely the merger is possible. Lots of details remain to be worked out. For example, I still don't think the header structure has been fleshed out. But the details can be resolved later. Regards, Alex. In a message dated 3/20/2004 5:21:26 PM Central Standard Time, hadi@znyx.com writes: Can we just say to the WG that there is consensus for a merger without providing details? Looking at this and previous email from Weiming as well as my previous concerns in the last email i posted, i think we dont loose anything by not providing details. Instead lets reserve the energy for coming up with the protocol and other related details. cheers, jamal On Sat, 2004-03-20 at 01:46, wmwang@mail.hzic.edu.cn wrote: > Hi Hormuzd, > > Thank you for your work on the summary. > Please see some replies inline. > > Weiming > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Hi All > > Here is a brief summary of all the major issues that the team discussed. > > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD > > [Weiming] I think we have also reached agreement on using LFB ID and LFB > Instance ID for addressing. Do you agree? > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 3 bits for Priority. (The semantics/length of > this is TBD) > > TypeID: TBD, no consensus on whether it is needed or not > > [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits, > and the semantics) need to be discussed further). > > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. > > [Agreed] > > Issue# 3 Transport: unicast/multicast/broadcast:- > There was some consensus around this text to describe this issue... > > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) > > David provided some clarification to the group on this issue via his > email below... > https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren > t/msg00317.html > There seems to be consensus around the approaches outlined by David in > his email. > > There was also general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. > > [Weiming ] Haven't we achieved anything on DoS? > > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. > > In general, I believe we made a lot of good progress :-) > Let me know if you guys have any comments on this summary ? > > Thanks to everyone for their contributions! > Hormuzd -------------------------------1079850054 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Definitely the merger is possible. Lots of details remain to be wo= rked out. For example, I
still don't think the header structure has been fleshed out.  But=20= the details can be resolved
later.
 
Regards,
Alex.
 
In a message dated 3/20/2004 5:21:26 PM Central Standard Time, hadi@zny= x.com writes:
Can we just say to the WG that there is consen= sus for a merger
without providing details?
Looking at this and previ= ous email from Weiming as well as my previous
concerns in the last email=20= i posted, i think we dont loose anything by
not providing details. Instea= d lets reserve the energy for coming up
with the protocol and other relat= ed details.

cheers,
jamal

On Sat, 2004-03-20 at 01:46, wmwa= ng@mail.hzic.edu.cn wrote:
> Hi Hormuzd,
>
> Thank you fo= r your work on the summary.
> Please see some replies inline.
>=20=
> Weiming
>
> ----- Original Message -----
> From= : "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
>
>= ; Hi All
>
> Here is a brief summary of all the major issues th= at the team discussed.
>
> Issue# 0 IDs in the header:-
>= There was a lot of discussion on this topic regarding the naming,
> s= emantics, length of these IDs.
> The result was as follows...
>=20= Naming: CE ID, FE ID
> Semantics: Used to address a single, group or a= ll CEs/FEs respectively
> Length: 16-32 bits...TBD
>
> [W= eiming] I think we have also reached agreement on using LFB ID and LFB
&= gt; Instance ID for addressing. Do you agree?
>
> Issue# 1 Head= er/Encoding:-
> Here are the fields in the common header that there wa= s consensus around
> IDs: as summarized in issue 0
> Version/sub= -ver: 4 bits
> Sequence No. : 32 bits
> Length : 16 bits
>= Command Type : 8 bits (semantics - TBD)
> Flags: 16 bits, including 3= bits for Priority. (The semantics/length of
> this is TBD)
> > TypeID: TBD, no consensus on whether it is needed or not
>
= > [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3= bits,
> and the semantics) need to be discussed further).
> > Issue# 2 Multiple channels/connections:-
> There was a lot of di= scussion on this topic as well. There was agreement
> on the fact that= there MUST be a way to prioritize and separate Control
> and Data tra= ffic. There was no clear consensus around mandating using
> separate c= hannels or connections (better term) for Data and Control in
> order t= o provide this separation. There were reasons presented regarding
> th= e ineffectiveness of separate connections to help during DoS attacks
>= as well as the reasons for using reliable and unreliable connections for> Control and Data respectively. The use of separate
> transports/= connections is TBD.
>
> [Agreed]
>
> Issue# 3 Tran= sport: unicast/multicast/broadcast:-
> There was some consensus around= this text to describe this issue...
>
> All ForCES protocol im= plementations, MUST support a reliable, congestion
> aware Unicast met= hod of communication between the CEs and the FEs.
> Furthermore, in ca= se of IP this will be a TCP or SCTP connection between
> the CE and FE= s. In addition to this, in case of 'close proximity'
> between the CEs= and FEs And in case the interconnect between them
> supports multicas= t, the CEs and FEs Must also establish reliable,
> congestion aware Mu= lticast connections. The establishment and semantics
> of these Multic= ast connections is negotiated during the
> binding/capability discover= y phase in the ForCES protocol or during
> pre-association (TBD). For=20= example, the CE and subset of FEs might
> negotiate on establishing a=20= Multicast connection for communication of
> IPv4 LFB attributes. These= reliable, congestion aware connections will
> be used to communicate=20= the control messages outlined in RFC 3654
> (section 6, #6c). (For dat= a messages such as those outlined in RFC 3654
> (section 6, #6b), the=20= ForCES protocol Must/Should also support an
> un-reliable but congesti= on aware Unicast connection between the CE and
> FEs.- TBD:issue# 2)>
> David provided some clarification to the group on this issue= via his
> email below...
> https://www1.ietf.org/mail-archive/w= orking-groups/forces-protocol/curren
> t/msg00317.html
> There s= eems to be consensus around the approaches outlined by David in
> his=20= email.
>
> There was also general consensus about separation of= the ForCES PL
> (protocol layer) from the TML (Transport Mapping Laye= r) ala GSMP. The
> link below provides a good explanation of these lay= ers...
> http://www.sstanamera.com/~forces/proto/ForCESLayered.htm
= >
> Issue# 4 Congestion control:-
> General consensus was th= at Congestion Control (CC) is a MUST for the
> protocol for all messag= es, whether Control or Data in order to meet the
> basic scalability r= equirement. There was also some discussion around DoS
> protection in=20= context with CC, but this is still being discussed.
>
> [Weimin= g ] Haven't we achieved anything on DoS?
>
> Issue# 5 Reliabil= ity:-
> General consensus was that Reliability is a MUST for all contr= ol
> messages. The separation of TML from PL has provided the team the=
> opportunity to make progress on the PL and defer the details of the= TML
> for now. This issue is also closely related to issue# 3 and bot= h were
> discussed in parallel to some extent.
>
> In gen= eral, I believe we made a lot of good progress :-)
> Let me know if yo= u guys have any comments on this summary ?
>
> Thanks to everyo= ne for their contributions!
> Hormuzd
-------------------------------1079850054-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 01:39:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15300 for ; Sun, 21 Mar 2004 01:39:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wbb-0004te-Tv for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 01:38:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L6chMY018816 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 01:38:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wbb-0004tP-Oo for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 01:38:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15284 for ; Sun, 21 Mar 2004 01:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4wbY-0002SN-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:38:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4wac-0002KU-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:37:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4wZv-0002CU-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 01:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wZx-0004V1-Ax; Sun, 21 Mar 2004 01:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4wZd-0004Sz-CZ for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 01:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15173 for ; Sun, 21 Mar 2004 01:36:29 -0500 (EST) From: Aaudu2000@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4wZQ-00029g-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:36:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4wYa-00023G-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:35:37 -0500 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx with esmtp (Exim 4.12) id 1B4wXu-0001uo-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 01:34:54 -0500 Received: from Aaudu2000@aol.com by imo-m27.mx.aol.com (mail_out_v37_r1.2.) id s.133.2caad2e4 (4468); Sun, 21 Mar 2004 01:34:04 -0500 (EST) Message-ID: <133.2caad2e4.2d8e915c@aol.com> Subject: Re: [Forces-protocol] summary of discussions so far... (part 1) To: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1079850844" X-Mailer: 9.0 for Windows sub 5017 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 01:34:04 EST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 -------------------------------1079850844 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Weiming, The tag is used to communicate the meaning of the value being communicated in the reason field. Otherwise, there is no way of telling whether the 32 bit field carries LFBID or reason code or any other 32-bit value. And of course, we may also want to encode the values in other formats like XML,..etc. So, there ought to be a way to communicate the method of encoding we are using in the header. I have hinted at this in my earlier suggestion for a common header structure. Regards, Alex. -------------------------------1079850844 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Weiming,
 
The tag is used to communicate the meaning of the value being communica= ted in the
reason field. Otherwise, there is no way of telling whether the 32 bit=20= field carries LFBID or
reason code or any other 32-bit value.
 
And of course, we may also want to encode the values in other formats l= ike XML,..etc.
So, there ought to be a way to communicate the method of encoding we ar= e using in the
header. I have hinted at this in my earlier suggestion for a common hea= der structure.
 
Regards,
Alex.
-------------------------------1079850844-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 04:47:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04021 for ; Sun, 21 Mar 2004 04:47:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4zXU-000394-K2 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 04:46:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L9keqX012083 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 04:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4zXT-00038k-GQ for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 04:46:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04000 for ; Sun, 21 Mar 2004 04:46:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4zXQ-0006Sk-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 04:46:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4zWU-0006MQ-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 04:45:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4zVu-0006GH-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 04:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4zVw-00034W-LB; Sun, 21 Mar 2004 04:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4zVU-0002xx-7o for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 04:44:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03866 for ; Sun, 21 Mar 2004 04:44:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4zVR-0006Cs-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 04:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4zUS-00062i-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 04:43:33 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B4zTU-0005pE-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 04:42:33 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 21 Mar 2004 17:53:52 +0800 Message-ID: <003d01c40f28$749d9790$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: Subject: Re: [Forces-protocol] Summary for issues 0-5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C40F6B.829CFBE0" 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 17:39:50 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MAILTO_TO_SPAM_ADDR,MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C40F6B.829CFBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KSSBhZ3JlZSB3aXRoIHlvdS4gV2hhdCBJJ3YganVzdCBwb3N0ZWQgYWxzbyBt ZWFucyB0aGlzLiBOb3cgd2Ugb25seSBuZWVkIHRvIGRlY2lkZSBpcyBpZiB0aGUgbWVyZ2VyIGlz IHBvc3NpYmxlLCB3ZSB0aGVuIGNhbiBoYXZlIGxvdHMgb2YgdGltZSBkaXNjdXNzaW5nIHRoZSBk ZXRhaWxzLCBpbmNsdWRpbmcgdGhlIHN1bW1hcnkgZm9yIHByZXZpb3VzIGRpc2N1c3Npb25zLiAN Cg0KQlINCndlaW1pbmcNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTog QWF1ZHUyMDAwQGFvbC5jb20gDQogIFRvOiBoYWRpQHpueXguY29tIDsgd213YW5nQG1haWwuaHpp Yy5lZHUuY24gDQogIENjOiBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIFNlbnQ6IFN1bmRh eSwgTWFyY2ggMjEsIDIwMDQgMjoyMCBQTQ0KICBTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2Nv bF0gU3VtbWFyeSBmb3IgaXNzdWVzIDAtNQ0KDQoNCiAgSGkgQWxsLA0KDQogIERlZmluaXRlbHkg dGhlIG1lcmdlciBpcyBwb3NzaWJsZS4gTG90cyBvZiBkZXRhaWxzIHJlbWFpbiB0byBiZSB3b3Jr ZWQgb3V0LiBGb3IgZXhhbXBsZSwgSQ0KICBzdGlsbCBkb24ndCB0aGluayB0aGUgaGVhZGVyIHN0 cnVjdHVyZSBoYXMgYmVlbiBmbGVzaGVkIG91dC4gIEJ1dCB0aGUgZGV0YWlscyBjYW4gYmUgcmVz b2x2ZWQNCiAgbGF0ZXIuDQoNCiAgUmVnYXJkcywNCiAgQWxleC4NCg0KICBJbiBhIG1lc3NhZ2Ug ZGF0ZWQgMy8yMC8yMDA0IDU6MjE6MjYgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lLCBoYWRpQHpu eXguY29tIHdyaXRlczoNCiAgICBDYW4gd2UganVzdCBzYXkgdG8gdGhlIFdHIHRoYXQgdGhlcmUg aXMgY29uc2Vuc3VzIGZvciBhIG1lcmdlciANCiAgICB3aXRob3V0IHByb3ZpZGluZyBkZXRhaWxz Pw0KICAgIExvb2tpbmcgYXQgdGhpcyBhbmQgcHJldmlvdXMgZW1haWwgZnJvbSBXZWltaW5nIGFz IHdlbGwgYXMgbXkgcHJldmlvdXMNCiAgICBjb25jZXJucyBpbiB0aGUgbGFzdCBlbWFpbCBpIHBv c3RlZCwgaSB0aGluayB3ZSBkb250IGxvb3NlIGFueXRoaW5nIGJ5DQogICAgbm90IHByb3ZpZGlu ZyBkZXRhaWxzLiBJbnN0ZWFkIGxldHMgcmVzZXJ2ZSB0aGUgZW5lcmd5IGZvciBjb21pbmcgdXAN CiAgICB3aXRoIHRoZSBwcm90b2NvbCBhbmQgb3RoZXIgcmVsYXRlZCBkZXRhaWxzLg0KDQogICAg Y2hlZXJzLA0KICAgIGphbWFsDQoNCiAgICBPbiBTYXQsIDIwMDQtMDMtMjAgYXQgMDE6NDYsIHdt d2FuZ0BtYWlsLmh6aWMuZWR1LmNuIHdyb3RlOg0KICAgID4gSGkgSG9ybXV6ZCwNCiAgICA+IA0K ICAgID4gVGhhbmsgeW91IGZvciB5b3VyIHdvcmsgb24gdGhlIHN1bW1hcnkuDQogICAgPiBQbGVh c2Ugc2VlIHNvbWUgcmVwbGllcyBpbmxpbmUuDQogICAgPiANCiAgICA+IFdlaW1pbmcNCiAgICA+ IA0KICAgID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICA+IEZyb206ICJLaG9z cmF2aSwgSG9ybXV6ZCBNIiA8aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbT4NCiAgICA+IA0K ICAgID4gSGkgQWxsDQogICAgPiANCiAgICA+IEhlcmUgaXMgYSBicmllZiBzdW1tYXJ5IG9mIGFs bCB0aGUgbWFqb3IgaXNzdWVzIHRoYXQgdGhlIHRlYW0gZGlzY3Vzc2VkLg0KICAgID4gDQogICAg PiBJc3N1ZSMgMCBJRHMgaW4gdGhlIGhlYWRlcjotDQogICAgPiBUaGVyZSB3YXMgYSBsb3Qgb2Yg ZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIHJlZ2FyZGluZyB0aGUgbmFtaW5nLA0KICAgID4gc2Vt YW50aWNzLCBsZW5ndGggb2YgdGhlc2UgSURzLg0KICAgID4gVGhlIHJlc3VsdCB3YXMgYXMgZm9s bG93cy4uLg0KICAgID4gTmFtaW5nOiBDRSBJRCwgRkUgSUQNCiAgICA+IFNlbWFudGljczogVXNl ZCB0byBhZGRyZXNzIGEgc2luZ2xlLCBncm91cCBvciBhbGwgQ0VzL0ZFcyByZXNwZWN0aXZlbHkN CiAgICA+IExlbmd0aDogMTYtMzIgYml0cy4uLlRCRA0KICAgID4gDQogICAgPiBbV2VpbWluZ10g SSB0aGluayB3ZSBoYXZlIGFsc28gcmVhY2hlZCBhZ3JlZW1lbnQgb24gdXNpbmcgTEZCIElEIGFu ZCBMRkIgDQogICAgPiBJbnN0YW5jZSBJRCBmb3IgYWRkcmVzc2luZy4gRG8geW91IGFncmVlPw0K ICAgID4gDQogICAgPiBJc3N1ZSMgMSBIZWFkZXIvRW5jb2Rpbmc6LQ0KICAgID4gSGVyZSBhcmUg dGhlIGZpZWxkcyBpbiB0aGUgY29tbW9uIGhlYWRlciB0aGF0IHRoZXJlIHdhcyBjb25zZW5zdXMg YXJvdW5kDQogICAgPiBJRHM6IGFzIHN1bW1hcml6ZWQgaW4gaXNzdWUgMA0KICAgID4gVmVyc2lv bi9zdWItdmVyOiA0IGJpdHMNCiAgICA+IFNlcXVlbmNlIE5vLiA6IDMyIGJpdHMNCiAgICA+IExl bmd0aCA6IDE2IGJpdHMNCiAgICA+IENvbW1hbmQgVHlwZSA6IDggYml0cyAoc2VtYW50aWNzIC0g VEJEKQ0KICAgID4gRmxhZ3M6IDE2IGJpdHMsIGluY2x1ZGluZyAzIGJpdHMgZm9yIFByaW9yaXR5 LiAoVGhlIHNlbWFudGljcy9sZW5ndGggb2YNCiAgICA+IHRoaXMgaXMgVEJEKQ0KICAgID4gDQog ICAgPiBUeXBlSUQ6IFRCRCwgbm8gY29uc2Vuc3VzIG9uIHdoZXRoZXIgaXQgaXMgbmVlZGVkIG9y IG5vdA0KICAgID4gDQogICAgPiBbV2VpbWluZ10gV2UndiBhZ3JlZWQgdG8gdXNlIHByaW9yaXR5 IGJpdChzKSwgaG93IGl0IGlzIGRlZmluZWQgKDFiaXQvM2JpdHMsIA0KICAgID4gYW5kIHRoZSBz ZW1hbnRpY3MpIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGZ1cnRoZXIpLg0KICAgID4gDQogICAgPiBJ c3N1ZSMgMiBNdWx0aXBsZSBjaGFubmVscy9jb25uZWN0aW9uczotDQogICAgPiBUaGVyZSB3YXMg YSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGFzIHdlbGwuIFRoZXJlIHdhcyBhZ3Jl ZW1lbnQNCiAgICA+IG9uIHRoZSBmYWN0IHRoYXQgdGhlcmUgTVVTVCBiZSBhIHdheSB0byBwcmlv cml0aXplIGFuZCBzZXBhcmF0ZSBDb250cm9sDQogICAgPiBhbmQgRGF0YSB0cmFmZmljLiBUaGVy ZSB3YXMgbm8gY2xlYXIgY29uc2Vuc3VzIGFyb3VuZCBtYW5kYXRpbmcgdXNpbmcNCiAgICA+IHNl cGFyYXRlIGNoYW5uZWxzIG9yIGNvbm5lY3Rpb25zIChiZXR0ZXIgdGVybSkgZm9yIERhdGEgYW5k IENvbnRyb2wgaW4NCiAgICA+IG9yZGVyIHRvIHByb3ZpZGUgdGhpcyBzZXBhcmF0aW9uLiBUaGVy ZSB3ZXJlIHJlYXNvbnMgcHJlc2VudGVkIHJlZ2FyZGluZw0KICAgID4gdGhlIGluZWZmZWN0aXZl bmVzcyBvZiBzZXBhcmF0ZSBjb25uZWN0aW9ucyB0byBoZWxwIGR1cmluZyBEb1MgYXR0YWNrcw0K ICAgID4gYXMgd2VsbCBhcyB0aGUgcmVhc29ucyBmb3IgdXNpbmcgcmVsaWFibGUgYW5kIHVucmVs aWFibGUgY29ubmVjdGlvbnMgZm9yDQogICAgPiBDb250cm9sIGFuZCBEYXRhIHJlc3BlY3RpdmVs eS4gVGhlIHVzZSBvZiBzZXBhcmF0ZQ0KICAgID4gdHJhbnNwb3J0cy9jb25uZWN0aW9ucyBpcyBU QkQuDQogICAgPiANCiAgICA+IFtBZ3JlZWRdDQogICAgPiANCiAgICA+IElzc3VlIyAzIFRyYW5z cG9ydDogdW5pY2FzdC9tdWx0aWNhc3QvYnJvYWRjYXN0Oi0NCiAgICA+IFRoZXJlIHdhcyBzb21l IGNvbnNlbnN1cyBhcm91bmQgdGhpcyB0ZXh0IHRvIGRlc2NyaWJlIHRoaXMgaXNzdWUuLi4NCiAg ICA+IA0KICAgID4gQWxsIEZvckNFUyBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbnMsIE1VU1Qgc3Vw cG9ydCBhIHJlbGlhYmxlLCBjb25nZXN0aW9uDQogICAgPiBhd2FyZSBVbmljYXN0IG1ldGhvZCBv ZiBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIENFcyBhbmQgdGhlIEZFcy4NCiAgICA+IEZ1cnRo ZXJtb3JlLCBpbiBjYXNlIG9mIElQIHRoaXMgd2lsbCBiZSBhIFRDUCBvciBTQ1RQIGNvbm5lY3Rp b24gYmV0d2Vlbg0KICAgID4gdGhlIENFIGFuZCBGRXMuIEluIGFkZGl0aW9uIHRvIHRoaXMsIGlu IGNhc2Ugb2YgJ2Nsb3NlIHByb3hpbWl0eScNCiAgICA+IGJldHdlZW4gdGhlIENFcyBhbmQgRkVz IEFuZCBpbiBjYXNlIHRoZSBpbnRlcmNvbm5lY3QgYmV0d2VlbiB0aGVtDQogICAgPiBzdXBwb3J0 cyBtdWx0aWNhc3QsIHRoZSBDRXMgYW5kIEZFcyBNdXN0IGFsc28gZXN0YWJsaXNoIHJlbGlhYmxl LA0KICAgID4gY29uZ2VzdGlvbiBhd2FyZSBNdWx0aWNhc3QgY29ubmVjdGlvbnMuIFRoZSBlc3Rh Ymxpc2htZW50IGFuZCBzZW1hbnRpY3MNCiAgICA+IG9mIHRoZXNlIE11bHRpY2FzdCBjb25uZWN0 aW9ucyBpcyBuZWdvdGlhdGVkIGR1cmluZyB0aGUNCiAgICA+IGJpbmRpbmcvY2FwYWJpbGl0eSBk aXNjb3ZlcnkgcGhhc2UgaW4gdGhlIEZvckNFUyBwcm90b2NvbCBvciBkdXJpbmcNCiAgICA+IHBy ZS1hc3NvY2lhdGlvbiAoVEJEKS4gRm9yIGV4YW1wbGUsIHRoZSBDRSBhbmQgc3Vic2V0IG9mIEZF cyBtaWdodA0KICAgID4gbmVnb3RpYXRlIG9uIGVzdGFibGlzaGluZyBhIE11bHRpY2FzdCBjb25u ZWN0aW9uIGZvciBjb21tdW5pY2F0aW9uIG9mDQogICAgPiBJUHY0IExGQiBhdHRyaWJ1dGVzLiBU aGVzZSByZWxpYWJsZSwgY29uZ2VzdGlvbiBhd2FyZSBjb25uZWN0aW9ucyB3aWxsDQogICAgPiBi ZSB1c2VkIHRvIGNvbW11bmljYXRlIHRoZSBjb250cm9sIG1lc3NhZ2VzIG91dGxpbmVkIGluIFJG QyAzNjU0DQogICAgPiAoc2VjdGlvbiA2LCAjNmMpLiAoRm9yIGRhdGEgbWVzc2FnZXMgc3VjaCBh cyB0aG9zZSBvdXRsaW5lZCBpbiBSRkMgMzY1NA0KICAgID4gKHNlY3Rpb24gNiwgIzZiKSwgdGhl IEZvckNFUyBwcm90b2NvbCBNdXN0L1Nob3VsZCBhbHNvIHN1cHBvcnQgYW4NCiAgICA+IHVuLXJl bGlhYmxlIGJ1dCBjb25nZXN0aW9uIGF3YXJlIFVuaWNhc3QgY29ubmVjdGlvbiBiZXR3ZWVuIHRo ZSBDRSBhbmQNCiAgICA+IEZFcy4tIFRCRDppc3N1ZSMgMikNCiAgICA+IA0KICAgID4gRGF2aWQg cHJvdmlkZWQgc29tZSBjbGFyaWZpY2F0aW9uIHRvIHRoZSBncm91cCBvbiB0aGlzIGlzc3VlIHZp YSBoaXMNCiAgICA+IGVtYWlsIGJlbG93Li4uDQogICAgPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dvcmtpbmctZ3JvdXBzL2ZvcmNlcy1wcm90b2NvbC9jdXJyZW4NCiAgICA+ IHQvbXNnMDAzMTcuaHRtbA0KICAgID4gVGhlcmUgc2VlbXMgdG8gYmUgY29uc2Vuc3VzIGFyb3Vu ZCB0aGUgYXBwcm9hY2hlcyBvdXRsaW5lZCBieSBEYXZpZCBpbg0KICAgID4gaGlzIGVtYWlsLg0K ICAgID4gDQogICAgPiBUaGVyZSB3YXMgYWxzbyBnZW5lcmFsIGNvbnNlbnN1cyBhYm91dCBzZXBh cmF0aW9uIG9mIHRoZSBGb3JDRVMgUEwNCiAgICA+IChwcm90b2NvbCBsYXllcikgZnJvbSB0aGUg VE1MIChUcmFuc3BvcnQgTWFwcGluZyBMYXllcikgYWxhIEdTTVAuIFRoZQ0KICAgID4gbGluayBi ZWxvdyBwcm92aWRlcyBhIGdvb2QgZXhwbGFuYXRpb24gb2YgdGhlc2UgbGF5ZXJzLi4uDQogICAg PiBodHRwOi8vd3d3LnNzdGFuYW1lcmEuY29tL35mb3JjZXMvcHJvdG8vRm9yQ0VTTGF5ZXJlZC5o dG0NCiAgICA+IA0KICAgID4gSXNzdWUjIDQgQ29uZ2VzdGlvbiBjb250cm9sOi0NCiAgICA+IEdl bmVyYWwgY29uc2Vuc3VzIHdhcyB0aGF0IENvbmdlc3Rpb24gQ29udHJvbCAoQ0MpIGlzIGEgTVVT VCBmb3IgdGhlDQogICAgPiBwcm90b2NvbCBmb3IgYWxsIG1lc3NhZ2VzLCB3aGV0aGVyIENvbnRy b2wgb3IgRGF0YSBpbiBvcmRlciB0byBtZWV0IHRoZQ0KICAgID4gYmFzaWMgc2NhbGFiaWxpdHkg cmVxdWlyZW1lbnQuIFRoZXJlIHdhcyBhbHNvIHNvbWUgZGlzY3Vzc2lvbiBhcm91bmQgRG9TDQog ICAgPiBwcm90ZWN0aW9uIGluIGNvbnRleHQgd2l0aCBDQywgYnV0IHRoaXMgaXMgc3RpbGwgYmVp bmcgZGlzY3Vzc2VkLg0KICAgID4gDQogICAgPiBbV2VpbWluZyBdIEhhdmVuJ3Qgd2UgYWNoaWV2 ZWQgYW55dGhpbmcgb24gRG9TPyANCiAgICA+IA0KICAgID4gSXNzdWUjIDUgUmVsaWFiaWxpdHk6 LQ0KICAgID4gR2VuZXJhbCBjb25zZW5zdXMgd2FzIHRoYXQgUmVsaWFiaWxpdHkgaXMgYSBNVVNU IGZvciBhbGwgY29udHJvbA0KICAgID4gbWVzc2FnZXMuIFRoZSBzZXBhcmF0aW9uIG9mIFRNTCBm cm9tIFBMIGhhcyBwcm92aWRlZCB0aGUgdGVhbSB0aGUNCiAgICA+IG9wcG9ydHVuaXR5IHRvIG1h a2UgcHJvZ3Jlc3Mgb24gdGhlIFBMIGFuZCBkZWZlciB0aGUgZGV0YWlscyBvZiB0aGUgVE1MDQog ICAgPiBmb3Igbm93LiBUaGlzIGlzc3VlIGlzIGFsc28gY2xvc2VseSByZWxhdGVkIHRvIGlzc3Vl IyAzIGFuZCBib3RoIHdlcmUNCiAgICA+IGRpc2N1c3NlZCBpbiBwYXJhbGxlbCB0byBzb21lIGV4 dGVudC4NCiAgICA+IA0KICAgID4gSW4gZ2VuZXJhbCwgSSBiZWxpZXZlIHdlIG1hZGUgYSBsb3Qg b2YgZ29vZCBwcm9ncmVzcyA6LSkNCiAgICA+IExldCBtZSBrbm93IGlmIHlvdSBndXlzIGhhdmUg YW55IGNvbW1lbnRzIG9uIHRoaXMgc3VtbWFyeSA/DQogICAgPiANCiAgICA+IFRoYW5rcyB0byBl dmVyeW9uZSBmb3IgdGhlaXIgY29udHJpYnV0aW9ucyENCiAgICA+IEhvcm11emQNCg== ------=_NextPart_000_003A_01C40F6B.829CFBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBCQUNLR1JP VU5ELUNPTE9SOiAjZmZmZmZmIiANCmJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGkgQWxleCw8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgYWdyZWUgd2l0aCB5b3UuIFdoYXQgSSd2IGp1 c3QgcG9zdGVkIGFsc28gbWVhbnMgdGhpcy4gTm93IHdlIG9ubHkgbmVlZCB0byANCmRlY2lkZSBp cyBpZiB0aGUgbWVyZ2VyIGlzIHBvc3NpYmxlLCB3ZSB0aGVuIGNhbiBoYXZlIGxvdHMgb2YgdGlt ZSBkaXNjdXNzaW5nIA0KdGhlIGRldGFpbHMsIGluY2x1ZGluZyB0aGUgc3VtbWFyeSBmb3IgcHJl dmlvdXMgZGlzY3Vzc2lvbnMuIDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QlI8L0RJ Vj4NCjxESVY+d2VpbWluZzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURE SU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JE RVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBz dHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJ Vj4NCiAgPERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgYXJp YWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPUFhdWR1MjAw MEBhb2wuY29tIA0KICBocmVmPSJtYWlsdG86QWF1ZHUyMDAwQGFvbC5jb20iPkFhdWR1MjAwMEBh b2wuY29tPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+VG86 PC9CPiA8QSB0aXRsZT1oYWRpQHpueXguY29tIA0KICBocmVmPSJtYWlsdG86aGFkaUB6bnl4LmNv bSI+aGFkaUB6bnl4LmNvbTwvQT4gOyA8QSANCiAgdGl0bGU9d213YW5nQG1haWwuaHppYy5lZHUu Y24gDQogIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+d213YW5nQG1haWwu aHppYy5lZHUuY248L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48 Qj5DYzo8L0I+IDxBIHRpdGxlPWZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyANCiAgaHJlZj0ibWFp bHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U2VudDo8L0I+IFN1 bmRheSwgTWFyY2ggMjEsIDIwMDQgMjoyMCANClBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gU3VtbWFy eSANCiAgZm9yIGlzc3VlcyAwLTU8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+DQog IDxESVY+SGkgQWxsLDwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPkRlZmluaXRl bHkgdGhlIG1lcmdlciBpcyBwb3NzaWJsZS4mbmJzcDtMb3RzIG9mIGRldGFpbHMgcmVtYWluIHRv IGJlIA0KICB3b3JrZWQgb3V0LiBGb3IgZXhhbXBsZSwmbmJzcDtJPC9ESVY+DQogIDxESVY+c3Rp bGwgZG9uJ3QgdGhpbmsgdGhlIGhlYWRlciBzdHJ1Y3R1cmUgaGFzIGJlZW4gZmxlc2hlZCBvdXQu Jm5ic3A7IEJ1dCANCiAgdGhlIGRldGFpbHMgY2FuIGJlIHJlc29sdmVkPC9ESVY+DQogIDxESVY+ bGF0ZXIuPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+UmVnYXJkcyw8L0RJVj4N CiAgPERJVj5BbGV4LjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPkluIGEgbWVz c2FnZSBkYXRlZCAzLzIwLzIwMDQgNToyMToyNiBQTSBDZW50cmFsIFN0YW5kYXJkIFRpbWUsIDxB IA0KICBocmVmPSJtYWlsdG86aGFkaUB6bnl4LmNvbSI+aGFkaUB6bnl4LmNvbTwvQT4gd3JpdGVz OjwvRElWPg0KICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJH SU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogYmx1ZSAycHggc29saWQiPjxGT05UIA0KICAgIGZh Y2U9QXJpYWw+Q2FuIHdlIGp1c3Qgc2F5IHRvIHRoZSBXRyB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1 cyBmb3IgYSBtZXJnZXIgDQogICAgPEJSPndpdGhvdXQgcHJvdmlkaW5nIGRldGFpbHM/PEJSPkxv b2tpbmcgYXQgdGhpcyBhbmQgcHJldmlvdXMgZW1haWwgZnJvbSANCiAgICBXZWltaW5nIGFzIHdl bGwgYXMgbXkgcHJldmlvdXM8QlI+Y29uY2VybnMgaW4gdGhlIGxhc3QgZW1haWwgaSBwb3N0ZWQs IGkgDQogICAgdGhpbmsgd2UgZG9udCBsb29zZSBhbnl0aGluZyBieTxCUj5ub3QgcHJvdmlkaW5n IGRldGFpbHMuIEluc3RlYWQgbGV0cyANCiAgICByZXNlcnZlIHRoZSBlbmVyZ3kgZm9yIGNvbWlu ZyB1cDxCUj53aXRoIHRoZSBwcm90b2NvbCBhbmQgb3RoZXIgcmVsYXRlZCANCiAgICBkZXRhaWxz LjxCUj48QlI+Y2hlZXJzLDxCUj5qYW1hbDxCUj48QlI+T24gU2F0LCAyMDA0LTAzLTIwIGF0IDAx OjQ2LCANCiAgICB3bXdhbmdAbWFpbC5oemljLmVkdS5jbiB3cm90ZTo8QlI+Jmd0OyBIaSBIb3Jt dXpkLDxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoYW5rIA0KICAgIHlvdSBmb3IgeW91ciB3b3JrIG9uIHRo ZSBzdW1tYXJ5LjxCUj4mZ3Q7IFBsZWFzZSBzZWUgc29tZSByZXBsaWVzIA0KICAgIGlubGluZS48 QlI+Jmd0OyA8QlI+Jmd0OyBXZWltaW5nPEJSPiZndDsgPEJSPiZndDsgLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSANCiAgICAtLS0tLSA8QlI+Jmd0OyBGcm9tOiAiS2hvc3JhdmksIEhvcm11emQgTSIg DQogICAgJmx0O2hvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20mZ3Q7PEJSPiZndDsgPEJSPiZn dDsgSGkgQWxsPEJSPiZndDsgDQogICAgPEJSPiZndDsgSGVyZSBpcyBhIGJyaWVmIHN1bW1hcnkg b2YgYWxsIHRoZSBtYWpvciBpc3N1ZXMgdGhhdCB0aGUgdGVhbSANCiAgICBkaXNjdXNzZWQuPEJS PiZndDsgPEJSPiZndDsgSXNzdWUjIDAgSURzIGluIHRoZSBoZWFkZXI6LTxCUj4mZ3Q7IFRoZXJl IHdhcyBhIA0KICAgIGxvdCBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMgcmVnYXJkaW5nIHRo ZSBuYW1pbmcsPEJSPiZndDsgc2VtYW50aWNzLCANCiAgICBsZW5ndGggb2YgdGhlc2UgSURzLjxC Uj4mZ3Q7IFRoZSByZXN1bHQgd2FzIGFzIGZvbGxvd3MuLi48QlI+Jmd0OyBOYW1pbmc6IENFIA0K ICAgIElELCBGRSBJRDxCUj4mZ3Q7IFNlbWFudGljczogVXNlZCB0byBhZGRyZXNzIGEgc2luZ2xl LCBncm91cCBvciBhbGwgQ0VzL0ZFcyANCiAgICByZXNwZWN0aXZlbHk8QlI+Jmd0OyBMZW5ndGg6 IDE2LTMyIGJpdHMuLi5UQkQ8QlI+Jmd0OyA8QlI+Jmd0OyBbV2VpbWluZ10gSSANCiAgICB0aGlu ayB3ZSBoYXZlIGFsc28gcmVhY2hlZCBhZ3JlZW1lbnQgb24gdXNpbmcgTEZCIElEIGFuZCBMRkIg PEJSPiZndDsgDQogICAgSW5zdGFuY2UgSUQgZm9yIGFkZHJlc3NpbmcuIERvIHlvdSBhZ3JlZT88 QlI+Jmd0OyA8QlI+Jmd0OyBJc3N1ZSMgMSANCiAgICBIZWFkZXIvRW5jb2Rpbmc6LTxCUj4mZ3Q7 IEhlcmUgYXJlIHRoZSBmaWVsZHMgaW4gdGhlIGNvbW1vbiBoZWFkZXIgdGhhdCANCiAgICB0aGVy ZSB3YXMgY29uc2Vuc3VzIGFyb3VuZDxCUj4mZ3Q7IElEczogYXMgc3VtbWFyaXplZCBpbiBpc3N1 ZSAwPEJSPiZndDsgDQogICAgVmVyc2lvbi9zdWItdmVyOiA0IGJpdHM8QlI+Jmd0OyBTZXF1ZW5j ZSBOby4gOiAzMiBiaXRzPEJSPiZndDsgTGVuZ3RoIDogMTYgDQogICAgYml0czxCUj4mZ3Q7IENv bW1hbmQgVHlwZSA6IDggYml0cyAoc2VtYW50aWNzIC0gVEJEKTxCUj4mZ3Q7IEZsYWdzOiAxNiBi aXRzLCANCiAgICBpbmNsdWRpbmcgMyBiaXRzIGZvciBQcmlvcml0eS4gKFRoZSBzZW1hbnRpY3Mv bGVuZ3RoIG9mPEJSPiZndDsgdGhpcyBpcyANCiAgICBUQkQpPEJSPiZndDsgPEJSPiZndDsgVHlw ZUlEOiBUQkQsIG5vIGNvbnNlbnN1cyBvbiB3aGV0aGVyIGl0IGlzIG5lZWRlZCBvciANCiAgICBu b3Q8QlI+Jmd0OyA8QlI+Jmd0OyBbV2VpbWluZ10gV2UndiBhZ3JlZWQgdG8gdXNlIHByaW9yaXR5 IGJpdChzKSwgaG93IGl0IGlzIA0KICAgIGRlZmluZWQgKDFiaXQvM2JpdHMsIDxCUj4mZ3Q7IGFu ZCB0aGUgc2VtYW50aWNzKSBuZWVkIHRvIGJlIGRpc2N1c3NlZCANCiAgICBmdXJ0aGVyKS48QlI+ Jmd0OyA8QlI+Jmd0OyBJc3N1ZSMgMiBNdWx0aXBsZSBjaGFubmVscy9jb25uZWN0aW9uczotPEJS PiZndDsgDQogICAgVGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBh cyB3ZWxsLiBUaGVyZSB3YXMgDQogICAgYWdyZWVtZW50PEJSPiZndDsgb24gdGhlIGZhY3QgdGhh dCB0aGVyZSBNVVNUIGJlIGEgd2F5IHRvIHByaW9yaXRpemUgYW5kIA0KICAgIHNlcGFyYXRlIENv bnRyb2w8QlI+Jmd0OyBhbmQgRGF0YSB0cmFmZmljLiBUaGVyZSB3YXMgbm8gY2xlYXIgY29uc2Vu c3VzIA0KICAgIGFyb3VuZCBtYW5kYXRpbmcgdXNpbmc8QlI+Jmd0OyBzZXBhcmF0ZSBjaGFubmVs cyBvciBjb25uZWN0aW9ucyAoYmV0dGVyIA0KICAgIHRlcm0pIGZvciBEYXRhIGFuZCBDb250cm9s IGluPEJSPiZndDsgb3JkZXIgdG8gcHJvdmlkZSB0aGlzIHNlcGFyYXRpb24uIA0KICAgIFRoZXJl IHdlcmUgcmVhc29ucyBwcmVzZW50ZWQgcmVnYXJkaW5nPEJSPiZndDsgdGhlIGluZWZmZWN0aXZl bmVzcyBvZiANCiAgICBzZXBhcmF0ZSBjb25uZWN0aW9ucyB0byBoZWxwIGR1cmluZyBEb1MgYXR0 YWNrczxCUj4mZ3Q7IGFzIHdlbGwgYXMgdGhlIA0KICAgIHJlYXNvbnMgZm9yIHVzaW5nIHJlbGlh YmxlIGFuZCB1bnJlbGlhYmxlIGNvbm5lY3Rpb25zIGZvcjxCUj4mZ3Q7IENvbnRyb2wgDQogICAg YW5kIERhdGEgcmVzcGVjdGl2ZWx5LiBUaGUgdXNlIG9mIHNlcGFyYXRlPEJSPiZndDsgdHJhbnNw b3J0cy9jb25uZWN0aW9ucyBpcyANCiAgICBUQkQuPEJSPiZndDsgPEJSPiZndDsgW0FncmVlZF08 QlI+Jmd0OyA8QlI+Jmd0OyBJc3N1ZSMgMyBUcmFuc3BvcnQ6IA0KICAgIHVuaWNhc3QvbXVsdGlj YXN0L2Jyb2FkY2FzdDotPEJSPiZndDsgVGhlcmUgd2FzIHNvbWUgY29uc2Vuc3VzIGFyb3VuZCB0 aGlzIA0KICAgIHRleHQgdG8gZGVzY3JpYmUgdGhpcyBpc3N1ZS4uLjxCUj4mZ3Q7IDxCUj4mZ3Q7 IEFsbCBGb3JDRVMgcHJvdG9jb2wgDQogICAgaW1wbGVtZW50YXRpb25zLCBNVVNUIHN1cHBvcnQg YSByZWxpYWJsZSwgY29uZ2VzdGlvbjxCUj4mZ3Q7IGF3YXJlIFVuaWNhc3QgDQogICAgbWV0aG9k IG9mIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgQ0VzIGFuZCB0aGUgRkVzLjxCUj4mZ3Q7IEZ1 cnRoZXJtb3JlLCBpbiANCiAgICBjYXNlIG9mIElQIHRoaXMgd2lsbCBiZSBhIFRDUCBvciBTQ1RQ IGNvbm5lY3Rpb24gYmV0d2VlbjxCUj4mZ3Q7IHRoZSBDRSBhbmQgDQogICAgRkVzLiBJbiBhZGRp dGlvbiB0byB0aGlzLCBpbiBjYXNlIG9mICdjbG9zZSBwcm94aW1pdHknPEJSPiZndDsgYmV0d2Vl biB0aGUgDQogICAgQ0VzIGFuZCBGRXMgQW5kIGluIGNhc2UgdGhlIGludGVyY29ubmVjdCBiZXR3 ZWVuIHRoZW08QlI+Jmd0OyBzdXBwb3J0cyANCiAgICBtdWx0aWNhc3QsIHRoZSBDRXMgYW5kIEZF cyBNdXN0IGFsc28gZXN0YWJsaXNoIHJlbGlhYmxlLDxCUj4mZ3Q7IGNvbmdlc3Rpb24gDQogICAg YXdhcmUgTXVsdGljYXN0IGNvbm5lY3Rpb25zLiBUaGUgZXN0YWJsaXNobWVudCBhbmQgc2VtYW50 aWNzPEJSPiZndDsgb2YgDQogICAgdGhlc2UgTXVsdGljYXN0IGNvbm5lY3Rpb25zIGlzIG5lZ290 aWF0ZWQgZHVyaW5nIHRoZTxCUj4mZ3Q7IA0KICAgIGJpbmRpbmcvY2FwYWJpbGl0eSBkaXNjb3Zl cnkgcGhhc2UgaW4gdGhlIEZvckNFUyBwcm90b2NvbCBvciBkdXJpbmc8QlI+Jmd0OyANCiAgICBw cmUtYXNzb2NpYXRpb24gKFRCRCkuIEZvciBleGFtcGxlLCB0aGUgQ0UgYW5kIHN1YnNldCBvZiBG RXMgbWlnaHQ8QlI+Jmd0OyANCiAgICBuZWdvdGlhdGUgb24gZXN0YWJsaXNoaW5nIGEgTXVsdGlj YXN0IGNvbm5lY3Rpb24gZm9yIGNvbW11bmljYXRpb24gDQogICAgb2Y8QlI+Jmd0OyBJUHY0IExG QiBhdHRyaWJ1dGVzLiBUaGVzZSByZWxpYWJsZSwgY29uZ2VzdGlvbiBhd2FyZSBjb25uZWN0aW9u cyANCiAgICB3aWxsPEJSPiZndDsgYmUgdXNlZCB0byBjb21tdW5pY2F0ZSB0aGUgY29udHJvbCBt ZXNzYWdlcyBvdXRsaW5lZCBpbiBSRkMgDQogICAgMzY1NDxCUj4mZ3Q7IChzZWN0aW9uIDYsICM2 YykuIChGb3IgZGF0YSBtZXNzYWdlcyBzdWNoIGFzIHRob3NlIG91dGxpbmVkIGluIA0KICAgIFJG QyAzNjU0PEJSPiZndDsgKHNlY3Rpb24gNiwgIzZiKSwgdGhlIEZvckNFUyBwcm90b2NvbCBNdXN0 L1Nob3VsZCBhbHNvIA0KICAgIHN1cHBvcnQgYW48QlI+Jmd0OyB1bi1yZWxpYWJsZSBidXQgY29u Z2VzdGlvbiBhd2FyZSBVbmljYXN0IGNvbm5lY3Rpb24gDQogICAgYmV0d2VlbiB0aGUgQ0UgYW5k PEJSPiZndDsgRkVzLi0gVEJEOmlzc3VlIyAyKTxCUj4mZ3Q7IDxCUj4mZ3Q7IERhdmlkIA0KICAg IHByb3ZpZGVkIHNvbWUgY2xhcmlmaWNhdGlvbiB0byB0aGUgZ3JvdXAgb24gdGhpcyBpc3N1ZSB2 aWEgaGlzPEJSPiZndDsgZW1haWwgDQogICAgYmVsb3cuLi48QlI+Jmd0OyANCiAgICBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dvcmtpbmctZ3JvdXBzL2ZvcmNlcy1wcm90b2Nv bC9jdXJyZW48QlI+Jmd0OyANCiAgICB0L21zZzAwMzE3Lmh0bWw8QlI+Jmd0OyBUaGVyZSBzZWVt cyB0byBiZSBjb25zZW5zdXMgYXJvdW5kIHRoZSBhcHByb2FjaGVzIA0KICAgIG91dGxpbmVkIGJ5 IERhdmlkIGluPEJSPiZndDsgaGlzIGVtYWlsLjxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZXJlIHdhcyBh bHNvIA0KICAgIGdlbmVyYWwgY29uc2Vuc3VzIGFib3V0IHNlcGFyYXRpb24gb2YgdGhlIEZvckNF UyBQTDxCUj4mZ3Q7IChwcm90b2NvbCBsYXllcikgDQogICAgZnJvbSB0aGUgVE1MIChUcmFuc3Bv cnQgTWFwcGluZyBMYXllcikgYWxhIEdTTVAuIFRoZTxCUj4mZ3Q7IGxpbmsgYmVsb3cgDQogICAg cHJvdmlkZXMgYSBnb29kIGV4cGxhbmF0aW9uIG9mIHRoZXNlIGxheWVycy4uLjxCUj4mZ3Q7IA0K ICAgIGh0dHA6Ly93d3cuc3N0YW5hbWVyYS5jb20vfmZvcmNlcy9wcm90by9Gb3JDRVNMYXllcmVk Lmh0bTxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KICAgIElzc3VlIyA0IENvbmdlc3Rpb24gY29udHJvbDot PEJSPiZndDsgR2VuZXJhbCBjb25zZW5zdXMgd2FzIHRoYXQgQ29uZ2VzdGlvbiANCiAgICBDb250 cm9sIChDQykgaXMgYSBNVVNUIGZvciB0aGU8QlI+Jmd0OyBwcm90b2NvbCBmb3IgYWxsIG1lc3Nh Z2VzLCB3aGV0aGVyIA0KICAgIENvbnRyb2wgb3IgRGF0YSBpbiBvcmRlciB0byBtZWV0IHRoZTxC Uj4mZ3Q7IGJhc2ljIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50LiANCiAgICBUaGVyZSB3YXMgYWxz byBzb21lIGRpc2N1c3Npb24gYXJvdW5kIERvUzxCUj4mZ3Q7IHByb3RlY3Rpb24gaW4gY29udGV4 dCB3aXRoIA0KICAgIENDLCBidXQgdGhpcyBpcyBzdGlsbCBiZWluZyBkaXNjdXNzZWQuPEJSPiZn dDsgPEJSPiZndDsgW1dlaW1pbmcgXSBIYXZlbid0IA0KICAgIHdlIGFjaGlldmVkIGFueXRoaW5n IG9uIERvUz8gPEJSPiZndDsgPEJSPiZndDsgSXNzdWUjIDUgDQogICAgUmVsaWFiaWxpdHk6LTxC Uj4mZ3Q7IEdlbmVyYWwgY29uc2Vuc3VzIHdhcyB0aGF0IFJlbGlhYmlsaXR5IGlzIGEgTVVTVCBm b3IgDQogICAgYWxsIGNvbnRyb2w8QlI+Jmd0OyBtZXNzYWdlcy4gVGhlIHNlcGFyYXRpb24gb2Yg VE1MIGZyb20gUEwgaGFzIHByb3ZpZGVkIHRoZSANCiAgICB0ZWFtIHRoZTxCUj4mZ3Q7IG9wcG9y dHVuaXR5IHRvIG1ha2UgcHJvZ3Jlc3Mgb24gdGhlIFBMIGFuZCBkZWZlciB0aGUgDQogICAgZGV0 YWlscyBvZiB0aGUgVE1MPEJSPiZndDsgZm9yIG5vdy4gVGhpcyBpc3N1ZSBpcyBhbHNvIGNsb3Nl bHkgcmVsYXRlZCB0byANCiAgICBpc3N1ZSMgMyBhbmQgYm90aCB3ZXJlPEJSPiZndDsgZGlzY3Vz c2VkIGluIHBhcmFsbGVsIHRvIHNvbWUgZXh0ZW50LjxCUj4mZ3Q7IA0KICAgIDxCUj4mZ3Q7IElu IGdlbmVyYWwsIEkgYmVsaWV2ZSB3ZSBtYWRlIGEgbG90IG9mIGdvb2QgcHJvZ3Jlc3MgOi0pPEJS PiZndDsgDQogICAgTGV0IG1lIGtub3cgaWYgeW91IGd1eXMgaGF2ZSBhbnkgY29tbWVudHMgb24g dGhpcyBzdW1tYXJ5ID88QlI+Jmd0OyA8QlI+Jmd0OyANCiAgICBUaGFua3MgdG8gZXZlcnlvbmUg Zm9yIHRoZWlyIGNvbnRyaWJ1dGlvbnMhPEJSPiZndDsgDQogIEhvcm11emQ8L0ZPTlQ+PC9CTE9D S1FVT1RFPjwvRElWPg0KICA8RElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_003A_01C40F6B.829CFBE0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 13:37:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23200 for ; Sun, 21 Mar 2004 13:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57oZ-0001sd-3N for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:36:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LIapUb007227 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:36:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57oY-0001sU-U5 for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 13:36:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23134 for ; Sun, 21 Mar 2004 13:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B57oW-0000nt-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:36:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B57nf-0000dU-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:35:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B57mn-0000S1-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57mo-0001il-Qv; Sun, 21 Mar 2004 13:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57lu-0001f3-6B for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 13:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22812 for ; Sun, 21 Mar 2004 13:34:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B57lr-0000Fx-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:34:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B57kq-00002K-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:33:01 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B57jp-0007Ym-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:31:57 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2LIZP6P031845; Sun, 21 Mar 2004 18:35:25 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2LIXNEU015548; Sun, 21 Mar 2004 18:33:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032110311804885 ; Sun, 21 Mar 2004 10:31:18 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 21 Mar 2004 10:31: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 Subject: RE: [Forces-protocol] Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEAA1@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary for issues 0-5 Thread-Index: AcQOH9wF/acblQsDQUmRFrPJE85Z7gBUqYKQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 21 Mar 2004 18:31:18.0068 (UTC) FILETIME=[B337BF40:01C40F72] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 10:31:17 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable That's fine Jamal. I will add this note below. BTW, do you disagree with any of the text below ? Lets discuss Security, Availability when we get to those issues. Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, March 19, 2004 6:06 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary for issues 0-5 Hi Hormuzd, I think issues 2-5 can mow be described with the TML separation. i.e the TML layer will take care of: - management of Multiple channels/connections - Transport: unicast/multicast/broadcast - Congestion control - Reliability We may as well add: security, availability. Thoughts? cheers, jamal On Fri, 2004-03-19 at 19:41, Khosravi, Hormuzd M wrote: > Hi All >=20 > Here is a brief summary of all the major issues that the team discussed. >=20 > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD >=20 > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 3 bits for Priority. (The semantics/length of > this is TBD) >=20 > TypeID: TBD, no consensus on whether it is needed or not >=20 > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. >=20 > Issue# 3 Transport: unicast/multicast/broadcast:- > There was some consensus around this text to describe this issue... >=20 > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) >=20 > David provided some clarification to the group on this issue via his > email below... > https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren > t/msg00317.html > There seems to be consensus around the approaches outlined by David in > his email. >=20 > There was also general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm >=20 > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. >=20 > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. >=20 >=20 > In general, I believe we made a lot of good progress :-) > Let me know if you guys have any comments on this summary ? >=20 > Thanks to everyone for their contributions! > Hormuzd >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 13:44:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23486 for ; Sun, 21 Mar 2004 13:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57vL-0002WL-P2 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:43:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LIhpvu009683 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57vL-0002W6-Kz for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 13:43:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23455 for ; Sun, 21 Mar 2004 13:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B57vJ-0001WL-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:43:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B57uQ-0001Qz-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:42:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B57tX-0001LL-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57tZ-0002Sz-3s; Sun, 21 Mar 2004 13:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B57tP-0002SN-L5 for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 13:41:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23409 for ; Sun, 21 Mar 2004 13:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B57tN-0001Jf-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B57sT-0001EN-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:40:54 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B57s6-00019M-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:40:30 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2LIgHt5030269; Sun, 21 Mar 2004 18:42:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2LIflEm018248; Sun, 21 Mar 2004 18:42:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032110395805321 ; Sun, 21 Mar 2004 10:39:58 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 21 Mar 2004 10:39:58 -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 Subject: RE: [Forces-protocol] summary of discussions so far... (part 1) Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEAA5@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] summary of discussions so far... (part 1) Thread-Index: AcQOQ6kmLkR2iDFPQhWQSa5FbKWBtwBL556Q From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 21 Mar 2004 18:39:58.0822 (UTC) FILETIME=[E99C8060:01C40F73] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 10:39:58 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Weiming, I think you are reading too much into this. By TLV I don't mean a specific implementation that we have done for FACT. What I mean is using some kind of compact encoding other than XML, OIDs, etc. I believe there is agreement on this and all the protocols are using this. What you have provided below are details which still need to be flushed out. But that doesn't mean we don't agree on the basics. I will clarify in the text that the "details of TLV encoding are TBD" Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Sent: Friday, March 19, 2004 10:32 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] summary of discussions so far... (part 1) Hi Hormuzd, ----- Original Message -----=20 From: "Khosravi, Hormuzd M" Hi All ..... The ForCES protocol payload consists of a number of variable size TLVs i.e. all ForCES messages must use TLV encoding. The TLVs should also be 32-bit aligned. [Weiming Re] I'm afraid this sub-issue has not completely come to an agreement.=20 I actually agree to use TLVs in ForCES protocol. The only question is why it=20 should be MUST. I think we only need to use it when we actually need it.=20 Talking about this, I'm afraid I have to kindly mention FACT again. I have just=20 found that in many cases inside FACT where the first layer 'Tag' and 'Length'=20 field are used, after these fields have been moved away while without any other=20 changes, the protocol still can run very well . Please allow me to take one=20 from FACT as an examples as below (FACT P.18): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Tag (0x04) | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Reason |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 When we just use: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Reason |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 It still can work well. In this way, we actually have taken the 'reason' field=20 as a field inside the large ForCES message TLV( the message type as the T, the=20 message length as the L). To compare with, I would more appreciate the way the TLV is used in Netlink2,=20 in which I think it has not strictly tried to use TLV when not necessary. For=20 example, the Netlink2 ACK message (Netlink2 P.28): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Netlink2 message header | | type =3D NLMSG_ERROR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | error code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLD Netlink2 message header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the error code and old message header part are explicitly expressed=20 instead by TLVs.=20 Actually GRMP has taken the way like this to use TLV. That is to use TLV only=20 when necessary.=20 Another problem related to strictly and uniformly use TLV in the payload of the=20 message body is, then we have to define the TLV's Tag field globally even when=20 the TLV is a very micro item (as above example where the Tag (0x04) is glabal),=20 which may result in so many types of TLV we need to define, as a result, I'm=20 not sure if the 16 bits space will become exausted or not in the future. As a result, I would prefer to use TLVs as follows: 1. All items (parameters) that have variable length and are mostly defined by=20 FE models Must be defined as TLVs. 2. All items that actually have global meanings for more than one kind of=20 ForCES messages is better to be defined as TLVs.=20 3. All items that are optional to a message payload is better been described as=20 TLV(just like IP, TCP, etc do) Anyway, I just want to say that it may be too early to decide "all ForCES=20 messages must use TLV encoding". We may need to gain more experiences (when we=20 actually begin to encode the ForCES messages), then to decide it. I don't think=20 to do in this way has any harm to all of us.=20 Yours, Weiming ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 13:58:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23772 for ; Sun, 21 Mar 2004 13:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B588w-00040s-EA for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:57:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LIvsBg015420 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 13:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B588w-00040d-8q for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 13:57:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23741 for ; Sun, 21 Mar 2004 13:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B588t-0002pO-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B587v-0002jb-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:56:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5876-0002eg-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 13:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5877-0003YE-T1; Sun, 21 Mar 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B586y-0003Xi-2o for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 13:55:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23688 for ; Sun, 21 Mar 2004 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B586v-0002dM-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5864-0002Xu-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:54:57 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B585I-0002Lf-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 13:54:08 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2LIvg6P007804; Sun, 21 Mar 2004 18:57:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2LItdEW022903; Sun, 21 Mar 2004 18:55:42 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032110533706116 ; Sun, 21 Mar 2004 10:53:37 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 21 Mar 2004 10:53: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 Subject: RE: [Forces-protocol] Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEAAA@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary for issues 0-5 Thread-Index: AcQOReVubHf8y/mYQ3mykrt7br24rQBLr/8w From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 21 Mar 2004 18:53:36.0994 (UTC) FILETIME=[D147A420:01C40F75] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 10:53:36 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, Thanks for your comments ! See my replies below, I'll make the appropriate changes. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn. Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD [Weiming] I think we have also reached agreement on using LFB ID and LFB Instance ID for addressing. Do you agree?=20 [HK]Yes I will add this as part of the payload, good catch. Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 3 bits for Priority. (The semantics/length of this is TBD) TypeID: TBD, no consensus on whether it is needed or not [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits,=20 and the semantics) need to be discussed further). [HK] OK, I'll make this change, Issue# 2 Multiple channels/connections:- There was a lot of discussion on this topic as well. There was agreement on the fact that there MUST be a way to prioritize and separate Control and Data traffic. There was no clear consensus around mandating using separate channels or connections (better term) for Data and Control in order to provide this separation. There were reasons presented regarding the ineffectiveness of separate connections to help during DoS attacks as well as the reasons for using reliable and unreliable connections for Control and Data respectively. The use of separate transports/connections is TBD. [Agreed] Issue# 3 Transport: unicast/multicast/broadcast:- There was some consensus around this text to describe this issue... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association (TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) David provided some clarification to the group on this issue via his email below... https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren t/msg00317.html There seems to be consensus around the approaches outlined by David in his email. There was also general consensus about separation of the ForCES PL (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm Issue# 4 Congestion control:- General consensus was that Congestion Control (CC) is a MUST for the protocol for all messages, whether Control or Data in order to meet the basic scalability requirement. There was also some discussion around DoS protection in context with CC, but this is still being discussed. [Weiming ] Haven't we achieved anything on DoS?=20 [HK] I don't think so, let me know if you think I should add some text that we have agreed on ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 14:06:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24169 for ; Sun, 21 Mar 2004 14:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B58Gl-0004Yu-29 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 14:06:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LJ5xou017530 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 14:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B58Gk-0004Yf-Sf for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 14:05:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24121 for ; Sun, 21 Mar 2004 14:05:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B58Gi-0003uY-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 14:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B58Ff-0003kM-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 14:04:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B58Eo-0003cI-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 14:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B58Eq-0004Rp-Nr; Sun, 21 Mar 2004 14:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B58EG-0004Pw-1R for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 14:03:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23977 for ; Sun, 21 Mar 2004 14:03:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B58ED-0003WB-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 14:03:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B58D5-0003Lb-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 14:02:12 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B58CE-00039S-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 14:01:18 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2LJ4p6P010788; Sun, 21 Mar 2004 19:04:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2LJ2pEU025759; Sun, 21 Mar 2004 19:02:51 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032111004606652 ; Sun, 21 Mar 2004 11:00:46 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 21 Mar 2004 11:00: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 Subject: RE: [Forces-protocol] Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEAAC@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary for issues 0-5 Thread-Index: AcQO0giPdhXT0QZtTr2Z9CSjMqQH8QAofHcQ From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 21 Mar 2004 19:00:46.0048 (UTC) FILETIME=[D1041600:01C40F76] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 21 Mar 2004 11:00:45 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, Weiming If we all agree that the merger is possible then why cant we provide some details to the WG about the discussions that we have had so far ? I think its very important and we are obliged to keep all the members informed about whats going on. This is part of the IETF open door policy, everyone is entitled to know whats been going on. Unless we don't agree with the summary sent out (which is not the case) I think this is very important. The other advantage to this is to have the WG members comment on any issues that we don't agree on. Avri pointed this out and I think it would be a very good way of resolving issues. Also, based on my experiences on the Requirements RFC, I would prefer to have an open discussion on the list upfront rather than repeat all the same arguments later. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Saturday, March 20, 2004 3:18 PM To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary for issues 0-5 Can we just say to the WG that there is consensus for a merger=20 without providing details? Looking at this and previous email from Weiming as well as my previous concerns in the last email i posted, i think we dont loose anything by not providing details. Instead lets reserve the energy for coming up with the protocol and other related details. cheers, jamal On Sat, 2004-03-20 at 01:46, wmwang@mail.hzic.edu.cn wrote: > Hi Hormuzd, >=20 > Thank you for your work on the summary. > Please see some replies inline. >=20 > Weiming >=20 > ----- Original Message -----=20 > From: "Khosravi, Hormuzd M" >=20 > Hi All >=20 > Here is a brief summary of all the major issues that the team discussed. >=20 > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD >=20 > [Weiming] I think we have also reached agreement on using LFB ID and LFB=20 > Instance ID for addressing. Do you agree? >=20 > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 3 bits for Priority. (The semantics/length of > this is TBD) >=20 > TypeID: TBD, no consensus on whether it is needed or not >=20 > [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits,=20 > and the semantics) need to be discussed further). >=20 > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. >=20 > [Agreed] >=20 > Issue# 3 Transport: unicast/multicast/broadcast:- > There was some consensus around this text to describe this issue... >=20 > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) >=20 > David provided some clarification to the group on this issue via his > email below... > https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren > t/msg00317.html > There seems to be consensus around the approaches outlined by David in > his email. >=20 > There was also general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm >=20 > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. >=20 > [Weiming ] Haven't we achieved anything on DoS?=20 >=20 > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. >=20 > In general, I believe we made a lot of good progress :-) > Let me know if you guys have any comments on this summary ? >=20 > Thanks to everyone for their contributions! > Hormuzd >=20 >=20 >=20 >=20 > ------------------------------------------------- > This mail sent through HUCNIC Webmail system. >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 15:30:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29098 for ; Sun, 21 Mar 2004 15:30:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59aD-0006hB-RG for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 15:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LKU9GX025729 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 15:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59aD-0006gA-B6 for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 15:30:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29095 for ; Sun, 21 Mar 2004 15:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B59aC-0006EM-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 15:30:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B59ZY-00065d-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 15:29:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B59YB-0005od-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 15:28:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B59YB-0006p4-Hf for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 15:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59Y9-0006VF-1C; Sun, 21 Mar 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59XE-0006Ee-Rx for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 15:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28764 for ; Sun, 21 Mar 2004 15:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B59XD-0005ab-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 15:27:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B59WE-0005OY-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 15:26:02 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B59VN-0005Cc-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 15:25:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032112273062:10270 ; Sun, 21 Mar 2004 12:27:30 -0800 Subject: RE: [Forces-protocol] Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E3FEAAC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E3FEAAC@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1079900704.1040.110.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 03/21/2004 12:27:31 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/21/2004 12:27:33 PM, Serialize complete at 03/21/2004 12:27:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 21 Mar 2004 15:25:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2004-03-21 at 14:00, Khosravi, Hormuzd M wrote: > Jamal, Weiming > > If we all agree that the merger is possible then why cant we provide > some details to the WG about the discussions that we have had so far ? I > think its very important and we are obliged to keep all the members > informed about whats going on. This is part of the IETF open door > policy, everyone is entitled to know whats been going on. Unless we > don't agree with the summary sent out (which is not the case) I think > this is very important. I just checked who is subscribed to this list and now more than before i am thinking we should focus our energies on getting over the rest of the issues. Other than Joel and probably Lily, there is noone else who is not on this list that contributes regularly (more than once a year that is). If we had reached a good conclusion i would say, yes we should. I think the WG is obligated to know at least we are heading towards a merger. Thats the most important piece of information that needs to be delivered. As you can see we already have small glitches with Weiming and myself making comments. I really dont wanna be spending time correcting little issues. Lets finish the rest of topics - then we can post. I will post the next two topics if noone else does. > The other advantage to this is to have the WG members comment on any > issues that we don't agree on. Avri pointed this out and I think it > would be a very good way of resolving issues. Who are you hoping other than the people on this list already will contribute - most of whom are merely lurking? Joel probably should have been on this list. I am a little suprised he is not. There is no big secret on what we are discussing here. This is more open than anything else that any design team in Forces has ever done (it is being archived). cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Mar 21 17:32:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04111 for ; Sun, 21 Mar 2004 17:32:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5BU6-0006g9-6Y for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 17:31:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LMVwBf025667 for forces-protocol-archive@odin.ietf.org; Sun, 21 Mar 2004 17:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5BU6-0006fu-2F for forces-protocol-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 17:31:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04101 for ; Sun, 21 Mar 2004 17:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5BU3-0005Il-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 17:31:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5BTa-0005EJ-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 17:31:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5BSC-00059s-00 for forces-protocol-web-archive@ietf.org; Sun, 21 Mar 2004 17:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5BSE-0006ch-El; Sun, 21 Mar 2004 17:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5BRH-0006bu-6T for forces-protocol@optimus.ietf.org; Sun, 21 Mar 2004 17:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04045 for ; Sun, 21 Mar 2004 17:28:59 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5BRE-00054a-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 17:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5BQR-0004zK-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 17:28:12 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B5BPe-0004sz-00 for forces-protocol@ietf.org; Sun, 21 Mar 2004 17:27:22 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5BPe-000FjW-Ey for forces-protocol@ietf.org; Sun, 21 Mar 2004 22:27:22 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1079900704.1040.110.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E3FEAAC@orsmsx408.jf.intel.com> <1079900704.1040.110.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Summary for issues 0-5 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 07:27:20 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In this case, especially with the 20th having come and gone, it might be good for the the WG chairs to actually let us know what they expect to be delivered to the group. I think the statement of possible merger, at the least, is due. Even if we do still send the issue list, which I still think is reasonable, it does not need to go out at the same time. And while I agree that spending a lot of time wordcrafting that list at moment seems time consuming when we should be covering the rest of the issues, it is also useful to know where the agreements really are (or aren't), so I do support Hormuzd's attempt to write this. a. On 22 mar 2004, at 05.25, Jamal Hadi Salim wrote: > On Sun, 2004-03-21 at 14:00, Khosravi, Hormuzd M wrote: >> Jamal, Weiming >> >> If we all agree that the merger is possible then why cant we provide >> some details to the WG about the discussions that we have had so far >> ? I >> think its very important and we are obliged to keep all the members >> informed about whats going on. This is part of the IETF open door >> policy, everyone is entitled to know whats been going on. Unless we >> don't agree with the summary sent out (which is not the case) I think >> this is very important. > > I just checked who is subscribed to this list and now more than before > i am thinking we should focus our energies on getting over the rest of > the issues. > Other than Joel and probably Lily, there is noone else who is not > on this list that contributes regularly (more than once a year that > is). > If we had reached a good conclusion i would say, yes we should. > I think the WG is obligated to know at least we are heading towards > a merger. Thats the most important piece of information that needs to > be delivered. > As you can see we already have small glitches with Weiming and myself > making comments. I really dont wanna be spending time correcting > little issues. Lets finish the rest of topics - then we can post. > I will post the next two topics if noone else does. > >> The other advantage to this is to have the WG members comment on any >> issues that we don't agree on. Avri pointed this out and I think it >> would be a very good way of resolving issues. > > Who are you hoping other than the people on this list already will > contribute - most of whom are merely lurking? > Joel probably should have been on this list. I am a little suprised he > is not. There is no big secret on what we are discussing here. > This is more open than anything else that any design team in Forces has > ever done (it is being archived). > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 12:16:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06859 for ; Mon, 22 Mar 2004 12:16:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5T1R-0003wD-Bw for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 12:15:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHFXRu015136 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 12:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5T1Q-0003w3-Qg for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:15:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06831 for ; Mon, 22 Mar 2004 12:15:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5T1P-0006Pc-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:15:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5T0T-0006Jc-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:14:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Sze-0006E8-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:13:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SzZ-0003oe-BC; Mon, 22 Mar 2004 12:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SyV-0003iJ-IQ for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 12:12:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06704 for ; Mon, 22 Mar 2004 12:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SyT-00065c-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:12:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SxW-0005zT-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:11:30 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Swc-0005pI-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:10:34 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MHDd9i003258 for ; Mon, 22 Mar 2004 17:13:39 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MHAQ9c028856 for ; Mon, 22 Mar 2004 17:11:23 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032209091731126 for ; Mon, 22 Mar 2004 09:09:17 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 09:09:17 -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 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FECAC@orsmsx408.jf.intel.com> Thread-Topic: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+QAIuIDSA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Mar 2004 17:09:17.0017 (UTC) FILETIME=[6874B490:01C41030] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: Summary for issues 0-5 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 09:09:16 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Incorporating Weiming's, Jamal's comments... Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD Another issue we reached agreement on was using LFB Type ID, LFB Instance ID in combination of FE ID for addressing LFBs on the FE. The LFB IDs will be part of the payload. Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length of Flags and Priority fields is TBD) TypeID: TBD, no consensus on whether it is needed or not Issue# 2 Multiple channels/connections:- There was a lot of discussion on this topic as well. There was agreement on the fact that there MUST be a way to prioritize and separate Control and Data traffic. There was no clear consensus around mandating using separate channels or connections (better term) for Data and Control in order to provide this separation. There were reasons presented regarding the ineffectiveness of separate connections to help during DoS attacks as well as the reasons for using reliable and unreliable connections for Control and Data respectively. The use of separate transports/connections is TBD. Note: This issue will be further addressed in context with the TML (see below) Issue# 3 Transport: unicast/multicast/broadcast:- There was some consensus around this text to describe this issue... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association (TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) David provided some clarification to the group on this issue via his email below... https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren t/msg00317.html There seems to be consensus around the approaches outlined by David in his email. There was also general consensus about separation of the ForCES PL (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm Issue# 4 Congestion control:- General consensus was that Congestion Control (CC) is a MUST for the protocol for all messages, whether Control or Data in order to meet the basic scalability requirement. There was also some discussion around DoS protection in context with CC, but this is still being discussed. Note: This issue will be further addressed in context with TML Issue# 5 Reliability:- General consensus was that Reliability is a MUST for all control messages. The separation of TML from PL has provided the team the opportunity to make progress on the PL and defer the details of the TML for now. This issue is also closely related to issue# 3 and both were discussed in parallel to some extent. Note: This issue will be further addressed in context with TML Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 12:35:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07897 for ; Mon, 22 Mar 2004 12:35:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TK5-0005i8-Ia for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 12:34:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHYno8021948 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 12:34:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TK5-0005hv-1Y for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07837 for ; Mon, 22 Mar 2004 12:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5TK3-0000r1-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:34:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TJC-0000jU-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:33:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5TIK-0000c6-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 12:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TIL-0005Vm-FM; Mon, 22 Mar 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5THz-0005Le-CN for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 12:32:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07691 for ; Mon, 22 Mar 2004 12:32:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5THx-0000ZA-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:32:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TH7-0000S3-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:31:46 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5TGP-0000G1-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 12:31:01 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MHWWA2006944 for ; Mon, 22 Mar 2004 17:32:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MHMhXP006767 for ; Mon, 22 Mar 2004 17:23:09 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032209294413131 for ; Mon, 22 Mar 2004 09:29:44 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 09:29:44 -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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <52D13A805349A249960B9943E5590BD802B2D56E@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+QAIuIDSAAAK/8wA== From: "Putzolu, David" To: "Khosravi, Hormuzd M" , X-OriginalArrivalTime: 22 Mar 2004 17:29:44.0477 (UTC) FILETIME=[44143CD0:01C41033] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 09:29:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hormuzd - my feedback inline...=20 On Monday March 22, 2004 9:09 AM Hormuzd wrote > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was=20 > consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) I'm not sure that this level of detail is good - was there this much consensus? Maybe instead say there was a consensus on the inclusion of certain types of fields, but leave it for later to get the exact # of bits etc. On Monday March 22, 2004 9:09 AM Hormuzd wrote > > All ForCES protocol implementations, MUST support a reliable,=20 > congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP=20 > connection between the CE and FEs.=20 Careful - I only suggested use of TCP as an example. It would be up to the IP TML team to choose one of these (or DCCP, or RMT). =20 On Monday March 22, 2004 9:09 AM Hormuzd wrote > > In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and=20 > semantics of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD).=20 I had a different impression. Here is some alternate text=20 for the team to consider on the unicast/multicast/etc issue: The ForCES team reached consensus that ForCES would define a set of transport requirements that must be met by any transport implementation. These requirements include an assumption of support for prioritized connections, a reliable, ordered unicast delivery service, and a multicast delivery service (details TBD). The ForCES team reached consensus that a set of concrete transport mappings would be defined in order to achieve interoperability on different transports. An IP TML will be defined that adheres to charter guidelines in regards to use of a RFC2914-compliant transport, per AD feedback. =20 Other non-IP TMLs will be defined as well. The rest looked ok to me. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 13:22:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10146 for ; Mon, 22 Mar 2004 13:22:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5U3g-00010T-LL for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 13:21:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MILumj003846 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 13:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5U3c-0000zo-Jd for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 13:21:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10111 for ; Mon, 22 Mar 2004 13:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5U3V-0006Tp-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5U2Z-0006ML-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:20:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5U1o-0006Fm-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5U1o-0000v2-Qt; Mon, 22 Mar 2004 13:20:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5U1P-0000t4-SN for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 13:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10020 for ; Mon, 22 Mar 2004 13:19:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5U1N-0006EY-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:19:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5U0V-0006A9-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:18:40 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1B5Tzz-0005yt-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:18:07 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2MIHG8d010199; Mon, 22 Mar 2004 12:17:16 -0600 (CST) Message-ID: <405F2DAB.3010800@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Maloy CC: "Putzolu, David" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES References: <52D13A805349A249960B9943E5590BD802B2D19D@orsmsx409.jf.intel.com> <405B7B73.4070407@ericsson.com> In-Reply-To: <405B7B73.4070407@ericsson.com> Content-Type: multipart/alternative; boundary="------------070000010808030908040307" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 12:17:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070000010808030908040307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Jon, One way to reduce the heartbeat overhead is to NOT do it if traffic is being sent between CE and FE in question successfully. So, you only send heartbeat when channel has been idle for a while (some preset time span). I think this is also goes with your selective heartbeat notion. Regards, Alex. Jon Maloy wrote: > /jon > > Putzolu, David wrote: > >>Hi Alex - my response inline. >> >>[snip..] >> >>Alex wrote> >> [snip..] >> >>>Also, the liveness checking by TML can only guarrantee the >>>TML->transport->peerTML connectivity. To make sure PL is >>>in the loop, PL should have its own scheme (e.g. ACKs, >>>heartbeat,..). That checks the PL->TML->transport->peerTML->peerPL >>> removed connectivity. This helps ensure the PL is not off in the weeds or or crashed while the transport is fine. It also helps problem isolation. >>>[David] >>>Having a PL <-> PL heartbeat, to make sure the PL is alive, >>>makes sense. I agree that this is separate from TML liveness. >>>[/David] >>> >>> > Both are needed, but the PL supervision can (and should be) made much > more selective, i.e. the heartbeat frequency must be set depending on > the importance of the user. We are talking about potentally hundreds > of nodes here, and having multiple-level heartbeats on multiple > connections > between each CE and all FE:s, which I assume is a realistic scenario, may > easily amount to a significant background load. There is an example in > my draft where I calculate the background load for supervising a > 2000-node > cluster, and this shows that this algorithm must be designed with > great care, > and preferrably made hierarchical. > >> >> --------------070000010808030908040307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jon,

One way to reduce the heartbeat overhead is to NOT do it if traffic is being sent between
CE and FE in question successfully. So, you only send heartbeat when channel has been
idle for a while (some preset time span).  I think this is also goes with your selective
heartbeat  notion.

Regards,
Alex.

Jon Maloy wrote:
/jon

Putzolu, David wrote:
Hi Alex - my response inline.

[snip..]  

Alex wrote>
  [snip..]
Also, the liveness checking by TML can only guarrantee the 
TML->transport->peerTML connectivity.  To make sure PL is 
in the loop, PL should have its own scheme (e.g. ACKs,
heartbeat,..).  That checks the PL->TML->transport->peerTML->peerPL 
    removed connectivity. This helps ensure the PL is not off in the weeds or or crashed while the transport is fine.  It also helps problem  isolation.
[David]
Having a PL <-> PL heartbeat, to make sure the PL is alive,
makes sense.  I agree that this is separate from TML liveness.
[/David]
Both are needed, but the PL supervision can (and should be) made much
more selective, i.e. the heartbeat frequency must be set depending on
the importance of the user.  We are talking about potentally hundreds
of nodes here, and having multiple-level heartbeats on multiple connections
between each CE and all FE:s, which I assume is a realistic scenario, may
easily amount to a significant background load. There is an example in
my draft where I calculate  the background load for supervising a 2000-node
cluster, and this shows that this algorithm must be designed with great care,
and preferrably made hierarchical.
--------------070000010808030908040307-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 13:58:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12448 for ; Mon, 22 Mar 2004 13:57:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uc7-0003R6-QB for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 13:57:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MIvV8j013202 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 13:57:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uc6-0003Qr-RO for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 13:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12362 for ; Mon, 22 Mar 2004 13:57:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uc4-0003BM-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:57:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Uak-0002tn-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:56:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5UZa-0002k2-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:54:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5UTv-0004xL-SU for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 13:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UTu-000384-1H; Mon, 22 Mar 2004 13:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UTZ-00037f-VT for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 13:48:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11896 for ; Mon, 22 Mar 2004 13:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5UTX-0002Bv-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:48:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5USj-000279-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:47:50 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5USG-0001zn-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 13:47:21 -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.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MIf6AU000992 for ; Mon, 22 Mar 2004 18:48:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MI3YXT003550 for ; Mon, 22 Mar 2004 18:03:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032210102719836 for ; Mon, 22 Mar 2004 10:10:27 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 10:10: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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEE01@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+QAIuIDSAAAK/8wAABRbbQ From: "Khosravi, Hormuzd M" To: "Putzolu, David" , X-OriginalArrivalTime: 22 Mar 2004 18:10:27.0454 (UTC) FILETIME=[F434F1E0:01C41038] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 10:10:27 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for the feedback, David! See my replies below... -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was=20 > consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) I'm not sure that this level of detail is good - was there this much consensus? =20 [HK] Yes I believe we had clear consensus on these fields. I have put a TBD for whatever there was no clear consensus on. On Monday March 22, 2004 9:09 AM Hormuzd wrote > > All ForCES protocol implementations, MUST support a reliable,=20 > congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP=20 > connection between the CE and FEs.=20 Careful - I only suggested use of TCP as an example. It would be up to the IP TML team to choose one of these (or DCCP, or RMT). =20 [HK] This was in context with the reliable unicast connection, thus=20 I mentioned TCP or SCTP as per Jamal's comment. On Monday March 22, 2004 9:09 AM Hormuzd wrote > > In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. The establishment and=20 > semantics of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association (TBD).=20 I had a different impression. Here is some alternate text=20 for the team to consider on the unicast/multicast/etc issue: The ForCES team reached consensus that ForCES would define a set of transport requirements that must be met by any transport implementation. These requirements include an assumption of support for prioritized connections, a reliable, ordered unicast delivery service, and a multicast delivery service (details TBD). The ForCES team reached consensus that a set of concrete transport mappings would be defined in order to achieve interoperability on different transports. An IP TML will be defined that adheres to charter guidelines in regards to use of a RFC2914-compliant transport, per AD feedback. =20 Other non-IP TMLs will be defined as well. [HK] I can add this text as well. However, I did incorporate=20 any comments I received from Jamal, Weiming on the previous para. Also, I think it captures some of the details we discussed.=20 What do others think ? I am fine with either/both the texts. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 14:21:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13845 for ; Mon, 22 Mar 2004 14:21:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uya-0005k0-Kl for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:20:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJKiBE022068 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UyY-0005jX-Dn for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13806 for ; Mon, 22 Mar 2004 14:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5UyW-0006I4-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5UxZ-0006Ai-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:19:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uwf-00064C-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:18:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UwW-0005VK-Sd; Mon, 22 Mar 2004 14:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uvs-0005UC-Mv for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 14:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13602 for ; Mon, 22 Mar 2004 14:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uvg-0005xe-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:17:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Uuo-0005rQ-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:16:50 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B5UuH-0005l4-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:16:17 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032211183738:11222 ; Mon, 22 Mar 2004 11:18:37 -0800 Subject: Re: [Forces-protocol] RE: Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E3FECAC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E3FECAC@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079982963.1091.113.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 03/22/2004 11:18:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/22/2004 11:18:40 AM, Serialize complete at 03/22/2004 11:18:40 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 22 Mar 2004 14:16:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, Since you are putting a lot of effort in this; i am gonna respond. My view is this should not be taking the time it is. It doesnt gain us much in terms of moving forward. I will do the write up for the HA piece next. On Mon, 2004-03-22 at 12:09, Khosravi, Hormuzd M wrote: > Incorporating Weiming's, Jamal's comments... > > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD > > Another issue we reached agreement on was using LFB Type ID, LFB > Instance ID in combination of FE ID for addressing LFBs on the FE. The > LFB IDs will be part of the payload. Did you mean LFB instance ID? > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) > > TypeID: TBD, no consensus on whether it is needed or not In issue 0 you talk about LFB typeID. This is the same thing, no? Issues 2-5: I think that TML should be introduced first then you should talk about TML satisfying those issues. Infact i feel there is no point in mentioning any protocols by name since its the TML thats responsible for delivering 2-5. Granted it may want to use TCP - but thats just an example. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 14:30:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14258 for ; Mon, 22 Mar 2004 14:30:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V7P-0006Hp-0G for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:29:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJTom3024165 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:29:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V7O-0006Hg-Nd for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14219 for ; Mon, 22 Mar 2004 14:29:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5V7M-0007Hu-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:29:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5V6K-0007BK-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:28:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5V5b-00075o-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V5d-00065D-Fx; Mon, 22 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5V5J-000642-5S for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 14:27:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14064 for ; Mon, 22 Mar 2004 14:27:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5V5E-00072z-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:27:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5V4D-0006un-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:26:34 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5V3F-0006kC-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:25:33 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MJSx9i001939; Mon, 22 Mar 2004 19:29:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MJHkXV024852; Mon, 22 Mar 2004 19:18:16 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032211245132553 ; Mon, 22 Mar 2004 11:24:51 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 11:24:50 -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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEF32@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQQQil0lLkqCVm5SxiVVW5MMeHnsQAACJhg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 22 Mar 2004 19:24:50.0886 (UTC) FILETIME=[589E9E60:01C41043] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 11:24:49 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Jamal, appreciate your comments! -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Mon, 2004-03-22 at 12:09, Khosravi, Hormuzd M wrote: > Incorporating Weiming's, Jamal's comments... >=20 > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD >=20 > Another issue we reached agreement on was using LFB Type ID, LFB > Instance ID in combination of FE ID for addressing LFBs on the FE. The > LFB IDs will be part of the payload. Did you mean LFB instance ID? [HK] I meant both LFB Type ID and LFB instance ID mentioned in the previous sentence. I will clarify this explicitly in the text. >=20 > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) >=20 > TypeID: TBD, no consensus on whether it is needed or not In issue 0 you talk about LFB typeID. This is the same thing, no? [HK] I am not sure, this is something that you had mentioned but we did not reach any agreement around whether it is needed or not, what are the semantics, etc. That's why I have left it as TBD, I assume will be revisiting this in the future. Issues 2-5: I think that TML should be introduced first then you should talk about TML satisfying those issues. Infact i feel there is no point in mentioning any protocols by name since its the TML thats responsible for delivering 2-5. Granted it may want to use TCP - but thats just an example. [HK] Alright I will introduce some text on TML before describing these issues(2-5). BTW, I have not mentioned only TCP at any place, I have put both TCP/SCTP as you, others had suggested. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 14:47:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15161 for ; Mon, 22 Mar 2004 14:47:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VNl-0008EL-H5 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:46:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJkjXV031637 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VNk-0008EC-TN for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:46:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15148 for ; Mon, 22 Mar 2004 14:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VNi-0001HO-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:46:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VMm-0001Bd-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:45:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5VM4-00014s-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VM5-0007za-1p; Mon, 22 Mar 2004 14:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VLj-0007yZ-Pm for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 14:44:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15027 for ; Mon, 22 Mar 2004 14:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VLh-00012I-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:44:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VKn-0000tz-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:43:42 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B5VJs-0000me-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:42:44 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032211450470:11264 ; Mon, 22 Mar 2004 11:45:04 -0800 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E3FEF32@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E3FEF32@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079984555.1091.126.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 03/22/2004 11:45:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/22/2004 11:45:07 AM, Serialize complete at 03/22/2004 11:45:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 22 Mar 2004 14:42:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-22 at 14:24, Khosravi, Hormuzd M wrote: > > Issue# 0 IDs in the header:- > > There was a lot of discussion on this topic regarding the naming, > > semantics, length of these IDs. > > The result was as follows... > > Naming: CE ID, FE ID > > Semantics: Used to address a single, group or all CEs/FEs respectively > > Length: 16-32 bits...TBD > > > > Another issue we reached agreement on was using LFB Type ID, LFB > > Instance ID in combination of FE ID for addressing LFBs on the FE. The > > LFB IDs will be part of the payload. > > Did you mean LFB instance ID? > [HK] I meant both LFB Type ID and LFB instance ID mentioned in the > previous sentence. > I will clarify this explicitly in the text. The LFBID is not something we agreed on as to be on the payload or the header. The reasoning was that based on some threshold it may make sense to put it in the header. At least i raised this in some emails. so It is to be discussed as to where it belongs. The Instance id is definetely in the body. > > Issue# 1 Header/Encoding:- > > Here are the fields in the common header that there was consensus > around > > IDs: as summarized in issue 0 > > Version/sub-ver: 4 bits > > Sequence No. : 32 bits > > Length : 16 bits > > Command Type : 8 bits (semantics - TBD) > > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > > of Flags and Priority fields is TBD) > > > > TypeID: TBD, no consensus on whether it is needed or not > > In issue 0 you talk about LFB typeID. This is the same thing, no? > [HK] I am not sure, this is something that you had mentioned but we did > not reach any agreement around whether it is needed or not, what are the > semantics, etc. That's why I have left it as TBD, I assume will be > revisiting this in the future. It is definetly the same one. So have both as TBD. > Issues 2-5: I think that TML should be introduced first then you should > talk about TML satisfying those issues. > Infact i feel there is no point in mentioning any protocols by name > since its the TML thats responsible for delivering 2-5. Granted it may > want to use TCP - but thats just an example. > > [HK] Alright I will introduce some text on TML before describing these > issues(2-5). BTW, I have not mentioned only TCP at any place, I have put > both TCP/SCTP as you, others had suggested. I would think the generic view should be that of the TML. Infact i started writting the HA text with explicit mention of the role of the TML. I think this is the way we should proceed from now on. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 15:43:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19392 for ; Mon, 22 Mar 2004 15:43:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WFu-0006qk-PH for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 15:42:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MKgg6a026327 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 15:42:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WFu-0006qY-HS for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 15:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19286 for ; Mon, 22 Mar 2004 15:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5WFs-0000C3-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 15:42:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5WEy-00006g-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 15:41:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5WEJ-000018-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 15:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WEJ-0006mr-JA; Mon, 22 Mar 2004 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WDC-0006jO-B9 for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 15:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19216 for ; Mon, 22 Mar 2004 15:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5WD8-0007iO-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 15:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5WCR-0007cH-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 15:39:08 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5WBk-0007TG-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 15:38:25 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MKfc9i025211; Mon, 22 Mar 2004 20:41:38 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MKU3XZ015793; Mon, 22 Mar 2004 20:30:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032212372911336 ; Mon, 22 Mar 2004 12:37:29 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 12:37: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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FF011@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQQRd2AMmRz6L30T4qd8KZSj3g3eQAB1FIQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 22 Mar 2004 20:37:29.0369 (UTC) FILETIME=[7E7A5890:01C4104D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 12:37:28 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alright Jamal, I am fine with your comments and will=20 make the changes that you have suggested below. Thanks ! Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > > Issue# 0 IDs in the header:- > > There was a lot of discussion on this topic regarding the naming, > > semantics, length of these IDs. > > The result was as follows... > > Naming: CE ID, FE ID > > Semantics: Used to address a single, group or all CEs/FEs respectively > > Length: 16-32 bits...TBD > >=20 > > Another issue we reached agreement on was using LFB Type ID, LFB > > Instance ID in combination of FE ID for addressing LFBs on the FE. The > > LFB IDs will be part of the payload. >=20 > Did you mean LFB instance ID? > [HK] I meant both LFB Type ID and LFB instance ID mentioned in the > previous sentence. > I will clarify this explicitly in the text. The LFBID is not something we agreed on as to be on the payload or the header. The reasoning was that based on some threshold it may make sense to put it in the header. At least i raised this in some emails. so It is to be discussed as to where it belongs. The Instance id is definetely in the body. > > Issue# 1 Header/Encoding:- > > Here are the fields in the common header that there was consensus > around > > IDs: as summarized in issue 0 > > Version/sub-ver: 4 bits > > Sequence No. : 32 bits > > Length : 16 bits > > Command Type : 8 bits (semantics - TBD) > > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > > of Flags and Priority fields is TBD) > >=20 > > TypeID: TBD, no consensus on whether it is needed or not >=20 > In issue 0 you talk about LFB typeID. This is the same thing, no? > [HK] I am not sure, this is something that you had mentioned but we did > not reach any agreement around whether it is needed or not, what are the > semantics, etc. That's why I have left it as TBD, I assume will be > revisiting this in the future. It is definetly the same one. So have both as TBD. > Issues 2-5: I think that TML should be introduced first then you should > talk about TML satisfying those issues. > Infact i feel there is no point in mentioning any protocols by name > since its the TML thats responsible for delivering 2-5. Granted it may > want to use TCP - but thats just an example. >=20 > [HK] Alright I will introduce some text on TML before describing these > issues(2-5). BTW, I have not mentioned only TCP at any place, I have put > both TCP/SCTP as you, others had suggested. I would think the generic view should be that of the TML. Infact i started writting the HA text with explicit mention of the role of the TML. I think this is the way we should proceed from now on. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 16:19:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23604 for ; Mon, 22 Mar 2004 16:19:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wow-00022X-5E for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 16:18:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MLIs9x007835 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 16:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wov-00022I-Sr for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 16:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23470 for ; Mon, 22 Mar 2004 16:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Woi-0006RN-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:18:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Wms-0005zB-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:16:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5WlS-0005jB-01 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:15:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5WdX-0007cA-No for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WdR-0000YR-QD; Mon, 22 Mar 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wcl-0000TV-H1 for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 16:06:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21754 for ; Mon, 22 Mar 2004 16:06:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wcj-00043h-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Way-0003c3-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:04:31 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5WYy-00031U-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:02:24 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2ML5i9i011902 for ; Mon, 22 Mar 2004 21:05:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MKrPXd001621 for ; Mon, 22 Mar 2004 20:54:46 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032213012007431 for ; Mon, 22 Mar 2004 13:01:20 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 13:01:20 -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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FF058@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+QAIuIDSAAB9TrgA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Mar 2004 21:01:20.0800 (UTC) FILETIME=[D3AD6200:01C41050] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 13:01:20 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Incorporating Jamal's latest comments... Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD Another issue we reached agreement on was using LFB Type ID, LFB Instance ID in combination of FE ID for addressing LFBs on the FE. The LFB Instance ID will be part of the payload. The LFB Type ID location, whether it is part of header or payload is TBD. Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length of Flags and Priority fields is TBD) LFB TypeID: TBD, no consensus on whether it is needed or not in the header ----- There was a general consensus about separation of the ForCES PL (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm The issues 2-5 below will be satisfied by the TML. ----- Issue# 2 Multiple channels/connections:- There was a lot of discussion on this topic as well. There was agreement on the fact that there MUST be a way to prioritize and separate Control and Data traffic. There was no clear consensus around mandating using separate channels or connections (better term) for Data and Control in order to provide this separation. There were reasons presented regarding the ineffectiveness of separate connections to help during DoS attacks as well as the reasons for using reliable and unreliable connections for Control and Data respectively. The use of separate transports/connections is TBD. Note: This issue will be further addressed in context with the TML=20 Issue# 3 Transport: unicast/multicast/broadcast:- The protocol team reached consensus that ForCES would define a set of transport requirements that must be met by any transport implementation. These requirements include an assumption of support for prioritized connections, a reliable, ordered unicast delivery service, and a multicast delivery service (details TBD). The protocol team reached consensus that a set of concrete transport mappings would be defined in order to achieve interoperability on different transports. An IP TML will be defined that adheres to charter guidelines in regards to use of a RFC2914-compliant transport, per AD feedback. =20 Other non-IP TMLs will be defined as well. There was some consensus around this text to describe the details... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. (The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association - TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) Issue# 4 Congestion control:- General consensus was that Congestion Control (CC) is a MUST for the protocol for all messages, whether Control or Data in order to meet the basic scalability requirement. There was also some discussion around DoS protection in context with CC, but this is still being discussed. Note: This issue will be further addressed in context with TML Issue# 5 Reliability:- General consensus was that Reliability is a MUST for all control messages. The separation of TML from PL has provided the team the opportunity to make progress on the PL and defer the details of the TML for now. This issue is also closely related to issue# 3 and both were discussed in parallel to some extent. Note: This issue will be further addressed in context with TML Let me know if there are any others comments. I will post this summary to the list by end of today (22nd), unless I get any requests for changes. Thanks again, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 16:23:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24397 for ; Mon, 22 Mar 2004 16:23:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WtD-0002kM-Bx for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 16:23:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MLNIFd010552 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 16:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WtB-0002k7-Ao for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 16:23:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24246 for ; Mon, 22 Mar 2004 16:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wt9-0007SK-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Wri-0007AG-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:21:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5WqH-0006oP-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 16:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WqH-0002Gx-KR; Mon, 22 Mar 2004 16:20:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wpt-0002DZ-Ma for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 16:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23708 for ; Mon, 22 Mar 2004 16:19:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wpr-0006j2-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:19:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Wo4-0006IW-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:18:01 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B5WmF-0005s3-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 16:16:07 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032213182857:11443 ; Mon, 22 Mar 2004 13:18:28 -0800 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E3FF058@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E3FF058@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1079990164.1090.164.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 03/22/2004 01:18:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/22/2004 01:18:30 PM, Serialize complete at 03/22/2004 01:18:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 22 Mar 2004 16:16:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, You have a lot of verbage on #3 that i didnt thoroughly read. Overall looks good. So i would say its ready. cheers, jamal On Mon, 2004-03-22 at 16:01, Khosravi, Hormuzd M wrote: > Incorporating Jamal's latest comments... > > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD > > Another issue we reached agreement on was using LFB Type ID, LFB > Instance ID in combination of FE ID for addressing LFBs on the FE. The > LFB Instance ID will be part of the payload. The LFB Type ID location, > whether it is part of header or payload is TBD. > > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits > Length : 16 bits > Command Type : 8 bits (semantics - TBD) > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) > LFB TypeID: TBD, no consensus on whether it is needed or not in the > header > > ----- > There was a general consensus about separation of the ForCES PL > (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The > link below provides a good explanation of these layers... > http://www.sstanamera.com/~forces/proto/ForCESLayered.htm > The issues 2-5 below will be satisfied by the TML. > > ----- > Issue# 2 Multiple channels/connections:- > There was a lot of discussion on this topic as well. There was agreement > on the fact that there MUST be a way to prioritize and separate Control > and Data traffic. There was no clear consensus around mandating using > separate channels or connections (better term) for Data and Control in > order to provide this separation. There were reasons presented regarding > the ineffectiveness of separate connections to help during DoS attacks > as well as the reasons for using reliable and unreliable connections for > Control and Data respectively. The use of separate > transports/connections is TBD. > Note: This issue will be further addressed in context with the TML > > Issue# 3 Transport: unicast/multicast/broadcast:- > The protocol team reached consensus that ForCES would define a > set of transport requirements that must be met by any transport > implementation. These requirements include an assumption of > support for prioritized connections, a reliable, ordered > unicast delivery service, and a multicast delivery service > (details TBD). > > The protocol team reached consensus that a set of concrete > transport mappings would be defined in order to achieve > interoperability on different transports. An IP TML will > be defined that adheres to charter guidelines in regards to > use of a RFC2914-compliant transport, per AD feedback. > Other non-IP TMLs will be defined as well. > > There was some consensus around this text to describe the details... > > All ForCES protocol implementations, MUST support a reliable, congestion > aware Unicast method of communication between the CEs and the FEs. > Furthermore, in case of IP this will be a TCP or SCTP connection between > the CE and FEs. In addition to this, in case of 'close proximity' > between the CEs and FEs And in case the interconnect between them > supports multicast, the CEs and FEs Must also establish reliable, > congestion aware Multicast connections. (The establishment and semantics > of these Multicast connections is negotiated during the > binding/capability discovery phase in the ForCES protocol or during > pre-association - TBD). For example, the CE and subset of FEs might > negotiate on establishing a Multicast connection for communication of > IPv4 LFB attributes. These reliable, congestion aware connections will > be used to communicate the control messages outlined in RFC 3654 > (section 6, #6c). (For data messages such as those outlined in RFC 3654 > (section 6, #6b), the ForCES protocol Must/Should also support an > un-reliable but congestion aware Unicast connection between the CE and > FEs.- TBD:issue# 2) > > Issue# 4 Congestion control:- > General consensus was that Congestion Control (CC) is a MUST for the > protocol for all messages, whether Control or Data in order to meet the > basic scalability requirement. There was also some discussion around DoS > protection in context with CC, but this is still being discussed. > Note: This issue will be further addressed in context with TML > > Issue# 5 Reliability:- > General consensus was that Reliability is a MUST for all control > messages. The separation of TML from PL has provided the team the > opportunity to make progress on the PL and defer the details of the TML > for now. This issue is also closely related to issue# 3 and both were > discussed in parallel to some extent. > Note: This issue will be further addressed in context with TML > > > Let me know if there are any others comments. > I will post this summary to the list by end of today (22nd), > unless I get any requests for changes. > > Thanks again, > Hormuzd > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Mar 22 21:37:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12257 for ; Mon, 22 Mar 2004 21:37:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5bmu-0008FD-8T for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 21:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N2b8MP031688 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 21:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5bmt-0008Et-LT for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 21:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12245 for ; Mon, 22 Mar 2004 21:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5bmq-0006eH-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 21:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5blt-0006Wn-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 21:36:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5bkr-0006P5-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 21:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5bks-00087i-ST; Mon, 22 Mar 2004 21:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5bkj-00086T-1z for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 21:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12120 for ; Mon, 22 Mar 2004 21:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5bkg-0006NH-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 21:34:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5bjk-0006Gy-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 21:33:53 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5bis-00065d-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 21:32:58 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2N2OEHg021587; Tue, 23 Mar 2004 02:36:34 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MH4XXd026096; Mon, 22 Mar 2004 17:05:03 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032209113609957 ; Mon, 22 Mar 2004 09:11:36 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 09:11: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 Subject: RE: [Forces-protocol] Summary for issues 0-5 Message-ID: <52D13A805349A249960B9943E5590BD802B2D535@orsmsx409.jf.intel.com> Thread-Topic: [Forces-protocol] Summary for issues 0-5 Thread-Index: AcQPgwOeiUbY6p0VSHGrZcciTxHaMgArTYrw From: "Putzolu, David" To: , "Khosravi, Hormuzd M" Cc: , X-OriginalArrivalTime: 22 Mar 2004 17:11:36.0175 (UTC) FILETIME=[BB6687F0:01C41030] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 09:11:35 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all - my reply inline... On Sunday march 21 2004 12:25pm Jamal wrote > > Who are you hoping other than the people on this list already will > contribute - most of whom are merely lurking? > Joel probably should have been on this list. I am a little suprised he > is not. There is no big secret on what we are discussing here. > This is more open than anything else that any design team in=20 > Forces has ever done (it is being archived). I agree that most of the key players are already on this list. However, the ADs are always very concerned about open-ness, visibility, etc. So it behooves us to at least come up with a summary of any agreements/consensus areas. A full justification or reasoning for every single decision isn't needed, but there should be enough so that a list reader could go over it and understand where the protocol is going. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 24 09:20:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23637 for ; Wed, 24 Mar 2004 09:20:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69EJ-0007i7-Uf for forces-protocol-archive@odin.ietf.org; Wed, 24 Mar 2004 09:19:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OEJdQX029638 for forces-protocol-archive@odin.ietf.org; Wed, 24 Mar 2004 09:19:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69EJ-0007hx-Ov for forces-protocol-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 09:19:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23593 for ; Wed, 24 Mar 2004 09:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69EI-00051K-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:19:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69DU-0004jy-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:18:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B69Ck-0004S8-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69Cl-0007ad-QH; Wed, 24 Mar 2004 09:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69CG-0007YJ-4d for forces-protocol@optimus.ietf.org; Wed, 24 Mar 2004 09:17:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23424 for ; Wed, 24 Mar 2004 09:17:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69CE-0004NY-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:17:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69BC-00045O-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:16:27 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1B69Aa-0003kr-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:15:48 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2OEFAxJ090140 for ; Wed, 24 Mar 2004 14:15:13 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2OE986M193096 for ; Wed, 24 Mar 2004 15:09:08 +0100 Received: from zurich.ibm.com (dhcp69-193.zurich.ibm.com [9.4.69.193]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA42872 for ; Wed, 24 Mar 2004 15:09:06 +0100 Message-ID: <40619680.3040601@zurich.ibm.com> From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: forces-protocol@ietf.org 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 i2OEFAxJ090140 Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] catching up Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 24 Mar 2004 15:09:04 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Currently catching up on the numerous exchanges after a couple of weeks=20 of intense customer-oriented work. It's good to see that agreements have=20 been reached. I am hoping to contribute again from now on. Best 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 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Mar 24 09:20:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23658 for ; Wed, 24 Mar 2004 09:20:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69EN-0007iU-Cw for forces-protocol-archive@odin.ietf.org; Wed, 24 Mar 2004 09:19:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OEJho6029656 for forces-protocol-archive@odin.ietf.org; Wed, 24 Mar 2004 09:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69EN-0007iF-8u for forces-protocol-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 09:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23618 for ; Wed, 24 Mar 2004 09:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69EL-00051w-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69DV-0004kK-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:18:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B69Cl-0004S7-00 for forces-protocol-web-archive@ietf.org; Wed, 24 Mar 2004 09:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69Cl-0007aU-K5; Wed, 24 Mar 2004 09:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69C4-0007XW-Gp for forces-protocol@optimus.ietf.org; Wed, 24 Mar 2004 09:17:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23393 for ; Wed, 24 Mar 2004 09:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69C2-0004Lq-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:17:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69B0-00043U-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:16:15 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B69A5-0003kd-00 for forces-protocol@ietf.org; Wed, 24 Mar 2004 09:15:17 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004032406173428:14642 ; Wed, 24 Mar 2004 06:17:34 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1080137710.1023.7.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 03/24/2004 06:17:34 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/24/2004 06:17:38 AM, Serialize complete at 03/24/2004 06:17:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] topic 7: HA Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 24 Mar 2004 09:15:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Heres something to reduce the noisy silence ;-> cheers, jamal This text does not talk about state synchronization or restarts or rollovers. Those details are considered solvable if the discussion below is resolvable. Two levels of HA responsibilities that i see: 1) TML level: a) The TML controls logical connection availability and failover. b) The TML also controls peer HA managements. 2) PL Level: Depending on the scheme implemented by the TML level, the PL level may have no role to play i.e HA being transparent to it. The TML layer ------------- To describe the detail, a good example would be to show multiple CEs trying to control an FE. For all three schemes, a heartbeat that terminates at the TML layer is needed for meeting requirement 1). The are three schemes i can think of which i will list here: Scheme 1) Le brute force: The FE TML is aware of the multiple CEs i.e knows their logical connections. It may receive commands from all the CEs but will process the one with highest priority only in given time instances. Protocol requirement: To have priorities in the headers. We already do. Advantages: KISS. Disadvatanges: too much traffic Scheme 2) the Tenor: The FE TML is aware of all CEs controlling it however responds to only one at any one point. Something akin to HA as achieved by SCTP multihoming or some mobility protocols. i.e at some point the current known master is obsoleted for example because of some missing heartbeats or physical disconnect or by explicit instructions to migrate. Protocol requirement: A "move" command to instruct to a migration to a new CE being issued to the FE. Advantages: less traffic Disadvantages: slower in recovery compared to 1). Scheme 3) the soprano: The FE is NOT aware of the CEs unlike 1 and 2 above. The election of which CE is controlling an FE is done elsewhere at the CE level. At any point the controlling CE will use a logical address. This makes it transparent to the FE how many CEs are behind the control point. Very easily doable with a broadcast or multicast protocol. Example protocol which does this is VRRP. Protocol requirement: None, the TML is burdened with providing either multicast or broadcast. In terms of compute requirements on the FE a) > b) > c) In terms of bandwidth requirements on the wire a > b > c The PL Layer ------------ The PL layer provides HA management of the LFBs and their availability. Scheme 1) The PL heartbeats terminate at the TML layer. The TML layer aggregates info on its PLs into its own heartbeats to its peers. The TML peer uses the knowledge to make calls on failover. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:45:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19602 for ; Tue, 30 Mar 2004 17:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjh-0006ZK-DO for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Fl6pm032659 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRi-0008Uc-Ph for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02929 for ; Tue, 9 Mar 2004 10:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRg-00047b-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNd-0002qm-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMG-0002Ul-03 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jIL-0004Bx-NC for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIK-0004Wt-5E; Tue, 09 Mar 2004 10:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0iOZ-00060t-3Q for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28968 for ; Tue, 9 Mar 2004 09:39:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0iOX-0006yj-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:39:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iNa-0006oe-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:38:47 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0iMz-0006eJ-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:38:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030906384601:65725 ; Tue, 9 Mar 2004 06:38:46 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn, david.putzolu@intel.com Organization: ZNYX Networks Message-Id: <1078843084.1035.605.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 03/09/2004 06:38:46 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 06:38:47 AM, Serialize complete at 03/09/2004 06:38:47 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] forces-protocol list dead? Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 09:38:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Another test. This mail list is proving unreliable. SMTP over UDP? ;-> (no pun intended). cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:45:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19625 for ; Tue, 30 Mar 2004 17:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006WI-HS for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FlAuA032746 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRm-0008W3-Nw for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02947 for ; Tue, 9 Mar 2004 10:47:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRk-00049W-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNh-0002sD-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMH-0002Ul-02 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jIH-0004Bh-0x for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIF-0004UC-My; Tue, 09 Mar 2004 10:37:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0iEn-0005Sy-Vh for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:29:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28672 for ; Tue, 9 Mar 2004 09:29:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0iEm-0005Ov-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:29:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iDp-0005FF-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:28:42 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0iD1-00055O-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:27: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 2004030906282264:65711 ; Tue, 9 Mar 2004 06:28:22 -0800 Subject: Re: [Forces-protocol] issue 1: packet encoding From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, Weiming Wang In-Reply-To: <0bcf01c405dc$22f71a60$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> <09d601c40515$01f8c830$845c21d2@Necom.hzic.edu.cn> <1078775008.1037.455.camel@jzny.localdomain> <0bcf01c405dc$22f71a60$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1078842463.1037.594.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 03/09/2004 06:28:23 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 06:28:29 AM, Serialize complete at 03/09/2004 06:28:29 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 09:27:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Weiming, On Tue, 2004-03-09 at 08:40, Wang,Weiming wrote: > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: "Wang,Weiming" > > > Weimimg, > > > > On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote: > > >[Jamal Re: > > Every message will have a command. For that reason it belongs to the > > main header.] > > [Wang Re: I would say it is also possible to have a message contain more than > one command. But I don't want push this too hard so that we may be quicker to > reach an agreement.] Now i see your reasoning. I may be biased by the way we did things in netlink2; but i am willing to consider things differently if it makes sense. In netlink2 we batched several messages in one TCP or UDP PDU. The overhead of this is much smaller than having a command as a TLV. Essentially a 8 bit command will now take 64 bits space (8 bytes). I think we agree that there will always be a command on each message, correct? Given that scenario, i think that for a single command putting the command in the TLV space instead of header is more waste of bits. The breakeven point for UDP is around 5 commands batched together. Around 7 for TCP and lower for running directly over ethernet. So we may have to weight out the options and come to some conclusion. You can respond to this point but lets consider it closed. > > > > > 2) If we keep it, I'm afraid its meaning should be far from these. For > > > example, how an event report can be represented, and how a command bundle > > > is represented then, and many others? > > >[Jamal Re: > > I will explain how we implemented events; note, this is different from > > the current command structure but shoudl give you a view: > > - An "add route" from CE->FE means to configure something on one or more > > FEs that are addressed. > > - An "add route" from FE->CE is an event notifying that a route was > > added. > > > > An alternative is to reserve one bit for saying its an event or > > configuration then you dont have to intepret directions.] > > [Wang Re: > Why not just let us use an "Event report message" instead of using such a "add > route" along with some bit to say it is an event, while leaving the "command" > field from being fully used.] Theres a few ways to skin this cat (with apologies to people who own cats). We can discuss later. I also think this is resolvable. Lets close it. > >{Jamal Re: > > I prefer to have the headers with flags; flags were usable on every > > message. ] > > [Wang Re: not very sure how your reply maps what I said.] I meant that flags would further refine the headers. I dont wanna go into a lot of details because i think this is further resolvable. > >[Jamal Re: > > Netlink2 has the concept of several shades of reliability. > > Some messages dont need to be validated and therefore dont > > need a checksum. This is also the path we are following now, > > for that reason checksum should stay an optional field.] > > [Wang Re: checksum in GRMP is also optional, my opinion is it has better > performance to optionally put it at the message end, just the same as UDP.] Nod. Same with authentication headers etc. Weiming, Please keep the momentum going so we can close these issues. Shall we close issue 1? I think any leftovers are resolvable. Hormuzd, are you working on issue 2's text? If you have it please post it. This way we have two topics in the pipeline all the time. Somebody should volunteer for writing up topic 3; the timeout is 24 hours, if no volunteers, i will write it up. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:45:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19643 for ; Tue, 30 Mar 2004 17:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006Xa-9m for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Fl3sQ032477 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRe-0008RY-Pw for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02913 for ; Tue, 9 Mar 2004 10:46:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRc-00046J-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNa-0002py-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMG-0002UY-03 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jIK-0004Br-CB for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIJ-0004WH-2L; Tue, 09 Mar 2004 10:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0iMT-0005kP-1y for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28885 for ; Tue, 9 Mar 2004 09:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0iMR-0006cP-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iLS-0006TB-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:36:34 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0iKX-0006Kl-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:35:37 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030906361382:65723 ; Tue, 9 Mar 2004 06:36:13 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: Wang@ietf-mx.cnri.reston.va.us, Weiming , Putzolu@ietf-mx.cnri.reston.va.us, David Organization: ZNYX Networks Message-Id: <1078842933.1039.602.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 03/09/2004 06:36:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 06:36:15 AM, Serialize complete at 03/09/2004 06:36:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] forces list dead? Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 09:35:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Is there a problem with the list? I dont see any echoes back neither does the archive show anything new. Seems like we are having a few issues with this list maybe we can move to a more reliable site? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19826 for ; Tue, 30 Mar 2004 17:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006a4-M0 for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Fl8U7032693 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRk-0008V9-Ho for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02939 for ; Tue, 9 Mar 2004 10:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRi-00048T-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNf-0002rR-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMH-0002UY-02 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jIH-0004Bj-Pc for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIG-0004Ui-Bj; Tue, 09 Mar 2004 10:37:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0iKV-0005cq-Hd for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:35:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28845 for ; Tue, 9 Mar 2004 09:35:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0iKT-0006KG-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:35:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iJd-0006Bq-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:34:42 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B0iIq-000632-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:33:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004030906342909:65719 ; Tue, 9 Mar 2004 06:34:29 -0800 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: "Putzolu, ""Daviddavid.putzoluati" , Wang@ietf-mx.cnri.reston.va.us, Weiming Organization: ZNYX Networks Message-Id: <1078842828.1038.600.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 03/09/2004 06:34:29 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2004 06:34:30 AM, Serialize complete at 03/09/2004 06:34:30 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Is the list dead? Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Mar 2004 09:33:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Is there a problem with the list? I dont see any echoes back neither does the archive show anything new. Seems like we are having a few issues with this list maybe we can move to a more reliable site? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:49:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20316 for ; Tue, 30 Mar 2004 17:49:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-Sd for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLQ3Do006642 for forces-protocol-archive@odin.ietf.org; Fri, 12 Mar 2004 16:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uAJ-0001ij-Oo for forces-protocol-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19271 for ; Fri, 12 Mar 2004 16:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uAH-0000AG-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:25:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1u9D-0007kT-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1u8g-0007cm-00 for forces-protocol-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1u8e-0000lP-El; Fri, 12 Mar 2004 16:24:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tdL-0007qo-Co for forces-protocol@optimus.ietf.org; Fri, 12 Mar 2004 15:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18052 for ; Fri, 12 Mar 2004 15:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1tdJ-000420-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 15:51:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1tce-0003u9-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 15:51:12 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B1tc2-0003kv-00 for forces-protocol@ietf.org; Fri, 12 Mar 2004 15:50:34 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2CKo0TN010996; Fri, 12 Mar 2004 14:50:04 -0600 (CST) Message-ID: <40522277.1050507@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Droz CC: hadi@znyx.com, "Deleganes, Ellen M" , forces-protocol@ietf.org Subject: Re: [Forces-protocol] Issue 3: Transport/Unicast/Multicast/Broadcast References: <468F3FDA28AA87429AD807992E22D07E1BB5B7@orsmsx408.jf.intel.com> <1078966003.1037.59.camel@jzny.localdomain> <405088EB.3040004@alcatel.com> <1079035283.1038.65.camel@jzny.localdomain> <4050DD8D.5040301@alcatel.com> <4051915E.2010505@zurich.ibm.com> In-Reply-To: <4051915E.2010505@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 14:49:59 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Patrick, Sorry it took me this late to respond. I really don't know what a "MUST if available" means. The main issue with multicast is that there are still a lot of unresolved issues about it viz: 1) In a critical environment like the one we are talking about, we need ACKs to give a warm-fuzzy feeling that FEs are getting what the CEs are blasting at them. What is the implication of this as number of FEs rise into the thousands? You run the risk of tons of ACKs comming back and overwhleming the CE. That is essentially a flooding attack on the CE. I believe it is called ACK implosion in literature. A lot of ways have been proposed to avoid this,..like selective ACK/NACK,..etc. These suggested solutions are pretty complex. 2) As the number of FEs grows, the chance of packet loss increases in the network when doing multicast. You have to fall back on retransmits to accommodate this. That essentially whipes out the percieved benefits of mulitcast. 3) How do you synchronize your packets and make sure they are recieved in order at the the FEs? You have to build something extra into your application or the FoRCES protocol to take care of such issues. And if you don't specify it, there is danger of different implementations resulting in interoperability issues. 4) And there are issues of security to address. In short, I am not sure we know enough about multicast to mandate its use in a critical envirnonment. If we are not concerned about timing, sure, we can retransmit a couple of times untill all the endpoints get the data. But we resorted to multicast to save time in the first place. Regards, Alex. Patrick Droz wrote: > Hi Alex, > > why not take the same approach that OSPF is taking. > Unicast a MUST > Mcast/Bcast a must if available. > > Regards, > Patrick > > Alex Audu wrote: > >> Issue 3: >> >> We can start by agreeing that Unicast is a MUST implement, and MCAST, >> BCAST a >> SHOULD. >> >> Any comments? >> >> >> As an asside, on the GroupFEID issue, certainly you can define any >> grouping to >> help the application accomplish its goal, but we don't want that >> bubled up to the >> protocol addressing structure. >> >> Regards, >> Alex. >> Jamal Hadi Salim wrote: >> >>> In your other email you say: >>> >>> On Thu, 2004-03-11 at 12:38, Alex Audu wrote: >>> >>>> I agree, ..I don't see any need for GroupFEID, and other such group >>>> IDs. >>>> >>>> >>> >>> >>> I actually wasnt agreeing with what you said above. I think the >>> grouping >>> of IDs is needed; the mechanics is what i was commenting on. >>> >>> BTW, momentum is dead. Who is the taker for topic #3? I could take it. >>> Starting a timer ... >>> >>> cheers, >>> jamal >>> >>> >>> >>> _______________________________________________ >>> Forces-protocol mailing list >>> Forces-protocol@ietf.org >>> https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:55:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21527 for ; Tue, 30 Mar 2004 17:55:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006WI-VT for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJ7jSs016267 for forces-protocol-archive@odin.ietf.org; Mon, 22 Mar 2004 14:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Um1-0004EA-0u for forces-protocol-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13117 for ; Mon, 22 Mar 2004 14:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uly-0004mT-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:07:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ul9-0004fG-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:06:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5UkM-0004Vk-00 for forces-protocol-web-archive@ietf.org; Mon, 22 Mar 2004 14:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5UkN-0003ts-Q9; Mon, 22 Mar 2004 14:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Uk8-0003sX-9w for forces-protocol@optimus.ietf.org; Mon, 22 Mar 2004 14:05:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12928 for ; Mon, 22 Mar 2004 14:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Uk5-0004TJ-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:05:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Uj4-0004Ia-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:04:42 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B5UiD-000459-00 for forces-protocol@ietf.org; Mon, 22 Mar 2004 14:03:49 -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: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2MJ7A9i015918 for ; Mon, 22 Mar 2004 19:07:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2MIrnXh006155 for ; Mon, 22 Mar 2004 18:56:22 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032211025428965 for ; Mon, 22 Mar 2004 11:02:54 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Mar 2004 11:02:54 -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 Subject: RE: [Forces-protocol] RE: Summary for issues 0-5 Message-ID: <468F3FDA28AA87429AD807992E22D07E3FEECB@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: Summary for issues 0-5 Thread-Index: AcQNrG9f4KgHf6KBSd6iFiANesWZ8AAVJS+QAIuIDSAAA4lzoA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Mar 2004 19:02:54.0606 (UTC) FILETIME=[480E3AE0:01C41040] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 11:02:54 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Incorporating David's feedback... Issue# 3 Transport: unicast/multicast/broadcast:- The protocol team reached consensus that ForCES would define a set of transport requirements that must be met by any transport implementation. These requirements include an assumption of support for prioritized connections, a reliable, ordered unicast delivery service, and a multicast delivery service (details TBD). The protocol team reached consensus that a set of concrete transport mappings would be defined in order to achieve interoperability on different transports. An IP TML will be defined that adheres to charter guidelines in regards to use of a RFC2914-compliant transport, per AD feedback. =20 Other non-IP TMLs will be defined as well. The link below provides a good explanation of these layers... http://www.sstanamera.com/~forces/proto/ForCESLayered.htm There was some consensus around this text to describe the details... All ForCES protocol implementations, MUST support a reliable, congestion aware Unicast method of communication between the CEs and the FEs. Furthermore, in case of IP this will be a TCP or SCTP connection between the CE and FEs. In addition to this, in case of 'close proximity' between the CEs and FEs And in case the interconnect between them supports multicast, the CEs and FEs Must also establish reliable, congestion aware Multicast connections. (The establishment and semantics of these Multicast connections is negotiated during the binding/capability discovery phase in the ForCES protocol or during pre-association - TBD). For example, the CE and subset of FEs might negotiate on establishing a Multicast connection for communication of IPv4 LFB attributes. These reliable, congestion aware connections will be used to communicate the control messages outlined in RFC 3654 (section 6, #6c). (For data messages such as those outlined in RFC 3654 (section 6, #6b), the ForCES protocol Must/Should also support an un-reliable but congestion aware Unicast connection between the CE and FEs.- TBD:issue# 2) Rest of the issues text is same as before. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 17:55:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21621 for ; Tue, 30 Mar 2004 17:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006YH-DD for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Fkg63031797 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:46:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRK-0008GG-48 for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:46:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02800 for ; Tue, 9 Mar 2004 10:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRH-0003yR-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:46:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNC-0002js-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMD-0002UY-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jJN-0004CN-JM for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:38:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIP-0004Z2-KT; Tue, 09 Mar 2004 10:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ibv-0006Z5-SI for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:53:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29559 for ; Tue, 9 Mar 2004 09:53:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ibt-0001NJ-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:53:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0iav-0001DW-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:52:33 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0iZw-0000wq-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:51:32 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id ; Tue, 9 Mar 2004 23:02:27 +0800 Message-ID: <0c8401c405e5$a90986c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: Cc: "Weiming Wang" References: <52D13A805349A249960B9943E5590BD802928D6E@orsmsx409.jf.intel.com> Subject: Re: [Forces-protocol] issue 1: packet encoding 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 22:49:01 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I quite don't agree to limit a message type (or refered as "command") to only "Add/Del/Get". If we are decided to use a "command" field in the header, I think at least as a start, we should include following message types: For FE coarse layer management: FE Join or Leave Request Message FE Action Manipulate Message FE Attribute Manipulate Message FE Attribute Query and Response Messages FE Event Report Message For LFB management: LFB Action Manipulate Message LFB Topology Query and Response Messages LFB Attribute Manipulate Message LFB Attribute Query and Response Messages For Datapath management: Datapath Manipulate Message Datapath Query and Response Messages I just want to see why such an arrangement is not good. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 18:01:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23058 for ; Tue, 30 Mar 2004 18:01:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006WI-Ql for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295QPST014071 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 00:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Zl3-0003dz-0u for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 00:26:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22535 for ; Tue, 9 Mar 2004 00:26:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Zkl-0003b4-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Zjm-0003LS-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:25:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Zil-000331-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 00:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Zin-0002aD-Dp; Tue, 09 Mar 2004 00:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Z3D-0008G0-Au for forces-protocol@optimus.ietf.org; Mon, 08 Mar 2004 23:41:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20791 for ; Mon, 8 Mar 2004 23:41:03 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Z3B-0004Gh-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 23:41:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Z2I-00048N-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 23:40:11 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Z1M-0003z7-00 for forces-protocol@ietf.org; Mon, 08 Mar 2004 23:39:13 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i294leep029017 for ; Tue, 9 Mar 2004 05:47:42 +0100 Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <404CC7F3.1000602@alcatel.com> References: <468F3FDA28AA87429AD807992E22D07E054213@orsmsx408.jf.intel.com> <0F7B3A3C-70D9-11D8-B109-000393CC2112@acm.org> <404CC7F3.1000602@alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] issue 1: packet encoding To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 13:39:02 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 9 mar 2004, at 04.22, Alex Audu wrote: > Hello Avri, > > I think error indication is actually another type of data to be sent > between FE and CE. > So we should carry it in the message itself (as an error message type). > > I think that could work. Though it might still be helpful to mark as message as being/containing an error message in the header. If one of the specific message types that can be sent is error, then it could work, but then you would be restricted to error payload in a message. If there was a flag (and agree with the comment about not shortchanging the header in terms of flags.) indicating the message contained error information that would be helpful too. I have a general question about headers, is there any feeling in this group that a common header could not be arrived at. If not then we could move on to other issues. The reason I ask is that one can spend a whole lot of time fine tuning a header to be just right. If there are as of yet unresolved issues on the header, can anyone list them? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 18:02:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23441 for ; Tue, 30 Mar 2004 18:02:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006a4-CV for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FksJi032272 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jRW-0008ON-1z for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:46:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02859 for ; Tue, 9 Mar 2004 10:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jRT-00042V-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNN-0002mo-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jME-0002Ul-03 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jIg-0004Ci-TV for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIU-0004f6-4i; Tue, 09 Mar 2004 10:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ifm-0006fr-Qn for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:57:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29671 for ; Tue, 9 Mar 2004 09:57:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ifk-0001yz-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:57:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ieo-0001pb-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:56:35 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0idw-0001YT-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:55:41 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Tue, 9 Mar 2004 23:06:53 +0800 Message-ID: <0c9a01c405e6$47c0c850$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: Subject: Re: [Forces-protocol] issue 1: packet encoding 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 22:53:27 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL autolearn=no version=2.60 > Hi Jamal, > > Could you just add some tag to indicate your reply? Or else, I have to help to > add it so that others can see your reply. Some comments as below. > > Thank you. > > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: "Wang,Weiming" > > > Weimimg, > > > > On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote: > > [..] > > > > > 1. The "command" field > > > This is really a field that confuses me. The confusion is: > > > 1) If it is a field only with command "Add/Del/Get", I suppose we can just > > > obsolete it. The command can be surely be expressed in the followed body > > > by using TLVs. > > >[Jamal Re: > > Every message will have a command. For that reason it belongs to the > > main header.] > > [Wang Re: I would say it is also possible to have a message contain more than > one command. But I don't want push this too hard so that we may be quicker to > reach an agreement.] > > > > > > 2) If we keep it, I'm afraid its meaning should be far from these. For > > > example, how an event report can be represented, and how a command bundle > > > is represented then, and many others? > > >[Jamal Re: > > I will explain how we implemented events; note, this is different from > > the current command structure but shoudl give you a view: > > - An "add route" from CE->FE means to configure something on one or more > > FEs that are addressed. > > - An "add route" from FE->CE is an event notifying that a route was > > added. > > > > An alternative is to reserve one bit for saying its an event or > > configuration then you dont have to intepret directions.] > > [Wang Re: > Why not just let us use an "Event report message" instead of using such a "add > route" along with some bit to say it is an event, while leaving the "command" > field from being fully used.] > > > > We just think to have a field with insufficient functions really makes > > > confusions. > > > As a result, I suppose two solution schemes for this problem: > > > > > > Scheme 1: Define this as "message type", to have the message body to express > > > the operation not just based on TLV format. This means things like "Flags" > > > "operating fields" are explicitly expressed according to the "message type" > > > operation requirements. Remember that by using this scheme, we have already > > > taken the whole ForCES message as one TLV. > > > > > > Scheme 2: Not define anything in the header on the "command" or > > > "message type", leaving things defined in the followed body, while the body > > > is expressed by a set of TLVs, each TLV representing a type of operation. > > > > > > The advantage for Scheme1 is it is very clear in semantics and saves bits > > > quite a lot. > > > > > > The disadvantage is it has to define a specific message type for > > > command bundle. > > > > > > The advantage for Scheme 2 is it is easy to implement command bundle, > > > but the disadvantage is it costs more bits and makes protocol header less > > > to do. > > >{Jamal Re: > > I prefer to have the headers with flags; flags were usable on every > > message. ] > > [Wang Re: not very sure how your reply maps what I said.] > > > > > > 2. The Checksum field and other error control mechanism > > > One essential function a protocol header takes is for a reliable > > > information exchange, therefore, the common error control mechanism should > > > be included in the header instead in the body. > > > > > > It seems no argue that a checksum should be provided as an option. > > > Only difference between the candidate protocols is how it should be put. > > > GRMP puts it at the protocol message end, Netlink2 has it as a TLV, I > > > suppose FACT also intends the same. I'm thinking the purpose to have it as > > > a TLV is mainly trying to reach a uniform TLV format. What we argue is to > > > put checksum in a TLV may get more loss for the checking function, because > > > it then will be in a risk that the TLV structure itself may be erred, > > > which may result in the invalidation of the checksum. > > > >[Jamal Re: > > Netlink2 has the concept of several shades of reliability. > > Some messages dont need to be validated and therefore dont > > need a checksum. This is also the path we are following now, > > for that reason checksum should stay an optional field.] > > [Wang Re: checksum in GRMP is also optional, my opinion is it has better > performance to optionally put it at the message end, just the same as UDP.] > > > > > > GRMP reuses the idea "result" and "code" from GSMP, I'm sure this > > > error control function should be included in the protocol. As the protocol > > > header takes the tasks for a reliable information exchange, I > > > strongly suggest it is put in the header. Could other candidate team > > > show your opinions or solutions to this? > > > > [Jamal Re: > > We had the concept of an ACK which returns results. > > Depending on the result, this could be considered a NACK. > > The ACK is requested per message using flagd and so sometimes may never > > be sent. Again this has to do with levels of reliability. > > In other words while the result is useful in the header, > > it is only useful when the result is requested. > > This is described in the section " The ACK Netlink2 Message". > > I think this is similar to the way you do it in GRMP. > > ] > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Mar 30 18:02:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23528 for ; Tue, 30 Mar 2004 18:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006WI-Hz for forces-protocol-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FkG0N030902 for forces-protocol-archive@odin.ietf.org; Tue, 9 Mar 2004 10:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jQu-00082L-7Q for forces-protocol-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02720 for ; Tue, 9 Mar 2004 10:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jQr-0003qe-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jMp-0002gW-00 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:42:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jM8-0002UY-01 for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jLv-0004Ot-Ng for forces-protocol-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIS-0004bG-ML; Tue, 09 Mar 2004 10:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0iep-0006ey-GB for forces-protocol@optimus.ietf.org; Tue, 09 Mar 2004 09:56:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29653 for ; Tue, 9 Mar 2004 09:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ien-0001pR-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:56:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0idu-0001h1-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:55:39 -0500 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1B0idF-0001YG-00 for forces-protocol@ietf.org; Tue, 09 Mar 2004 09:54:59 -0500 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Tue, 9 Mar 2004 23:06:10 +0800 Message-ID: <0c9401c405e6$2d764880$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: Subject: Re: [Forces-protocol] Issue 0: Application addressing 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 9 Mar 2004 22:52:43 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL autolearn=no version=2.60 > Jamal, > > Actually I have understood what your Src. ID and Dest. ID is refered to > even before you put this email. In one word, your IDs (actually are > PIDs) are in fact mapped to PIDs of FECxs. When I carefully read your > approach, it just seems to me that there may be some limitation to use > such an addressing scheme. Let's say there are two LFBs LFB1 and LFB2, > which in your scheme are belong to two different threads FEC1 and FEC2. > Now we need to address the two LFBs in one ForCES message, then I'm not > sure how this will be implemented in the PID based scheme? Will the two > LFBs be defined as a group then can be addressed at the same time or any > others? Actually, GRMP (I suppose FACT also) can deal with this such > case very easily. It's true that GRMP uses quite the same addressing > method as FACT. The FE ID should be put in the message header, so that > the ID is only used to tell which FEs the message will go, while leaving > further addressing tasks to be implemented by the FEs themselves. Are > there any limitations for such an addressing way? > > Best regards, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Monday, March 08, 2004 9:03 PM > Subject: Re: [Forces-protocol] Issue 0: Application addressing > > > > Hormuzd, Weiming, > > > > Apologies for long email; i am attempting to respond to two emails in > > one. > > > > Ok, let me provide an example of an FE (same concept applies at > > the CE). > > Heres a diagram that may help to clarify what i have been refering > > to; note that netlink2 did not start like this, however over > > time implementation ended being like this; this shows an FE > > side implementation. I have attached the two diagrams so they > > dont get mangled. > > > > Figure 1. shows the netlink2 manager ( a s/ware daemon) managing > > two socket connections on the lower side labelled as wire0 and wire1 > > and entities called FECs on the upper side. > > Figure2 shows the role of the FEC; it MAY manages one or more LFBs. > > The communication mechanism used there is again beyond the scope of > > ForCES. > > Messages arriving at either of the sockets could end up in two sorts > of > > general classes of destinations: > > 1) for the FE - in which they are serviced by the netlink2 daemon. > > 2) for any of FEC0 to FECx; in that case the netlink2 daemon > multiplexes > > them to those entities. > > > > Although i only list two classes, there could be more - but thats > beside > > the point. > > FECs are OS processes/applications. (How they communicate to the > > netlink2 daemon is beyond the scope of ForCES; lets say it could be a > > local OS IPC.) > > > > As an example, there may be a FEC which controls several LFBs; > > Another example is an FEC which sends and receives OSPF hellos. > > Each FEC has a counterpart which understands it on the CE side. > > The CE piece of OSPF (call it CEC) sends messages to > > a specific PID when it wants to talk to the FEC portion (the hello > > offloader). > > As you can see this is application talking to another application; > > this could be looked at as essentially IPC. Therefore the concept of > PID > > is useful. > > > > Now to address your emails: > > > > On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote: > > > > Weiming, could you make sure your emails wrap around at 80 characters? > > It helps when i am trying to respond. > > > > > > > We think a layer-based tree structure according to the ForCES > architecture > > > is efficient to do such addressing. If we address entities at > > > the FE coarse layer ( to take the FE as a whole entity, which idea > is also > > > used by new version of FE model ), we only need to > > > have a FE ID. > > > > If i am not mistaken what you are talking about is a detail > > on how the address gets split; i.e you want to have a hierachical > > addressing - as an example you want to split the address above to > > FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above). > > If this is the case, i think it is a small detail and we could move > > on and talk baout it later; if not please look at the diagram and > > tell me how you would split the ID to configure LFB0. I actually have > > a feeling your approach to this would be VERY different from > Hormuzd;-> > > > > > To address > > > CEs, we use CE ID. By defining IDs for FE broadcast, LFB broadcast, > LFB > > > Instance broadcast, and CE broadcast, following addressing can be > > > implemented: > > > > I think we all agree on the broadcast or multicast to a specific > > type of entities. > > > > >>- a set of LFBs on an FE > > > - a set of LFBs on different FEs > > > > > > > > > [Wang Re: Are the set of LFBs of the same type?] > > > > Yes, example "all IPV4 fwding LFBs" instead of "all LFBs". > > > > > - proxies for LFBs, > > > - proxies for control application in the form on the CEs, > > > > > > [Wang Re: If ever we have these proxies, are they need to be seen > at the > > > protocol layer? > > > > No, there is nothing speacial needed at the protocol header. The list > > was an exhaustive example. > > > > > Moreover, how about FE proxies then?] > > > > They dont need to be addressed by anything speacial in the header. > > > > On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: > > > > > [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we > go > > > with that terminology then? > > > > Lets talk about what needs to be addressed first before we jump to > that. > > Refer to the two diagrams i sent. > > > > > [HK] I don't see the value of having an App ID in the common header. > How > > > is it useful ? May be if you could give a good example of how this > can > > > be used, it would help. The ForCES endpoints are CEs and FEs which > > > should be addressed in the common header. LFBs are like knobs on the > FEs > > > used to program its functionality. I am sure you know all this very > well > > > and I think most folks will agree on this. If we go with a different > > > view, we will probably land up breaking the FE Model as well. Other > > > views on this one ? > > > > Refer to the two diagrams i sent for an example, then lets discuss. > > > > [HK] Could you give me an example of why this is limiting? > > > > I was refering to the fact that you have a single ID to address > > entities within an FE or CE. In my diagram i am rtying to show theres > > more than one class of end targets. So calling it CEID or FEID > > is limiting. > > > > > I would like > > > to know if using 16 bits would break in some scenarios. If this was > part > > > of a TLV I wouldn't care as much, but since this is the common > header, I > > > am a bit concerned...acting stingy :-)) > > .. > > > > [HK] Exactly, ForCES has much limited/specific scope (NE) than general > > > purpose middleware such as Corba. You cannot compare these 2 because > of > > > the difference in scope. > > > > I gave the historical experience of PCs (by quoting a naive bill > gates), > > IPV4(by making a mockery over the famous last words that brought IPV6 > to > > the world) and now i can add the experience of unix which would have > > been more interesting with 64 bit PIDs. > > Summary: Nothing would break; however it is useful to learn from > history > > and say lets go with something larger. > > > > Again, apologies for long email; hopefully this would group > > things together. > > > > cheers, > > jamal > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol