From owner-manet@itd.nrl.navy.mil Mon Jul 3 10:44:25 2000 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 KAA02766 for ; Mon, 3 Jul 2000 10:44:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA21857 for manet-outgoing; Mon, 3 Jul 2000 08:22:25 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA21852 for ; Mon, 3 Jul 2000 08:22:23 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e63CMJ508217; Mon, 3 Jul 2000 14:22:19 +0200 (MET DST) Message-Id: <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 03 Jul 2000 14:27:18 +0200 To: Zygmunt Haas , Laurent Viennot Subject: Re: Overhead analysis Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <14680.41651.904705.246567@cupidon.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id IAA21853 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Zygmunt, It is not exactly the conclusion of our study. It looks like that hybrid protocol overheads are roughly the sum of flooding protocol overheads and hello protocol overheads. They would be very likely always above. This is the reason why we a priori prefered not to include it in the first version of our study. Philippe and Laurent PS: Laurent just got a baby yesterday, so I replace him on the spot. A 07:47 30/06/00 -0400, Zygmunt Haas a écrit : >Hi Laurent, > >There is another "class" of protocols, the hybrid class, which is a mix of >proactive-reactive behavior. Examples of such protocols include the Zone >Routing Protocol (ZRP) and the Fisheye protocol. > >As you have stated, pure proactive/reactive protocols may not present >"optimal" performance for a specific network operational conditions >(mobility and traffic). The bigest advantage of the hybrid class is that >it can adapt itself to the network operational conditions. More >specifically, by dynamically adjusting the ratio of the proactive >vs. reactive behavior, the amount of overhead control traffic can be >*drastically* reduced. In the Zone Routing Protocol, this is achieved >through the use of a single parameter - the Zone Radius, which is updated >based on continual measurement of the mobility (the rate of >creation/destruction of links with a node's neighbors) and the amout of >traffic a node sees. (More on updating of the zone radius could be found >in our paper in JSAC / August 1999.) > >I guess, what I am trying to say is that the hybrid class of protocols is >the answer to the conclusions of your study - that in order to "cover" a >broad range of MANET topologies (size of networks) and operational >conditions, a *hybrid* strategy should be used. > >Zygmunt. >==--==-=== >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >Prof. Zygmunt J. Haas tel: +1-607-255-3454 >Wireless Networks Laboratory >School of Electrical Engineering fax: +1-607-255-9072 >Cornell University >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu >Ithaca, NY 14853 >U.S.A http://www.ee.cornell.edu/~haas/wnl.html >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > >On Tue, 27 Jun 2000, Laurent Viennot wrote: > >> >> Dear MANet members, >> >> After the discussions on the mailing, we have been thinking quite a >> lot with Philippe on overhead. We have developed some analysis about >> the relation between routing performance (overhead) and networks >> parameters (size, mobility, traffic). Our aim is to identify the >> scenarios which favor such and such MANet protocols. We consider a >> mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). >> >> We have identified two classes of protocols which more or less fit >> the reactive and proactive boundary: >> >> 1. the flooding protocols (AODV/DSR, TORA) >> 2. the hello protocols (DSDV,OLSR) >> >> The performance are quantified by the quantity of overhead generated >> by each protocols. We have identified two source of overheads: >> >> A. the control overheads >> B. the route overheads >> >> Our main findings are the following: >> >> -Both classes have O(N^2) control overheads which is no surprising >> from graph theory point of view. Flooding algorithm and hello >> algorithm have different factors in front of N^2 which actually >> depends on traffic, geometry, mobility. One can find scenarios in >> favor of flooding and other scenarios in favor of hello. >> >> -Flooding protocols may not provide optimal routes (in term of hop >> number) the average deviation between optimal routes can be >> significant (a factor of 33% in dense 1D networks, more in 2D and >> 3D). The overhead generated by the extra transmission of data may be >> important since it is proportional to data traffic. >> >> >> A research report detailing these results is available: >> http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) >> >> >> Comments are welcome, >> >> >> Laurent >> > From owner-manet@itd.nrl.navy.mil Mon Jul 3 12:21:05 2000 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 MAA04322 for ; Mon, 3 Jul 2000 12:21:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24550 for manet-outgoing; Mon, 3 Jul 2000 10:38:40 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24545 for ; Mon, 3 Jul 2000 10:38:38 -0400 (EDT) Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 1397Mn-0001SV-00; Mon, 03 Jul 2000 15:38:33 +0100 Message-ID: <3960A569.83220ED0@ee.surrey.ac.uk> Date: Mon, 03 Jul 2000 15:38:33 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr, manet Subject: Re: Overhead analysis References: <14680.41651.904705.246567@cupidon.inria.fr> <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Philippe how about including in your results a routing scheme that uses localisation for route discovery as well as for the route repair of broken data paths.. Such as scheme could be the RDMAR protocol..-:) Although RDMAR is referred in your report, I would be very much interested to see it in your analysis too. Regards, George A. > Hi, Zygmunt, > > It is not exactly the conclusion of our study. It looks like that hybrid > protocol overheads are roughly the sum of flooding protocol overheads and > hello protocol overheads. They would be very likely always above. This is > the reason why we a priori prefered not to include it in the first version > of our study. > > Philippe and Laurent > > PS: Laurent just got a baby yesterday, so I replace him on the spot. > > A 07:47 30/06/00 -0400, Zygmunt Haas a écrit : > >Hi Laurent, > > > >There is another "class" of protocols, the hybrid class, which is a mix of > >proactive-reactive behavior. Examples of such protocols include the Zone > >Routing Protocol (ZRP) and the Fisheye protocol. > > > >As you have stated, pure proactive/reactive protocols may not present > >"optimal" performance for a specific network operational conditions > >(mobility and traffic). The bigest advantage of the hybrid class is that > >it can adapt itself to the network operational conditions. More > >specifically, by dynamically adjusting the ratio of the proactive > >vs. reactive behavior, the amount of overhead control traffic can be > >*drastically* reduced. In the Zone Routing Protocol, this is achieved > >through the use of a single parameter - the Zone Radius, which is updated > >based on continual measurement of the mobility (the rate of > >creation/destruction of links with a node's neighbors) and the amout of > >traffic a node sees. (More on updating of the zone radius could be found > >in our paper in JSAC / August 1999.) > > > >I guess, what I am trying to say is that the hybrid class of protocols is > >the answer to the conclusions of your study - that in order to "cover" a > >broad range of MANET topologies (size of networks) and operational > >conditions, a *hybrid* strategy should be used. > > > >Zygmunt. > >==--==-=== > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > >Prof. Zygmunt J. Haas tel: +1-607-255-3454 > >Wireless Networks Laboratory > >School of Electrical Engineering fax: +1-607-255-9072 > >Cornell University > >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu > >Ithaca, NY 14853 > >U.S.A http://www.ee.cornell.edu/~haas/wnl.html > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > >On Tue, 27 Jun 2000, Laurent Viennot wrote: > > > >> > >> Dear MANet members, > >> > >> After the discussions on the mailing, we have been thinking quite a > >> lot with Philippe on overhead. We have developed some analysis about > >> the relation between routing performance (overhead) and networks > >> parameters (size, mobility, traffic). Our aim is to identify the > >> scenarios which favor such and such MANet protocols. We consider a > >> mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). > >> > >> We have identified two classes of protocols which more or less fit > >> the reactive and proactive boundary: > >> > >> 1. the flooding protocols (AODV/DSR, TORA) > >> 2. the hello protocols (DSDV,OLSR) > >> > >> The performance are quantified by the quantity of overhead generated > >> by each protocols. We have identified two source of overheads: > >> > >> A. the control overheads > >> B. the route overheads > >> > >> Our main findings are the following: > >> > >> -Both classes have O(N^2) control overheads which is no surprising > >> from graph theory point of view. Flooding algorithm and hello > >> algorithm have different factors in front of N^2 which actually > >> depends on traffic, geometry, mobility. One can find scenarios in > >> favor of flooding and other scenarios in favor of hello. > >> > >> -Flooding protocols may not provide optimal routes (in term of hop > >> number) the average deviation between optimal routes can be > >> significant (a factor of 33% in dense 1D networks, more in 2D and > >> 3D). The overhead generated by the extra transmission of data may be > >> important since it is proportional to data traffic. > >> > >> > >> A research report detailing these results is available: > >> http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) > >> > >> > >> Comments are welcome, > >> > >> > >> Laurent > >> > > -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Mon Jul 3 12:22:56 2000 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 MAA04335 for ; Mon, 3 Jul 2000 12:22:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24715 for manet-outgoing; Mon, 3 Jul 2000 10:48:41 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24710 for ; Mon, 3 Jul 2000 10:48:39 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id KAA25370; Mon, 3 Jul 2000 10:48:38 -0400 (EDT) Date: Mon, 3 Jul 2000 10:48:35 -0400 (EDT) From: Zygmunt Haas To: jacquet@menetou.inria.fr cc: Laurent Viennot , manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id KAA24711 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi Philippe, Hmmm, this is not so. Hybrid protocols, through their ability to adjust to the network operational conditions will *always* result in less control traffic than pure proactive or pure reactive protocols. This statement is nearly self-explanatory, as *hyrbrid protocols degrade to either pure reactive or pure proactive behavior, based on their parameter settings.* Let me comment on the last statement: in the Zone Routing Protocol (ZRP), for instance, there is a single parameter to set - the Zone Radius (ZR). If ZR=1, then ZRP degrades to pure reactice protocol, while when ZR=\infty, then ZRP degrades to pure proactive protocol. The characteristic curves of ZRP look as follows: (see for instance the paper: [M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration of for the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc Networks, vol. 17, no.8, August 1999]) total traffic ^ |* | * * | * * | * * | * * | * * | * * | * * | *** | ---------|--------------> Zone Radius the optimal ZR The protocol should dynamically adjust the ZR, so as to minimize the total control traffic. Depending on the operational conditions of the network, the reduction of the hybrid scheme can be "quite dramatic" - please see the above paper for more quantitative results. Thus, repeating myself, the hybrid protocols yield *much* reduction in the control traffic and are a natural choice in an environment with changing operational conditions, as well as for a broad range of MANETs. Congratulations to Laurent on his new baby ! Zygmunt. ==--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Mon, 3 Jul 2000 jacquet@menetou.inria.fr wrote: > Hi, Zygmunt, > > It is not exactly the conclusion of our study. It looks like that hybrid > protocol overheads are roughly the sum of flooding protocol overheads and > hello protocol overheads. They would be very likely always above. This is > the reason why we a priori prefered not to include it in the first version > of our study. > > Philippe and Laurent > > PS: Laurent just got a baby yesterday, so I replace him on the spot. > > A 07:47 30/06/00 -0400, Zygmunt Haas a écrit : > >Hi Laurent, > > > >There is another "class" of protocols, the hybrid class, which is a mix of > >proactive-reactive behavior. Examples of such protocols include the Zone > >Routing Protocol (ZRP) and the Fisheye protocol. > > > >As you have stated, pure proactive/reactive protocols may not present > >"optimal" performance for a specific network operational conditions > >(mobility and traffic). The bigest advantage of the hybrid class is that > >it can adapt itself to the network operational conditions. More > >specifically, by dynamically adjusting the ratio of the proactive > >vs. reactive behavior, the amount of overhead control traffic can be > >*drastically* reduced. In the Zone Routing Protocol, this is achieved > >through the use of a single parameter - the Zone Radius, which is updated > >based on continual measurement of the mobility (the rate of > >creation/destruction of links with a node's neighbors) and the amout of > >traffic a node sees. (More on updating of the zone radius could be found > >in our paper in JSAC / August 1999.) > > > >I guess, what I am trying to say is that the hybrid class of protocols is > >the answer to the conclusions of your study - that in order to "cover" a > >broad range of MANET topologies (size of networks) and operational > >conditions, a *hybrid* strategy should be used. > > > >Zygmunt. > >==--==-=== > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > >Prof. Zygmunt J. Haas tel: +1-607-255-3454 > >Wireless Networks Laboratory > >School of Electrical Engineering fax: +1-607-255-9072 > >Cornell University > >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu > >Ithaca, NY 14853 > >U.S.A http://www.ee.cornell.edu/~haas/wnl.html > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > > > >On Tue, 27 Jun 2000, Laurent Viennot wrote: > > > >> > >> Dear MANet members, > >> > >> After the discussions on the mailing, we have been thinking quite a > >> lot with Philippe on overhead. We have developed some analysis about > >> the relation between routing performance (overhead) and networks > >> parameters (size, mobility, traffic). Our aim is to identify the > >> scenarios which favor such and such MANet protocols. We consider a > >> mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). > >> > >> We have identified two classes of protocols which more or less fit > >> the reactive and proactive boundary: > >> > >> 1. the flooding protocols (AODV/DSR, TORA) > >> 2. the hello protocols (DSDV,OLSR) > >> > >> The performance are quantified by the quantity of overhead generated > >> by each protocols. We have identified two source of overheads: > >> > >> A. the control overheads > >> B. the route overheads > >> > >> Our main findings are the following: > >> > >> -Both classes have O(N^2) control overheads which is no surprising > >> from graph theory point of view. Flooding algorithm and hello > >> algorithm have different factors in front of N^2 which actually > >> depends on traffic, geometry, mobility. One can find scenarios in > >> favor of flooding and other scenarios in favor of hello. > >> > >> -Flooding protocols may not provide optimal routes (in term of hop > >> number) the average deviation between optimal routes can be > >> significant (a factor of 33% in dense 1D networks, more in 2D and > >> 3D). The overhead generated by the extra transmission of data may be > >> important since it is proportional to data traffic. > >> > >> > >> A research report detailing these results is available: > >> http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) > >> > >> > >> Comments are welcome, > >> > >> > >> Laurent > >> > > > From owner-manet@itd.nrl.navy.mil Mon Jul 3 13:03:12 2000 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 NAA04901 for ; Mon, 3 Jul 2000 13:03:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA25338 for manet-outgoing; Mon, 3 Jul 2000 11:23:49 -0400 (EDT) Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA25333 for ; Mon, 3 Jul 2000 11:23:42 -0400 (EDT) Received: from localhost (azaziz@localhost) by iti-idsc.gov.eg (8.9.3+Sun/8.9.3) with ESMTP id SAA02543 for ; Mon, 3 Jul 2000 18:29:10 +0300 (EEST) Date: Mon, 3 Jul 2000 18:29:10 +0300 (EEST) From: SSDP143 To: manet@itd.nrl.navy.mil Subject: Destination sequence number Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear all, We are a goroup of students at the Information Technology Institute Egypt we are currently implementing the AODV deamon for linux, We have a question : what is meant by "Distination sequence number " in all packets ( RREQ, RREP, RERR,.)?and when any node needs to update this sequence(increment or .........)? Best regards Azza Hany Morcos From owner-manet@itd.nrl.navy.mil Mon Jul 3 15:21:36 2000 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 PAA06554 for ; Mon, 3 Jul 2000 15:21:36 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA27579 for manet-outgoing; Mon, 3 Jul 2000 13:23:22 -0400 (EDT) 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 NAA27574 for ; Mon, 3 Jul 2000 13:23:20 -0400 (EDT) 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 KAA21118; Mon, 3 Jul 2000 10:22:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA21889; Mon, 3 Jul 2000 10:22:11 -0700 X-Virus-Scanned: Mon, 3 Jul 2000 10:22:11 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma021737; Mon, 3 Jul 00 10:22:06 -0700 Message-ID: <3960CBBF.D39E8EAC@iprg.nokia.com> Date: Mon, 03 Jul 2000 10:22:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: SSDP143 CC: manet@itd.nrl.navy.mil Subject: Re: Destination sequence number 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 folks, The destination sequence number is a monotonically increasing number maintained by a node in the ad hoc network. Each node keeps its own destination sequence number, and uses it to ensure freshness for RREP messages. Each other node that receives a RREP is required by protocol to keep track of the destination sequence number for the associated IP address representing the destination. A destination sequence number can only be incremented by the destination, except in one circumstance which has the effect of invalidating routes towards that destination. So, the destination has to be considered the _authority_ for any transactions involving that number. Other nodes offering routes to that destination will have the validity of their offer judged based on the value of the sequence number. A higher destination sequence number can invalidate any route towards that destination that is tagged with a lower destination sequence number. The destination increments the sequence number whenever it notices a change in its neighborhood topology. It is possible for the destination sequence number to be incremented by an intermediate node, but ONLY by one, and ONLY if that intermediate node then reports a metric of infinity. Then any sequence number reported by the destination will result in a route update that replaces the pseudo-route-entry represented by the infinite metric. I hope that is a sufficiently clear, if long, explanation for an idea that is basically very simple. However, this simple idea lies at the very heart of the protocol. It is what makes AODV loop-free at all instants. Regards, Charlie P. SSDP143 wrote: > > Dear all, > We are a goroup of students at the Information Technology > Institute Egypt we are currently implementing the AODV deamon for linux, > We have a question : what is meant by "Distination sequence number " in > all packets ( RREQ, RREP, RERR,.)?and when any node needs to update this > sequence(increment or .........)? > > Best regards > Azza > Hany > Morcos From owner-manet@itd.nrl.navy.mil Mon Jul 3 15:23:13 2000 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 PAA06573 for ; Mon, 3 Jul 2000 15:23:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA27590 for manet-outgoing; Mon, 3 Jul 2000 13:24:23 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA27585 for ; Mon, 3 Jul 2000 13:24:21 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e63HOK518443; Mon, 3 Jul 2000 19:24:20 +0200 (MET DST) Message-Id: <3.0.1.32.20000703192919.00c8f260@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 03 Jul 2000 19:29:19 +0200 To: Zygmunt Haas Subject: Re: Overhead analysis Cc: Laurent Viennot , manet@itd.nrl.navy.mil In-Reply-To: References: <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id NAA27586 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Dear Zygmunt, I feel uncomfortable to talk about ZRP because it does not specify the link state algorithm it uses for intra-zone routing. If you use non-optimized OSPF link state, then I will agree with your plot, but if you use another optimized link state, like OLSR for example, you will obtain a completely different plot. As we see in our study, the leading overhead in OLSR is in the hello transmissions. Therefore ZRP implemented on OLSR will likely do worse than OLSR or flooding protocols as soon ZR is greater than 1 and smaller than infinity, because ZRP would include both hellos cost for intra-zone and flooding cost for inter-zone. We also expect that ZRP on OSPF will do worse than ZRP on OLSR. For example, I would expect a plot like this one, which depends on traffic scenarios, mobility, etc... But I am not sure at 100 %, it needs more work and we prefer to skip this in our first version. total traffic ZRP on OLSR ^ | | | * * * * * | * * | * * | | * * | | | ---|------------------|-----> Zone Radius the optimal ZR Best regards, Philippe PS: Laurent will come back soon, I will not able to continue this interesting discussion because I leave for a one week travel. A 10:48 03/07/00 -0400, Zygmunt Haas a écrit : >Hi Philippe, > >Hmmm, this is not so. Hybrid protocols, through their ability to adjust to >the network operational conditions will *always* result in less control >traffic than pure proactive or pure reactive protocols. This statement is >nearly self-explanatory, as *hyrbrid protocols degrade to either pure >reactive or pure proactive behavior, based on their parameter settings.* > >Let me comment on the last statement: in the Zone Routing Protocol (ZRP), >for instance, there is a single parameter to set - the Zone Radius >(ZR). If ZR=1, then ZRP degrades to pure reactice protocol, while when >ZR=\infty, then ZRP degrades to pure proactive protocol. The >characteristic curves of ZRP look as follows: (see for instance the >paper: [M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration >of for the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc >Networks, vol. 17, no.8, August 1999]) > > >total traffic > ^ > |* > | * * > | * * > | * * > | * * > | * * > | * * > | * * > | *** > | > ---------|--------------> Zone Radius > the optimal ZR > >The protocol should dynamically adjust the ZR, so as to minimize the total >control traffic. Depending on the operational conditions of the network, >the reduction of the hybrid scheme can be "quite dramatic" - please see >the above paper for more quantitative results. > >Thus, repeating myself, the hybrid protocols yield *much* reduction in the >control traffic and are a natural choice in an environment with changing >operational conditions, as well as for a broad range of MANETs. > >Congratulations to Laurent on his new baby ! > >Zygmunt. >==--==-==== > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >Prof. Zygmunt J. Haas tel: +1-607-255-3454 >Wireless Networks Laboratory >School of Electrical Engineering fax: +1-607-255-9072 >Cornell University >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu >Ithaca, NY 14853 >U.S.A http://www.ee.cornell.edu/~haas/wnl.html >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >On Mon, 3 Jul 2000 jacquet@menetou.inria.fr wrote: > >> Hi, Zygmunt, >> >> It is not exactly the conclusion of our study. It looks like that hybrid >> protocol overheads are roughly the sum of flooding protocol overheads and >> hello protocol overheads. They would be very likely always above. This is >> the reason why we a priori prefered not to include it in the first version >> of our study. >> >> Philippe and Laurent >> >> PS: Laurent just got a baby yesterday, so I replace him on the spot. >> >> A 07:47 30/06/00 -0400, Zygmunt Haas a écrit : >> >Hi Laurent, >> > >> >There is another "class" of protocols, the hybrid class, which is a mix of >> >proactive-reactive behavior. Examples of such protocols include the Zone >> >Routing Protocol (ZRP) and the Fisheye protocol. >> > >> >As you have stated, pure proactive/reactive protocols may not present >> >"optimal" performance for a specific network operational conditions >> >(mobility and traffic). The bigest advantage of the hybrid class is that >> >it can adapt itself to the network operational conditions. More >> >specifically, by dynamically adjusting the ratio of the proactive >> >vs. reactive behavior, the amount of overhead control traffic can be >> >*drastically* reduced. In the Zone Routing Protocol, this is achieved >> >through the use of a single parameter - the Zone Radius, which is updated >> >based on continual measurement of the mobility (the rate of >> >creation/destruction of links with a node's neighbors) and the amout of >> >traffic a node sees. (More on updating of the zone radius could be found >> >in our paper in JSAC / August 1999.) >> > >> >I guess, what I am trying to say is that the hybrid class of protocols is >> >the answer to the conclusions of your study - that in order to "cover" a >> >broad range of MANET topologies (size of networks) and operational >> >conditions, a *hybrid* strategy should be used. >> > >> >Zygmunt. >> >==--==-=== >> >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >> >Prof. Zygmunt J. Haas tel: +1-607-255-3454 >> >Wireless Networks Laboratory >> >School of Electrical Engineering fax: +1-607-255-9072 >> >Cornell University >> >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu >> >Ithaca, NY 14853 >> >U.S.A http://www.ee.cornell.edu/~haas/wnl.html >> >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >> > >> >On Tue, 27 Jun 2000, Laurent Viennot wrote: >> > >> >> >> >> Dear MANet members, >> >> >> >> After the discussions on the mailing, we have been thinking quite a >> >> lot with Philippe on overhead. We have developed some analysis about >> >> the relation between routing performance (overhead) and networks >> >> parameters (size, mobility, traffic). Our aim is to identify the >> >> scenarios which favor such and such MANet protocols. We consider a >> >> mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). >> >> >> >> We have identified two classes of protocols which more or less fit >> >> the reactive and proactive boundary: >> >> >> >> 1. the flooding protocols (AODV/DSR, TORA) >> >> 2. the hello protocols (DSDV,OLSR) >> >> >> >> The performance are quantified by the quantity of overhead generated >> >> by each protocols. We have identified two source of overheads: >> >> >> >> A. the control overheads >> >> B. the route overheads >> >> >> >> Our main findings are the following: >> >> >> >> -Both classes have O(N^2) control overheads which is no surprising >> >> from graph theory point of view. Flooding algorithm and hello >> >> algorithm have different factors in front of N^2 which actually >> >> depends on traffic, geometry, mobility. One can find scenarios in >> >> favor of flooding and other scenarios in favor of hello. >> >> >> >> -Flooding protocols may not provide optimal routes (in term of hop >> >> number) the average deviation between optimal routes can be >> >> significant (a factor of 33% in dense 1D networks, more in 2D and >> >> 3D). The overhead generated by the extra transmission of data may be >> >> important since it is proportional to data traffic. >> >> >> >> >> >> A research report detailing these results is available: >> >> http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) >> >> >> >> >> >> Comments are welcome, >> >> >> >> >> >> Laurent >> >> >> > >> > From owner-manet@itd.nrl.navy.mil Mon Jul 3 17:48:07 2000 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 RAA07918 for ; Mon, 3 Jul 2000 17:48:06 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA29916 for manet-outgoing; Mon, 3 Jul 2000 15:50:17 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA29911 for ; Mon, 3 Jul 2000 15:50:15 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id PAA04910; Mon, 3 Jul 2000 15:50:13 -0400 (EDT) Date: Mon, 3 Jul 2000 15:50:13 -0400 (EDT) From: Zygmunt Haas To: jacquet@menetou.inria.fr cc: Laurent Viennot , manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <3.0.1.32.20000703192919.00c8f260@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Philipe, > As we see in our study, the leading overhead in OLSR is in the hello > transmissions. I would agree with this. > Therefore ZRP implemented on OLSR will likely do worse than > OLSR or flooding protocols as soon ZR is greater than 1 and smaller than > infinity, because ZRP would include both hellos cost for intra-zone and > flooding cost for inter-zone. No, this is not correct. For any specific intra-zone protocol, one can obtain a *minimum* by choosing the right ZR. The point that you are missing is the way the inter-zone is implemented in ZRP - it is NOT a regular flooding. Rather, the inter-zone is implemented through bordercasting (which, in our newer version, is done through multicasting). Thus the ZRP cost is NOT a simple addition of the intra-zone and flooding costs. In other words, indeed, as the ZR increases, the cost of the intra-zone increases, BUT the cost of the inter-zone decreases. ***This is the whole idea of the hybrid protocol like ZRP. *** Again, the total control traffic in ZRP as a function of the Zone Radius behaves as follows: total traffic ^ |* | * * | * * | * * | * * | * * | * * | * * | *** | -|-------|-----------------|--> Zone Radius pure optimal ZR pure reactive proactive behavior behavior Again, please refer to our paper: [M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration of for the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc Networks, vol. 17, no.8, August 1999] - the interplay between the cost of the intra-zone and the inter-zone routing is clearly explained there. > We also expect that ZRP on OSPF will do worse > than ZRP on OLSR. This is possible - optimizing the intra-zone protocol will, indeed, result in lower total ZRP cost. But this is not the issue. The issue is that once you have chosen the intra-zone (proactive protocol, whether OSPF, OLSR, or any other you-favorite-procative protocol), the hybrid mechanism allows you to adjust to the operational conditions of the network. Let me try to clarify the last statement again. For a highly mobile network, a hybrid protocol with a smaller ZR will do better (as the cost of maintaining the states in a zone (through proactive protocol) will be too costly). On the other hand, if a network is nearly stationary and there are no changes, large ZR (in the limit the whole network) will lead to smaller total overhead. Again, note that the total cost is the sum of the intra-zone and inter-zone routing costs. The first increases, while the second decreases as the ZR increases. I think that your confusion stems from the fact that you overlooked the complementary behavior of the two costs. Regards, Zygmunt. ==-=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Mon Jul 3 17:59:31 2000 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 RAA07955 for ; Mon, 3 Jul 2000 17:59:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA00158 for manet-outgoing; Mon, 3 Jul 2000 16:18:46 -0400 (EDT) Received: from taurus.cs.albany.edu (taurus.cs.albany.edu [169.226.2.109]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA00148 for ; Mon, 3 Jul 2000 16:18:29 -0400 (EDT) Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id QAA13639; Mon, 3 Jul 2000 16:16:33 -0400 (EDT) From: "S.S.Ravi" Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id QAA15531; Mon, 3 Jul 2000 16:16:31 -0400 Date: Mon, 3 Jul 2000 16:16:31 -0400 Message-Id: <200007032016.QAA15531@euler.cs.albany.edu> To: dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de, itc@ieee.org, manet@itd.nrl.navy.mil, mobile-ip@standards.nortelnetworks.com, mobility@media.mit.edu, opt-net@zib.de, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu Subject: DIAL M Workshop (Early Registration Deadline: July 15, 2000) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk CALL FOR PARTICIPATION 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html EARLY REGISTRATION DEADLINE: July 15, 2000 SPONSORS: (a) National Science Foundation. (b) ACM SIGMOBILE (in cooperation with ACM SIGACT) (c) Basic and Applied Simulation Science Group (TSA-2) of Los Alamos National Laboratory. SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The conference program includes three invited talks and 11 contributed papers. The list of contributed papers and the presentation schedule are available through the workshop URL given above. REGISTRATION INFORMATION: DIAL M Workshop registration is being conducted in conjunction with the MobiCom 2000 conference registration. Please see the Mobicom 2000 home page (http://www.argreenhouse.com/mobicom2000) for registration and related information. STUDENT TRAVEL GRANTS: Students attending DIAL M may apply for Student Grants to defray a part of the cost of attending the workshop. Any student may apply (presenting a paper is NOT a prerequisite). For further information, please contact the DIAL M Program Chair Professor Errol Lloyd (elloyd@udel.edu). Funding for these grants is provided by the National Science Foundation. INVITED TALKS: (a) ``Data Structures for Mobile Data'', by Leonidas Guibas (Stanford University). (b) ``The Post-PC Era: It's about the New Services-Enabled Internet'', by Randy Katz (University of California, Berkeley). (c) ``Application of a Theory of Simulation to Models of Mobile Communication Systems'', by Chris Barrett (Los Alamos National Laboratory). PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S. S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. From owner-manet@itd.nrl.navy.mil Mon Jul 3 21:20:27 2000 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 VAA09078 for ; Mon, 3 Jul 2000 21:20:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA02192 for manet-outgoing; Mon, 3 Jul 2000 19:22:18 -0400 (EDT) Received: from hnl.erg.sri.com (hnl.erg.sri.com [128.18.100.13] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA02187 for ; Mon, 3 Jul 2000 19:22:16 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by hnl.erg.sri.com (8.9.1/8.9.0) with ESMTP id QAA24049; Mon, 3 Jul 2000 16:22:15 -0700 (PDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.8.8+Sun/8.8.8) with ESMTP id QAA06767; Mon, 3 Jul 2000 16:22:11 -0700 (PDT) Message-Id: <200007032322.QAA06767@pit.erg.sri.com> To: Zygmunt Haas cc: jacquet@menetou.inria.fr, Laurent Viennot , manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-reply-to: Your message of "Mon, 03 Jul 2000 15:50:13 EDT." Date: Mon, 03 Jul 2000 16:22:11 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Zygmunt, > Let me try to clarify the last statement again. For a highly mobile > network, a hybrid protocol with a smaller ZR will do better (as the cost > of maintaining the states in a zone (through proactive protocol) will be > too costly). Is the above statement true even if the traffic demand is heavy and uniformly distributed? I think this was discussed before. In this case, in a highly mobile network with heavy uniform traffic, each node must be provided with frequently updated paths to all destinations, which is what a proactive protocol provides. And an efficient proactive protocol (e.g., OLSR or STAR or TBRPF) may be able to do this more efficiently than a reactive protocol. Richard ----------------------- 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 ------------------------ > On the other hand, if a network is nearly stationary and > there are no changes, large ZR (in the limit the whole network) will lead > to smaller total overhead. Again, note that the total cost is the sum of > the intra-zone and inter-zone routing costs. The first increases, while > the second decreases as the ZR increases. > > I think that your confusion stems from the fact that you overlooked the > complementary behavior of the two costs. > > Regards, > > Zygmunt. > ==-=-===== > > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas tel: +1-607-255-3454 > Wireless Networks Laboratory > School of Electrical Engineering fax: +1-607-255-9072 > Cornell University > 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu > Ithaca, NY 14853 > U.S.A http://www.ee.cornell.edu/~haas/wnl.html > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > From owner-manet@itd.nrl.navy.mil Tue Jul 4 07:30:11 2000 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 HAA26625 for ; Tue, 4 Jul 2000 07:30:11 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA07362 for manet-outgoing; Tue, 4 Jul 2000 05:30:11 -0400 (EDT) Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA07273 for ; Tue, 4 Jul 2000 05:30:04 -0400 (EDT) Received: from localhost (habanoub@localhost) by iti-idsc.gov.eg (8.9.3+Sun/8.9.3) with ESMTP id MAA10796 for ; Tue, 4 Jul 2000 12:35:35 +0300 (EEST) Date: Tue, 4 Jul 2000 12:35:35 +0300 (EEST) From: SSDP143 To: mobile adhoc group Subject: Source sequence number Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi what is the main goal of using the source sequence number, and is it a fixed number for each node? and if so, what is the basis on which a node decides it's source seq number? thanks From owner-manet@itd.nrl.navy.mil Tue Jul 4 11:00:30 2000 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 LAA28359 for ; Tue, 4 Jul 2000 11:00:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA08996 for manet-outgoing; Tue, 4 Jul 2000 09:01:46 -0400 (EDT) Received: from giascl01.vsnl.net.in (giascl01.vsnl.net.in [202.54.9.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA08991 for ; Tue, 4 Jul 2000 09:01:33 -0400 (EDT) Received: from impactjucal2 (ppp112-29.pppcal.vsnl.net.in [203.197.112.29]) by giascl01.vsnl.net.in (8.9.0/8.9.0) with SMTP id SAA21180; Tue, 4 Jul 2000 18:32:06 +0500 (GMT+0500) From: "Samir R. Das" To: "SSDP143" , "mobile adhoc group" Subject: RE: Source sequence number Date: Tue, 4 Jul 2000 09:02:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I assume that your question relates to AODV. Source sequence number is the sequence number of the source node. Each node X maintains a sequence number for itself. See Charlie's last email about the details how sequence numbers are maintained. Sequence numbers serve somewhat similar purpose as logical clocks, if you are familiar with the latter concept. The terms "destination sequence number" or "source sequence number" are contextual. For example, if a node Y sends out an RREQ for a route to X, it includes its own current sequence number in the RREQ message as well as the last known sequence number of node X. Since node Y is the source and node X is the destination, Y's sequence number is called the source sequence number and X's sequence number is called the destination sequence number. Hope this helps, Samir >-----Original Message----- >From: owner-manet@itd.nrl.navy.mil >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of SSDP143 >Sent: Tuesday, July 04, 2000 5:36 AM >To: mobile adhoc group >Subject: Source sequence number > > >Hi >what is the main goal of using the source sequence number, and is it a >fixed number for each node? and if so, what is the basis on which a node >decides it's source seq number? >thanks > From owner-manet@itd.nrl.navy.mil Tue Jul 4 20:48:12 2000 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 UAA01752 for ; Tue, 4 Jul 2000 20:48:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA14356 for manet-outgoing; Tue, 4 Jul 2000 18:59:40 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA14351 for ; Tue, 4 Jul 2000 18:59:39 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id SAA00756; Tue, 4 Jul 2000 18:59:33 -0400 (EDT) Date: Tue, 4 Jul 2000 18:59:31 -0400 (EDT) From: Zygmunt Haas To: Richard cc: jacquet@menetou.inria.fr, Laurent Viennot , manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <200007032322.QAA06767@pit.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Richard, On Mon, 3 Jul 2000, Richard wrote: > > Let me try to clarify the last statement again. For a highly mobile > > network, a hybrid protocol with a smaller ZR will do better (as the cost > > of maintaining the states in a zone (through proactive protocol) will be > > too costly). > > Is the above statement true even if the traffic demand is heavy > and uniformly distributed? I think this was discussed before. > In this case, in a highly mobile network with heavy uniform traffic, > each node must be provided with frequently updated paths to all > destinations, which is what a proactive protocol provides. > And an efficient proactive protocol (e.g., OLSR or STAR or TBRPF) may > be able to do this more efficiently than a reactive protocol. You have asked a very interesting and important question. I have been a bit "simplistic" in my previous postings - my goal was to justify the claims that the hybrid protocols can do better, sometimes drastically better, than pure reactive or proactive protocols. However, in fact, there are *two* parameters that control what the "optimal" mixture of practive vs. reactive behavior of a protocol should be: the mobility of the nodes (how fast nodes move relative to their neighbors, and, thus, how often they break the links with their neighbors) and the activity of the nodes (how often they initiate the route discovery process). For the sake of simplicity, let's assume that the values of these two parameters are constant throughout the network. (Of course, in practical cases this is far from being true, especially when the network is large.) Let me first state the claim and then comment. The Claim: The larger the mobility of the network is and the smaller the activity, the more reactive the routing protocol should be. And, vice versa, the smaller the network mobility and the larger the activity, a more proactive protocol would lead to smaller total amount of control traffic. The justification is as follows, if the mobility is large, using a proactive scheme would lead to a situation in which the resources (wireless, processing, etc) used to "learn" the topology of the network would be wasted, as by the time that the information about the topology is used, the topology has already changed due to the large mobility of the nodes. Thus, more reactive appraoch would be better here. And vice versa, if the mobility is small ... Also, the larger the network activity is, a proactive approach would engage the route discovery process quite often. Thus learning the topology information would lead to less control traffic. Such learning of topology is, of course, done by a proactive protocol. And vice versa, if the network activity is small ... Of course, practical cases are in between ... this is why some mixture of proactive/reactive behavior is so beneficial. Relating this to the Zone Routing Protocol (ZRP), the larger the network mobility is and the smaller the network activity is, the more reactive the protocol should be and, thus, the smaller the Zone Radius (ZR) should be. In the limit, ZR=1, which is the pure flooding case - in which the changes of the network are so frequent that learning the topology is a total waste, since by the time it is used, the topology has already changed. Similarly, if the network activity is low, learning the network activity would not pay off, as the topology information is very infrequently needed. On the other side of the spectrum, if the mobility in the network is low (a stationary network, in the limit) and the network activity is high, the protocol should be more proactive, and the ZR should be large - in the limit the ZR=the network diameter (and conceptually, ZR=\infty). The reasons are as stated above. Happy 4th of July! Zygmunt. ===--=-=-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Wed Jul 5 12:49:22 2000 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 MAA11265 for ; Wed, 5 Jul 2000 12:49:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24604 for manet-outgoing; Wed, 5 Jul 2000 10:46:02 -0400 (EDT) Received: from hotmail.com (f174.law6.hotmail.com [216.32.241.174]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24599 for ; Wed, 5 Jul 2000 10:46:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Jul 2000 07:45:55 -0700 Received: from 128.178.151.157 by lw6fd.law6.hotmail.msn.com with HTTP; Wed, 05 Jul 2000 GMT X-Originating-IP: [128.178.151.157] From: "ck Toh" To: sdas@ececs.uc.edu, habanoub@iti-idsc.gov.eg, manet@itd.nrl.navy.mil Subject: RE: Source sequence number Date: Wed, 05 Jul 2000 14:45:55 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jul 2000 14:45:55.0671 (UTC) FILETIME=[B9827670:01BFE68F] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Charlie: Perhaps you should just confirm this: Source sequence no. is used by the source during transmission of route request message. This signifies the "freshness" of the request associated with this particular desired route. Destination sequence number is created by the receiver to confirm the "validity and freshness" of the selected route. How does that sound? C.K. >From: "Samir R. Das" >To: "SSDP143" , "mobile adhoc group" > >Subject: RE: Source sequence number >Date: Tue, 4 Jul 2000 09:02:57 -0400 > >Hi, > >I assume that your question relates to AODV. > >Source sequence number is the sequence number of the source node. Each node >X maintains a sequence number for itself. See Charlie's last email about >the >details how sequence numbers are maintained. Sequence numbers serve >somewhat >similar purpose as logical clocks, if you are familiar with the latter >concept. > >The terms "destination sequence number" or "source sequence number" are >contextual. For example, if a node Y sends out an RREQ for a route to X, it >includes its own current sequence number in the RREQ message as well as the >last known sequence number of node X. Since node Y is the source and node X >is the destination, Y's sequence number is called the source sequence >number >and X's sequence number is called the destination sequence number. > >Hope this helps, > >Samir > > > >-----Original Message----- > >From: owner-manet@itd.nrl.navy.mil > >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of SSDP143 > >Sent: Tuesday, July 04, 2000 5:36 AM > >To: mobile adhoc group > >Subject: Source sequence number > > > > > >Hi > >what is the main goal of using the source sequence number, and is it a > >fixed number for each node? and if so, what is the basis on which a node > >decides it's source seq number? > >thanks > > > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Wed Jul 5 15:36:19 2000 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 PAA15346 for ; Wed, 5 Jul 2000 15:36:18 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA27738 for manet-outgoing; Wed, 5 Jul 2000 12:49:12 -0400 (EDT) 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 MAA27732 for ; Wed, 5 Jul 2000 12:49:10 -0400 (EDT) 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 JAA20448; Wed, 5 Jul 2000 09:49:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA01355; Wed, 5 Jul 2000 09:49:02 -0700 X-Virus-Scanned: Wed, 5 Jul 2000 09:49:02 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) with SMTP id smtpd2ZVsfx; Wed, 05 Jul 2000 09:48:52 PDT Message-ID: <396366F5.79EE59C1@iprg.nokia.com> Date: Wed, 05 Jul 2000 09:48:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ck Toh CC: Chai Keong Toh , manet@itd.nrl.navy.mil, "Samir R. Das" Subject: Re: Source sequence number 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 C-K., > Source sequence no. is used by the source during > transmission of route request message. This signifies > the "freshness" of the request associated with this > particular desired route. The source sequence number causes reverse routes back to the source to be tagged appropriately at each intermediate node, for purposes (at least!) of delivering the RREP back to the source of the RREQ. The destination sequence number causes prevents an intermediate node from responding unless it has "fresher" information about a route to the destination (i.e., a route tagged with a bigger sequence number). The two sequence numbers are associated with route table entries for two different nodes, and actually are used somewhat differently (one _enabling_ the insertion of a new route table entry for the source, the other _disabling_ the reporting of old route table information for the destination). Regards, Charlie P. > > Destination sequence number is created by the > receiver to confirm the "validity and freshness" > of the selected route. > > How does that sound? > > C.K. > > >From: "Samir R. Das" > >To: "SSDP143" , "mobile adhoc group" > > > >Subject: RE: Source sequence number > >Date: Tue, 4 Jul 2000 09:02:57 -0400 > > > >Hi, > > > >I assume that your question relates to AODV. > > > >Source sequence number is the sequence number of the source node. Each node > >X maintains a sequence number for itself. See Charlie's last email about > >the > >details how sequence numbers are maintained. Sequence numbers serve > >somewhat > >similar purpose as logical clocks, if you are familiar with the latter > >concept. > > > >The terms "destination sequence number" or "source sequence number" are > >contextual. For example, if a node Y sends out an RREQ for a route to X, it > >includes its own current sequence number in the RREQ message as well as the > >last known sequence number of node X. Since node Y is the source and node X > >is the destination, Y's sequence number is called the source sequence > >number > >and X's sequence number is called the destination sequence number. > > > >Hope this helps, > > > >Samir > > > > > > >-----Original Message----- > > >From: owner-manet@itd.nrl.navy.mil > > >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of SSDP143 > > >Sent: Tuesday, July 04, 2000 5:36 AM > > >To: mobile adhoc group > > >Subject: Source sequence number > > > > > > > > >Hi > > >what is the main goal of using the source sequence number, and is it a > > >fixed number for each node? and if so, what is the basis on which a node > > >decides it's source seq number? > > >thanks > > > > > > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Thu Jul 6 09:53:52 2000 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 JAA16591 for ; Thu, 6 Jul 2000 09:53:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA14085 for manet-outgoing; Thu, 6 Jul 2000 07:35:28 -0400 (EDT) Received: from neodymium (neodymium.btinternet.com [194.73.73.83]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA14080 for ; Thu, 6 Jul 2000 07:35:26 -0400 (EDT) Received: from [62.7.20.243] (helo=salavat) by neodymium with smtp (Exim 3.03 #82) id 13A9vl-00028K-00 for manet@itd.nrl.navy.mil; Thu, 06 Jul 2000 12:34:58 +0100 Message-ID: <003d01bfe725$32d52960$f314073e@salavat> From: "Salavat Magazov" To: "MANET mailing list" Subject: AODV questions Date: Thu, 6 Jul 2000 12:24:28 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01BFE745.20EFA840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Salavat Magazov" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BFE745.20EFA840 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello I have some questions regarding AODV. Sequence numbers in particular. Let's imagine the situation where node S (source) tries to find a route to node D (destination) using destination sequence number n. Say there are four other participating nodes 1, 2, 3 and 4 through which route lies. S-->1-->2-->3-->4-->D After the route is found the source starts transmitting, etc. Suddenly the connection, say, between 2 and 3 breaks for whatever reason, then RERR message is sent upstream to notify nodes of broken link. Let's also assume that route entry for D in nodes from 3 through D did not expire yet. S-x->1-x->2-x->3-->4-->D After S gets RERR message it will try to find another route to D, and as specification says uses n+1 as a dest. seq. number to be sure that new route is established. This is the point I do not understand. Why not to use n and thus use the part of the route from 3 to D which is still available? The nodes could save time and bandwidth. Due to the movement of nodes there may emerge another shorter route which will be used as soon as S is notified about its existence by receiving RREP with smaller hop count. Disclaimer: I am not saying that what you offer is bad, I rather say I do not understand the reason. Regards Salavat ------=_NextPart_000_0011_01BFE745.20EFA840 Content-Type: text/x-vcard; name="Salavat R. Magazov.vcf" Content-Disposition: attachment; filename="Salavat R. Magazov.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Magazov;Salavat;R. FN:Salavat R. Magazov NICKNAME:Sal ORG:University of Kent at Canterbury TEL;HOME;VOICE:+44-1227-472835 X-WAB-GENDER:2 BDAY:20000517 EMAIL;PREF;INTERNET:srm4@ukc.ac.uk EMAIL;INTERNET:salavat@ukonline.co.uk REV:20000706T082428Z END:VCARD ------=_NextPart_000_0011_01BFE745.20EFA840-- From owner-manet@itd.nrl.navy.mil Thu Jul 6 11:31:13 2000 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 LAA18658 for ; Thu, 6 Jul 2000 11:31:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA16932 for manet-outgoing; Thu, 6 Jul 2000 09:41:09 -0400 (EDT) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA16926 for ; Thu, 6 Jul 2000 09:41:06 -0400 (EDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JRGA9B7EGW000ABZ@research.kpn.com> for manet@itd.nrl.navy.mil; Thu, 6 Jul 2000 15:41:03 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id <3G58JFL9>; Thu, 06 Jul 2000 15:40:59 +0100 Content-return: allowed Date: Thu, 06 Jul 2000 15:40:59 +0100 From: "Groten, D." Subject: RE: Overhead analysis To: Laurent Viennot , "'jacquet@menetou.inria.fr'" Cc: manet@itd.nrl.navy.mil, Zygmunt Haas Message-id: <59063B5B4D98D311BC0D0001FA7E4522704C62@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id JAA16927 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi Philippe and Laurent, I have a reaction on your paper concerning the terminology you use: on the one hand, we can distinguish between on-demand (reactive) and table-driven (proactive) protocols. On the other hand, you have identified the first category as "flooding", and the second category as "hello". I find this quite confusing: both types of protocols flood routing information over the network. And while "hello"-type neighbour discovery is mandatory in a table-driven protocol, it may also be used in an on-demand protocol in order to establish and repair routes more quickly. Of course, strictly speaking, a purely on-demand protocol cannot use "hellos" because such neighbour discovery is performed pro-actively. But from the point-of-view of the general concept, the distinction between on-demand (end-to-end routes are only found when necessary) and pro-active (end-to-end routes always available) is more easy to grasp than that between hello and flooding. I have two questions: 1. Am I correct when concluding that your analysis is based purely on the extreme case where on-demand actually is equivalent to flooding of the entire network (no hellos to help)? 2. Is the combination of a simple neighbour discovery (via pro-active hellos) and on-demand route discovery equivalent to ZRP with zone radius 1? Regards, Dirk. ------------------------------------------------------------------ Dirk Groten KPNResearch ------------------------------------------------------------------ P. O. Box 421 Tel: +31 6 53747220 2260 AK Leidschendam Fax: +31 70 3326477 The Netherlands E-mail: mailto:d.groten@kpn.com -----Original Message----- From: jacquet@menetou.inria.fr [mailto:jacquet@menetou.inria.fr] Sent: maandag 3 juli 2000 18:29 To: Zygmunt Haas Cc: Laurent Viennot; manet@itd.nrl.navy.mil Subject: Re: Overhead analysis Dear Zygmunt, I feel uncomfortable to talk about ZRP because it does not specify the link state algorithm it uses for intra-zone routing. If you use non-optimized OSPF link state, then I will agree with your plot, but if you use another optimized link state, like OLSR for example, you will obtain a completely different plot. As we see in our study, the leading overhead in OLSR is in the hello transmissions. Therefore ZRP implemented on OLSR will likely do worse than OLSR or flooding protocols as soon ZR is greater than 1 and smaller than infinity, because ZRP would include both hellos cost for intra-zone and flooding cost for inter-zone. We also expect that ZRP on OSPF will do worse than ZRP on OLSR. For example, I would expect a plot like this one, which depends on traffic scenarios, mobility, etc... But I am not sure at 100 %, it needs more work and we prefer to skip this in our first version. total traffic ZRP on OLSR ^ | | | * * * * * | * * | * * | | * * | | | ---|------------------|-----> Zone Radius the optimal ZR Best regards, Philippe PS: Laurent will come back soon, I will not able to continue this interesting discussion because I leave for a one week travel. A 10:48 03/07/00 -0400, Zygmunt Haas a écrit : >Hi Philippe, > >Hmmm, this is not so. Hybrid protocols, through their ability to adjust to >the network operational conditions will *always* result in less control >traffic than pure proactive or pure reactive protocols. This statement is >nearly self-explanatory, as *hyrbrid protocols degrade to either pure >reactive or pure proactive behavior, based on their parameter settings.* > >Let me comment on the last statement: in the Zone Routing Protocol (ZRP), >for instance, there is a single parameter to set - the Zone Radius >(ZR). If ZR=1, then ZRP degrades to pure reactice protocol, while when >ZR=\infty, then ZRP degrades to pure proactive protocol. The >characteristic curves of ZRP look as follows: (see for instance the >paper: [M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration >of for the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc >Networks, vol. 17, no.8, August 1999]) > > >total traffic > ^ > |* > | * * > | * * > | * * > | * * > | * * > | * * > | * * > | *** > | > ---------|--------------> Zone Radius > the optimal ZR > >The protocol should dynamically adjust the ZR, so as to minimize the total >control traffic. Depending on the operational conditions of the network, >the reduction of the hybrid scheme can be "quite dramatic" - please see >the above paper for more quantitative results. > >Thus, repeating myself, the hybrid protocols yield *much* reduction in the >control traffic and are a natural choice in an environment with changing >operational conditions, as well as for a broad range of MANETs. > >Congratulations to Laurent on his new baby ! > >Zygmunt. >==--==-==== > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >Prof. Zygmunt J. Haas tel: +1-607-255-3454 >Wireless Networks Laboratory >School of Electrical Engineering fax: +1-607-255-9072 >Cornell University >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu >Ithaca, NY 14853 >U.S.A http://www.ee.cornell.edu/~haas/wnl.html >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >On Mon, 3 Jul 2000 jacquet@menetou.inria.fr wrote: > >> Hi, Zygmunt, >> >> It is not exactly the conclusion of our study. It looks like that hybrid >> protocol overheads are roughly the sum of flooding protocol overheads and >> hello protocol overheads. They would be very likely always above. This is >> the reason why we a priori prefered not to include it in the first version >> of our study. >> >> Philippe and Laurent >> >> PS: Laurent just got a baby yesterday, so I replace him on the spot. >> >> A 07:47 30/06/00 -0400, Zygmunt Haas a écrit : >> >Hi Laurent, >> > >> >There is another "class" of protocols, the hybrid class, which is a mix of >> >proactive-reactive behavior. Examples of such protocols include the Zone >> >Routing Protocol (ZRP) and the Fisheye protocol. >> > >> >As you have stated, pure proactive/reactive protocols may not present >> >"optimal" performance for a specific network operational conditions >> >(mobility and traffic). The bigest advantage of the hybrid class is that >> >it can adapt itself to the network operational conditions. More >> >specifically, by dynamically adjusting the ratio of the proactive >> >vs. reactive behavior, the amount of overhead control traffic can be >> >*drastically* reduced. In the Zone Routing Protocol, this is achieved >> >through the use of a single parameter - the Zone Radius, which is updated >> >based on continual measurement of the mobility (the rate of >> >creation/destruction of links with a node's neighbors) and the amout of >> >traffic a node sees. (More on updating of the zone radius could be found >> >in our paper in JSAC / August 1999.) >> > >> >I guess, what I am trying to say is that the hybrid class of protocols is >> >the answer to the conclusions of your study - that in order to "cover" a >> >broad range of MANET topologies (size of networks) and operational >> >conditions, a *hybrid* strategy should be used. >> > >> >Zygmunt. >> >==--==-=== >> >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >> >Prof. Zygmunt J. Haas tel: +1-607-255-3454 >> >Wireless Networks Laboratory >> >School of Electrical Engineering fax: +1-607-255-9072 >> >Cornell University >> >323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu >> >Ithaca, NY 14853 >> >U.S.A http://www.ee.cornell.edu/~haas/wnl.html >> >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- >> > >> >On Tue, 27 Jun 2000, Laurent Viennot wrote: >> > >> >> >> >> Dear MANet members, >> >> >> >> After the discussions on the mailing, we have been thinking quite a >> >> lot with Philippe on overhead. We have developed some analysis about >> >> the relation between routing performance (overhead) and networks >> >> parameters (size, mobility, traffic). Our aim is to identify the >> >> scenarios which favor such and such MANet protocols. We consider a >> >> mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). >> >> >> >> We have identified two classes of protocols which more or less fit >> >> the reactive and proactive boundary: >> >> >> >> 1. the flooding protocols (AODV/DSR, TORA) >> >> 2. the hello protocols (DSDV,OLSR) >> >> >> >> The performance are quantified by the quantity of overhead generated >> >> by each protocols. We have identified two source of overheads: >> >> >> >> A. the control overheads >> >> B. the route overheads >> >> >> >> Our main findings are the following: >> >> >> >> -Both classes have O(N^2) control overheads which is no surprising >> >> from graph theory point of view. Flooding algorithm and hello >> >> algorithm have different factors in front of N^2 which actually >> >> depends on traffic, geometry, mobility. One can find scenarios in >> >> favor of flooding and other scenarios in favor of hello. >> >> >> >> -Flooding protocols may not provide optimal routes (in term of hop >> >> number) the average deviation between optimal routes can be >> >> significant (a factor of 33% in dense 1D networks, more in 2D and >> >> 3D). The overhead generated by the extra transmission of data may be >> >> important since it is proportional to data traffic. >> >> >> >> >> >> A research report detailing these results is available: >> >> http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) >> >> >> >> >> >> Comments are welcome, >> >> >> >> >> >> Laurent >> >> >> > >> > From owner-manet@itd.nrl.navy.mil Thu Jul 6 13:51:33 2000 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 NAA22006 for ; Thu, 6 Jul 2000 13:51:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA20261 for manet-outgoing; Thu, 6 Jul 2000 11:50:06 -0400 (EDT) Received: from verinet.cis.upenn.edu (VERINET.CIS.UPENN.EDU [158.130.13.33]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA20256 for ; Thu, 6 Jul 2000 11:50:04 -0400 (EDT) Received: from verinet.cis.upenn.edu (IDENT:bkarthik@verinet.cis.upenn.edu [158.130.13.33]) by verinet.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id LAA16058; Thu, 6 Jul 2000 11:50:44 -0400 Date: Thu, 6 Jul 2000 11:50:44 -0400 (EDT) From: Karthik To: Salavat Magazov cc: MANET mailing list Subject: Re: AODV questions In-Reply-To: <003d01bfe725$32d52960$f314073e@salavat> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="----=_NextPart_000_0011_01BFE745.20EFA840" Content-ID: Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------=_NextPart_000_0011_01BFE745.20EFA840 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: The reason the same sequence number (n) cannot be used is to prevent loops. The basic reason is that AODV depends on the "persistence" of dest sequence numbers and each sequence number denotes a valid routing configuration to a destination. So when a sequence number goes "bad", i.e. one of the links fail, everyone who is aware of this must stop using this sequence number. To answer your particular question: Assume the current configuration is S-->1-->2-x-->3-->4-->D i.e. 2 is aware of the link break but 1 isnt Further assume that the RERR from 2 to 1 gets dropped. Now, suppose 2 needs a route to D and sends an RREQ with dest sequence number n, clearly, 1 (and maybe S) will respond to this RREQ. This will immediatedly cause a loop. On the other hand, if 2 sent the RREQ with n+1, 1 (and S) cannot respond (since they only have n) and so we are safe. This may be inefficient in re-using old "good" routes, but is necessary to avoid re-using old "bad" routes. -Karthik -------------------------------------- http://www.seas.upenn.edu/~bkarthik -------------------------------------- On Thu, 6 Jul 2000, Salavat Magazov wrote: > Hello > > I have some questions regarding AODV. Sequence numbers in particular. > > Let's imagine the situation where node S (source) tries to find a route to > node D (destination) using destination sequence number n. Say there are four > other participating nodes 1, 2, 3 and 4 through which route lies. > S-->1-->2-->3-->4-->D > After the route is found the source starts transmitting, etc. Suddenly the > connection, say, between 2 and 3 breaks for whatever reason, then RERR > message is sent upstream to notify nodes of broken link. Let's also assume > that route entry for D in nodes from 3 through D did not expire yet. > S-x->1-x->2-x->3-->4-->D > After S gets RERR message it will try to find another route to D, and as > specification says uses n+1 as a dest. seq. number to be sure that new route > is established. This is the point I do not understand. Why not to use n and > thus use the part of the route from 3 to D which is still available? The > nodes could save time and bandwidth. Due to the movement of nodes there may > emerge another shorter route which will be used as soon as S is notified > about its existence by receiving RREP with smaller hop count. > > Disclaimer: > I am not saying that what you offer is bad, I rather say I do not understand > the reason. > > Regards > Salavat > ------=_NextPart_000_0011_01BFE745.20EFA840 Content-Type: TEXT/X-VCARD; NAME="Salavat R. Magazov.vcf" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="Salavat R. Magazov.vcf" BEGIN:VCARD VERSION:2.1 N:Magazov;Salavat;R. FN:Salavat R. Magazov NICKNAME:Sal ORG:University of Kent at Canterbury TEL;HOME;VOICE:+44-1227-472835 X-WAB-GENDER:2 BDAY:20000517 EMAIL;PREF;INTERNET:srm4@ukc.ac.uk EMAIL;INTERNET:salavat@ukonline.co.uk REV:20000706T082428Z END:VCARD ------=_NextPart_000_0011_01BFE745.20EFA840-- From owner-manet@itd.nrl.navy.mil Thu Jul 6 17:19:19 2000 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 RAA25791 for ; Thu, 6 Jul 2000 17:19:18 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA25398 for manet-outgoing; Thu, 6 Jul 2000 15:23:07 -0400 (EDT) Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA25393 for ; Thu, 6 Jul 2000 15:23:05 -0400 (EDT) Received: from [62.7.45.58] (helo=salavat) by tantalum with esmtp (Exim 3.03 #82) id 13AHEm-0000cs-00 for manet@itd.nrl.navy.mil; Thu, 06 Jul 2000 20:23:04 +0100 Message-ID: <000401bfe766$9801d2c0$3a2d073e@salavat> From: "Salavat R. Magazov \(BT\)" To: "MANET mailing list" Subject: AODV questions Date: Thu, 6 Jul 2000 12:54:27 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F2_01BFE749.5191C600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00F2_01BFE749.5191C600 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello I have some questions regarding AODV. Sequence numbers in particular. Let's imagine the situation where node S (source) tries to find a route to node D (destination) using destination sequence number n. Say there are four other participating nodes 1, 2, 3 and 4 through which route lies. S-->1-->2-->3-->4-->D After the route is found the source starts transmitting, etc. Suddenly the connection, say, between 2 and 3 breaks for whatever reason, then RERR message is sent upstream to notify nodes of broken link. Let's also assume that route entry for D in nodes from 3 through D did not expire yet. S-x->1-x->2-x->3-->4-->D After S gets RERR message it will try to find another route to D, and as specification says uses n+1 as a dest. seq. number to be sure that new route is established. This is the point I do not understand. Why not to use n and thus use the part of the route from 3 to D which is still available? The nodes could save time and bandwidth. Due to the movement of nodes there may emerge another shorter route which will be used as soon as S is notified about its existence by receiving RREP with smaller hop count. Disclaimer: I am not saying that what you offer is bad, I rather say I do not understand the reason. Regards Salavat ------=_NextPart_000_00F2_01BFE749.5191C600 Content-Type: text/x-vcard; name="Salavat R. Magazov.vcf" Content-Disposition: attachment; filename="Salavat R. Magazov.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Magazov;Salavat;R. FN:Salavat R. Magazov NICKNAME:Sal ORG:University of Kent at Canterbury TEL;HOME;VOICE:+44-1227-472835 X-WAB-GENDER:2 BDAY:20000517 EMAIL;PREF;INTERNET:srm4@ukc.ac.uk EMAIL;INTERNET:salavat@ukonline.co.uk REV:20000706T082428Z END:VCARD ------=_NextPart_000_00F2_01BFE749.5191C600-- From owner-manet@itd.nrl.navy.mil Thu Jul 6 20:12:07 2000 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 UAA27793 for ; Thu, 6 Jul 2000 20:12:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA00118 for manet-outgoing; Thu, 6 Jul 2000 18:34:06 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA00113 for ; Thu, 6 Jul 2000 18:34:04 -0400 (EDT) Received: from localhost (sjlee@localhost) by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id PAA26629; Thu, 6 Jul 2000 15:33:54 -0700 (PDT) Date: Thu, 6 Jul 2000 15:33:54 -0700 (PDT) From: SJ Lee To: "S.J. (Sung-Ju) Lee" Subject: MobiHOC 2000: Call for Participation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk [Please accept our apologies if you receive duplicate messages] ================================================================== Announcement & Call for Participation THE FIRST ANNUAL WORKSHOP ON MOBILE AD HOC NETWORKING & COMPUTING (MobiHOC 2000) in conjunction with Mobicom 2000 August 11, 2000 Boston, Massachusetts, USA Advance program, registration information, and hotel information for the MobiHOC workshop are now available at http://www.cs.tamu.edu/faculty/vaidya/mobihoc/ If you are unable to access the above web page, please send an e-mail to vaidya@cs.tamu.edu -------------------------------------------------------------------------- MobiHOC 2000 Advance Program -------------------------------------------------------------------------- MobiHoc received 82 submissions, of which 13 were accepted as regular papers, and 12 as posters. The accepted papers/posters came from 13 countries. -------------------------------------------------------------------------- Keynote Leonard Kleinrock will present a keynote address on Beyond the Netherworld of Cyberspace. -------------------------------------------------------------------------- Introductions and Welcome 8:00 - 8:30 a.m. -------------------------------------------------------------------------- Session A: Routing 8:30 - 10:15 a.m. Session Chair: David B. Johnson, CMU and Rice University * On the Impact of Alternate Path Routing for Load Balancing in Mobile Ad-Hoc Networks Marc Pearlman, Zygmunt Haas (Cornell University), Peter Sholander (Scientific Research Corporation), and Siamak S. Tabrizi (Air Force Rome Laboratories) * LANMAR: Landmark Routing for Large Scale Wireless Ad Hoc Networks with Group Mobility Guangyu Pei, Mario Gerla, and Xiaoyan Hong (University of California, Los Angeles) * DDR-Distributed Dynamic Routing Algorithm for Mobile Ad Hoc Networks Navid Nikaein, Houda Labiod, and Christian Bonnet (Eurecom Institute) * Predicting Node Proximity in Ad-Hoc Networks: A Least Overhead Adaptive Model for Selecting Stable Routes A. Bruce McDonald and Taieb Znati (University of Pittsburgh) -------------------------------------------------------------------------- Session B: Multicasting 10:45 - 12:00 a.m. Session Chair: Joseph Macker, Naval Research Laboratory * Neighbor Supporting Ad Hoc Multicast Routing Protocol Seungjoon Lee and Chongkwon Kim (Seoul National University) * Role-Based Multicast in Highly Mobile but Sparsely Connected Ad Hoc Networks Linda Briesemeister (DaimlerChrysler Research and Technology) and Gunter Hommel (Technical University of Berlin) * Content Based Multicast (CBM) in Ad Hoc Networks Hu Zhou and Suresh Singh (Oregon State University) -------------------------------------------------------------------------- Keynote Address and Lunch 12:00 - 1:30 p.m. Keynote Speaker: Leonard Kleinrock Topic: Beyond the Netherworld of Cyberspace -------------------------------------------------------------------------- Session C: Novel Issues 1:30 - 2:45 p.m. Session Chair: Andrew Campbell, Columbia University * An Architecture for Building Self-Configurable Systems Lakshminarayanan Subramanian and Randy H. Katz (University of California, Berkeley) * MIPMANET - Mobile IP for Mobile Ad Hoc Networks Ulf Jonsson, Fredrik Alriksson, Tony Larsson, Per Johansson (Ericsson Radio Systems), and Gerald Q. Maguire Jr. (Royal Institute of Technology) * Enforcing Service Availability in Mobile Ad-Hoc WANs Levente Buttyan and Jean-Pierre Hubaux (Swiss Federal Institute of Technology, Lausanne) -------------------------------------------------------------------------- Session D: Link Layer 3:15 - 4:30 p.m. Session Chair: Fred L. Templin, SRI International * Fair Medium Access in 802.11 based Wireless Ad-Hoc Networks Brahim Bensaou, Yu Wang, and Chi Chung Ko (National University of Singapore) * Low Power Rendezvous in Embedded Wireless Networks Terry Todd (McMaster University), Frazer Bennett (PA Consulting Group), and Alan Jones (AT&T Laboratories Cambridge) * Assignment Methods for Spatial Reuse TDMA Jimmi Gronkvist (Swedish Defence Research Establishment) -------------------------------------------------------------------------- Poster Session 4:30 - 6:00 p.m. Session Chair: TBA * A Speech-Optimised Multiple Access Scheme for a Mobile Ad Hoc Network V. N. Muthiah and W. C. Wong (National University of Singapore) * On the Reduction of Broadcast Redundancy in Mobile Ad Hoc Networks Wei Peng and Xi-Cheng Lu (Changsha Institute of Technology) * Central Controller Handover Procedure for ETSI-BRAN HiperLAN/2 Ad Hoc Networks and Clustering with Quality of Service Guarantees Jorg Habetha, Andreas Hettich, Jorg Peetz (Aachen Institute of Technology), and Yonggang Du (Philips Research Laboratories) * DEAPspace -- Transient Ad-hoc Networking of Pervasive Devices Reto Hermann, Dirk Husemann, Michael Moser, Michael Nidd, Christian Rohner, and Andreas Schade (IBM Zurich Research Lab) * Securing Ad Hoc Services, a Jini View Christian Gehrmann (Ericsson Research), and Pekka Nikander (Helsinki Institute of Technology) * Dynamic Quality-of-Service for Mobile Ad Hoc Networks M. Mirhakkak, N. Schult, and D. Thomson (MITRE Corporation) * A Simulation Analysis on Reactive Route Repair Techniques for QoS Sensitive Applications in Mobile Ad Hoc Networks George Aggelou and Rahim Tafazolli (University of Surrey) * Proximity Awareness and Fast Connection Establishment in Bluetooth Theodoros Salonidis (University of Maryland), Pravin Bhagwat (IBM T. J. Watson Research Center), and Leandros Tassiulas (University of Maryland) * Utility-Based Decision-Making in Wireless Sensor Networks John Byers and Gabriel Nasser (Boston University) * A Distributed Mechanism for Topology Discovery in Ad hoc Wireless Networks using Mobile Agents Romit RoyChoudhury (Haldia Institute of Technology), Somprakash Bandyopadhyay (PricewaterhouseCoopers Ltd.), and Krishna Paul (CTS-Calcutta) * Performance Aspects of Bluetooth Scatternet Formation G. Miklos, A. Racz, Z. Turanyi, A. Valko (Ericsson Research), and P. Johansson (Ericsson Radio Systems) * Load Balancing via Relay in Next Generation Wireless Systems Chunming Qiao, Hongyi Wu, and Ozan Tonguz (University at Buffalo) -------------------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Jul 6 20:29:18 2000 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 UAA27944 for ; Thu, 6 Jul 2000 20:29:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA00479 for manet-outgoing; Thu, 6 Jul 2000 19:04:58 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA00474 for ; Thu, 6 Jul 2000 19:04:56 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id TAA29380 for ; Thu, 6 Jul 2000 19:04:56 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id TAA19098 for ; Thu, 6 Jul 2000 19:03:16 -0400 (EDT) Received: from mbppp167.mitre.org (129.83.69.167) by mailhub2.mitre.org with SMTP id 3870007; Thu, 06 Jul 2000 19:04:51 EST Message-ID: <39650256.19CA5C92@mitre.org> Date: Thu, 06 Jul 2000 18:04:06 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: MANET mailing list Subject: On Demand Flaw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit In reflecting upon the behavior of the on demand routing protocols, I made a very disturbing observation. I don't believe that I have seen anyone discuss this issue before, so I submit it now to alert others. The motivation behind the on demand routing protocols was to increase scalability by not having to distribute topology information like traditional routing protocols. In the on demand approach, when a source has a packet to send to a destination for which it does not have a route, the source initiates a flooded route request. Unfortunately, if the intended destination is disconnected from the network, the flooded route request propagates across the entire network but produces no useful result. Even worse, since the source never discovers a route, it is forced to try flooding another route request again later which will continue to waste resources as long as the destination is disconnected. The problem here is that the source has no way of determining what nodes are disconnected from the network. This is exactly why topology information is useful! A link state protocol would consume no additional resources for a disconnected destination since the source would know that there was no route. Consider now that the network has one well known server that all the other nodes try to connect to, and the server happens to be disconnected. The number of messages sent as part of the unsuccessful flooded route requests are enough to distribute the entire network topology to every node! At this point a link state algorithm would be superior to the on demand protocol. In fact, the resources consumed and wasted by the on demand routing protocol grows linearly with the number of disconnected well known servers. Eg. a network with 3 disconnected well known servers would cause an on demand protocol to consume and waste 3 times the resources of a link state protocol. It appears to me that the on demand routing protocols have a fatal flaw which preclude them from scaling well and that the link state approach is superior. ********************************************************* Kevin H. Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (781) 271-8388 kgrace@mitre.org From owner-manet@itd.nrl.navy.mil Thu Jul 6 21:39:07 2000 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 VAA29752 for ; Thu, 6 Jul 2000 21:39:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA01400 for manet-outgoing; Thu, 6 Jul 2000 20:08:57 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA01395 for ; Thu, 6 Jul 2000 20:08:55 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id UAA14989; Thu, 6 Jul 2000 20:08:54 -0400 (EDT) Date: Thu, 6 Jul 2000 20:08:58 -0400 (EDT) From: Zygmunt Haas To: Kevin Grace cc: MANET mailing list Subject: Re: On Demand Flaw In-Reply-To: <39650256.19CA5C92@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Kevin, > It appears to me that the on demand routing protocols have a fatal flaw > which preclude them from scaling well and that the link state approach > is superior. I am not for on-demand protocols, you know, just hybrid protocols (:-) ... However, I would like to comment on your observation. You are right in saying that on-demand may be costly, but everything is relative and depends on the two parameters that I have mentioned in my previous e-mail. Say, you have a network with very little activity, say, one message per day. But the network reconfigures very often, say a link lifetime is on the order of 100 [msec]. Would you still prefer the "link state" approach - obviously not, since even if you need to flood the network hundred of times to discover the one-per-day route request in the reactive (on demand) approach, you still will be much better off then the very frequent link (on the order of 10 [updates/sec]) exchanges in the proactive state. So, again, the ratio of how much proactive/reactive a protocol should be depends on the two parameters: 1. mobility, and 2. activity s per my prsvious e-mail. Best, Zygmunt. ==--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Fri Jul 7 00:17:01 2000 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 AAA02825 for ; Fri, 7 Jul 2000 00:17:01 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA03076 for manet-outgoing; Thu, 6 Jul 2000 22:29:14 -0400 (EDT) Received: from horton.cse.ucsc.edu (horton.cse.ucsc.edu [128.114.49.15]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id WAA03071 for ; Thu, 6 Jul 2000 22:29:12 -0400 (EDT) Received: from localhost (jyoti@localhost) by horton.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id TAA18192; Thu, 6 Jul 2000 19:29:07 -0700 X-Authentication-Warning: horton.cse.ucsc.edu: jyoti owned process doing -bs Date: Thu, 6 Jul 2000 19:29:07 -0700 (PDT) From: Jyoti Raju To: Kevin Grace cc: MANET mailing list Subject: Re: On Demand Flaw In-Reply-To: <39650256.19CA5C92@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We presented a discussion of this problem, which we called "searching to infinity" in our paper "A New Approach to On-demand Loop-Free Multipath Routing" presented at IEEE IC3N 99. We also presented an on-demand protocol (ROAM) based on diffusing computations that would not suffer from the problem. ROAM requires reliable updates. It can be efficiently implemented if the MAC protocol allows reliable updates. Adding reliability at the network layer will result in increased control overhead. Your observation is right; table-driven routing protocols (distance vector or link state) will not suffer from this problem. Jyoti Raju Graduate Student Researcher Computer Communications Research Group UC-Santa Cruz On Thu, 6 Jul 2000, Kevin Grace wrote: > In reflecting upon the behavior of the on demand routing protocols, I > made a very disturbing observation. I don't believe that I have seen > anyone discuss this issue before, so I submit it now to alert > others. > > The motivation behind the on demand routing protocols was to increase > scalability by not having to distribute topology information like > traditional routing protocols. In the on demand approach, when a > source has a packet to send to a destination for which it does not > have a route, the source initiates a flooded route > request. Unfortunately, if the intended destination is disconnected > from the network, the flooded route request propagates across the > entire network but produces no useful result. Even worse, since the > source never discovers a route, it is forced to try flooding another > route request again later which will continue to waste resources as > long as the destination is disconnected. > > The problem here is that the source has no way of determining what > nodes are disconnected from the network. This is exactly why topology > information is useful! A link state protocol would consume no > additional resources for a disconnected destination since the source > would know that there was no route. > > Consider now that the network has one well known server that all the > other nodes try to connect to, and the server happens to be > disconnected. The number of messages sent as part of the unsuccessful > flooded route requests are enough to distribute the entire network > topology to every node! At this point a link state algorithm would be > superior to the on demand protocol. In fact, the resources consumed > and wasted by the on demand routing protocol grows linearly with the > number of disconnected well known servers. Eg. a network with 3 > disconnected well known servers would cause an on demand protocol to > consume and waste 3 times the resources of a link state protocol. > > It appears to me that the on demand routing protocols have a fatal flaw > which preclude them from scaling well and that the link state approach > is superior. > > ********************************************************* > Kevin H. Grace > The MITRE Corporation > 202 Burlington Rd > Bedford, MA 01730 > (781) 271-8388 > kgrace@mitre.org > From owner-mmnet@itd.nrl.navy.mil Fri Jul 7 05:40:22 2000 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 FAA19243 for ; Fri, 7 Jul 2000 05:40:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA06352 for mmnet-outgoing; Fri, 7 Jul 2000 02:46:02 -0400 (EDT) Received: from pluto.psn.net (pluto.psn.net [207.211.58.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA06347 for ; Fri, 7 Jul 2000 02:46:00 -0400 (EDT) Received: from [209.140.8.231] (helo=shally) by pluto.psn.net with smtp (PSN Internet Service 3.14 #1) for mmnet@itd.nrl.navy.mil id 13ARtf-00078u-00; Thu, 06 Jul 2000 23:45:59 -0700 From: "Shally Steckerl" To: Subject: Need your help with Optical Netwoking project Date: Thu, 6 Jul 2000 23:46:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm Shally Steckerl and I work for Cisco System's Service Provider Line of Business. I got your address from a web page on the internet. I've been tasked with helping a very important project within our Optical Networking Group, and was wondering if you could help me. I'm new to this sector of the industry and need to network with good folks who may know someone interested in joining our rapidly growing team. We are undertaking many important projects with big customers in the Rocky Mountain region (Montana, Kansas, Colorado, Utah, Idaho or Wyoming) and need to grow our staff. I thought that since you are in this business you may be able to help me network. I'm looking for people with engineering or sales experience who are familiar with the Optical sector, even if they are not in that geographic area. Please let me know if any of your friends, peers or contacts would be interested in talking with me about this opportunity or know someone in the optical networking business. Also any suggestions on where else to network would be eternally appreciated! At the end of this message is a detailed description of the technical environment. If I should contact you by other means, or at another address, please reply or call. Or, if you know someone who is interested, feel free to simply forward this message. ADVthanksANCE! Shally Steckerl Cisco Systems 480-922-9287 p.s. this is sent from my home address, if you prefer you could reply to sstecker@cisco.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * Optical Transport and Optical Networking Buzz: http://www.cisco.com/jobs/us/culture.shtml http://www.cisco.com/warp/public/779/servpro/solutions/optical/ About Cisco: http://www.fortune.com/fortune/2000/05/29/ten10.html Best Companies: http://www.pathfinder.com/fortune/bestcompanies/ Responsibilities: - Perform technical presentations to customers and prospects as well as assist in the development and generation of formal sales proposals to ensure technical accuracy - Determine network requirements and design efficient, cost-effective solutions based on transmission product specifications and customer requirements - Perform equipment demonstrations for existing and prospective customers and sales force - Perform technical marketing functions to designated regions in support of strategic sales efforts Requirements: - BS/BA, EE/CS or equivalent, with a minimum of 3 years related industry experience designing and implementing networks - Specific experience with SONET/SDH transport/access equipment - Understanding of traditional TDM and WDM From owner-mmnet@itd.nrl.navy.mil Fri Jul 7 09:52:40 2000 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 JAA26204 for ; Fri, 7 Jul 2000 09:52:39 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA08913 for mmnet-outgoing; Fri, 7 Jul 2000 07:14:35 -0400 (EDT) Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA08908 for ; Fri, 7 Jul 2000 07:14:33 -0400 (EDT) Received: from orannt ([171.69.210.7]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA3574; Fri, 7 Jul 2000 07:14:55 -0400 From: "Dave Oran" To: "Shally Steckerl" Cc: Subject: RE: Need your help with Optical Netwoking project Date: Fri, 7 Jul 2000 07:17:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Shally, You may not have known this, but you sent this message not to an individual, but to an IETF mailing list. Doing so is in fact a fairly serious breach of nettiquette, and a retraction and apology are in order. Recruiting via IETF mailing lists is considered well outside the bounds of acceptable postings to mailing lists whose purpose is furthering standards development in the IETF. Thanks for dealing with this quickly, Dave Oran, Area Director, Routing Area, IETF. -----Original Message----- From: owner-mmnet@itd.nrl.navy.mil [mailto:owner-mmnet@itd.nrl.navy.mil]On Behalf Of Shally Steckerl Sent: Friday, July 07, 2000 2:47 AM To: mmnet@itd.nrl.navy.mil Subject: Need your help with Optical Netwoking project Hi, I'm Shally Steckerl and I work for Cisco System's Service Provider Line of Business. I got your address from a web page on the internet. I've been tasked with helping a very important project within our Optical Networking Group, and was wondering if you could help me. I'm new to this sector of the industry and need to network with good folks who may know someone interested in joining our rapidly growing team. We are undertaking many important projects with big customers in the Rocky Mountain region (Montana, Kansas, Colorado, Utah, Idaho or Wyoming) and need to grow our staff. I thought that since you are in this business you may be able to help me network. I'm looking for people with engineering or sales experience who are familiar with the Optical sector, even if they are not in that geographic area. Please let me know if any of your friends, peers or contacts would be interested in talking with me about this opportunity or know someone in the optical networking business. Also any suggestions on where else to network would be eternally appreciated! At the end of this message is a detailed description of the technical environment. If I should contact you by other means, or at another address, please reply or call. Or, if you know someone who is interested, feel free to simply forward this message. ADVthanksANCE! Shally Steckerl Cisco Systems 480-922-9287 p.s. this is sent from my home address, if you prefer you could reply to sstecker@cisco.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * Optical Transport and Optical Networking Buzz: http://www.cisco.com/jobs/us/culture.shtml http://www.cisco.com/warp/public/779/servpro/solutions/optical/ About Cisco: http://www.fortune.com/fortune/2000/05/29/ten10.html Best Companies: http://www.pathfinder.com/fortune/bestcompanies/ Responsibilities: - Perform technical presentations to customers and prospects as well as assist in the development and generation of formal sales proposals to ensure technical accuracy - Determine network requirements and design efficient, cost-effective solutions based on transmission product specifications and customer requirements - Perform equipment demonstrations for existing and prospective customers and sales force - Perform technical marketing functions to designated regions in support of strategic sales efforts Requirements: - BS/BA, EE/CS or equivalent, with a minimum of 3 years related industry experience designing and implementing networks - Specific experience with SONET/SDH transport/access equipment - Understanding of traditional TDM and WDM From owner-manet@itd.nrl.navy.mil Fri Jul 7 14:01:09 2000 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 OAA07772 for ; Fri, 7 Jul 2000 14:01:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA16117 for manet-outgoing; Fri, 7 Jul 2000 12:08:02 -0400 (EDT) Received: from icarus.lis.pitt.edu (icarus.lis.pitt.edu [136.142.116.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id MAA16112 for ; Fri, 7 Jul 2000 12:08:01 -0400 (EDT) Received: by icarus.lis.pitt.edu (SMI-8.6/1.34) id MAA14952; Fri, 7 Jul 2000 12:08:29 -0400 Date: Fri, 7 Jul 2000 12:08:29 -0400 (EDT) From: "A. Bruce McDonald" Subject: Proactive vs Reactive vs Hybrid To: MANET mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, I have been following the recent discussion and have a few observations. It seems clear that the tradeoffs between proactive and reactive routing strategies are quite complex---which approach is best depends on many interacting factors. Perhaps more importantly, these factors themselves can be expected to be dynamic. Hence, to develop a technology that has any hope of long term commercial viability---or practical application, ad-hoc networks MUST be capable of adapting to work under a wide range of circumstances/scenarios. The must be work under a wide range of mobility conditions, they must be scalable and they must support many diverse applications. Hence, I strongly agree with Dr. Haas that the answer to the concerns lies in the study and development of hybrid routing strategies. The most viable solution to the problem is to build hybrid systems that can adapt in a way that dynamically manages the tradeoffs between proactive and reactive routing to meet 'local' conditions. That is, the appropriate routing strategy will depend on factors that are both temporally and spatially determined. These include the mobility patterns of the nodes, the number and distribution of nodes throughout a network, and the traffic patterns between the nodes. Other factors include the capabilities---processing, power etc.., of the nodes, and the environment---how does it affect the reliability of links. As I see it we can do one of two things: (1) Build ad-hoc systems that use a fixed approach and are only viable under a well-defined range of circumstances---very niche oriented. To do this we tune the networks to a particular scenario. Perhaps such systems can be tunable to work under different circumstances by changing system parameters; however, this destroys the spirit of ad-hoc networking, and is not likely to be a scalable alternative. (2) Build ad-hoc systems that dynamically adjust their routing strategy according to conditions that change in time and space. I believe as a community we should concentrate on the later approach. A. Bruce McDonald University of Pittsburgh and Northeastern University From owner-mmnet@itd.nrl.navy.mil Fri Jul 7 14:15:43 2000 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 OAA08332 for ; Fri, 7 Jul 2000 14:15:42 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA17447 for mmnet-outgoing; Fri, 7 Jul 2000 12:51:07 -0400 (EDT) Received: from pluto.psn.net (pluto.psn.net [207.211.58.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA17442 for ; Fri, 7 Jul 2000 12:51:05 -0400 (EDT) Received: from [209.140.8.231] (helo=shally) by pluto.psn.net with smtp (PSN Internet Service 3.14 #1) id 13AbLB-0006W3-00; Fri, 07 Jul 2000 09:51:01 -0700 From: "Shally Steckerl" To: "Dave Oran" Cc: Subject: RE: Need your help with Optical Networking project Date: Fri, 7 Jul 2000 09:50:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Thank you for notifying me! I am indeed aware that sending such a message to a list is an inexcusable breach of etiquette. As a list admin myself, and subscriber to many, I am embarrassed. I beg readers accept my apology. My intention was to reach an individual not a list, and I did not recognize mmnet@itd.nrl.navy.mil as a list address. It was given to me by a good person, as a professional referral, with the best of intentions. I assumed it was an individual's address and thought I would be able to network further. Once again, my sincerest apologies for the mistake. -Shally "The man who makes no mistakes does not usually make anything." --Bishop W. C. Magee From owner-manet@itd.nrl.navy.mil Fri Jul 7 14:33:03 2000 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 OAA09161 for ; Fri, 7 Jul 2000 14:33:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA17789 for manet-outgoing; Fri, 7 Jul 2000 13:03:24 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA17784 for ; Fri, 7 Jul 2000 13:03:21 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA02597; Fri, 7 Jul 2000 13:03:14 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA26188; Fri, 7 Jul 2000 13:01:33 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub2.mitre.org with SMTP id 3876475; Fri, 07 Jul 2000 13:02:39 EST Message-ID: <39660D03.5F39820F@mitre.org> Date: Fri, 07 Jul 2000 13:01:55 -0400 From: "Kevin H. Grace" Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Laura Feeney CC: manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw References: <39650256.19CA5C92@mitre.org> <200007071630.SAA20621@kanin.sics.se> 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 Laura, I hope the example has not obfuscated my observation. My hope was to simply illustrate that the resources wasted by flooded route requests to disconnected destination can quickly grow to a level where a link state approach would have been more efficient. ********************************************************* Kevin H. Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (781) 271-8388 kgrace@mitre.org > You raise interesting questions, but I'm not sure I accept your > example. > > Why would you choose to have a well-known server, rather than a > replicated service, in a wireless network that is subject to frequent > partitions? > > Even if your application is built around connectivity to a particular > host (e.g. physical apparatus), you might still be better off with an > higher-level protocol that provides notification of an essential > host's status. > > Regards, > Laura From owner-manet@itd.nrl.navy.mil Fri Jul 7 14:57:25 2000 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 OAA09877 for ; Fri, 7 Jul 2000 14:57:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA16913 for manet-outgoing; Fri, 7 Jul 2000 12:30:19 -0400 (EDT) Received: from color.sics.se (color.sics.se [193.10.66.199]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA16908 for ; Fri, 7 Jul 2000 12:30:17 -0400 (EDT) Received: from kanin.sics.se (kanin.sics.se [193.10.65.146]) by color.sics.se (8.9.3/8.9.3) with ESMTP id SAA18007; Fri, 7 Jul 2000 18:30:16 +0200 (MET DST) env-from (lmfeeney@color.sics.se) Received: (from lmfeeney@localhost) by kanin.sics.se (8.8.7/8.8.7) id SAA20621; Fri, 7 Jul 2000 18:30:16 +0200 Date: Fri, 7 Jul 2000 18:30:16 +0200 Message-Id: <200007071630.SAA20621@kanin.sics.se> X-Authentication-Warning: kanin.sics.se: lmfeeney set sender to lmfeeney@kanin.sics.se using -f From: Laura Feeney To: kgrace@mitre.org CC: manet@itd.nrl.navy.mil In-reply-to: <39650256.19CA5C92@mitre.org> (message from Kevin Grace on Thu, 06 Jul 2000 18:04:06 -0400) Subject: Re: On Demand Flaw References: <39650256.19CA5C92@mitre.org> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >>>>> Kevin Grace writes: Kevin> Consider now that the network has one well known server that Kevin> all the other nodes try to connect to, and the server happens Kevin> to be disconnected. The number of messages sent as part of the [...] Kevin> fact, the resources consumed and wasted by the on demand Kevin> routing protocol grows linearly with the number of disconnected Kevin> well known servers. Eg. a network with 3 disconnected well [...] Hi Kevin, You raise interesting questions, but I'm not sure I accept your example. Why would you choose to have a well-known server, rather than a replicated service, in a wireless network that is subject to frequent partitions? Even if your application is built around connectivity to a particular host (e.g. physical apparatus), you might still be better off with an higher-level protocol that provides notification of an essential host's status. Regards, Laura -- Laura Marie Feeney lmfeeney@sics.se Visiting Researcher http://www.sics.se/ Computer and Network Architectures Lab Tel: +46 8 633 15 09 Swedish Institute of Computer Science Mobile: +46 70 246 56 63 Box 1263, SE-164 29 KISTA, SWEDEN Fax: +46 8 751 72 30 From owner-manet@itd.nrl.navy.mil Fri Jul 7 17:47:35 2000 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 RAA13940 for ; Fri, 7 Jul 2000 17:47:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA23000 for manet-outgoing; Fri, 7 Jul 2000 16:02:45 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA22994 for ; Fri, 7 Jul 2000 16:02:43 -0400 (EDT) Received: from pearlman (pearlman.ee.cornell.edu [128.84.224.56]) by ee.cornell.edu (8.9.3/8.9.1) with SMTP id QAA16043; Fri, 7 Jul 2000 16:02:40 -0400 (EDT) Received: by localhost with Microsoft MAPI; Fri, 7 Jul 2000 16:02:41 -0400 Message-ID: <01BFE82C.C7E45BE0.pearlman@ee.cornell.edu> From: Marc Pearlman Reply-To: "pearlman@ee.cornell.edu" To: "'Groten, D.'" Cc: "manet@itd.nrl.navy.mil" Subject: RE: Overhead analysis Date: Fri, 7 Jul 2000 16:02:35 -0400 Organization: Cornell University EE X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 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 Dirk, > 2. Is the combination of a simple neighbour discovery (via pro-active > hellos) and on-demand route discovery equivalent to ZRP with zone radius 1? Yes. Technically speaking, a purely reactive ZRP configuration would correspond to a zone radius == 0 hops. In such a case, there is no neighbor discovery and route requests (RREQs) are distributed via unreliable shared-channel neighbor broadcast. Sometimes, unreliable shared channel neighbor broadcast is not advisable (due to low success rate) or even available (in a multiple channel system). In these situations, neighbor discovery is needed, either to track neighbor ACKs from a *reliable* neighbor broadcast or to resolve the neighbor broadcast into individual unicasts to each neighbor. If this neighbor information is provided to the ZRP, then the zone radius will be == 1 hop Within this context, we sometimes refer to a zone radius == 1 as being purely reactive. What we really mean is that this is the *most reactive* configuration possible, given that neighbor discovery is already present to support other networking services. regards, Marc ============================================================ Marc R. Pearlman tel: (607) 255-0236 Wireless Networks Laboratory fax: (607) 255-9072 School of Electrical Engineering Cornell University pearlman@ee.cornell.edu 389 Frank Rhodes Hall www.ee.cornell.edu/~pearlman Ithaca, NY 14853 From owner-manet@itd.nrl.navy.mil Fri Jul 7 17:47:35 2000 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 RAA13941 for ; Fri, 7 Jul 2000 17:47:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA23218 for manet-outgoing; Fri, 7 Jul 2000 16:17:31 -0400 (EDT) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA23213 for ; Fri, 7 Jul 2000 16:17:29 -0400 (EDT) Received: from [62.7.18.170] (helo=salavat) by tungsten with esmtp (Exim 3.03 #83) id 13AeYx-0001N8-00 for manet@itd.nrl.navy.mil; Fri, 07 Jul 2000 21:17:27 +0100 Message-ID: <009601bfe837$5bfb3ba0$7b4501d5@salavat> Reply-To: "Salavat R. Magazov \(BT\)" From: "Salavat R. Magazov \(BT\)" To: "MANET mailing list" Subject: Critical combination Date: Fri, 7 Jul 2000 21:17:32 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0088_01BFE858.C3867C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0088_01BFE858.C3867C00 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hello Did anybody consider the critical combination of parameters like mobility, activity and number of nodes at which the set of nodes can no longer be treated as a network. I mean there may happen that nodes move so fast and have to transmit so much information that it is simply impossible to find the route and transmit information while this route is still available. The question is how fast is too fast and how mush is too much. Is flooding a solution for this situation? Regards Salavat ------=_NextPart_000_0088_01BFE858.C3867C00 Content-Type: text/x-vcard; name="Salavat R. Magazov.vcf" Content-Disposition: attachment; filename="Salavat R. Magazov.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Magazov;Salavat;R. FN:Salavat R. Magazov NICKNAME:Sal ORG:University of Kent at Canterbury TEL;HOME;VOICE:+44-1227-472835 X-WAB-GENDER:2 BDAY:20000517 EMAIL;PREF;INTERNET:srm4@ukc.ac.uk EMAIL;INTERNET:salavat@ukonline.co.uk REV:20000707T171732Z END:VCARD ------=_NextPart_000_0088_01BFE858.C3867C00-- From owner-manet@itd.nrl.navy.mil Fri Jul 7 18:43:50 2000 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 SAA14931 for ; Fri, 7 Jul 2000 18:43:49 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA24463 for manet-outgoing; Fri, 7 Jul 2000 17:12:21 -0400 (EDT) Received: from scires.com (mail.scires.com [12.36.154.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id RAA24458 for ; Fri, 7 Jul 2000 17:12:20 -0400 (EDT) Received: from SRCATL-Message_Server by scires.com with Novell_GroupWise; Fri, 07 Jul 2000 17:13:29 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 07 Jul 2000 17:13:05 -0400 From: "Pete Sholander" To: , Subject: Re: On Demand Flaw 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 itd.nrl.navy.mil id RAA24459 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Greetings! It's been well known (since the mid-90's) that OSPF simply fails in MANETs, while my U.S. DoD contacts claim that NTDR's improvements on OSPF start to perform poorly at about 50 nodes in their testbed networks. Anyone else have any recent data-points from real, deployed networks ... as opposed to theoretical results or simulation studies? It seems like TORA (or maybe OLSR) should have some real-life numbers by now ... although maybe not over the "realistic terrain" (hills, foliage, jarheads in foxholes, ...) found in DoD exercises. Regards, Pete Sholander Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400S Atlanta, GA 30339 E: psholander@scires.com V: 770-859-9161, x551 F: 770-859-9315 >>> "Kevin H. Grace" 07/07/00 01:01PM >>> Hi Laura, I hope the example has not obfuscated my observation. My hope was to simply illustrate that the resources wasted by flooded route requests to disconnected destination can quickly grow to a level where a link state approach would have been more efficient. ********************************************************* Kevin H. Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (781) 271-8388 kgrace@mitre.org > You raise interesting questions, but I'm not sure I accept your > example. > > Why would you choose to have a well-known server, rather than a > replicated service, in a wireless network that is subject to frequent > partitions? > > Even if your application is built around connectivity to a particular > host (e.g. physical apparatus), you might still be better off with an > higher-level protocol that provides notification of an essential > host's status. > > Regards, > Laura From owner-manet@itd.nrl.navy.mil Fri Jul 7 19:03:42 2000 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 TAA15141 for ; Fri, 7 Jul 2000 19:03:42 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA25208 for manet-outgoing; Fri, 7 Jul 2000 17:33:46 -0400 (EDT) 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 RAA25203 for ; Fri, 7 Jul 2000 17:33:45 -0400 (EDT) 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 OAA21698; Fri, 7 Jul 2000 14:33:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA14542; Fri, 7 Jul 2000 14:33:42 -0700 X-Virus-Scanned: Fri, 7 Jul 2000 14:33:42 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) with SMTP id smtpd57tQpj; Fri, 07 Jul 2000 14:33:37 PDT Message-ID: <39664CB2.A7B46973@iprg.nokia.com> Date: Fri, 07 Jul 2000 14:33:38 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "A. Bruce McDonald" CC: MANET mailing list Subject: Re: Proactive vs Reactive vs Hybrid 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, > It seems clear that the tradeoffs between proactive and reactive routing > strategies are quite complex---which approach is best depends on many > interacting factors. Moreover, the interactions between the factors are not well understood. > Hence, I strongly agree with Dr. Haas that the answer to the concerns > lies in the study and development of hybrid routing strategies. While I may not totally disagree with this statement, I fear that it would lead to confusion in the short term. One thing about hybrid strategies is that they are almost guaranteed to be more complicated than "purer" strategies. Thus, gauging the effects of parameter selection and effects from traffic patterns and mobility rates and node populations and so on would, perhaps, become totally impossible. Already it is very, very difficult to get a clear picture about how these interactions affect performance. > The > most viable solution to the problem is to build hybrid systems that can > adapt in a way that dynamically manages the tradeoffs between proactive > and reactive routing to meet 'local' conditions. That is, the > appropriate routing strategy will depend on factors that are both > temporally and spatially determined. Those two statements are not the same, and I only agree with the second one. I think the most viable strategy is to come up with some general principles for protocol design, and see if we can use it to make performance predictions for particular choices of parameters, environmental conditions, traffic patters from particular applications, and so on. If we cannot make any reliable predictions from the choices we might have available, then we can't do any realistic protocol design. Thus, I am not at all sure that making things more complicated by going into hybrid protocol designs right now is really viable. Also note that a protocol can be made to be dynamic by measuring external effects, and dynamically adjusting internal parameter values. This is not a hybrid approach, but it may be sufficient to handle most time-varying scenarios. Or maybe it will not be sufficient. Who knows?! > As I see it we can do one of two things: (1) Build > ad-hoc systems that use a fixed approach and are only viable under a > well-defined range of circumstances---very niche oriented. To do this we > tune the networks to a particular scenario. Perhaps such systems can be > tunable to work under different circumstances by changing system > parameters; however, this destroys the spirit of ad-hoc networking, and > is not likely to be a scalable alternative. (2) Build ad-hoc systems > that dynamically adjust their routing strategy according to conditions > that change in time and space. I believe as a community we should > concentrate on the later approach. I would suggest instead that we follow another approach: - Get a common simulation testbed - Get some common basis for comparison between protocols - Identify the viable protocol techniques that are likely to have wide applicability (e.g, local repair, expanding rings, ...) - Create a repository of realistic traffic patterns, mobility traces, source code, and so on. Of course, this isn't exactly the approach that we've been taking, but on the other hand it is different than going into hybrids as the next step. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Sat Jul 8 05:12:46 2000 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 FAA04308 for ; Sat, 8 Jul 2000 05:12:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA01777 for manet-outgoing; Sat, 8 Jul 2000 03:34:39 -0400 (EDT) Received: from hotmail.com (f11.law6.hotmail.com [216.32.241.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA01772 for ; Sat, 8 Jul 2000 03:34:37 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 8 Jul 2000 00:34:34 -0700 Received: from 212.161.131.55 by lw6fd.law6.hotmail.msn.com with HTTP; Sat, 08 Jul 2000 GMT X-Originating-IP: [212.161.131.55] From: "ck Toh" To: manet@itd.nrl.navy.mil Cc: ck_away@hotmail.com Subject: Re: Fwd: MobiHOC 2000: Call for Participation Date: Sat, 08 Jul 2000 07:34:34 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jul 2000 07:34:34.0870 (UTC) FILETIME=[F696E160:01BFE8AE] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >From: "ck Toh" >To: tccc@ieee.org >CC: ck_away@hotmail.com >Subject: Fwd: MobiHOC 2000: Call for Participation >Date: Sat, 08 Jul 2000 07:30:17 GMT > >Folks, > >Please note that registration for MobiHOC 2000 is >done through MobiCOM conference. However, one can >register only for MobiHOC if that is the intention. >Please also check out on MobiCOM program. >Again, same thing for the hotel. > >C.K. Toh >===================================================== >>From: SJ Lee >>To: "S.J. (Sung-Ju) Lee" >>Subject: MobiHOC 2000: Call for Participation >>Date: Thu, 6 Jul 2000 15:33:54 -0700 (PDT) >> >> >>[Please accept our apologies if you receive duplicate messages] >> >>================================================================== >> >> Announcement & Call for Participation >> >> >> THE FIRST ANNUAL WORKSHOP ON >> MOBILE AD HOC NETWORKING & COMPUTING >> (MobiHOC 2000) >> >> in conjunction with Mobicom 2000 >> >> August 11, 2000 >> Boston, Massachusetts, USA >> >> >>Advance program, registration information, and hotel >>information for the MobiHOC workshop are now available at >> >> http://www.cs.tamu.edu/faculty/vaidya/mobihoc/ >> >>If you are unable to access the above web page, please >>send an e-mail to vaidya@cs.tamu.edu >> >> >>-------------------------------------------------------------------------- >> >> MobiHOC 2000 Advance Program >> >>-------------------------------------------------------------------------- >> >>MobiHoc received 82 submissions, of which 13 were accepted as regular >>papers, and 12 as posters. The accepted papers/posters came from 13 >>countries. >> >>-------------------------------------------------------------------------- >> >> Keynote >> >>Leonard Kleinrock will present a keynote address on Beyond the Netherworld >>of Cyberspace. >> >>-------------------------------------------------------------------------- >> >> Introductions and Welcome >> 8:00 - 8:30 a.m. >> >>-------------------------------------------------------------------------- >> >> Session A: Routing >> 8:30 - 10:15 a.m. >> Session Chair: David B. Johnson, CMU and Rice University >> >> * On the Impact of Alternate Path Routing for Load Balancing in Mobile >> Ad-Hoc Networks >> Marc Pearlman, Zygmunt Haas (Cornell University), Peter Sholander >> (Scientific Research Corporation), and Siamak S. Tabrizi (Air Force >> Rome Laboratories) >> >> * LANMAR: Landmark Routing for Large Scale Wireless Ad Hoc Networks >>with >> Group Mobility >> Guangyu Pei, Mario Gerla, and Xiaoyan Hong (University of >>California, >> Los Angeles) >> >> * DDR-Distributed Dynamic Routing Algorithm for Mobile Ad Hoc Networks >> Navid Nikaein, Houda Labiod, and Christian Bonnet (Eurecom >>Institute) >> >> * Predicting Node Proximity in Ad-Hoc Networks: A Least Overhead >>Adaptive >> Model for Selecting Stable Routes >> A. Bruce McDonald and Taieb Znati (University of Pittsburgh) >> >>-------------------------------------------------------------------------- >> >> Session B: Multicasting >> 10:45 - 12:00 a.m. >> Session Chair: Joseph Macker, Naval Research Laboratory >> >> * Neighbor Supporting Ad Hoc Multicast Routing Protocol >> Seungjoon Lee and Chongkwon Kim (Seoul National University) >> >> * Role-Based Multicast in Highly Mobile but Sparsely Connected Ad Hoc >> Networks >> Linda Briesemeister (DaimlerChrysler Research and Technology) and >> Gunter Hommel (Technical University of Berlin) >> >> * Content Based Multicast (CBM) in Ad Hoc Networks >> Hu Zhou and Suresh Singh (Oregon State University) >> >>-------------------------------------------------------------------------- >> >> Keynote Address and Lunch >> 12:00 - 1:30 p.m. >> >>Keynote Speaker: Leonard Kleinrock >> >>Topic: Beyond the Netherworld of Cyberspace >> >>-------------------------------------------------------------------------- >> >> Session C: Novel Issues >> 1:30 - 2:45 p.m. >> Session Chair: Andrew Campbell, Columbia University >> >> * An Architecture for Building Self-Configurable Systems >> Lakshminarayanan Subramanian and Randy H. Katz (University of >> California, Berkeley) >> >> * MIPMANET - Mobile IP for Mobile Ad Hoc Networks >> Ulf Jonsson, Fredrik Alriksson, Tony Larsson, Per Johansson >>(Ericsson >> Radio Systems), and Gerald Q. Maguire Jr. (Royal Institute of >> Technology) >> >> * Enforcing Service Availability in Mobile Ad-Hoc WANs >> Levente Buttyan and Jean-Pierre Hubaux (Swiss Federal Institute of >> Technology, Lausanne) >> >>-------------------------------------------------------------------------- >> >> Session D: Link Layer >> 3:15 - 4:30 p.m. >> Session Chair: Fred L. Templin, SRI International >> >> * Fair Medium Access in 802.11 based Wireless Ad-Hoc Networks >> Brahim Bensaou, Yu Wang, and Chi Chung Ko (National University of >> Singapore) >> >> * Low Power Rendezvous in Embedded Wireless Networks >> Terry Todd (McMaster University), Frazer Bennett (PA Consulting >>Group), >> and Alan Jones (AT&T Laboratories Cambridge) >> >> * Assignment Methods for Spatial Reuse TDMA >> Jimmi Gronkvist (Swedish Defence Research Establishment) >> >>-------------------------------------------------------------------------- >> >> Poster Session >> 4:30 - 6:00 p.m. >> Session Chair: TBA >> >> * A Speech-Optimised Multiple Access Scheme for a Mobile Ad Hoc >>Network >> V. N. Muthiah and W. C. Wong (National University of Singapore) >> >> * On the Reduction of Broadcast Redundancy in Mobile Ad Hoc Networks >> Wei Peng and Xi-Cheng Lu (Changsha Institute of Technology) >> >> * Central Controller Handover Procedure for ETSI-BRAN HiperLAN/2 Ad >>Hoc >> Networks and Clustering with Quality of Service Guarantees >> Jorg Habetha, Andreas Hettich, Jorg Peetz (Aachen Institute of >> Technology), and Yonggang Du (Philips Research Laboratories) >> >> * DEAPspace -- Transient Ad-hoc Networking of Pervasive Devices >> Reto Hermann, Dirk Husemann, Michael Moser, Michael Nidd, Christian >> Rohner, and Andreas Schade (IBM Zurich Research Lab) >> >> * Securing Ad Hoc Services, a Jini View >> Christian Gehrmann (Ericsson Research), and Pekka Nikander (Helsinki >> Institute of Technology) >> >> * Dynamic Quality-of-Service for Mobile Ad Hoc Networks >> M. Mirhakkak, N. Schult, and D. Thomson (MITRE Corporation) >> >> * A Simulation Analysis on Reactive Route Repair Techniques for QoS >> Sensitive Applications in Mobile Ad Hoc Networks >> George Aggelou and Rahim Tafazolli (University of Surrey) >> >> * Proximity Awareness and Fast Connection Establishment in Bluetooth >> Theodoros Salonidis (University of Maryland), Pravin Bhagwat (IBM T. >>J. >> Watson Research Center), and Leandros Tassiulas (University of >> Maryland) >> >> * Utility-Based Decision-Making in Wireless Sensor Networks >> John Byers and Gabriel Nasser (Boston University) >> >> * A Distributed Mechanism for Topology Discovery in Ad hoc Wireless >> Networks using Mobile Agents >> Romit RoyChoudhury (Haldia Institute of Technology), Somprakash >> Bandyopadhyay (PricewaterhouseCoopers Ltd.), and Krishna Paul >> (CTS-Calcutta) >> >> * Performance Aspects of Bluetooth Scatternet Formation >> G. Miklos, A. Racz, Z. Turanyi, A. Valko (Ericsson Research), and P. >> Johansson (Ericsson Radio Systems) >> >> * Load Balancing via Relay in Next Generation Wireless Systems >> Chunming Qiao, Hongyi Wu, and Ozan Tonguz (University at Buffalo) >> >>-------------------------------------------------------------------------- >> >> > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Sun Jul 9 09:15:58 2000 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 JAA07961 for ; Sun, 9 Jul 2000 09:15:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA13613 for manet-outgoing; Sun, 9 Jul 2000 07:19:06 -0400 (EDT) Received: from neopolis.t.u-tokyo.ac.jp (neopolis.t.u-tokyo.ac.jp [133.11.64.198]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA13608 for ; Sun, 9 Jul 2000 07:19:03 -0400 (EDT) Received: from mori (mori.t.u-tokyo.ac.jp [133.11.65.210]) by neopolis.t.u-tokyo.ac.jp (8.9.3/3.7W-01/12/00) with ESMTP id UAA04825; Sun, 9 Jul 2000 20:13:23 +0900 (JST) Message-Id: <4.2.0.58.J.20000709202038.00b53cb0@neopolis.t.u-tokyo.ac.jp> X-Sender: mori@neopolis.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 09 Jul 2000 20:21:17 +0900 To: manet@itd.nrl.navy.mil From: Hiroyuki Morikawa Subject: Call for Papers: MoMuC2000 and IEICE special issue Cc: mori@mlab.t.u-tokyo.ac.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk ------------- MoMuC2000: Call for Papers --------------- CALL FOR PAPERS The 7th International Workshop on Mobile Multimedia Communications MoMuC2000 http://www.giti.or.jp/activity/momucj Date: October 23.-26. 2000 Place: Waseda, Tokyo, JAPAN Submission due: August 11, 2000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The 7th International Workshop on Mobile Multimedia Communications (MoMuC2000) will provide an international forum for the discussion for research in mobile multimedia communications and platforms regardless of wireless and wired medium. The workshop, to be held in Tokyo, Waseda, a city where the 1st MoMuC(MoMuC-1) was held back in 1993, will bring together researchers, developers and practitioners working in all facets of advanced mobile multimedia communications. The scope of MoMuC2000 will include mobile multimedia systems and applications together with associated mobile computing, broadband wireless networking, video processing and enabling software technologies. The workshop will be corss-diciplinary, well focused, consisting keynote speakers, tutorials, panels and solicited contributions with the emphasis on innovations. An amount of time should be devoted to informal discussion. Authors are cordially invited to submit previously unpublished papers including short papers. Papers with regard to concept and proposal of immature idea are also welcome for an inherent nature of workshop. Technical visit to Yokosuka Research Park(YRP) is also planned. Further information will be provided through MoMuC2000 web page with the following URL. http://www.giti.or.jp/activity/momucj Suggested Areas - Mobile multimedia applications and platforms - Mobile computing and advanced mobile IP - Source coding and channel coding for mobile multimedia including MPEG-4 - Distributed systems and mobile multimedia communications - Mobile ad hoc networks - Mobile multimedia networks - High speed wireless packet systems and technologies - Mobile multimedia applications and technologies in IMT-2000 - Intelligent Transportation System for mobile multimedia - Internetworking of wired and wireless networks - Next generation mobile Internet - Mobile agent technology - Enabling software technologies for mobile systems - Quality of service in wireless and mobile networks - Medium access/data link control - Wireless networks management & service control for mobile multimedia - Software radio for mobile multimedia Workshop Committee - Steering Committee: D. Goodman (Polytechnic University, USA) D. Raychaudhuri (NEC, Princeton, USA) H. Tominaga (Waseda University, JAPAN) - Organizing Committee Chair: H. Tominaga(Waseda University) - Technical Program Committee: Chair: T. Hattori(Sophia University) Co-Chairs: H. Yasuda(University of Tokyo) S. Komaki(University of Osaka) K. Aizawa(University of Tokyo) - Local Organization Committee: Chair: M. Matsumoto(Waseda University) - Secretariat: Ms. Noriko Hosokawa Global Information and Telecommunication Institute, Waseda University, 29-7 Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 JAPAN Tel. /Fax. +81-3-5286-9863 E-mail: momuc2000@giti.or.jp http://www.giti.or.jp/activity/momucj Important Dates Paper(Extended Abstract) Submission Deadline: 11 August 2000 Acceptance of Notification: 4 September 2000 Camera Ready Copy Submission: 22 September 2000 Instructions Manuscripts must be in English and not exceed 3000 words and may include figures and tables. Each copy of the manuscript should include a cover page containing: 1. Name of all authors 2. Name of contact author, affiliation, return address, e-mail, telephone and fax numbers of contact author. 3. A double-spaced, 100-word abstract containing no equations and printed in a 12 point or larger plain font suitable for electronic scanning. 4. All other pages should be marked with the title of the paper, name of the first author, and page numbers. For electronic submissions, file format will be disirable in whether MS-Word 6.0/higher or Adobe PDF format. On-line paper submission is available at the following URL; http://www.giti.or.jp/activity/momucj/submissions.html Sponsors Host: MoMuC-J of IEICE, Waseda University Co-sponsors: IEEE Commnucation Society Japan Chapter, IEEE Communication Society, IEICE (Institute of Electronics, Information and Communication Engineering), IPSJ (Information Processing Society of Japan), IIEEJ (The Institute of Image Electronics Engineers of Japan), ITE (The Institute fo Image Information and Television Engineers) ------------- IEICE special issue: Call for Papers --------------- CALL FOR PAPERS IEICE Special Issue on Mobile Multimedia Communications The IEICE (Institute of Electronics, Information and Communication Engineering) Transactions on Communications announces a forthcoming special issue on Mobile Multimedia Communications to be published in April 2001. Recently, intensive efforts are now underway to promote practical use of mobile multimedia communications technologies; Progress has been achieved in the international standardization activities such as IMT-2000, IrDA, MPEG-4, etc. Many test bed experiments have been carried out as mobile communications systems such as wireless ATM, wireless Internet, etc. Also, various research and developments are widely in progress in the field of application and terminal technologies such as mobile contents, data broadcasting, PDA terminals, information appliance, etc., and of networking technologies such as mobile IP, quality of service, mobile agent, etc. The purpose of this special issue is to present the recent advance of mobile multimedia communications technologies including mobile applications, terminals, network, broadcasting, etc., and to promote future progress of research, development, and new applications of mobile multimedia communications. We are calling for papers from engineers in Japan and abroad. Submission of a paper presented at MoMuC 2000, to be held in Tokyo during October 23rd to 26th, 2000, is encouraged, but presentation of the paper at the workshop is not a requirement for its inclusion in this special issue. Conversely, presentation at the conference will not guarantee acceptance in the special issue. 1. Scope Suggested topics include but are not limited to the following: - Mobile multimedia applications and terminals Mobile computing, mobile contents, architecture for multimedia mobile terminals, mobile IP, personal multimedia applications, audiovisual compressions for mobile applications, security - Mobile multimedia systems and implementations System architecture for mobile multimedia (including fast LAN), quality of service for mobile multimedia communications, agent systems, multimedia satellite, implementation techniques of advanced wireless systems for mobile multimedia, data integration for mobile communications, multimedia location service - Network for Mobile Multimedia Broadband/fast wireless network (including wireless ATM), IP adaptive wireless access method, distributed networking, mobile multimedia advanced wireless techniques (including IrDA), multimedia data integrated service network for mobile communications 2. Submission Instructions Submitted papers will be reviewed by referees in accordance with the regular rules of the Transactions Editorial Committee. The standard number of pages is 8 for a paper and 2 for a letter. Refer to ``Information for Authors'' at the following web site for more details; http://www.ieice.or.jp/eng/shiori/mokuji.html. Prospective authors are requested to send four copies of their manuscripts to the address below. ``Special Issue on Mobile Multimedia Communications'' should be placed on top of the first page. Hirohisa Jozawa NTT Department III (R&D Strategy Department) Teishin Building 8F, 2-3-1, Otemachi, Chiyoda-ku, Tokyo, 100-8116 Japan Tel: +81 3 5205 5379, Fax: +81 3 5205 5369 E-mail: h.jozawa@hco.ntt.co.jp 3. Paper Submission Deadline Papers must be received by August 25, 2000. ^^^^^^^^^^^^^^^ 4. Special Issue Editorial Committee Editor-in-Chief Takeshi Hattori (Sophia University) Secretary Hirohisa Jozawa (NTT), Takehiko Kobayashi (YRP), Hisashi Miyamori (CRL) Guest Editors Hirotaka Nakano (NTT DoCoMo), Shiro Sakata (NEC), Tadanori Mizuno (Shizuoka Univ), Kiyoharu Aizawa (Univ of Tokyo), Ki-ichi Matsuda (Fujitsu Lab), Minoru Etoh (Matsushita), Hiroshi Watanabe (NTT), Shuuichi Matsumoto (KDD Lab), Yoshihiko Akaiwa (Kyushu Univ), Shozo Komaki (Osaka Univ), Mitsuji Matsumoto (Waseda University), Mitsuo Iwama (Sharp), Kouichi Honma (Matsushita), Hiroshi Nakamura (NTT DoCoMo), Fumiyuki Adachi (Touhoku Univ), Hiroyuki Morikawa (Univ of Tokyo), Takuro Satoh (Niigata Univ) * Please note that if accepted for publication, all authors, including authors of invited papers, should pay for the page charges covering partial cost of publication. Authors will receive 100 copies of the reprint. ---------------------------------------------------- From owner-manet@itd.nrl.navy.mil Mon Jul 10 10:48:03 2000 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 KAA11196 for ; Mon, 10 Jul 2000 10:48:03 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA26829 for manet-outgoing; Mon, 10 Jul 2000 08:52:43 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id IAA26824 for ; Mon, 10 Jul 2000 08:52:42 -0400 (EDT) Received: (qmail 22728 invoked by uid 11205); 10 Jul 2000 12:52:32 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.50959.904325.903133@cupidon.inria.fr> Date: Mon, 10 Jul 2000 14:52:31 +0200 (CEST) To: "George N. Aggelou" CC: manet Subject: Re: Overhead analysis In-Reply-To: <3960A569.83220ED0@ee.surrey.ac.uk> References: <14680.41651.904705.246567@cupidon.inria.fr> <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> <3960A569.83220ED0@ee.surrey.ac.uk> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear George, With use of localisation, RDMAR can optimize the flooding cost by restricting the set of nodes that re-emit a flooding packet. To extend our analysis to RDMAR, you just need to evaluate the average proportion of nodes that participate to a flooding. laurent George N. Aggelou writes: > Philippe how about including in your results a routing scheme that uses > localisation for route discovery as well as for the route repair of > broken data paths.. Such as scheme could be the RDMAR protocol..-:) > > Although RDMAR is referred in your report, I would be very much > interested to see it in your analysis too. > > Regards, > George A. > From owner-manet@itd.nrl.navy.mil Mon Jul 10 10:49:01 2000 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 KAA11243 for ; Mon, 10 Jul 2000 10:49:00 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA26736 for manet-outgoing; Mon, 10 Jul 2000 08:48:41 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id IAA26730 for ; Mon, 10 Jul 2000 08:48:39 -0400 (EDT) Received: (qmail 22710 invoked by uid 11205); 10 Jul 2000 12:48:28 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.50715.422459.847207@cupidon.inria.fr> Date: Mon, 10 Jul 2000 14:48:27 +0200 (CEST) To: Zygmunt Haas , Richard CC: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: References: <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Zygmunt and Richard, Sorry for answering so late but I was taking care of my new born child. Both protocol approaches behave differently according to mobility and activity mainly. To summarize: flooding (reactive) protocols react better to high mobility and hello (pro-active) protocols react better to high activity. We agree on this. The topology of the network is also important because it determines how much hello protocols can optimize broadcasting. For example, the random graph model is a difficult case for hello protocols. We did not analyze ZRP because it depends greatly on the pro-active protocol used. My understanding is that the curve of your JSAC paper supposes a DSDV like protocol and that Philippe obtains a different curve when OLSR is used. Something I do not understand is why your curve does not have a discontinuity at ZR=0 (or ZR=1) since pure flooding do not include hello cost and ZRP with ZR=2 includes the hello cost of the pro-active protocol. I would have expected a curve like this : total traffic ^ | | * * | * * | * * | * * |* * * |. * * |. * * |. *** |. -.-------|--------------> Zone Radius . the optimal ZR . .<--- hello packets ----> . . no hello (pure reactive) laurent From owner-manet@itd.nrl.navy.mil Mon Jul 10 10:56:37 2000 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 KAA11527 for ; Mon, 10 Jul 2000 10:56:37 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA26588 for manet-outgoing; Mon, 10 Jul 2000 08:39:11 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id IAA26583 for ; Mon, 10 Jul 2000 08:39:09 -0400 (EDT) Received: (qmail 22657 invoked by uid 11205); 10 Jul 2000 12:38:59 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.50146.334092.815742@cupidon.inria.fr> Date: Mon, 10 Jul 2000 14:38:58 +0200 (CEST) To: manet@itd.nrl.navy.mil Subject: RE: Overhead analysis X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dirk, A word about our terminology: We call flooding protocols, protocols that construct routes by flooding like AODV. We call hello protocols those that discover the topology by neighborhood hellos (hellos containing lists of neighbors) and that use the knowledge of the topology to optimize broadcasting like OLSR (see the nice properties of multi-point relay sets). This can be seen as a refinement of the reactive/pro-active classification. We have chosen a different terminology to insist on a classification according to the way routes are constructed. Groten, D. writes: > Hi Philippe and Laurent, > > I have a reaction on your paper concerning the terminology you use: on the > one hand, we can distinguish between on-demand (reactive) and table-driven > (proactive) protocols. On the other hand, you have identified the first > category as "flooding", and the second category as "hello". I find this > quite confusing: both types of protocols flood routing information over the > network. And while "hello"-type neighbour discovery is mandatory in a > table-driven protocol, it may also be used in an on-demand protocol in order > to establish and repair routes more quickly. > > Of course, strictly speaking, a purely on-demand protocol cannot use > "hellos" because such neighbour discovery is performed pro-actively. But > from the point-of-view of the general concept, the distinction between > on-demand (end-to-end routes are only found when necessary) and pro-active > (end-to-end routes always available) is more easy to grasp than that between > hello and flooding. > > I have two questions: > 1. Am I correct when concluding that your analysis is based purely on the > extreme case where on-demand actually is equivalent to flooding of the > entire network (no hellos to help)? No. > 2. Is the combination of a simple neighbour discovery (via pro-active > hellos) and on-demand route discovery equivalent to ZRP with zone radius 1? > I guess yes, Zygmunt is the right person for answering that. > Regards, > Dirk. > > ------------------------------------------------------------------ > Dirk Groten KPNResearch > ------------------------------------------------------------------ > P. O. Box 421 Tel: +31 6 53747220 > 2260 AK Leidschendam Fax: +31 70 3326477 > The Netherlands E-mail: mailto:d.groten@kpn.com From owner-manet@itd.nrl.navy.mil Mon Jul 10 11:01:57 2000 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 LAA11764 for ; Mon, 10 Jul 2000 11:01:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA27621 for manet-outgoing; Mon, 10 Jul 2000 09:19:41 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id JAA27615 for ; Mon, 10 Jul 2000 09:19:39 -0400 (EDT) Received: (qmail 22850 invoked by uid 11205); 10 Jul 2000 13:19:28 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.52573.890827.655064@cupidon.inria.fr> Date: Mon, 10 Jul 2000 15:19:25 +0200 (CEST) To: Kevin Grace Cc: MANET mailing list Subject: On Demand Flaw In-Reply-To: <39650256.19CA5C92@mitre.org> References: <39650256.19CA5C92@mitre.org> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kevin, The analysis I have mentionned in a previous mail shows that all protocols include at least a O(N^2) control overhead where N is the number of nodes. This is not surprising since the topology of a radio network is certainly proportional to O(N^2) (imagine for example an IETF meeting room). If you call scalable a protocol that has a cost proportional to the size of the topology, you should not be alarmed by what you call the on demand flaw... laurent Kevin Grace writes: > In reflecting upon the behavior of the on demand routing protocols, I > made a very disturbing observation. I don't believe that I have seen > anyone discuss this issue before, so I submit it now to alert > others. > > The motivation behind the on demand routing protocols was to increase > scalability by not having to distribute topology information like > traditional routing protocols. In the on demand approach, when a > source has a packet to send to a destination for which it does not > have a route, the source initiates a flooded route > request. Unfortunately, if the intended destination is disconnected > from the network, the flooded route request propagates across the > entire network but produces no useful result. Even worse, since the > source never discovers a route, it is forced to try flooding another > route request again later which will continue to waste resources as > long as the destination is disconnected. > > The problem here is that the source has no way of determining what > nodes are disconnected from the network. This is exactly why topology > information is useful! A link state protocol would consume no > additional resources for a disconnected destination since the source > would know that there was no route. > > Consider now that the network has one well known server that all the > other nodes try to connect to, and the server happens to be > disconnected. The number of messages sent as part of the unsuccessful > flooded route requests are enough to distribute the entire network > topology to every node! At this point a link state algorithm would be > superior to the on demand protocol. In fact, the resources consumed > and wasted by the on demand routing protocol grows linearly with the > number of disconnected well known servers. Eg. a network with 3 > disconnected well known servers would cause an on demand protocol to > consume and waste 3 times the resources of a link state protocol. > > It appears to me that the on demand routing protocols have a fatal flaw > which preclude them from scaling well and that the link state approach > is superior. > > ********************************************************* > Kevin H. Grace > The MITRE Corporation > 202 Burlington Rd > Bedford, MA 01730 > (781) 271-8388 > kgrace@mitre.org > From owner-manet@itd.nrl.navy.mil Mon Jul 10 11:09:27 2000 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 LAA12059 for ; Mon, 10 Jul 2000 11:09:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA27636 for manet-outgoing; Mon, 10 Jul 2000 09:20:02 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA27631 for ; Mon, 10 Jul 2000 09:20:00 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13BdTR-0002aM-00; Mon, 10 Jul 2000 14:19:49 +0100 Message-ID: <3969CD76.6E9E21D5@ee.surrey.ac.uk> Date: Mon, 10 Jul 2000 14:19:50 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Viennot@inria.fr, manet Subject: Re: Overhead analysis References: <14680.41651.904705.246567@cupidon.inria.fr> <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> <3960A569.83220ED0@ee.surrey.ac.uk> <14697.50959.904325.903133@cupidon.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 Laurent Viennot wrote: > > Dear George, > > With use of localisation, RDMAR can optimize the flooding cost by > restricting the set of nodes that re-emit a flooding packet. To > extend our analysis to RDMAR, you just need to evaluate the average > proportion of nodes that participate to a flooding. Laurent: Don't you think that the avg number of nodes that are disturbed from flooded control messages should leverage protocol design? The average number of nodes disturbed during flooding, however, is equal to the number of nodes in your network, assuming no network partiotions. Right? (which comes from: total_nodes_disturbed/total_flooding_attempts) Therefore, you _don't_ need to evaluate this average proportion of nodes that participate to a flooding, as you note in yr message, because you know how much this is beforehand. Studying the use of localisation instead you could investigate on the followings: a) How much congestion flooding adds onto your network layer? (Measures scalability) b) How much does MAC layer performance suffers from the net-wide signalling generated from a flooding-based protocol. Transmission delays and the number of colliding packets are both a good metric for MAC performance. c) Impact of packet loss on transport layer. BTW, recently I submitted a paper to IEEE Transactions on Networking that studies the optimum configuration of the RDMAR protocol with focus on the above two issues. As many people have asked me for a copy of it, I will send a mail to the list as soon as this gets accepted (hopefully!.. -:). Regards, George A. > > laurent > > George N. Aggelou writes: > > Philippe how about including in your results a routing scheme that uses > > localisation for route discovery as well as for the route repair of > > broken data paths.. Such as scheme could be the RDMAR protocol..-:) > > > > Although RDMAR is referred in your report, I would be very much > > interested to see it in your analysis too. > > > > Regards, > > George A. > > -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Mon Jul 10 11:44:25 2000 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 LAA13837 for ; Mon, 10 Jul 2000 11:44:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA28509 for manet-outgoing; Mon, 10 Jul 2000 09:43:36 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id JAA28504 for ; Mon, 10 Jul 2000 09:43:35 -0400 (EDT) Received: (qmail 22984 invoked by uid 11205); 10 Jul 2000 13:43:24 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.54004.480967.826980@cupidon.inria.fr> Date: Mon, 10 Jul 2000 15:43:16 +0200 (CEST) To: "George N. Aggelou" Cc: Laurent.Viennot@inria.fr, manet Subject: Re: Overhead analysis In-Reply-To: <3969CD76.6E9E21D5@ee.surrey.ac.uk> References: <14680.41651.904705.246567@cupidon.inria.fr> <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> <3960A569.83220ED0@ee.surrey.ac.uk> <14697.50959.904325.903133@cupidon.inria.fr> <3969CD76.6E9E21D5@ee.surrey.ac.uk> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, there is just a misunderstanding on what we want to analyze. I was just mentioning the limitation of flooding to a certain area and not to all nodes in case of route repair. This is an interesting idea of RDMAR : ``restricting the range of route discovery within an area centred at the source node of the route discovery and with maximum radius that equals to the estimated relative distance''. If planar coordinates are available to each node, what about limiting the flooding to an even narrower area, for example a rectangle containing the source and the estimated position of the destination ? Do you have some hints about such ideas ? laurent George N. Aggelou writes: > Laurent Viennot wrote: > > > > Dear George, > > > > With use of localisation, RDMAR can optimize the flooding cost by > > restricting the set of nodes that re-emit a flooding packet. To > > extend our analysis to RDMAR, you just need to evaluate the average > > proportion of nodes that participate to a flooding. > > Laurent: > > Don't you think that the avg number of nodes that are disturbed from > flooded control messages should leverage protocol design? The average > number of nodes disturbed during flooding, however, is equal to the > number of nodes in your network, assuming no network partiotions. Right? For classical on demand protocols, of course yes. I thought RDMAR was using localisation to limit the number of nodes re-emitting the flooding packet. > (which comes from: total_nodes_disturbed/total_flooding_attempts) > Therefore, you _don't_ need to evaluate this average proportion of > nodes that participate to a flooding, as you note in yr message, because > you know how much this is beforehand. Studying the use of localisation > instead you could investigate on the followings: > > a) How much congestion flooding adds onto your network layer? (Measures > scalability) > b) How much does MAC layer performance suffers from the net-wide > signalling generated from a flooding-based protocol. Transmission delays > and the number of colliding packets are both a good metric for MAC > performance. > c) Impact of packet loss on transport layer. > Our analysis is just restricted to the estimation of the additional traffic generated by control packets. > BTW, recently I submitted a paper to IEEE Transactions on Networking > that studies the optimum configuration of the RDMAR protocol with focus > on the above two issues. As many people have asked me for a copy of > it, I will send a mail to the list as soon as this gets accepted > (hopefully!.. -:). > > > Regards, > George A. > > > > > > > laurent > > > > George N. Aggelou writes: > > > Philippe how about including in your results a routing scheme that uses > > > localisation for route discovery as well as for the route repair of > > > broken data paths.. Such as scheme could be the RDMAR protocol..-:) > > > > > > Although RDMAR is referred in your report, I would be very much > > > interested to see it in your analysis too. > > > > > > Regards, > > > George A. > > > > > -- > *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. > George N. Aggelou > Research Fellow > Centre for Communications Systems Research > University of Surrey > > http://www.ee.surrey.ac.uk/Personal/G.Aggelou > *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Mon Jul 10 12:12:37 2000 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 MAA14960 for ; Mon, 10 Jul 2000 12:12:36 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA29364 for manet-outgoing; Mon, 10 Jul 2000 10:10:51 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA29356 for ; Mon, 10 Jul 2000 10:10:50 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id JAA29075; Mon, 10 Jul 2000 09:10:36 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id JAA25918; Mon, 10 Jul 2000 09:10:27 -0500 (CDT) Date: Mon, 10 Jul 2000 09:10:27 -0500 (CDT) Message-Id: <200007101410.JAA25918@sun.cs.tamu.edu> To: Laurent.Viennot@inria.fr Subject: Re: Overhead analysis Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi Laurent >> From: Laurent Viennot ... >> If planar coordinates are available to each node, what about limiting >> the flooding to an even narrower area, for example a rectangle >> containing the source and the estimated position of the destination ? >> Do you have some hints about such ideas ? Yes ... you might want to take a look at the paper on Location-Aided Routing from the 1998 MobiCom, Dallas. - nitin From owner-manet@itd.nrl.navy.mil Mon Jul 10 12:19:14 2000 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 MAA15377 for ; Mon, 10 Jul 2000 12:19:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA00335 for manet-outgoing; Mon, 10 Jul 2000 10:32:32 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA00326 for ; Mon, 10 Jul 2000 10:32:31 -0400 (EDT) Received: (qmail 23351 invoked by uid 11205); 10 Jul 2000 14:32:21 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14697.56948.936756.841791@cupidon.inria.fr> Date: Mon, 10 Jul 2000 16:32:20 +0200 (CEST) To: Kevin Grace Cc: MANET mailing list Subject: Re: On Demand Flaw In-Reply-To: <3969DB80.1BAA1AFF@mitre.org> References: <39650256.19CA5C92@mitre.org> <14697.52573.890827.655064@cupidon.inria.fr> <3969DB80.1BAA1AFF@mitre.org> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit With such a heavy traffic, you'd rather consider a pro-active protocol like OLSR. You can model the traffic with the average number a of active routes per node. Simulations I have read often suppose a<1. If you consider the connections you initiate with your own computer in an every day use, you wouldn't expect a to be greater than 2 or 3. However there may be some applications producing such traffics. If you know some serious examples, I am curious to know them. laurent Kevin Grace writes: > Hi Laurent, > > >> If you call scalable a protocol that has a cost > >> proportional to the size of the topology, you should not be alarmed by > >> what you call the on demand flaw... > > The problem is that on-demand protocols can actually have an overhead > of O(N^3). This is much worse than the overhead of a link state > protocol which is O(N^2). > > To see why an on-demand protocol has an overhead of O(N^3) consider a > network of N nodes in which every node communicates to every other > node. Now consider that the network is severed into two halves, each > with N/2 nodes. Each node in a partition now sends flooded route > requests for N/2 disconnected destinations resulting in N/2 * N/2 > flooded route requests and since each flood consumes N/2 > transmissions, the total resources consumed is O(N^3). > > It still appears to me that on-demand protocols have a fatal flaw that > precludes them from scaling well. > > ********************************************************* > Kevin H. Grace > The MITRE Corporation > 202 Burlington Rd > Bedford, MA 01730 > (781) 271-8388 > kgrace@mitre.org > > > > Laurent Viennot wrote: > > > > Hi Kevin, > > > > The analysis I have mentionned in a previous mail shows that all > > protocols include at least a O(N^2) control overhead where N is the > > number of nodes. This is not surprising since the topology of a radio > > network is certainly proportional to O(N^2) (imagine for example an > > IETF meeting room). If you call scalable a protocol that has a cost > > proportional to the size of the topology, you should not be alarmed by > > what you call the on demand flaw... > > > > laurent > > > From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:34:17 2000 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 NAA19067 for ; Mon, 10 Jul 2000 13:34:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA02131 for manet-outgoing; Mon, 10 Jul 2000 11:24:58 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA02126 for ; Mon, 10 Jul 2000 11:24:56 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13BfQL-0003nT-00; Mon, 10 Jul 2000 16:24:45 +0100 Message-ID: <3969EABD.FC570D72@ee.surrey.ac.uk> Date: Mon, 10 Jul 2000 16:24:45 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Viennot@inria.fr, manet Subject: Re: Overhead analysis References: <14680.41651.904705.246567@cupidon.inria.fr> <3.0.1.32.20000703142718.01c19d10@menetou.inria.fr> <3960A569.83220ED0@ee.surrey.ac.uk> <14697.50959.904325.903133@cupidon.inria.fr> <3969CD76.6E9E21D5@ee.surrey.ac.uk> <14697.54004.480967.826980@cupidon.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 > If planar coordinates are available to each node, what about limiting > the flooding to an even narrower area, for example a rectangle > containing the source and the estimated position of the destination ? > Do you have some hints about such ideas ? Yes! the relative position of two mobiles (and hence their relative distance) is determined throught the Relative Distance Estimatin (RDE) algorithm in RDMAR. RDE relies its operation on a stochastic model that bases its estimations only on the previous relative distance of the two mobiles. Our results (reported in the paper I mentioned earlier) are very promising as 95-98% hit ratios (i.e., correct estimatinos) are achieved. Note finally that RDMAR protocol _does not_ assume any system parameters such as planar coordinates or the actual velicity of nodes are available to the nodes. Regards, George A. > > laurent > > George N. Aggelou writes: > > Laurent Viennot wrote: > > > > > > Dear George, > > > > > > With use of localisation, RDMAR can optimize the flooding cost by > > > restricting the set of nodes that re-emit a flooding packet. To > > > extend our analysis to RDMAR, you just need to evaluate the average > > > proportion of nodes that participate to a flooding. > > > > Laurent: > > > > Don't you think that the avg number of nodes that are disturbed from > > flooded control messages should leverage protocol design? The average > > number of nodes disturbed during flooding, however, is equal to the > > number of nodes in your network, assuming no network partiotions. Right? > > For classical on demand protocols, of course yes. I thought RDMAR was using > localisation to limit the number of nodes re-emitting the flooding packet. > > > (which comes from: total_nodes_disturbed/total_flooding_attempts) > > Therefore, you _don't_ need to evaluate this average proportion of > > nodes that participate to a flooding, as you note in yr message, because > > you know how much this is beforehand. Studying the use of localisation > > instead you could investigate on the followings: > > > > a) How much congestion flooding adds onto your network layer? (Measures > > scalability) > > b) How much does MAC layer performance suffers from the net-wide > > signalling generated from a flooding-based protocol. Transmission delays > > and the number of colliding packets are both a good metric for MAC > > performance. > > c) Impact of packet loss on transport layer. > > > > Our analysis is just restricted to the estimation of the additional traffic > generated by control packets. > > > BTW, recently I submitted a paper to IEEE Transactions on Networking > > that studies the optimum configuration of the RDMAR protocol with focus > > on the above two issues. As many people have asked me for a copy of > > it, I will send a mail to the list as soon as this gets accepted > > (hopefully!.. -:). > > > > > > Regards, > > George A. > > > > > > > > > > > > laurent > > > > > > George N. Aggelou writes: > > > > Philippe how about including in your results a routing scheme that uses > > > > localisation for route discovery as well as for the route repair of > > > > broken data paths.. Such as scheme could be the RDMAR protocol..-:) > > > > > > > > Although RDMAR is referred in your report, I would be very much > > > > interested to see it in your analysis too. > > > > > > > > Regards, > > > > George A. > > > > > > > > -- > > *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. > > George N. Aggelou > > Research Fellow > > Centre for Communications Systems Research > > University of Surrey > > > > http://www.ee.surrey.ac.uk/Personal/G.Aggelou > > *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:34:44 2000 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 NAA19094 for ; Mon, 10 Jul 2000 13:34:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA00258 for manet-outgoing; Mon, 10 Jul 2000 10:30:52 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA00252 for ; Mon, 10 Jul 2000 10:30:50 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 10 Jul 2000 15:30:33 +0100 X-Mailer: exmh version 2.0.2 To: Laurent.Viennot@inria.fr cc: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-reply-to: Your message of "Mon, 10 Jul 2000 15:43:16 +0200." <14697.54004.480967.826980@cupidon.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 15:30:31 +0100 Message-ID: <13117.963239431@cs.ucl.ac.uk> From: Nikos Triantafillis Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk In message <14697.54004.480967.826980@cupidon.inria.fr>, Laurent Viennot writes: ..... >If planar coordinates are available to each node, what about limiting >the flooding to an even narrower area, for example a rectangle >containing the source and the estimated position of the destination ? >Do you have some hints about such ideas ? There is some work done I believe in this area where flooding is limited to an even narrower space eg: Young-Bae Ko and Nitin H. Vaidya. "Location-Aided Routing (LAR) in Mobile Ad Hoc Networks". Proceedings of Mobicom '98 4th Annual ACM/IEEE International Conference on Mobile Computing and Networking, pp. 66-75, Dallas, TX, October 1998, including some other papers on geographic routing and maintenance. Nick From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:54:34 2000 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 NAA19957 for ; Mon, 10 Jul 2000 13:54:34 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA03370 for manet-outgoing; Mon, 10 Jul 2000 11:57:24 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA03364 for ; Mon, 10 Jul 2000 11:57:23 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id KAA02130; Mon, 10 Jul 2000 10:57:12 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id KAA28326; Mon, 10 Jul 2000 10:57:03 -0500 (CDT) Date: Mon, 10 Jul 2000 10:57:03 -0500 (CDT) Message-Id: <200007101557.KAA28326@sun.cs.tamu.edu> To: Laurent.Viennot@inria.fr, manet@itd.nrl.navy.mil Subject: Re: Overhead analysis Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Laurent: >> > If planar coordinates are available to each node, what about limiting >> > the flooding to an even narrower area, for example a rectangle >> > containing the source and the estimated position of the destination ? >> > Do you have some hints about such ideas ? By the way, also take a look at the Query Localization scheme from 1999 MobiCom by Castaneda & Das. That scheme also limits route discovery to a small region (as does Location-Aided Routing LAR), but without using physical location information (unlike LAR). Cheerio. - nitin From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:58:38 2000 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 NAA20085 for ; Mon, 10 Jul 2000 13:58:37 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA03857 for manet-outgoing; Mon, 10 Jul 2000 12:14:54 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA03852 for ; Mon, 10 Jul 2000 12:14:52 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA23251 for ; Mon, 10 Jul 2000 12:14:42 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA25402 for ; Mon, 10 Jul 2000 12:12:57 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub2.mitre.org with SMTP id 3888655; Mon, 10 Jul 2000 12:14:39 EST Message-ID: <3969F671.4E59747C@mitre.org> Date: Mon, 10 Jul 2000 12:14:41 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 CC: MANET mailing list Subject: Re: On Demand Flaw References: <39650256.19CA5C92@mitre.org> <14697.52573.890827.655064@cupidon.inria.fr> <3969DB80.1BAA1AFF@mitre.org> <14697.56948.936756.841791@cupidon.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 Oops...I failed to address this to the group previously. Hi Laurent, >> If you call scalable a protocol that has a cost >> proportional to the size of the topology, you should not be alarmed by >> what you call the on demand flaw... The problem is that on-demand protocols can actually have an overhead of O(N^3). This is much worse than the overhead of a link state protocol which is O(N^2). To see why an on-demand protocol has an overhead of O(N^3) consider a network of N nodes in which every node communicates to every other node. Now consider that the network is severed into two halves, each with N/2 nodes. Each node in a partition now sends flooded route requests for N/2 disconnected destinations resulting in N/2 * N/2 flooded route requests and since each flood consumes N/2 transmissions, the total resources consumed is O(N^3). It still appears to me that on-demand protocols have a fatal flaw that precludes them from scaling well. ********************************************************* Kevin H. Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (781) 271-8388 kgrace@mitre.org Laurent Viennot wrote: > > Hi Kevin, > > The analysis I have mentionned in a previous mail shows that all > protocols include at least a O(N^2) control overhead where N is the > number of nodes. This is not surprising since the topology of a radio > network is certainly proportional to O(N^2) (imagine for example an > IETF meeting room). If you call scalable a protocol that has a cost > proportional to the size of the topology, you should not be alarmed by > what you call the on demand flaw... > > laurent >Laurent Viennot wrote: > > With such a heavy traffic, you'd rather consider a pro-active protocol > like OLSR. > > You can model the traffic with the average number a of active routes > per node. Simulations I have read often suppose a<1. If you consider > the connections you initiate with your own computer in an every day > use, you wouldn't expect a to be greater than 2 or 3. > > However there may be some applications producing such traffics. If you > know some serious examples, I am curious to know them. > > laurent > From owner-manet@itd.nrl.navy.mil Mon Jul 10 14:37:08 2000 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 OAA22314 for ; Mon, 10 Jul 2000 14:37:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA03409 for manet-outgoing; Mon, 10 Jul 2000 11:58:37 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA03404 for ; Mon, 10 Jul 2000 11:58:32 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA19849; Mon, 10 Jul 2000 11:58:11 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA21859; Mon, 10 Jul 2000 11:56:25 -0400 (EDT) Received: from kbrayer.mitre.org (129.83.36.88) by mailhub2.mitre.org with SMTP id 3888334; Mon, 10 Jul 2000 11:58:06 EST Message-ID: <3969F6D3.CC73AE7C@mitre.org> Date: Mon, 10 Jul 2000 12:16:20 -0400 From: Kenneth Brayer Reply-To: kb@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.73C-20000509M (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: MANET mailing list Subject: Re: Proactive vs Reactive vs Hybrid References: <39664CB2.A7B46973@iprg.nokia.com> Content-Type: multipart/mixed; boundary="------------EAAC6B2215E499D85E21E1D5" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. --------------EAAC6B2215E499D85E21E1D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mr. Perkins "Charles E. Perkins" wrote: I would suggest instead that we follow another approach: - Get a common simulation testbed - Get some common basis for comparison between protocols - Identify the viable protocol techniques that are likely to have wide applicability (e.g, local repair, expanding rings, ...) - Create a repository of realistic traffic patterns, mobility traces, source code, and so on. I am the network engineer on the Air Force Global Grid project at The MITRE Corporation at the Electronic Systems Center, Hanscom AFB, MA. The approach that you have suggested above is exactly what I have been proposing for use in picking a MANET protocol for the Global Grid. In the end what we need is to evaluate protocols on a common basis against parameters that are meaningful to our customers. Rapid delivery of messages is what they generally want. We need standard traffic scenarios and measures of performance. Twenty years ago when I published my Ad-Hoc protocol, they didn't call it Ad-Hoc then, I used a testbed that I built with Intel 8086 single board computers. That is all gone now but I still have my software--real implementation on a bare machine in PL/M and ASM 86. I have noted that many researchers have implementations that run on Linux. One approach that I am looking at is using real software in a testbed. This would aviod the issue of demonstrating that the simulation is correct and allow us to go up to reasonable numbers of nodes by, say, using office computers over the weekend. The office computers also have corporate network connections which could be used to collect statistics of performance. P.S. I also know how to simulate errors on comm channels which could be done after baseline performance was determined. Kenneth Brayer P.S. References to my Ad-Hoc Protocol are enclosed in a word document for any who are interested --------------EAAC6B2215E499D85E21E1D5 Content-Type: application/msword; x-mac-type="5738424E"; x-mac-creator="4D535744"; name="Kenneth Brayer Ad-Hoc Pubs" Content-Description: Unknown Document Content-Disposition: inline; filename="Kenneth Brayer Ad-Hoc Pubs" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALAAAAAAA AAAAEAAALwAAAAEAAAD+////AAAAAC0AAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAGwAJBAAAABK/AAAAAAABEQABAAEABAAA aAsAAA4AamJqYmqqaqoAAAAAAAAAAAAAAAAAAAAAAAAJBBYAIhwAAADIAAAAyAAAaAcAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAKIAAAAAAAAAogAAAKIAAAAAAAAAogAAAAAAAACiAAAA AAAAAKIAAAAAAAAAogAAABQAAAAAAAAAAAAAAOYAAAAAAAAA5gAAAAAAAADmAAAAAAAAAOYA AAAAAAAA5gAAAAwAAADyAAAAFAAAAOYAAAAAAAAAtQIAAOoAAAASAQAAAAAAABIBAAAAAAAA EgEAAAAAAAASAQAAAAAAABIBAAAAAAAAEgEAAAAAAAASAQAAAAAAABIBAAAAAAAAcgIAAAIA AAB0AgAAAAAAAHQCAAAAAAAAdAIAAAAAAAB0AgAAAAAAAHQCAAAAAAAAdAIAACwAAACfAwAA 9AEAAJMFAACcAAAAoAIAABUAAAAAAAAAAAAAAAAAAAAAAAAAogAAAAAAAAASAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAASAQAAAAAAABIBAAAAAAAAEgEAAAAAAAASAQAAAAAAAKACAAAAAAAA 8gEAAAAAAACiAAAAAAAAAKIAAAAAAAAAEgEAAAAAAAAAAAAAAAAAABIBAAAAAAAAEgEAAAAA AADyAQAAAAAAAPIBAAAAAAAA8gEAAAAAAAASAQAA1gAAAKIAAAAAAAAAEgEAAAAAAACiAAAA AAAAABIBAAAAAAAAcgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtgAAABgAAADOAAAAGAAAAKIA AAAAAAAAogAAAAAAAACiAAAAAAAAAKIAAAAAAAAAEgEAAAAAAAByAgAAAAAAAPIBAACAAAAA 8gEAAAAAAAAAAAAAAAAAAHICAAAAAAAAogAAAAAAAACiAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgIAAAAAAAAAAAAA AAAAAAYBAAAMAAAA2aWPtQAAAADmAAAAAAAAAOYAAAAAAAAA6AEAAAoAAAByAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS2VubmV0aCBCcmF5ZXKScyBNb2JpbGUgUHJvdG9j b2wgd29yaw0NSXQgaXMgYSBNQU5FVCBidXQgSSB3YXMgdGhlIG9ubHkgcmVzZWFyY2hlciBp biB0aGUgZmllbGQgdGhlbiBhbmQgSSBkaWRuknQgdGhpbmsgb2YgdGhlIHRlcm0gQWQtSG9j Lg0NUGFja2V0IFN3aXRjaGluZyBmb3IgTW9iaWxlIEVhcnRoIFN0YXRpb25zIHZpYSBMb3ct T3JiaXQgU2F0ZWxsaXRlIE5ldHdvcmsNSy4gQnJheWVyLCBQcm9jZWVkaW5ncyBvZiB0aGUg SUVFRSwgTm92ZW1iZXIgMTk4NA0NQXV0b25vbW91cyBBZGFwdGl2ZSBMb2NhbCBBcmVhIE5l dHdvcmtpbmc6IFJpbmcgQ29tbXVuaWNhdGlvbnMgdmlhIFBvaW50LXRvLVBvaW50IEltcGxl bWVudGF0aW9uDUsuIEJyYXllciwgSUVFRSBJTkZPQ09NJzg0LCBTYW4gRnJhbmNpc2NvLCBD QSwgQXByaWwgMTk4NA0NQW4gQWRhcHRpdmUgQ29tcHV0ZXIgQ29tbXVuaWNhdGlvbiBOZXR3 b3JrIERlc2lnbmVkIHdpdGggRGVjZW50cmFsaXplZCBDb250cm9sDUsuIEJyYXllciwgSUVF RSBDb21tdW5pY2F0aW9ucyBNYWdhemluZSwgTm92ZW1iZXIgMTk4Mw0NQWRhcHRpdmUgTmV0 d29ya2luZyBvZiBWYXJpYWJsZSBUb3BvbG9neSBTYXRlbGxpdGUgTmV0d29ya3MNSy4gQnJh eWVyLCBTaXh0aCBJbnRlcm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gRGlnaXRhbCBTYXRlbGxp dGUgQ29tbXVuaWNhdGlvbnMsDVBob2VuaXgsIEFaLCBTZXB0ZW1iZXIgMTk4Mw0NUm91dGlu ZyBpbiBhICJtb2JpbGUiIG5ldHdvcmsgLSBmYWN0IG9yIGZhbnRhc3k/DUsuIEJyYXllciwg RGF0YSBDb21tdW5pY2F0aW9ucywgQXVndXN0IDE5ODMNDUltcGxlbWVudGF0aW9uIGFuZCBQ ZXJmb3JtYW5jZSBvZiBTdXJ2aXZhYmxlIENvbXB1dGVyIENvbW11bmljYXRpb24gd2l0aCBB dXRvbm9tb3VzIERlY2VudHJhbGl6ZWQgQ29udHJvbA1LLiBCcmF5ZXIsIElFRUUgQ29tbXVu aWNhdGlvbnMgTWFnYXppbmUsIEp1bHkgMTk4Mw0NR2VvZ3JhcGhpY2FsbHkgRGlzdHJpYnV0 ZWQgQ29udHJvbCBvZiBhIE1pY3JvcHJvY2Vzc29yIENvbW11bmljYXRpb25zIE5ldHdvcmsN Sy4gQnJheWVyLCBJRUVFIENvbW11bmljYXRpb25zIENvbmZlcmVuY2UsIEJvc3RvbiwgTUEs IEp1bmUgMTk4Mw0NSW1wbGVtZW50aW5nIENvbXB1dGVyIENvbW11bmljYXRpb25zIHdpdGgg T0VNIE1pY3JvcHJvY2Vzc29yczogU3Vydml2YWJsZSBOZXR3b3JrIFJvdXRpbmcgU3lzdGVt DUsuIEJyYXllciwgSUVFRSBHbG9iZWNvbSc4MiwgTWlhbWksIEZMLCBOb3ZlbWJlciAxOTgy DQ1JbXBsZW1lbnRpbmcgQ29tcHV0ZXIgQ29tbXVuaWNhdGlvbnMgd2l0aCBPRU0gTWljcm9w cm9jZXNzb3JzOiBTdXJ2aXZhYmxlIFJvdXRpbmcgU3lzdGVtIFBlcmZvcm1hbmNlDUsuIEJy YXllciwgSUVFRSBHbG9iZWNvbSc4MiwgTWlhbWksIEZMLCBOb3ZlbWJlciAxOTgyDQ1BIFRl c3RiZWQgQXBwcm9hY2ggdG8gdGhlIERlc2lnbiBvZiBhIENvbXB1dGVyIENvbW11bmljYXRp b24gTmV0d29yaw1LLiBCcmF5ZXIsIFYuUy4gTGFmbGV1ciwgSUVFRSBDT01QVVRFUiBNYWdh emluZSwgT2N0b2JlciAxOTgyDQ1TdXJ2aXZhYmxlIENvbXB1dGVyIENvbW11bmljYXRpb25z IFJvdXRpbmcgdXNpbmcgRGVjZW50cmFsaXplZCBDb250cm9sDUsuIEJyYXllciwgSUVFRSBJ bnRlcm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gQ2lyY3VpdHMgYW5kIENvbXB1dGVycywgDU5l dyBZb3JrLCBOWSwgU2VwdGVtYmVyIDE5ODINDVNpbXVsYXRpb24gdmlhIEltcGxlbWVudGF0 aW9uIHdpdGggQXBwbGljYXRpb25zIGluIENvbXB1dGVyIENvbW11bmljYXRpb24NSy4gQnJh eWVyLCBWLlMuIExhZmxldXIsIEcuSC4gU2ltcHNvbiwgMTV0aCBTaW11bGF0aW9uIFN5bXBv c2l1bSwgVGFtcGEsIEZMLCAJTWFyY2ggMTk4Mg0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAABoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQAACYEAAAnBAAA jAQAAI0EAADYBAAACgUAAAsFAABsBQAApgUAAKcFAAD2BQAALQYAAC4GAABqBgAAuQYAANUG AADWBgAABwcAADMHAAA0BwAAngcAANEHAADSBwAAIAgAAGEIAABiCAAAwwgAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AADEkABJkBAEAAA3GCwAD0AIs EBgVAAABAwAAMSQAABsABAAAJgQAACcEAACMBAAAjQQAANgEAAAKBQAACwUAAGwFAACmBQAA pwUAAPYFAAAtBgAALgYAAGoGAAC5BgAA1QYAANYGAAAHBwAAMwcAADQHAACeBwAA0QcAANIH AAAgCAAAYQgAAGIIAADDCAAA+QgAAPoIAABfCQAAlQkAAJYJAADbCQAAGQoAABoKAABhCgAA pgoAAMMKAADECgAADgsAAGcLAABoCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKsMIAAD5CAAA+ggAAF8J AACVCQAAlgkAANsJAAAZCgAAGgoAAGEKAACmCgAAwwoAAMQKAAAOCwAAZwsAAGgLAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAMAADEkAAAPIAAcUAEAH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAHX/FlZ5/xZX LP1EVy3+8Fcu/URXOv66Vzv+uldB/khXYf7gV2X/JFdp/3JXb/8kV3L/Zld1/1hXef8+WQn/ tlks/XZZLf4+WS79dlk6/nBZO/5wWUH+Illh/qBZZf5wWWn/GFlv/nBZcP7IWXH+cFl1/j5Z dv6uZmb/TGbV/+ByLP4uci7+LnYs/ah2Lv2odyz+eHcu/nh5LP6GeS7+htTU/j7VCf9o1XP+ kNV0/vDV1f4+AADqHAABAAAAEgEAAAQAIExUU0j9xjdiAAABLAAAATlPUy8yQOyN1AAAAmgA AABWVkRNWG+NdwQAAALAAAAF4GNtYXCCEw+pAAAIoAAABBZjdnQgWOwtHwAADLgAAAE8ZnBn bYhiJtoAAA30AAAFQGdhc3AAFwAJAAATNAAAABBnbHlmmx9qKwAAE0QAAJZUaGRteK8m9rIA AKmYAAAl0GhlYWTF5qTvAADPaAAAADZoaGVhDoAG2QAAz6AAAAAkaG10eAXzfcUAAM/EAAAE 1Gtlcm73Q/hXAADUmAAAAtZsb2NhDy82fwAA13AAAAJsbWF4cALmBgAAANncAAAAIG5hbWVu BCzhAADZ/AAACoVwb3N0OWycRwAA5IQAAAQBcHJlcOMukfwAAOgSAA8ACgABAFsADwACAAMA AwADADQAAEDx/wIANAAAAAYATgBvAHIAbQBhAGwAAAACAAAAFABDShgAT0oDAFBKAwBRSgMA bUgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAA YQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAAAAAAaAcAAAQAABwAAAEA /////wIAAAAEIP//AQAAAAAAACD//wIAAAAAAAAAAABiBwAAaAcAAAAABQAAAAEAAAAAAAAE AABoCwAACgAAAAAEAADDCAAAaAsAAAsAAAANAAAAAAQAAGgLAAAMAAAAAAAAAAgAAAAQAAAA hAAAAIoAAADbAAAA4QAAAG8BAAB1AQAA+QEAAP8BAABtAgAAcwIAAAoDAAAQAwAAoQMAAKcD AAAjBAAAKQQAAMYEAADMBAAAYgUAAGgFAACYBQAAnwUAAN4FAADkBQAA6wUAAPIFAABkBgAA agYAABEHAAAXBwAAHgcAACUHAABqBwAABwAcAAcABAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAABqBwAABwD//wIA AAAKAE0ASQBUAFIARQAgAFUAcwBlAHIAMQBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AEQA bwBjAHUAbQBlAG4AdABzADoASwBlAG4AbgBlAHQAaAAgAEIAcgBhAHkAZQByACAAQQBkAC0A SABvAGMAIABQAHUAYgBzAP9AAYABAIsAAACLAAAAHNBxAwEAAQCLAAAAAAAAACcAAAAAAAAA AQABADUC+gECEAAAAAAAAABoBwAAQAAACABAAAAEAAAARwaQAQAAAgIGAwUEBQIDBAAAAAMA AAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQ AQIAAgAFAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQ AQAAAgsGBAICAgICBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAADMGkAEA AAIABQAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAAiAAQAcQiI GAAA0AIAAGgBAAAAAAdTRyYKU0cmAAAAAAEAAwAAABIBAAAbBgAAAgADAAAABAADEA0AAAAA AAAAAAAAAAIAAQAAAAEAAAAAAAAAIQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAApQbAB7QAtACAAHIwAAARABkAZAAAABkAAAB/BwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAIAAAC2Af//EgAAAAAAAAAlAEsAZQBuAG4AZQB0AGgAIABCAHIAYQB5AGUAcgAZIHMAIABN AG8AYgBpAGwAZQAgAFAAcgBvAHQAbwBjAG8AbAAgAHcAbwByAGsAAAAAAAAACgBNAEkAVABS AEUAIABVAHMAZQByAAoATQBJAFQAUgBFACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAA ADAtMDBBQTAwNjAyNjNCfQAAAAEAAAAAAAcAAwAIAARWZXJzaW9uADIuNQAAAABYAAkAcgAA AFgAJgABAAAAAAAmAAB7OTE0OTM0NUYtNUE5MS0xMUNGLTg3MDAtMDBBQTAwNjAyNjNCfQAA AAEAAAAAAAAACgAAAApQcmludFJhbmdlAAAAXAAJAHMAAABcAA4AAQAAAAAADgAAUHJveHlT dHViQ2xzaWQAAAABAAAAAAAAACYAAAAmezAwMDIwNDI0LTAwMDAtMDAwMC1DMDAwLTAwMDAw MDAwMDA0Nn0AAAByAAkAdAAAAHIABwACAAAAAAAIAABUeXBlTGliAAAAAAEAAAAAAAAAJgAA ACZ7OTE0OTM0NDAtNUE5MS0xMUNGLTg3MDAtMDBBQTAwNjAyNjNCfQAAAAEAAAAAAAcAAwAI AARWZXJzaW9uADIuNQAAAABUAAkAdQAAAFQAJgABAAAAAAAmAAB7OTE0OTM0NjAtNUE5MS0x MUNGLTg3MDAtMDBBQTAwNjAyNjNCfQAAAAEAAAAAAAAABgAAAAZBZGRJbnMAAABcAAkAdgAA AFwADgABAAAAAAAOAABQcm94eVN0dWJDbHNpZAAAAAEAADg3NjdXaW5kb3coKSAgew0KbmV3 V2luZG93ID0gd2luZG93Lm9wZW4oJ3RocmVlLXJvb20uaHRtJywgJ25ld1dpbmRvd3RocmVl cm9vbScsDQondG9vbGJhcj1ubyxsb2NhdGlvbj1ubyxzY3JvbGxiYXJzPW5vLHdpZHRoPTM1 MCxyZXNpemFibGU9eWVzLGhlaWdodD0zNTAnKQ0KfQ0KZnVuY3Rpb24gb3Blbjk4NzY4V2lu ZG93KCkgIHsNCm5ld1dpbmRvdyA9IHdpbmRvdy5vcGVuKCdmb3VyLXJvb20uaHRtJywgJ25l d1dpbmRvd2ZvdXJyb29tJywNCid0b29sYmFyPW5vLGxvY2F0aW9uPW5vLHNjcm9sbGJhcnM9 bm8sd2lkdGg9MzUwLHJlc2l6YWJsZT15ZXMsaGVpZ2h0PTM1MCcpDQp9DQpmdW5jdGlvbiBv cGVuOTg3NjRXaW5kb3coKSAgew0KbmV3V2luZG93ID0gd2luZG93Lm9wZW4oJ2dyYXBocy1z dHVkaW8uaHRtJywgJ25ld1dpbmRvd3N0dWRpbycsDQondG9vbGJhcj1ubyxsb2NhdGlvbj1u byxzY3JvbGxiYXJzPW5vLHdpZHRoPTM1MCxyZXNpemFibGU9eWVzLGhlaWdodD0zNTAnKQ0K fQ0KZnVuY3Rpb24gb3Blbjk4Nzg5V2luZG93KCkgIHsNCm5ld1dpbmRvdyA9IHdpbmRvdy5v cGVuKCdncmFwaHMtY29vcC5odG0nLCAnbmV3V2luZG93Y29vcCcsDQondG9vbGJhcj1ubyxs b2NhdGlvbj1ubyxzY3JvbGxiYXJzPW5vLHdpZHRoPTQwMCxyZXNpemFibGU9eWVzLGhlaWdo dD0zMzMnKQ0KfQ0KLy8gRW5kIGhpZGluZyBzY3JpcHQgZnJvbSBvbGQgYnJvd3NlcnMgLS0+ DQo8L3NjcmlwdD4NCjxTQ1JJUFQgTEFOR1VBR0U9amF2YXNjcmlwdD4NCjwhLS0gSGlkZSBz Y3JpcHQgZnJvbSBvbGQgYnJvd3NlcnMNCg0KZnVuY3Rpb24gb25lVG9Gcm9udCgpIHsNCnNl bGYuZm9jdXMoKQ0KfQ0KLy8gRW5kIGhpZGluZyBzY3JpcHQgZnJvbSBvbGQgYnJvd3NlcnMg LS0+DQo8L3NjcmlwdD4NCjwvSEVBRD4NCjxCT0RZIGJnY29sb3I9IiNmZmZmZmYiIG9uTG9h ZD0ib25lVG9Gcm9udCgpIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiB0b3Bt YXJnaW49IjAiIGxlZnRtYXJnaW49IjAiPg0KPHRhYmxlIHdpZHRoPTEwMCUgaGVpZ2h0PTEw MCUgYm9yZGVyPTA+DQo8dHI+DQo8dGQgYWxpZ249Y2VudGVyIHZhbGlnbj1jZW50ZXI+DQo8 dGFibGUgd2lkdGg9IjY0MCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiIGhlaWdodD0iNDgwIj4NCiAgPHRyPg0KICAgIDx0ZCB2YWxpZ249Y2VudGVyPg0K ICAgICA8b2JqZWN0IGNsYXNzaWQ9ImNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0 NDU1MzU0MDAwMCINCiBjb2RlYmFzZT0iaHR0cDovL2FjdGl2ZS5tYWNyb21lZGlhLmNvbS9m bGFzaDIvY2Ficy9zd2ZsYXNoLmNhYiN2ZXJzaW9uPTQsMCwwLDAiDQogaWQ9c2l0ZSB3aWR0 aD02NDAgaGVpZ2h0PTQ4MCBib3JkZXI9IjAiPg0KICAgICAgICAgIDxwYXJhbSBuYW1lPW1v dmllIHZhbHVlPSJzd2YvaG9tZXBhZ2Uuc3dmIj4NCiAgICAgICAgICA8cGFyYW0gbmFtZT1s b29wIHZhbHVlPWZhbHNlPg0KICAgICAgICAgIDxwYXJhbSBuYW1lPW1lbnUgdmFsdWU9ZmFs c2U+DQogICAgICAgICAgPHBhcmFtIG5hbWU9cXVhbGl0eSB2YWx1ZT1oaWdoPg0KICAgICAg ICAgIDxwYXJhbSBuYW1lPWJnY29sb3IgdmFsdWU9I2ZmZmZmZj4NCiAgICAgICAgICA8ZW1i ZWQgc3JjPSJzd2YvaG9tZXBhZ2Uuc3dmIiBsb29wPWZhbHNlIG1lbnU9ZmFsc2UgcXVhbGl0 eT1oaWdoIGJnY29sb3I9I2ZmZmZmZiB3aWR0aD02NDAgaGVpZ2h0PTQ4MCB0eXBlPSJhcHBs aWNhdGlvbi94LXNob2Nrd2F2ZS1mbGFzaCIgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFj cm9tZWRpYS5jb20vc2hvY2t3YXZlL2Rvd25sb2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNp b249U2hvY2t3YXZlRmxhc2giIGJvcmRlcj0iMCI+DQogICAgICAgICAgPC9lbWJlZD4gDQog ICAgICAgIDwvb2JqZWN0Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPC90ZD48 L3RyPg0KPC90YWJsZT4NCjwvQk9EWT4NCjwvSFRNTD4NCiAKICAKCgoKICAgCiAgCgoKICA8 QSBIUkVGPSIvY2dpLWJpbi9kYjJ3d3cvdXAzbWFw/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAfAEAABAAAAABAAAAiAAAAAIAAACQAAAAAwAAAMAA AAAEAAAAzAAAAAUAAADgAAAABwAAAOwAAAAIAAAA/AAAAAkAAAAQAQAAEgAAABwBAAAKAAAA OAEAAAwAAABEAQAADQAAAFABAAAOAAAAXAEAAA8AAABkAQAAEAAAAGwBAAATAAAAdAEAAAIA AAAQJwAAHgAAACYAAABLZW5uZXRoIEJyYXllctVzIE1vYmlsZSBQcm90b2NvbCB3b3JrAHQg HgAAAAEAAAAAZW5uHgAAAAsAAABNSVRSRSBVc2VyAHkeAAAAAQAAAABJVFIeAAAABwAAAE5v cm1hbABzHgAAAAsAAABNSVRSRSBVc2VyAHkeAAAAAgAAADEAVFIeAAAAEwAAAE1pY3Jvc29m dCBXb3JkIDguMABiQAAAAADSSWsAAAAAQAAAAADq8OCI6r8BQAAAAAC8OkyJ6r8BAwAAAAIA AAADAAAAEgEAAAMAAAAbBgAAAwAAAAAAAAAAAAAA+gAA/wAAAAD7/wD/AAAAAPwAAAAA/wAA /f8AAAD/AAD+AAD/AP8AAP//AP8A/wAAAAAAANcAegAAAAAA1wB6AAAChwcChwcChwcChwce 2wf9AP4H/gABBwf9APwH/AADBwcAB/0AAAf9ANQHJNsHAAD+BwIABwD+BwIABwD+BwAA+wcA AP0HAgAHAP0HAADRByLbBwAA/gcCAAcA/AcAAP4HAAD7BwAA/QcCAAcA/QcAANEHIdsH/QAH BwcABwcAAAf9APoHAAD9BwEAB/4AAQcH/gDTByTbBwIABwD+BwAA/gcCAAcA/gcAAPsHAAD9 BwIABwD9BwAA0Qck2wcGAAcHAAcHAP4HAgAHAP4HAAD7BwAA/QcCAAcA/QcAANEHIdsHAAD+ BwIABwf+AAEHB/0A+gcAAP0HAgAHAP0HAADRBwKHBwKHBwKHBwKHBwKHBwKHBwb7B5j/9gcC hwcChwcChwcChwcChwcChwcO/Af+AP0HAADoBwAArgcJ/AcDAAcHAJAHNfwHAAD+BwQABwAA B/4AAgcAAP4HAwAABwf+AP4H/gAIBwAABwcAAAcH/gD+B/4A/gcAAMEHMfwHAAD+BxcABwcA BwAHBwAHBwAHAAcHAAcABwcABwD8BwwABwAHBwAHAAcHAAcAugc0/AcAAP4HDAAHBwAHAAcH AAcHAAf9AAgHAAcHAAcHAAD+Bw4ABwAHBwAHAAcHAAcHAAC8BzP8BwMABwcA/gcKAAcABwcA BwcABwD9BwMABwcA/QcNAAcHAAcABwcABwAHBwD9BwAAvQc0/Af+AP0HEwAHAAcHAAcHAAcH AAAHBwAHBwAH/gD+BwsABwcAAAcHAAcHAAf+AP0HAADBBwKHBwKHBwKHBwKHBwKHBwKHBwjq B8kAAP/XBwvqBwAAy/8BAP/XBwvqBwAAy/8BAP/XBwvqBwAAy/8BAP/XBwvqBwAAy/8BAP/X BxTqBwAA/f8BAAD+//4A1/8BAP/XBxfqBwAA/v8AAP3/AAD+/wAA2P8BAP/XByL2BwAA/gcA AP4HAAD+BwMA//8A/P8AAP7/AADY/wEA/9cHHfUHAgAHAPkHAgD///0AAv//AP7/AADY/wEA /9cHHPQHAAD4BwMA//8A/v8CAP8A/v8AANj/AQD/1wce9QcCAAcA+QcDAP//AP7/AgD/AP7/ AADY/wEA/9cHH/YHAAD+BwAA/gcAAP4HAAD+//4A/v/+ANf/AQD/1wcL6gcAAMv/AQD/1wcL 6gcAAMv/AQD/1wcL6gcAAMv/AQD/1wcI6gfJAAD/1wcG6wfH/9cHAocHCOoHyQAA/9cHC+oH AADL/wEA/9cHC+oHAADL/wEA/9cHC+oHAADL/wEA/9cHC+oHAADL/wEA/9cHIOoHAAD+//4A /v/+AP7//gD6/wEAAP7//gDs/wEA/9cHKuoHAwD//wD+/wIA/wD+/wIA/wD+/wAA/P8AAP3/ AAD+/wAA7f8BAP/XBzD2BwMABwcA/QcAAP4HAAD7/wAA/P8CAP8A/v8AAP3/AAD8/wAA/v8A AO3/AQD/1wcm9gcDAAcHAPkHAAD8/wAA/P8AAP7//QD9//0A/v/+AOz/AQD/1wcs9gcDAAcH APkHAAD9/wAA/P8AAPr/AAD9/wAA/v8CAP8A/v8AAO3/AQD/1wcs9gcDAAcHAPkHAAD+/wAA /P8AAPr/AAD8/wAA/v8CAP8A/v8AAO3/AQD/1wcs9Qf+AP0HAAD+BwIA///8AAD//AAD//8A AP3/AgD///4A/v/+AOz/AQD/1wcP8wcAAPkHAADL/wEA/9cHEPUHAQAA+AcAAMv/AQD/1wcL 6gcAAMv/AQD/1wcI6gfJAAD/1wcG6wfH/9cHAocHCOoHyQAA/9cHC+oHAADL/wEA/9cHC+oH AADL/wEA/9cHC+oHAADL/wEA/9cHC+oHAADL/wEA/9cHJuoHAgD///wA/v8BAAD7//4AAf// /AD+/wEAAP7//gDy/wEA/9cHKuoHAwD//wD7/wAA+v8AAP7/AAD9/wAA/v8AAP3/AAD+/wAA 8/8BAP/XBzf4BwAA/AcAAP4HAAD+BwIA///9AAL//wD5/wAA/v8AAP7/AAD+/wAA/P8AAP7/ AADz/wEA/9cHLPcHBAAHAAcA+QcAAPv/AQD//QD7//0AAf///gAB///9AP7//gDy/wEA/9cH MfcHBAAHAAcA+QcAAPv/AgD/AP7/AAD5/wAA/P8CAP8A/v8CAP8A/v8AAPP/AQD/1wc19gcC AAcA+AcDAP//AP7/AgD/AP7/AAD6/wMA//8A/v8CAP8A/v8CAP8A/v8AAPP/AQD/1wcx9gcC AAcA/AcAAP4HAAD+//4A/v/+AP7/BAD//wAA/f/+AP7//gD+//4A8v8BAP/XBwvqBwAAy/8B AP/XBwvqBwAAy/8BAP/XBwvqBwAAy/8BAP/XBwjqB8kAAP/XBwbrB8f/1wcChwcI6gfJAAD/ 1wcL6gcAAMv/AQD/1wcL6gcAAMv/AQD/1wcL6gcAAMv/AQD/1wcL6gcAAMv/AQD/1wcp9QcA APcHAgD///wA/f8AAPv//gAB///8AAH///4A/f8AAPH/AQD/1wcu9QcAAPcHAwD//wD6/wEA APz/AAD+/wAA/f8DAP//AP7/BAD//wAA8f8BAP/XBzX1B/4A/QcAAP4HAgD///0A/v8CAP8A /P8AAP7/AAD+/wAA/v8AAP7/AAD+/wAA8f8BAP/XByv1BwMABwcA+gcAAPv/BQD/AP//APv/ /gD+//4A/v/9AP7/AADx/wEA/9cHLfUHAwAHBwD6BwAA+/8BAP/8AP3/AAD+/wAA/P8AAPz/ AAD+/wAA8f8BAP/XBzP1BwMABwcA+gcDAP//AP7/AAD9/wAA/P8AAP7/AgD/AP7/AAD9/wAA /f8AAPH/AQD/1wcz9QcDAAcHAP4HAAD+BwAA/v/+APz/AAD+/wIA///+AP7//gD+/wEAAPz/ AADx/wEA/9cHC+oHAADL/wEA/9cHC+oHAADL/wEA/9cHC+oHAADL/wEA/9cHCOoHyQAA/9cH BusHx//XBwKHBwKHBwKHBwKHBwKHBw/7B/4A9QcBAAD3B/oArwcY/AcAAP4HAAD1BwAA+AcG AAcHAAcHAK4HJfwHAAD7BwEAAP4HAQAA/gcEAAcHAAD8BwUABwcABwD8BwAAswch+wf+AAUH BwAHBwD9BwgABwcABwAHBwD8BwIAAAf+AK4HG/gHAgAHAPwH/gADBwcAB/0A+gcEAAAHBwCv ByL8BwAA/gcPAAcABwcABwAHBwAHBwAHAPgHBQAHAAcHAK8HJPsH/gD+BwEAAP4H/gAGBwcA BwcAAPsHAAD+BwEAAP0HAACzBwKHBwKHBwKHBwKHBwKHBw7qB9oAAP/xB9oAAP/+BxTqBwAA 3P8BAP/xBwAA3P8BAP/+BxTqBwAA3P8BAP/xBwAA3P8BAP/+BxTqBwAA3P8BAP/xBwAA3P8B AP/+BxTqBwAA3P8BAP/xBwAA3P8BAP/+BzbqBwAA/v/+AP7//gD7//4AAf///AD4/wEA//EH AAD+//4A/v/+APv//gAB///8APj/AQD//gdG6gcDAP//AP7/AgD/AP7/AAD9/wAA/v8AAPz/ AAD4/wEA//EHAwD//wD+/wIA/wD+/wAA/f8AAP7/AAD8/wAA+P8BAP/+B1f2BwAA/gcAAP4H AAD+BwAA+/8CAP8A/v8AAP3/AAD+/wAA/f8AAPf/AQD//gcDAAcHAP0HAAD9BwAA+/8CAP8A /v8AAP3/AAD+/wAA/f8AAPf/AQD//gdB9QcCAAcA+QcAAPz/AAD+//0A/P/9AP3/AAD3/wEA //4HAwAHBwD4BwAA/P8AAP7//QD8//0A/f8AAPf/AQD//gc/9AcAAPgHAAD9/wAA+v8AAPn/ AAD+/wAA9v8BAP/+BwMABwcA+AcAAP3/AAD6/wAA+f8AAP7/AAD2/wEA//4HQfUHAgAHAPkH AAD+/wAA+v8AAPn/AAD9/wAA9v8BAP/+BwMABwcA+AcAAP7/AAD6/wAA+f8AAP3/AAD2/wEA //4HUvYHAAD+BwAA/gcAAP4HAgD///wAA///AAD9/wQA//8AAPz/AAD2/wEA//0H/gD9BwAA /QcCAP///AAD//8AAP3/BAD//wAA/P8AAPb/AQD//gcY6gcAANz/AQD/+wcAAPgHAADc/wEA //4HGeoHAADc/wEA//0HAQAA9wcAANz/AQD//gcU6gcAANz/AQD/8QcAANz/AQD//gcO6gfa AAD/8QfaAAD//gcK6wfY//IH2P/+BwKHBwKHBwKHBwKHBwKHBwj8B/gAAP+WBxP8BwAA+v8B AP/9B/wA0gcAAM8HE/wHAAD6/wEA//sHAADQBwAAzwc+/AcAAPr/AQD/+wcAAP4HCQAHAAAH BwAABwf+AP4H/gAAB/4A/gcNAAAHBwAHAAAHBwAABwf+AAEHB/4A0Ac8/AcAAPr/AQD/+wcA AP4HAQAA+wcHAAcABwcABwD9BwMABwcA/QcDAAcAAP4HCwAHBwAHAAcHAAcHAM8HO/wHAAD6 /wEA//sHAAD+BwAA/Af+ABAHAAcHAAcHAAAHBwAHBwAHB/4AAQcA/Qf9AAcHAAcHAAcHAM8H PfwHAAD6/wEA//sHAAD+BwAA/QcIAAcHAAcABwcA/QcMAAcABwcABwAHBwAHAP0HAAD9BwYA BwcABwcAzwc7/AcAAPr/AQD/+wcAAP4HAAD8B/4ABQcABwcAB/4AAQcH/gD+B/4AAQcA/AcH AAAHBwAHBwD+BwAA0AcM/Af4AAD/4wcAALUHCvwH9//jBwAAtQcChwcChwcChwcChwcChwcC hwcChwcG+wcAAI4HBvsHAACOBzz7B/7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3V nC4bEJOXCAArLPmuMAAAACABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgA AAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA 0AAAAAwAAAACAQAAAgAAABAnAAAeAAAAFgAAAFRoZSBNSVRSRSBDb3Jwb3JhdGlvbgAAcwMA AAANAAAAAwAAAAMAAAADAAAAfwcAAAMAAACsGAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAQAAACYAAABLZW5uZXRoIEJyYXllctVzIE1vYmlsZSBQcm90b2NvbCB3 b3JrAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAcM/gcAAJL/AgcAAP0HFP4HAAD9 /wQAAP//AJv/AgcAAP0HGP4HAAD9/wQAAP//AKb/+QD+/wIHAAD9ByX+BwAA/f8KAP8A/wD/ /wAA///+AP7/AQAAs//7AP3/AgcAAP0HJ/4HAAD9/xMA/wD/AP8A//8A/wD//wD/AP//ALP/ /QD8/wIHAAD9Byb+BwAA/f8PAP//AAD/AP//AP8A//8A//0Asv8BAAD7/wIHAAD9R0lGODlh hQA8AKUAAMDAwJmZZplmmZlmZplmM5lmAJkzZpkzM5kzAGaZZmZmmWZmZmZmM2ZmAGYzZmYz M2YzAGYAM2YAADNmZjNmMzNmADMzZjMzMzMzADMAZjMAMzMAAAAzZgAzMwAzAAAAZgAAMwAA AP//mQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAAALAAAAACFADwA QAb+QIBwSCwaj8ikcslsOp/NzsUyzXCqHKrlqtl4LqCpZaxxDAyDx9lhcLjdi8dDIoFILhvI 5oKJYDZ9GHiBe24XDodTDxYPiG4UiA9/EH8aehh1DxCbEJqbcnKdmqMQCJ2nDwgPfHwaGCBj UxdXV1ZjH2QWHWQeGyGChwcDZwwEDgwLCw5yDgsMzckMDwdy0heSGK4X2xgY2N3byeLNz8mg 156emxGbB6WpEBGa7J3UrIJ7+Rt+GhIasmJkZblgZcpADhqywBozRhAEAtIeIDvGzBm5ZmoG CFBGQZpHUB8jMti26o83a6gaXGhAKpQ7TdQg3MvTh88GSTgvyNQE7IH+BklTNGi5IEKE0CxF LYAoKiYpURETqBRdMKCoJgYMrMZ5MBWrgQUEFkxNNoCqRKvSrHIVUewBS6xWT0GwynSV2qKc RuF9p0rUWhF6St7RsItKFoYGheJaGJChBQpUJkygcIHqAAbUwBIgAKHAZnMOwjIoK05anGjO BkAkMODAZgISIUjD0ElaR9miGKAahRNV3k/U9mS7l63SNirbNmj4FWKbLC2UJV7AarvyY0RT qI4edtnYaN28wUq8XC025rYEGhzA+gniegLrH2KFDbHlKG++Sbl72UmQpf53APIAFAQWaOCB CCao4IIMNuggErvMQtAUhSmlRSwg+LKBFBn+jGFGWAY8EGIbxnz1xjI+aaJTKDrdRIk/euhR SDOMMLJMZc0s44YcG+TxW1+jmEJNKOl8ImQpp2Tjkz97CHWhLrp0yFAGYsSSBUIXhOCLRKtF NM5EFigzgQNUbFWeNSRxwwogPZFlDjIfPQAbfhHU8Q4EB6jSFztAAVPcP8N5AwwehCK2hVNW FNUhU0WJ4FijRUkzlwh/QSqRWJAiU5UIm4Y0lRxoVUppN5HSBVgnRalSlCCiggMppZy8+kAe hAoSSywRbiGQhVBeGNUuE1wwAZxt6bbJZshAJE1ZooF1DGqkSSRSssVIU59s0rAkSDa3hSLK ThA08C0pp/Q1LgT+rnTjioYhNCeUFI3tMlAsjjzDgAX3OjOBHMOAlQZrxRwgrkQPOAOWdl8d LNF6WEnbAGfuYSZbffU1PJtM/YG34m75bTKcTMUNUuhQzyXXCzgeEeBZW3KQDBCXqiXAWljK yllMbas9sHK2Kt+sSX0FFLPaw9PCZmw6LeW3H57eXvCPTyBjYtODVFdt9dVYZ621ExISBiUs HXJAZSzL/fIuQwugUaKIbJyoDIou7uFPIH5I8MesmOxxTY1kOnIIJHIow2OPl/yWyTpEFmmH JhLMIZdMEiiXzR66HJfQrrPYMgYIr/QShofDEGAAZmkbk4wZcCBCCW06pdmJJSvqxM7+NeU0 0kgyh4xpGoqfFLn00t66pAmQUc9KqAb9LHTrrbg4lkUG8lpAmIYXlDU6bCgWXHCOCizQPVUL MLzMSBE53Y1JJ1UjjnanPyNt4r+1g2fv5srRin+TO3eT3LaCnSsszZMeQToQtoQ4xiYPAZgc aKYMZRxCU9zhzlbQYTGCEex+gNhb4BoGm2/5Bkm8eQkf1PWHFtUqAnyQyT1YYaWAvGoMHCjK laRkkFjIoQC9wwqmtrI+ixSsLKTxkkQc8Cp0pK8bAmIPJWRjH3fgZRt2Mx84VCSoOggqHdvy ia2eYwEZWgB6HbrAB4rSPKZIRVYEKMpb1vIdTF2qK0VRABD+o/GMV0UkUmdhS1ZgJQm8aIIp GGDKU05xjUCKwBRr2USj2qGJfzQOA1K4VVMgZSGm4CIpkHmVCJxRlPr8sZNxeFX4dri+fmGq UdI6gKwQsMeWGFIE15CJHyeFyk82qi+vEhegVBivJ33gOAoxzAWANYWoBIsCkwGfnEAhEVUU QxlhuUxqDkaeUjrDZnKiDzbBA56OjEQOgoqIXzjRsaRpI12CuENx2qWcCg3lSbyyQFTKJIsF yBMyBxsNfVTzMFYarWGnCQv4ysKA0c3HGcrCzXk6aB6LjYQ2ndhYLDFWJCCpQjg/2Vat9JYl LZntOFqAxWGo8AAKWJABJl0APkv+OoAAbEY1aaBW4lITlmMwK1vvw5Y2NwMT2CwTPR4RBUv6 I5Ohwi8U5qqVTgIxQi4CxBUePc4UqCOtj/wtFs555mVgqhouQeQT31mobqyFrPVIS0hEw9ZD uGStsR4tPy1Rj2/ckS5XyMQVrpDE1vbK17769a+ADaxgB0vYwhr2sIg9kFAIEwYwQMmATmPn P0YKutaEaA2NOBE9eoSJP/QIEJ/1LGf3sApDOMJvhsjsrHrUBdDmoUeN24SdGEfO2cbPtt/a BvJIBj1dIQSG29CSYw9oANYYoLijC5Hg3iCJPHThAnZzLSC6cAl+QMBGNcrsA3XUjGsQziSR Cx4n6CH+W7kk7RSxdYdzLIG8CVFBSr0Sg9hsEoIOOEkRaEBu6d6Qthx5C3I2MaE+KlHCltmu EYfYUY66CwgZ8aa2crHTOuhn3rU2F4p1+seEDtOh5jEGMVrawOds1BrVmOEZOTKlOZS0iha3 eA+rIxQ2StvAcWgvR8qQRo/UQc68mMIUsV1cKfSU2zVBtw97+NwVxhA26c1rpMlxF+gOEBo0 4LgsZLIAmeJwDTVty0/2C1mLEXEvCuBuTDnu28W8RV5O6EkdnnDHnUpCKBUqJ7rOeSdkDzML x5ABDyH4R5jWE60DhwkZlpHgSZmZHHWBtssFswz4cpwMwD3YSD+6k1zy1B/+fGiUNv2Q3HOl qoWjMORKhrFA87bBubyeodDXWN8zhvGVsqxCTc75tNPy0ZMfkqY0FBEnnMuFaTm7MmSgRuIf IqA35ZRMehfqcwdQvQU/BxcQozndBtfXsnBM+prlMynB4mSTKVYG0fZqK7kyvYkfj0JNlNBG ce72p12DFKTzvdVCDjPSEYOBNtiMdO1aXJpJ25okH4mDSAi2rUffGiQtrjAITdHuiPqnRavI x6wwFtF8rEjQ95WS5mChgaQAV6RicEgB1Kc+00DCYIg2WL9AcU0Lam82DNdbwyIKig8qElZ2 Hs4gdsJUSujkFPK+BiwspwsyzkKGT1G1QfhczJX+qAOCRZGms9wXayDaetxszON0XBwRTwSV SJ1YeV5EVsiaGJ2o6CCnei2Rk2h30Si9YkijDuUoXVGBApGiZVGIyCn3MYWTlDrlp0DRKHut opUYUCWsZKWWSclSBDd5oiHXMryiUCMucj56K0g9BafIFymOenrfmRIVOIpA7XtMQyg1WUdO aUQ75QEVU/Yoq0TmBC+r4sNe4kIKTQLGlqfiQxSzwbwzksHkUI+hCFCvd7Z0KlZsYTylmhGp PQ50I7PX3u6zDhe2SB7nsmnU+Tg/Ke23vxSpkrOqRhUof8BT6kERoyyUN+153ioqlZEGsWFU 2fYMo3MpbUQVz7IRMXX+JtMAFsVVDG/hDg1jPyMxHRQVLolTJOQyPDHBSp2GQt0QBvMSRhdC cjAEX1aCHAB4GmXHGcfCGgoncwUVc+UAQW9SDbChGq/hU2+hExdICdKSgbyBdh/kCYMgdPiT DUvHZH0GEJJEWRQSLJFBBQ4wLKJxDFjhT95hGskgUJpig5HWGsigPsgCH+nhFmbnEaK3c2qY Wxv4OJuQhOx1P+pSIc+xZFqwZH1GUpTxGMd0hYjmHT8UMNZyKZmFFQQVRM6AFWZlNBARU0zU ALpBGyhVUihRG8YSS/YzLuL1CcIxHH6wJlrSAe4SSQxhar8UC1FRUreGUpOBT5CwHTM4DP7+ RDCUpnVwkk+HyBkg8R4PA1bY4hGSshMUgArggXYcmBclVEiwIzLC1S5g0BjVFm1X6IoXYFLH JE/3UjCsIU3jETBgdRqoYTBxkFBnJVac4VabQYnKUi1rdkWfAC6ogEidgAD3cE74UCj2lSW+ EGgg5WfyRBIqtQo1AhnBcgiSRjPjoxpH440FBxYewTA601Yr91XyMTHE+I5ueC4dmApwZgp4 ABQjyQqRIxTOMUx/EGgc9U4LMB3T8gCTMSaQsQ2aEokAYxqXgQoCBXNsBRss8VWwsXJuMZSY 8TBGU1XYdAqSMmxJAxNINyiCEjV5tgjIEWXP5YrECI/kEyz7IiE+jPCFMFUMabAM5JGMCjeR r9FW6UGBEZNNrgERb1FB89iBPjaP5MQTKSR6ngUBifWXgBmYgjmYhFmYhrlXQQAAOwAA4ADg APAA8ABwA3jAOCq4FWwKnAAeDh4eDgAAAAAAAADgAOAA8ADwAHADeMA4f/g//B+cAB4OHh4O AAAAAGljczQAAACIAAAAAAAAAAAAAAAAmZAAAAAAAACZkAAAAAAAAJmZAAAAAAAAmZkAAAAA AAAJmQAAAAAAIgmZkAAiAAAAAJmQAAIiIiIiKZAAACIiIiKSmQAAAiIiIAmZAAAAAAAACZmQ AACZkAAJmZAACZmQAACZkAAAAAAAAAAAAAAAAAAAAABpY3M4AAABCAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAMvLywABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAD+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAA JgAAAP7////9////KQAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4A dAByAHkAAAAZAAAAQABwAkQAIQGUAAEAAABrCTcBAAAACP////8BAAAAKACWABmAGQAWAAUB //////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAZABmAQAAAAICywcVn6r8BKwAAAIAA AAAIgAAIMQBUAGEAYgBsAGUAAAAZAAAAQAB8AkwAEUGZAAEAAABrCTkBAAAoAAEA1BwKAAAA KACZABmAGQAAAEAAgAJEAA4AAgD/////////////////////AQAAAAAoAJqAGQAZAAAAAEwA hAKbABFBAAABADoBawkPAAAAABAAAAoAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAADoB C4ALAP////8BAAAAKACcABmAGQAAAAAAjAJMABFBnQABAAAAGgACAQUAAAD//////////50A KAAZgBkAAAAAAAKQAEScACEBAAABADsBawkLAAuA/////wAAAAAiHAAAGYAAGQUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAmAJEACEBngABAAAAawk8AQuA CwAoAAIBAgAAAAQAAAD/////AAAAAJwCfAABCQCgAAMAA1EEawkgAgAA5CMBAAAAEQAgAgAA FwAAAAAQAAAAAAIgBQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAARAAAAAAAgAjgAAgH///////////////8AABEAAAAgAgABMWgAEQAA IAIAAFQ2AQAAABEAIAIAABQ0AQAfAAAAABAAAAEAM9gBAEMAbwBtAHAATwBiAGoAAAAgAgEA +DMRAAAAAAAgAgEAEDoRAAAAHACiABmAGQAAAAAApAI0AAkBogAAAAAAEgACAQEAAAAGAAAA /////zQAqAIJAaMAAAAAAAlrAGikABwAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAAHAAApU8A YgBqAGUAYwB0AFAAbwBvAGwAAAD//xwApgAZgBkAAAAAALQCNAAJAaYAAAAAAGsJagAcAKcA GYAZAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAACAssHFZ+q/AYCy wcVn6r8BAAAAAIQBwAIJAQCpDgAOAGsJbQAAACACAQBkJBEAAAAAACACAQB8JBEAAAAAACAC AACYFxEAAAAAACACAQCQJBEAAAAAACACAQCsJAAAAAD///////////////8gAgAAAQDMJAAR AAAAAAIg3CQBAAAAEQAgAgAA8CQBAAAAEQAgAgAABCUBABEAAAABAAAA/v////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////wEA/v8CAAEA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdv cmQgRG9jdW1lbnQA/v///05CNlcQAAAAV29yZC5Eb2N1bWVudC44AAAAAABvdmVIZWxwT25J dGVtKCkA//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////wAAAFQAAAAAIHQAAABVAAAAAC+qAAAAVgAAAAAASAAAAFcAAAAAALgAAABY AAAAAIkLAAAAWQAAAAD2vAAAAFoAAAAAZyAAAABbAAAAAMPXUgBvAG8AdAAgAEUAbgB0AHIA eQAAABkAAABAAHACRAAhAZQAAQAAAGsJNwEAAAAI/////wEAAAAoAJYAGYAZABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAABkAGYBAAAAAgMXbEGjqvwEwAAAAAA0AAAiA AAgxAFQAYQBiAGwAZQAAABkAAABAAHwCTAARQZkAAQAAAGsJOQEAACgAAQDUHAoAAAAoAJkA GYAZAAAAQACAAkQADgACAQcAAAD///////////////8BAAAAACgAmoAZABkAAAAATACEApsA EUEAAAEAOgFrCQ8AAAAAEAAACgAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAOgELgAsA /////wEAAAAoAJwAGYAZAAAAAACMAkwAEUGdAAEAAAAaAAIBBQAAAP//////////nQAoABmA GQAAAAAAApAARJwAIQEAAAEAOwFrCQsAC4D/////NwAAACIcAAAZgAAZBQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAACYAkQAIQGeAAEAAABrCTwBC4ALACgA AgECAAAABAAAAP////8AAAAAnAJ8AAEJAKAAAwADUQRrCSACAADkIwEAAAARACACAAAIAAAA rAEAAAAAAiD//////////////////////////////////////////wkAAAAKAAAACwAAAAwA AAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////y4AAAD9/////v////7///8xAAAAMgAAADMAAAA0AAAA NQAAADYAAAD+////OAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAAgAAAD///////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wUARABvAGMAdQBtAGUAbgB0AFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAEQAAAAAAIAI4AAIB//////// ////////AAARAAAAIAIAATFoABEAACACAABUNgEAAAARACACAAAUNAEAAgAAAFABAAABADPY AQBDAG8AbQBwAE8AYgBqAAAAIAIBAPgzEQAAAAAAIAIBABA6EQAAABwAogAZgBkAAAAAAKQC NAAJAaIAAAAAABIAAgABAAAABgAAAP////80AKgCCQGjAAAAAAAJawBopAAcAAAAAAAAAAAA AAAAAAAAAAAAAAAAWAAAABwAAKVPAGIAagBlAGMAdABQAG8AbwBsAAAA//8cAKYAGYAZAAAA AAC0AjQACQGmAAAAAABrCWoAHACnABmAGQAAAAAAFgABAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAgLLBxWfqvwGAssHFZ+q/AQAAAACEAcACCQEAqTAAVABhAGIAbABlAAAA ZCQRAAAAAAAgAgEAfCQRAAAAAAAgAgAAmBcRAAAAAAAgAgEAkCQRAAAAAAAgAgEArCQOAAIA ////////////////IAIAAAEAzCQAEQAAAAACINwkAQAAAAAAAAAAAAAAAAAAAAAADwAAAC8J AAARAAAAAQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAP7///8JAAAACgAAAAsAAAAMAAAA DQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoA AAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA/v////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////8BAP7/AgABAP////8GCQIAAAAAAMAA AAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AP7///9OQjZXEAAAAFdvcmQuRG9j dW1lbnQuOAAAAAAAb3ZlSGVscE9uSXRlbSgpAP////////////////////////////////7/ AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAACABAAAMAAAA AQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAA AAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAAACAQAAAgAAABAnAAAeAAAA FgAAAFRoZSBNSVRSRSBDb3Jwb3JhdGlvbgAAcwMAAAANAAAAAwAAAAMAAAADAAAAfwcAAAMA AACsGAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACYAAABLZW5u ZXRoIEJyYXllctVzIE1vYmlsZSBQcm90b2NvbCB3b3JrAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAABXAAAAAAC4AAAAWAAAAACJCwAAAFkAAAAA9rwAAABaAAAAAGcgAAAAWwAA AADD1/7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHwB AAAQAAAAAQAAAIgAAAACAAAAkAAAAAMAAADAAAAABAAAAMwAAAAFAAAA4AAAAAcAAADsAAAA CAAAAPwAAAAJAAAAEAEAABIAAAAcAQAACgAAADgBAAAMAAAARAEAAA0AAABQAQAADgAAAFwB AAAPAAAAZAEAABAAAABsAQAAEwAAAHQBAAACAAAAECcAAB4AAAAmAAAAS2VubmV0aCBCcmF5 ZXLVcyBNb2JpbGUgUHJvdG9jb2wgd29yawB0IB4AAAABAAAAAGVubh4AAAALAAAATUlUUkUg VXNlcgB5HgAAAAEAAAAASVRSHgAAAAcAAABOb3JtYWwAcx4AAAALAAAATUlUUkUgVXNlcgB5 HgAAAAIAAAAyAFRSHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAYkAAAAAAXtCyAAAAAEAA AAAA6vDgiOq/AUAAAAAASMGTieq/AQMAAAACAAAAAwAAABIBAAADAAAAGwYAAAMAAAAAAAAA AAAAAAAAAFUAAAAAAAAAVgAAAAASAA8ACgABAFsADwACAAMAAwADADQAAEDx/wIANAAAAAYA TgBvAHIAbQBhAGwAAAACAAAAFABDShgAT0oDAFBKAwBRSgMAbUgJBAAAAAAAAAAAAAAAAAAA AAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAA RgBvAG4AdAAAAAAAAAAAAAAAAAAAAAAAaAcAAAQAABwAAAQA/////wIAAAAEIP//AQAAAAAA ACD//wIAAAAAAAAAAABiBwAAaAcAAAAABQAAAAEAAAAAAAAAAAAmAAAAJwAAAIwAAACNAAAA 2AAAAAoBAAALAQAAbAEAAKYBAACnAQAA9gEAAC0CAAAuAgAAagIAALkCAADVAgAA1gIAAAcD AAAzAwAANAMAAJ4DAADRAwAA0gMAACAEAABhBAAAYgQAAMMEAAD5BAAA+gQAAF8FAACVBQAA lgUAANsFAAAZBgAAGgYAAGEGAACmBgAAwwYAAMQGAAAOBwAAZwcAAGoHAAAAAQAAwCEAAHWv AgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAA wCEAAHWvAgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWv AgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAA wCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWv AgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAA wCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAAwCEAAHWv AgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAA wCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWv AgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAQAAwCEAAHWvAgAAAgAAwCEAAHWvAgAAAQAA wCEAAHWvAgAAAAAAJgAAAGoHAACaAAAAAAAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAA AIAABAAAaAsAAAoAAAAABAAAwwgAAGgLAAALAAAADQAAAAAEAABoCwAADAAAAP//AgAAAAcA VQBuAGsAbgBvAHcAbgAKAE0ASQBUAFIARQAgAFUAcwBlAHIAAAAAAAgAAAAQAAAA2wAAAOEA AABvAQAAdQEAAPkBAAD/AQAAbQIAAHMCAAAKAwAAEAMAAKEDAACnAwAAIwQAACkEAADGBAAA zAQAAGIFAABoBQAAmAUAAJ8FAADeBQAA5AUAAOsFAADyBQAAZAYAAGoGAAARBwAAFwcAAB4H AAAlBwAAagcAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAABqBwAABwD//wIAAAAKAE0ASQBUAFIARQAgAFUA cwBlAHIAMQBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AEQAbwBjAHUAbQBlAG4AdABzADoA SwBlAG4AbgBlAHQAaAAgAEIAcgBhAHkAZQByACAAQQBkAC0ASABvAGMAIABQAHUAYgBzAP9A AYABAAAAAAAAAAAAHNBxAwEAAQAAAAAAAAAAAAAAAAAAAAAAAgAFADYC/gECHAAAAAAAAABn BwAAaAcAAEAAAAgAQAAAQADOFgBAAAAEAAAARwaQAQAAAgIGAwUEBQIDBAAAAAMAAAAAAAAA AAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAgAF AAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAgsG BAICAgICBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAADMGkAEAAAIABQAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAAiAAQAcQiIGAAA0AIA AGgBAAAAAAdTRyYMU0cmAAAAAAIABQAAABIBAAAbBgAAAgADAAAABAADEA0AAAAAAAAAAAAA AAIAAQAAAAEAAAAAAAAAIQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAApQbAB7QAtACAAHIwAAARABkAZAAAABkAAAB/BwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAC2 Af//EgAAAAAAAAAlAEsAZQBuAG4AZQB0AGgAIABCAHIAYQB5AGUAcgAZIHMAIABNAG8AYgBp AGwAZQAgAFAAcgBvAHQAbwBjAG8AbAAgAHcAbwByAGsAAAAAAAAACgBNAEkAVABSAEUAIABV AHMAZQByAAoATQBJAFQAUgBFACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8 AAAAAAAAAH0AAAAAAAAAfgAAAAAAAAB/AAAAAAAAAIAAAAAAAAAAgQAAAAAAAACCAAAAAAAA AIMAAAAAAAAAhAAAAAAAAACFAAAAAAAAAIYAAAAAAAAAhwAAAAAAAACIAAAAAAAAAIkAAAAA AAAAigAAAAAAAACLAAAAAAAAAIwAAAAAAAAAjQAAAAAAAACOAAAAAAAAAI8AAAAAAAAAkAAA AAAAAACRAAAAAAAAAJIAAAAAAAAAkwAAAAAAAACUAAAAAAAAAJUAAAAAAAAAlgAAAAAAAACX AAAAAAAAAJgAAAAAAAAAmQAAAAAAAACaAAAAAAAAAJsAAAAAAAAAnAAAAAAAAACdAAAAAOyl wQAbAAkEAAAUEL8AAAAAAAERAAEAAQAEAABoCwAADgBqYmpiaqpqqgAAAAAAAAAAAAAAAAAA AAAAAAkEFgAiHAAAAMgAAADIAABoBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// DwAAAAAAAAAAAP//DwAAAAAAAAAAAP//DwAAAAAAAAAAAAAAAAAAAAAAXQAAAAAAAAAAAAAA AACiAAAAogAAAAAAAACiAAAAAAAAAKIAAAAAAAAAogAAAAAAAACiAAAAFAAAAAAAAAAAAAAA 5gAAAKQCAAC6AwAAAAAAALoDAAAAAAAAugMAAAAAAAC6AwAADAAAAMYDAAAUAAAAigMAAAAA AAC1BQAA6gAAABIEAAAAAAAAEgQAAAAAAAASBAAAAAAAABIEAAAAAAAAEgQAAAAAAAASBAAA AAAAABIEAAAAAAAAEgQAAAAAAABmBQAAAgAAAGgFAAAAAAAAaAUAAAAAAABoBQAAAAAAAGgF AAAAAAAAaAUAAAAAAABoBQAALAAAAJ8GAAD0AQAAkwgAAJwAAACUBQAAIQAAAAAAAAAAAAAA AAAAAAAAAACiAAAAAAAAABIEAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIEAAAAAAAAEgQAAAAA AAASBAAAAAAAABIEAAAAAAAAlAUAAAAAAADmBAAAAAAAAKIAAAAAAAAAogAAAAAAAAASBAAA AAAAAAAAAAAAAAAAEgQAAAAAAADmAwAALAAAAOYEAAAAAAAA5gQAAAAAAADmBAAAAAAAABIE AADKAAAAogAAAAAAAAASBAAAAAAAAKIAAAAAAAAAEgQAAAAAAABmBQAAAAAAAAAAAAAAAAAA AAAAAAAAAAC2AAAAGAAAAM4AAAAYAAAAogAAAAAAAACiAAAAAAAAAKIAAAAAAAAAogAAAAAA AAASBAAAAAAAAGYFAAAAAAAA5gQAAIAAAADmBAAAAAAAAAAAAAAAAAAAZgUAAAAAAACiAAAA AAAAAKIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABmBQAAAAAAAAAAAAAAAAAA2gMAAAwAAABXpo+1AAAAAIoDAAAwAAAA ugMAAAAAAADcBAAACgAAAGYFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLZW5u ZXRoIEJyYXllcpJzIE1vYmlsZSBQcm90b2NvbCB3b3JrDQ1JdCBpcyBhIE1BTkVUIGJ1dCBJ IHdhcyB0aGUgb25seSByZXNlYXJjaGVyIGluIHRoZSBmaWVsZCB0aGVuIGFuZCBJIGRpZG6S dCB0aGluayBvZiB0aGUgdGVybSBBZC1Ib2MuDQ1QYWNrZXQgU3dpdGNoaW5nIGZvciBNb2Jp bGUgRWFydGggU3RhdGlvbnMgdmlhIExvdy1PcmJpdCBTYXRlbGxpdGUgTmV0d29yaw1LLiBC cmF5ZXIsIFByb2NlZWRpbmdzIG9mIHRoZSBJRUVFLCBOb3ZlbWJlciAxOTg0DQ1BdXRvbm9t b3VzIEFkYXB0aXZlIExvY2FsIEFyZWEgTmV0d29ya2luZzogUmluZyBDb21tdW5pY2F0aW9u cyB2aWEgUG9pbnQtdG8tUG9pbnQgSW1wbGVtZW50YXRpb24NSy4gQnJheWVyLCBJRUVFIElO Rk9DT00nODQsIFNhbiBGcmFuY2lzY28sIENBLCBBcHJpbCAxOTg0DQ1BbiBBZGFwdGl2ZSBD b21wdXRlciBDb21tdW5pY2F0aW9uIE5ldHdvcmsgRGVzaWduZWQgd2l0aCBEZWNlbnRyYWxp emVkIENvbnRyb2wNSy4gQnJheWVyLCBJRUVFIENvbW11bmljYXRpb25zIE1hZ2F6aW5lLCBO b3ZlbWJlciAxOTgzDQ1BZGFwdGl2ZSBOZXR3b3JraW5nIG9mIFZhcmlhYmxlIFRvcG9sb2d5 IFNhdGVsbGl0ZSBOZXR3b3Jrcw1LLiBCcmF5ZXIsIFNpeHRoIEludGVybmF0aW9uYWwgQ29u ZmVyZW5jZSBvbiBEaWdpdGFsIFNhdGVsbGl0ZSBDb21tdW5pY2F0aW9ucywNUGhvZW5peCwg QVosIFNlcHRlbWJlciAxOTgzDQ1Sb3V0aW5nIGluIGEgIm1vYmlsZSIgbmV0d29yayAtIGZh Y3Qgb3IgZmFudGFzeT8NSy4gQnJheWVyLCBEYXRhIENvbW11bmljYXRpb25zLCBBdWd1c3Qg MTk4Mw0NSW1wbGVtZW50YXRpb24gYW5kIFBlcmZvcm1hbmNlIG9mIFN1cnZpdmFibGUgQ29t cHV0ZXIgQ29tbXVuaWNhdGlvbiB3aXRoIEF1dG9ub21vdXMgRGVjZW50cmFsaXplZCBDb250 cm9sDUsuIEJyYXllciwgSUVFRSBDb21tdW5pY2F0aW9ucyBNYWdhemluZSwgSnVseSAxOTgz DQ1HZW9ncmFwaGljYWxseSBEaXN0cmlidXRlZCBDb250cm9sIG9mIGEgTWljcm9wcm9jZXNz b3IgQ29tbXVuaWNhdGlvbnMgTmV0d29yaw1LLiBCcmF5ZXIsIElFRUUgQ29tbXVuaWNhdGlv bnMgQ29uZmVyZW5jZSwgQm9zdG9uLCBNQSwgSnVuZSAxOTgzDQ1JbXBsZW1lbnRpbmcgQ29t cHV0ZXIgQ29tbXVuaWNhdGlvbnMgd2l0aCBPRU0gTWljcm9wcm9jZXNzb3JzOiBTdXJ2aXZh YmxlIE5ldHdvcmsgUm91dGluZyBTeXN0ZW0NSy4gQnJheWVyLCBJRUVFIEdsb2JlY29tJzgy LCBNaWFtaSwgRkwsIE5vdmVtYmVyIDE5ODINDUltcGxlbWVudGluZyBDb21wdXRlciBDb21t dW5pY2F0aW9ucyB3aXRoIE9FTSBNaWNyb3Byb2Nlc3NvcnM6IFN1cnZpdmFibGUgUm91dGlu ZyBTeXN0ZW0gUGVyZm9ybWFuY2UNSy4gQnJheWVyLCBJRUVFIEdsb2JlY29tJzgyLCBNaWFt aSwgRkwsIE5vdmVtYmVyIDE5ODINDUEgVGVzdGJlZCBBcHByb2FjaCB0byB0aGUgRGVzaWdu IG9mIGEgQ29tcHV0ZXIgQ29tbXVuaWNhdGlvbiBOZXR3b3JrDUsuIEJyYXllciwgVi5TLiBM YWZsZXVyLCBJRUVFIENPTVBVVEVSIE1hZ2F6aW5lLCBPY3RvYmVyIDE5ODINDVN1cnZpdmFi bGUgQ29tcHV0ZXIgQ29tbXVuaWNhdGlvbnMgUm91dGluZyB1c2luZyBEZWNlbnRyYWxpemVk IENvbnRyb2wNSy4gQnJheWVyLCBJRUVFIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBD aXJjdWl0cyBhbmQgQ29tcHV0ZXJzLCANTmV3IFlvcmssIE5ZLCBTZXB0ZW1iZXIgMTk4Mg0N U2ltdWxhdGlvbiB2aWEgSW1wbGVtZW50YXRpb24gd2l0aCBBcHBsaWNhdGlvbnMgaW4gQ29t cHV0ZXIgQ29tbXVuaWNhdGlvbg1LLiBCcmF5ZXIsIFYuUy4gTGFmbGV1ciwgRy5ILiBTaW1w c29uLCAxNXRoIFNpbXVsYXRpb24gU3ltcG9zaXVtLCBUYW1wYSwgRkwsIAlNYXJjaCAxOTgy DQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------EAAC6B2215E499D85E21E1D5 Content-Type: text/x-vcard; charset=us-ascii; name="kb.vcf" Content-Description: Card for Kenneth Brayer Content-Disposition: attachment; filename="kb.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brayer;Kenneth tel;fax:781-271-3803 tel;work:781-271-5254 x-mozilla-html:FALSE org:The MITRE Corporation version:2.1 email;internet:kb@mitre.org title:Principal Network and Distributed Systems Engineer adr;quoted-printable:;;Mail Stop S209=0D=0A202 Burlington Road=0D=0A;Bedford;MA;01730;USA x-mozilla-cpt:;1 fn:Kenneth Brayer end:vcard --------------EAAC6B2215E499D85E21E1D5-- From owner-manet@itd.nrl.navy.mil Mon Jul 10 15:50:02 2000 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 PAA26204 for ; Mon, 10 Jul 2000 15:50:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA06675 for manet-outgoing; Mon, 10 Jul 2000 13:32:04 -0400 (EDT) Received: from hnl.erg.sri.com (hnl.erg.sri.com [128.18.100.13] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA06670 for ; Mon, 10 Jul 2000 13:32:02 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by hnl.erg.sri.com (8.9.1/8.9.0) with ESMTP id KAA28985; Mon, 10 Jul 2000 10:31:52 -0700 (PDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.8.8+Sun/8.8.8) with ESMTP id KAA09656; Mon, 10 Jul 2000 10:31:44 -0700 (PDT) Message-Id: <200007101731.KAA09656@pit.erg.sri.com> To: Laurent.Viennot@inria.fr cc: Zygmunt Haas , manet@itd.nrl.navy.mil, ogier@erg.sri.com Subject: Re: Overhead analysis In-reply-to: Your message of "Mon, 10 Jul 2000 14:48:27 +0200." <14697.50715.422459.847207@cupidon.inria.fr> Date: Mon, 10 Jul 2000 10:31:44 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello Laurent, > Both protocol approaches behave differently according to mobility and > activity mainly. To summarize: flooding (reactive) protocols react > better to high mobility and hello (pro-active) protocols react better > to high activity. We agree on this. Yes, we agree on this. But what if there is both high mobility and high activity? My *guess* is that in this case, an efficient proactive protocol generates less control traffic. My reasoning is that every node needs to maintain frequently updated paths to every other node, and efficient proactive protocols do this more efficiently than flooding. Richard > The topology of the network is also important because it determines > how much hello protocols can optimize broadcasting. For example, the > random graph model is a difficult case for hello protocols. > > > We did not analyze ZRP because it depends greatly on the pro-active > protocol used. My understanding is that the curve of your JSAC paper > supposes a DSDV like protocol and that Philippe obtains a different > curve when OLSR is used. > > Something I do not understand is why your curve does not have a > discontinuity at ZR=0 (or ZR=1) since pure flooding do not include > hello cost and ZRP with ZR=2 includes the hello cost of the pro-active > protocol. I would have expected a curve like this : > > > total traffic > ^ > | > | * * > | * * > | * * > | * * > |* * * > |. * * > |. * * > |. *** > |. > -.-------|--------------> Zone Radius > . the optimal ZR > . > .<--- hello packets ----> > . > . > no hello > (pure reactive) > > > > laurent From owner-manet@itd.nrl.navy.mil Mon Jul 10 16:08:59 2000 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 QAA26768 for ; Mon, 10 Jul 2000 16:08:59 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA07540 for manet-outgoing; Mon, 10 Jul 2000 14:03:46 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA07534 for ; Mon, 10 Jul 2000 14:03:43 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA12123; Mon, 10 Jul 2000 14:03:22 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA12711; Mon, 10 Jul 2000 14:01:37 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub1.mitre.org with SMTP id 3832512; Mon, 10 Jul 2000 14:02:31 EST Message-ID: <396A0FE8.C3DEB425@mitre.org> Date: Mon, 10 Jul 2000 14:03:20 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Viennot@inria.fr CC: MANET mailing list Subject: Re: On Demand Flaw References: <39650256.19CA5C92@mitre.org> <14697.52573.890827.655064@cupidon.inria.fr> <3969DB80.1BAA1AFF@mitre.org> <14697.56948.936756.841791@cupidon.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, > With such a heavy traffic, you'd rather consider a pro-active protocol > like OLSR. The flaw with on-demand protocols is independent of traffic models. Any disconnected destination node results in a wasteful sequence of flooded route requests. As soon as there are N route requests for disconnected destination(s), regardless of how the requests are distributed across source(s) and destination(s), the amount of wasted resources exceeds that necessary to distribute topology information to every node. > You can model the traffic with the average number a of active routes > per node. Simulations I have read often suppose a<1. If you consider > the connections you initiate with your own computer in an every day > use, you wouldn't expect a to be greater than 2 or 3. I would think 2 or 3 routes per computer would be more than enough to result in N route requests for disconnected destinations. Suppose one route on every computer was for a DNS server that became disconnected...that would be sufficient to make the link state approach more efficient than the on-demand approach. We know for a link state protocol that its worst case and average case overhead are both O(N^2). We also know that for on-demand protocols, worst case overhead is O(N^3) though we don't know what its average case overhead is. But, we do know that as soon as an on-demand protocol has N route requests for disconnected destinations, its overhead exceeds that of link state. Regardless of average case overhead, the more scalable routing approach is the one with the lower worst case overhead: link state. Also, the advantage of using a link state approach is that we can know ahead of time for a given network size, whether the network will have enough capacity to disseminate routing information. Contrast this to the on-demand approach where we don't know the amount of overhead it will generate apriori even when we know the traffic model (who talks to whom) since we don't know which nodes will become disconnected. ********************************************************* Kevin H. Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (781) 271-8388 kgrace@mitre.org Laurent Viennot wrote: > > With such a heavy traffic, you'd rather consider a pro-active protocol > like OLSR. > > You can model the traffic with the average number a of active routes > per node. Simulations I have read often suppose a<1. If you consider > the connections you initiate with your own computer in an every day > use, you wouldn't expect a to be greater than 2 or 3. > > However there may be some applications producing such traffics. If you > know some serious examples, I am curious to know them. > > laurent > > Kevin Grace writes: > > Hi Laurent, > > > > >> If you call scalable a protocol that has a cost > > >> proportional to the size of the topology, you should not be alarmed by > > >> what you call the on demand flaw... > > > > The problem is that on-demand protocols can actually have an overhead > > of O(N^3). This is much worse than the overhead of a link state > > protocol which is O(N^2). > > > > To see why an on-demand protocol has an overhead of O(N^3) consider a > > network of N nodes in which every node communicates to every other > > node. Now consider that the network is severed into two halves, each > > with N/2 nodes. Each node in a partition now sends flooded route > > requests for N/2 disconnected destinations resulting in N/2 * N/2 > > flooded route requests and since each flood consumes N/2 > > transmissions, the total resources consumed is O(N^3). > > > > It still appears to me that on-demand protocols have a fatal flaw that > > precludes them from scaling well. > > > > ********************************************************* > > Kevin H. Grace > > The MITRE Corporation > > 202 Burlington Rd > > Bedford, MA 01730 > > (781) 271-8388 > > kgrace@mitre.org > > > > > > > > Laurent Viennot wrote: > > > > > > Hi Kevin, > > > > > > The analysis I have mentionned in a previous mail shows that all > > > protocols include at least a O(N^2) control overhead where N is the > > > number of nodes. This is not surprising since the topology of a radio > > > network is certainly proportional to O(N^2) (imagine for example an > > > IETF meeting room). If you call scalable a protocol that has a cost > > > proportional to the size of the topology, you should not be alarmed by > > > what you call the on demand flaw... > > > > > > laurent > > > > > -- Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Mon Jul 10 17:18:22 2000 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 RAA28931 for ; Mon, 10 Jul 2000 17:18:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA09688 for manet-outgoing; Mon, 10 Jul 2000 15:19:58 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA09683 for ; Mon, 10 Jul 2000 15:19:56 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id OAA08046; Mon, 10 Jul 2000 14:19:46 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id OAA29261; Mon, 10 Jul 2000 14:19:34 -0500 (CDT) Date: Mon, 10 Jul 2000 14:19:34 -0500 (CDT) Message-Id: <200007101919.OAA29261@sun.cs.tamu.edu> To: kgrace@mitre.org Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi Kevin >> From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:35:29 2000 >> From: Kevin Grace ... >> We know for a link state protocol that its worst case and average case >> overhead are both O(N^2). We also know that for on-demand protocols, >> worst case overhead is O(N^3) though we don't know what its average >> case overhead is. But, we do know that as soon as an on-demand >> protocol has N route requests for disconnected destinations, its >> overhead exceeds that of link state. >> >> Regardless of average case overhead, the more scalable routing >> approach is the one with the lower worst case overhead: link state. Your conclusion may very well be right in certain situations - personally, I do not believe any one approach is going to be a winner in all realistic environments (as characterized by mobility patterns, traffic patterns, performance metrics, capabilities of the mobile nodes, etc.). Trying to prove such a conclusion in general is probably futile. Unless I am missing something, the above analysis ignores time between route discoveries performed by an on-demand protocol. For the sake of argument, suppose that a minimum time interval of T is enforced on consecutive route discoveries by a given node, with tau being the time between link state updates transmitted by a node using a link state protocol. The results of your analysis could change depending on the relationship between T and tau - for instance, what if T/tau > N ? Note that with exponential backoff schemes, the time between route discoveries can be increased very rapidly, particularly in the case of partitions (i.e., a backoff scheme would tend to make T large). I am not suggesting that on-demand is going to be the method of choice in general. The devil is in the details. Cheerio. - nitin >> Also, the advantage of using a link state approach is that we can know >> ahead of time for a given network size, whether the network will have >> enough capacity to disseminate routing information. Contrast this to >> the on-demand approach where we don't know the amount of overhead it >> will generate apriori even when we know the traffic model (who talks >> to whom) since we don't know which nodes will become disconnected. >> >> ********************************************************* >> Kevin H. Grace >> The MITRE Corporation >> 202 Burlington Rd >> Bedford, MA 01730 >> (781) 271-8388 >> kgrace@mitre.org >> >> >> Laurent Viennot wrote: >> > >> > With such a heavy traffic, you'd rather consider a pro-active protocol >> > like OLSR. >> > >> > You can model the traffic with the average number a of active routes >> > per node. Simulations I have read often suppose a<1. If you consider >> > the connections you initiate with your own computer in an every day >> > use, you wouldn't expect a to be greater than 2 or 3. >> > >> > However there may be some applications producing such traffics. If you >> > know some serious examples, I am curious to know them. >> > >> > laurent >> > >> > Kevin Grace writes: >> > > Hi Laurent, >> > > >> > > >> If you call scalable a protocol that has a cost >> > > >> proportional to the size of the topology, you should not be alarmed by >> > > >> what you call the on demand flaw... >> > > >> > > The problem is that on-demand protocols can actually have an overhead >> > > of O(N^3). This is much worse than the overhead of a link state >> > > protocol which is O(N^2). >> > > >> > > To see why an on-demand protocol has an overhead of O(N^3) consider a >> > > network of N nodes in which every node communicates to every other >> > > node. Now consider that the network is severed into two halves, each >> > > with N/2 nodes. Each node in a partition now sends flooded route >> > > requests for N/2 disconnected destinations resulting in N/2 * N/2 >> > > flooded route requests and since each flood consumes N/2 >> > > transmissions, the total resources consumed is O(N^3). >> > > >> > > It still appears to me that on-demand protocols have a fatal flaw that >> > > precludes them from scaling well. >> > > >> > > ********************************************************* >> > > Kevin H. Grace >> > > The MITRE Corporation >> > > 202 Burlington Rd >> > > Bedford, MA 01730 >> > > (781) 271-8388 >> > > kgrace@mitre.org >> > > >> > > >> > > >> > > Laurent Viennot wrote: >> > > > >> > > > Hi Kevin, >> > > > >> > > > The analysis I have mentionned in a previous mail shows that all >> > > > protocols include at least a O(N^2) control overhead where N is the >> > > > number of nodes. This is not surprising since the topology of a radio >> > > > network is certainly proportional to O(N^2) (imagine for example an >> > > > IETF meeting room). If you call scalable a protocol that has a cost >> > > > proportional to the size of the topology, you should not be alarmed by >> > > > what you call the on demand flaw... >> > > > >> > > > laurent >> > > > >> > > >> >> -- >> Kevin Grace The MITRE Corporation >> 781-271-8388 202 Burlington Rd >> kgrace@mitre.org Bedford MA, 01730 >> >> From owner-manet@itd.nrl.navy.mil Mon Jul 10 17:29:34 2000 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 RAA29136 for ; Mon, 10 Jul 2000 17:29:34 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA09723 for manet-outgoing; Mon, 10 Jul 2000 15:20:48 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA09718 for ; Mon, 10 Jul 2000 15:20:46 -0400 (EDT) Received: from chip (DHCP044-066.BBN.COM [128.89.44.66]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id PAA19362 for ; Mon, 10 Jul 2000 15:20:36 -0400 (EDT) Message-Id: <3.0.3.32.20000710151413.014c4108@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Jul 2000 15:14:13 -0400 To: MANET mailing list From: Chip Elliott Subject: On-Demand vs Link State Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Another helpful way to look at these two protocol families (on demand, link state) is to consider how a malicious intruder would bring them to their knees. They fail in quite different ways, I think. For on-demand protocols, the worst attack is to keep requesting addresses that are not reachable. For link state, it's rapid change in the network topology. Both problems can be ameliorated by rate-limiting the control traffic, of course at the expense of making the network sluggish and irresponsive in some cases. Once you look at the families that way, then it's easy to apply Murphy's Law to determine how these networks are likely to behave in practice! One doesn't really need a malicious intruder - normal operation will suffice... Cheers, Chip Elliott BBN >The flaw with on-demand protocols is independent of traffic >models. Any disconnected destination node results in a wasteful >sequence of flooded route requests. As soon as there are N route >requests for disconnected destination(s), regardless of how the >requests are distributed across source(s) and destination(s), the >amount of wasted resources exceeds that necessary to distribute >topology information to every node. > >> You can model the traffic with the average number a of active routes >> per node. Simulations I have read often suppose a<1. If you consider >> the connections you initiate with your own computer in an every day >> use, you wouldn't expect a to be greater than 2 or 3. > >I would think 2 or 3 routes per computer would be more than enough to >result in N route requests for disconnected destinations. Suppose one >route on every computer was for a DNS server that became >disconnected...that would be sufficient to make the link state >approach more efficient than the on-demand approach. > >We know for a link state protocol that its worst case and average case >overhead are both O(N^2). We also know that for on-demand protocols, >worst case overhead is O(N^3) though we don't know what its average >case overhead is. But, we do know that as soon as an on-demand >protocol has N route requests for disconnected destinations, its >overhead exceeds that of link state. > >Regardless of average case overhead, the more scalable routing >approach is the one with the lower worst case overhead: link state. >Also, the advantage of using a link state approach is that we can know >ahead of time for a given network size, whether the network will have >enough capacity to disseminate routing information. Contrast this to >the on-demand approach where we don't know the amount of overhead it >will generate apriori even when we know the traffic model (who talks >to whom) since we don't know which nodes will become disconnected. > >********************************************************* > Kevin H. Grace > The MITRE Corporation > 202 Burlington Rd > Bedford, MA 01730 > (781) 271-8388 > kgrace@mitre.org > From owner-manet@itd.nrl.navy.mil Mon Jul 10 18:43:47 2000 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 SAA00964 for ; Mon, 10 Jul 2000 18:43:47 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA11662 for manet-outgoing; Mon, 10 Jul 2000 16:25:05 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA11657 for ; Mon, 10 Jul 2000 16:25:03 -0400 (EDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 768E919FFEC; Mon, 10 Jul 2000 15:24:40 -0500 (CDT) Received: from localhost (ravip@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id PAA03153; Mon, 10 Jul 2000 15:24:53 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: ravip owned process doing -bs Date: Mon, 10 Jul 2000 15:24:53 -0500 (CDT) From: Ravi Prakash To: Nitin H Vaidya Cc: kgrace@mitre.org, manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw In-Reply-To: <200007101919.OAA29261@sun.cs.tamu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk The on-demand routing protocols that I am aware of (namely AODV and DSR) rely on route caches to limit the number of route discoveries. However, based on some simple experiments we conducted we realized that the time for which a route stays valid is quite small, and this duration gets smaller as the network scales. So, route caching does not seem to scale well, and may have a benefit only if a source has to send a large number of packets in a short time immediately after route discovery. As the network size and diameter grow, in my opinion the following will happen: 1. Proactive protocols will have to increase the frequency of route updates, thus incurring higher overheads. 2. Reactive/on demand protocols like AODV and DSR will have to reduce their cache-lifetimes, thus also increasing their route discovery messages. Relying on the simulation results obtained using ns-2 to advocate the strengths of one's favorite protocol is risky because the propagation model in ns-2 is very simplistic. The achievable data rate and link stability will be far lower than what ns-2 tells us. Perhaps, this is why DOE's experiments with networks of 50 nodes have been far less than satisfactory. So, rather than trying to determine the strengths of one over the other, we need to be really worried about the lack of scalability that affects both. Just my humble opinion, ----Ravi. ======================================================================== Ravi Prakash (ravip@utdallas.edu) www.utdallas.edu/~ravip Department of Computer Science The University of Texas at Dallas Richardson, TX 75083-0688. Phone: (972) 883-2289, Fax: (972) 883-2349 On Mon, 10 Jul 2000, Nitin H Vaidya wrote: > > > hi Kevin > > >> From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:35:29 2000 > >> From: Kevin Grace > ... > >> We know for a link state protocol that its worst case and average case > >> overhead are both O(N^2). We also know that for on-demand protocols, > >> worst case overhead is O(N^3) though we don't know what its average > >> case overhead is. But, we do know that as soon as an on-demand > >> protocol has N route requests for disconnected destinations, its > >> overhead exceeds that of link state. > >> > >> Regardless of average case overhead, the more scalable routing > >> approach is the one with the lower worst case overhead: link state. > > > Your conclusion may very well be right in certain situations - personally, > I do not believe any one approach is going to be a winner in all realistic > environments (as characterized by mobility patterns, traffic patterns, > performance metrics, capabilities of the mobile nodes, etc.). > Trying to prove such a conclusion in general is probably futile. > > Unless I am missing something, the above analysis ignores time between > route discoveries performed by an on-demand protocol. For the > sake of argument, suppose that a minimum time interval of T is > enforced on consecutive route discoveries by a given node, with tau > being the time between link state updates transmitted by a node using > a link state protocol. > > The results of your analysis could change depending on the > relationship between T and tau - for instance, what if T/tau > N ? > > Note that with exponential backoff schemes, the time between route > discoveries can be increased very rapidly, particularly in the case > of partitions (i.e., a backoff scheme would tend to make T large). > > I am not suggesting that on-demand is going to be the method > of choice in general. > > The devil is in the details. > > Cheerio. > > - nitin > > > > > >> Also, the advantage of using a link state approach is that we can know > >> ahead of time for a given network size, whether the network will have > >> enough capacity to disseminate routing information. Contrast this to > >> the on-demand approach where we don't know the amount of overhead it > >> will generate apriori even when we know the traffic model (who talks > >> to whom) since we don't know which nodes will become disconnected. > >> > >> ********************************************************* > >> Kevin H. Grace > >> The MITRE Corporation > >> 202 Burlington Rd > >> Bedford, MA 01730 > >> (781) 271-8388 > >> kgrace@mitre.org > >> > >> > >> Laurent Viennot wrote: > >> > > >> > With such a heavy traffic, you'd rather consider a pro-active protocol > >> > like OLSR. > >> > > >> > You can model the traffic with the average number a of active routes > >> > per node. Simulations I have read often suppose a<1. If you consider > >> > the connections you initiate with your own computer in an every day > >> > use, you wouldn't expect a to be greater than 2 or 3. > >> > > >> > However there may be some applications producing such traffics. If you > >> > know some serious examples, I am curious to know them. > >> > > >> > laurent > >> > > >> > Kevin Grace writes: > >> > > Hi Laurent, > >> > > > >> > > >> If you call scalable a protocol that has a cost > >> > > >> proportional to the size of the topology, you should not be alarmed by > >> > > >> what you call the on demand flaw... > >> > > > >> > > The problem is that on-demand protocols can actually have an overhead > >> > > of O(N^3). This is much worse than the overhead of a link state > >> > > protocol which is O(N^2). > >> > > > >> > > To see why an on-demand protocol has an overhead of O(N^3) consider a > >> > > network of N nodes in which every node communicates to every other > >> > > node. Now consider that the network is severed into two halves, each > >> > > with N/2 nodes. Each node in a partition now sends flooded route > >> > > requests for N/2 disconnected destinations resulting in N/2 * N/2 > >> > > flooded route requests and since each flood consumes N/2 > >> > > transmissions, the total resources consumed is O(N^3). > >> > > > >> > > It still appears to me that on-demand protocols have a fatal flaw that > >> > > precludes them from scaling well. > >> > > > >> > > ********************************************************* > >> > > Kevin H. Grace > >> > > The MITRE Corporation > >> > > 202 Burlington Rd > >> > > Bedford, MA 01730 > >> > > (781) 271-8388 > >> > > kgrace@mitre.org > >> > > > >> > > > >> > > > >> > > Laurent Viennot wrote: > >> > > > > >> > > > Hi Kevin, > >> > > > > >> > > > The analysis I have mentionned in a previous mail shows that all > >> > > > protocols include at least a O(N^2) control overhead where N is the > >> > > > number of nodes. This is not surprising since the topology of a radio > >> > > > network is certainly proportional to O(N^2) (imagine for example an > >> > > > IETF meeting room). If you call scalable a protocol that has a cost > >> > > > proportional to the size of the topology, you should not be alarmed by > >> > > > what you call the on demand flaw... > >> > > > > >> > > > laurent > >> > > > > >> > > > >> > >> -- > >> Kevin Grace The MITRE Corporation > >> 781-271-8388 202 Burlington Rd > >> kgrace@mitre.org Bedford MA, 01730 > >> > >> > From owner-manet@itd.nrl.navy.mil Mon Jul 10 18:44:46 2000 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 SAA00993 for ; Mon, 10 Jul 2000 18:44:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA12793 for manet-outgoing; Mon, 10 Jul 2000 16:56:57 -0400 (EDT) Received: from po4.glue.umd.edu (po4.glue.umd.edu [128.8.10.124]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA12786 for ; Mon, 10 Jul 2000 16:56:55 -0400 (EDT) Received: from jewels (macscott.isr.umd.edu [128.8.140.119]) by po4.glue.umd.edu (8.10.1/8.10.1) with SMTP id e6AKukI28758; Mon, 10 Jul 2000 16:56:46 -0400 (EDT) Message-Id: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> X-Sender: mscorson@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 10 Jul 2000 17:00:43 -0400 To: Kevin Grace From: "M. Scott Corson" Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil In-Reply-To: <39650256.19CA5C92@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 06:04 PM 7/6/00 -0400, you wrote: >It appears to me that the on demand routing protocols have a fatal flaw >which preclude them from scaling well and that the link state approach >is superior. The behavior you mention is (or can be) true for on-demand protocols that utilize memoryless, non-suppressed query/route-request mechanisms, depending on application behavior. Assuming rather worst-case application behavior (e.g. a frustrated surfer continuously issuing HTTP requests--translated into route requests--for a mobile server currently disconnected), the amount of flooding traffic could indeed be large. This is not such an issue for small ad hoc nets, but becomes a consideration for those attempting to build larger ones. The following is NOT intended to be a shameless plug ;-), just an example of a protocol using suppression. If others know of any, please contribute as well. A little known feature of TORA is its approach to query suppression during route discovery. When a node issues a query for a destination, it is flooded throughout the network. Nodes that receive and process the query _remember_ this fact by setting a Route-Requested (RR) flag for the given destination. Thus the query process is not memoryless. It is destination-oriented and independent of the source node issuing the query. When a new link appears with a neighbor at a node with its RR flag set, it transmits a query for that destination to the neighbor. Thus the query propagates like a virus, and is rather similar to the epidemic routing concept, and some forms of reliable persistent flooding. The current specification states that a node retains its memory of the query indefinitely so that, in effect, once issued a query is active forever. We are amending this behavior so that the time a RR flag remains set is configurable (perhaps 30 seconds or so), we've not yet chosen a figure. After this time the RR flag settings time out. Nodes with RR flags set do not generate new querys for the same destination, so the mechanism suppresses multiple query floods and the behavior you mentioned does not occur. We are also adding an approach for query localization that can be turned on if desired, and are sorting this out in the simulator as well. I also do not think it is difficult to add memory/suppression behaviors to other on-demand algorithms, so the on-demand vs. proactive debate will likely continue. -scott From owner-manet@itd.nrl.navy.mil Mon Jul 10 18:45:20 2000 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 SAA01008 for ; Mon, 10 Jul 2000 18:45:20 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA12496 for manet-outgoing; Mon, 10 Jul 2000 16:45:41 -0400 (EDT) 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 QAA12485 for ; Mon, 10 Jul 2000 16:45:39 -0400 (EDT) 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 NAA18413; Mon, 10 Jul 2000 13:44:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA19859; Mon, 10 Jul 2000 13:44:54 -0700 X-Virus-Scanned: Mon, 10 Jul 2000 13:44:54 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdeBbZoh; Mon, 10 Jul 2000 13:44:49 PDT Message-ID: <396A35C5.C8BC9FA0@iprg.nokia.com> Date: Mon, 10 Jul 2000 13:44:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard CC: manet@itd.nrl.navy.mil, ogier@erg.sri.com Subject: Re: Overhead analysis References: <200007101731.KAA09656@pit.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 Richard, > ........... But what if there is both high mobility > and high activity? My *guess* is that in this case, an efficient > proactive protocol generates less control traffic. > My reasoning is that every node needs to maintain frequently > updated paths to every other node, and efficient proactive protocols > do this more efficiently than flooding. I believe this effect has been measured, although I do not have the reference, and indeed it is possible for proactive protocols to outperform on-demand protocols if all the nodes talk to all of the other nodes. It also helps if the nodes stand still, or if triggered updates are batched (i.e., not all sent separately). Regards, Charlie P. From owner-mmnet@itd.nrl.navy.mil Mon Jul 10 20:33:07 2000 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 UAA02504 for ; Mon, 10 Jul 2000 20:33:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA14784 for mmnet-outgoing; Mon, 10 Jul 2000 18:26:18 -0400 (EDT) Received: from otter.mbay.net (otter.mbay.net [206.40.79.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA14779 for ; Mon, 10 Jul 2000 18:26:16 -0400 (EDT) Received: from [206.55.224.66] (mty1-66.dip.mbay.net [206.55.224.66]) by otter.mbay.net (8.9.3/8.8.8) with ESMTP id LAA04593; Mon, 10 Jul 2000 11:42:38 -0700 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Jul 2000 11:39:57 -0700 Subject: re: An On-Line Real Estate System So Automated it Works Even if You Don't Own a Computer! From: Rand Smith To: Best Agent1 Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3046073997_2455478_MIME_Part" Sender: owner-mmnet@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. --MS_Mac_OE_3046073997_2455478_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The world's first On-Line Automated Real Estate System and Custom Consumer Web Site FREE to You for 30 Full Days: http://www.iProCenter.com Yes, today you can log onto http://www.iProCenter.com and discover for yourself, FREE of charge for a full 30 days, the awesome power of the world's first REAL ESTATE PRODUCTIVITY CENTER! You have never seen anything like this before=8Auntil today, it simply hasn=B9t existed! Would you like a simple-to-use automated system which includes your own private on line office? Would you like to harness the awesome power of technology without having to spend time having to learn how to do it? Are you are sick and tired of waiting for technology to get cheap enough to mak= e sense for you to use it? Would you love to have a custom web site and on line automated assistant working around the clock attracting and servicing hundreds of home buyers and sellers=8Awhile you sleep? Guess what? Right now, today, you can be one of the first to arm yourself with the Nation=B9s first and only fully automated service system. In fact you can us= e this dynamic new Productivity Center System with every feature listed below= , fully activated and personalized just for you, for a full 30 days FREE of charge. And that=B9s just the beginning. I know your skeptical but please take a minute and read on=8A Here=B9s what you will get when you go to http://www.iProCenter.com: v On-Line Email System in your name v Complete Automated On-Line Follow-up system. (Auto-responders.) v FREE site name. (Whatever you choose.) v Unlimited listings at no extra charge. (Plus Instant Flyer Feature) v Easy-edit format (Change anything, anytime, with ease.) v Insta-Site feature. (You'll be up and running with your very own customized website and Productivity Command Center within 5 minutes or less) v Weekly Marketing Workshops hosted by Master Marketer Rand Smith and many other top national marketing experts. v Unlimited links you can add or change easily, anytime. v Daily motivational quote or hot marketing tip. (Or both!) v Database functionality. Do broadcast emails or send snail mail with a simple click of a mouse. v Complete online calendar with action plans. v You get access to over 3,000,000 million properties framed in your site=8A(#1 reason buyers go on line is to view homes) For a limited time, all up-front fees are waived. Hurry, you can get 30 day= s to see if this isn=B9t the hottest marketing system ever offered on line or off!! Go to=20 http://www.iProCenter.com right now and get armed with the most potent on-line arsenal of automated system and tools ever offered in one place. Fast-Action Idea: DON'T GET LEFT OUT! Go to http://www.iProCenter.com , register, then wrap your arms around the world's first Productivity Center for real estate agents. So easy to use, i= t almost seems unfair. Finally, a utility that will deliver you what you want: productivity, real world systems, qualified leads and, of course, CASH IN THE PANTS! So go ahead, get a jump on your competition and sign up today! Be blessed, Rand Smith Real Estate by Rand --MS_Mac_OE_3046073997_2455478_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable re:  An On-Line Real Estate System So Automated it Works Even i= f You Don't Own a Computer!
The world's first On-Line= Automated Real Estate System and Custom Consumer Web Site FREE to You for 3= 0 Full Days:

http://www.iProCenter.c= om

Yes, today you can log onto http://w= ww.iProCenter.com and discover for yourself, FREE of charge= for a full 30 days, the awesome power of the world's first REAL E= STATE PRODUCTIVITY CENTER! You have never seen anything like this before= =8Auntil today, it simply hasn=B9t existed!

Would you like a simple-to-use automated system which includes your own pri= vate on line office?  Would you like to harness the awesome power of te= chnology without having to spend time having to learn how to do it?  Ar= e you are sick and tired of waiting for technology to get cheap enough to ma= ke sense for you to use it?  Would you love to have a custom web site a= nd on line automated assistant working around the clock attracting and servi= cing hundreds of home buyers and sellers=8Awhile you sleep? Guess what?

Right now, today, you can be one of the first to arm yourself with the Nati= on=B9s first and only fully automated service system.  In fact you= can use this dynamic new Productivity Center System with every feature list= ed below, fully activated and personalized just for you, for a full 30 da= ys FREE of charge.  And that=B9s just the beginning.  I know you= r skeptical but please take a minute and read on=8A

Here=B9s what you will get when you go to http://www.iProCenter.com:

v On-Line Email System in your name
v Complete Automated On-Line Follow-up system. (Auto-respo= nders.)
v FREE site name. (Whatever you choose.)
v Unlimited listings at no extra charge. (Plus Instant Fly= er Feature)
v Easy-edit format (Change anything, anytime, with ease.)<= BR> v Insta-Site feature. (You'll be up and running with your = very own customized     website and Productivity Command= Center within 5 minutes or less)
v Weekly Marketing Workshops hosted by Master Marke= ter Rand Smith and many other top national marketing experts.
v Unlimited links you can add or change easily, anytime. v Daily motivational quote or hot marketing tip. (Or both!= )
v Database functionality. Do broadcast emails or send snai= l mail with a simple click of a mouse.
v Complete online calendar with action plans.
v You get access to over 3,000,000 million properties fram= ed in your site=8A(#1 reason buyers go on line is to view homes)

For a limited time, all up-front fees are waived. Hurry, you can get 30 day= s to see if this isn=B9t the hottest marketing system ever offered on line or = off!! Go to
http:= //www.iProCenter.com= right now and get a= rmed with the most potent on-line arsenal of automated system and tools ever= offered in one place.  

Fast-Action Idea: DON'T GET LEFT OUT!

Go to http://www.iProCenter.com , register, then wrap your arms around the wor= ld's first Productivity Center for real estate agents. So easy to use, it al= most seems unfair.

Finally, a utility that will deliver you what you want: productivity, real = world systems, qualified leads and, of course, CASH IN THE PANTS!

So go ahead, get a jump on your competition and sign up today!

Be blessed,

Rand Smith
Real Estate by Rand
--MS_Mac_OE_3046073997_2455478_MIME_Part-- From owner-manet@itd.nrl.navy.mil Tue Jul 11 02:27:17 2000 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 CAA21106 for ; Tue, 11 Jul 2000 02:27:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA18721 for manet-outgoing; Mon, 10 Jul 2000 22:41:44 -0400 (EDT) Received: from otter.mbay.net (otter.mbay.net [206.40.79.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA18711; Mon, 10 Jul 2000 22:41:41 -0400 (EDT) Received: from [206.55.224.170] (mty3-170.dip.mbay.net [206.55.224.170]) by otter.mbay.net (8.9.3/8.8.8) with ESMTP id RAA10162; Mon, 10 Jul 2000 17:02:50 -0700 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Jul 2000 16:59:57 -0700 Subject: re: An On-Line Real Estate System So Automated it Works Even if You Don't Own a Computer! From: Rand Smith To: Best Agent5 Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3046093197_3610269_MIME_Part" 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. --MS_Mac_OE_3046093197_3610269_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The world's first On-Line Automated Real Estate System and Custom Consumer Web Site FREE to You for 30 Full Days: http://www.iProCenter.com Yes, today you can log onto http://www.iProCenter.com and discover for yourself, FREE of charge for a full 30 days, the awesome power of the world's first REAL ESTATE PRODUCTIVITY CENTER! You have never seen anything like this before=8Auntil today, it simply hasn=B9t existed! Would you like a simple-to-use automated system which includes your own private on line office? Would you like to harness the awesome power of technology without having to spend time having to learn how to do it? Are you are sick and tired of waiting for technology to get cheap enough to mak= e sense for you to use it? Would you love to have a custom web site and on line automated assistant working around the clock attracting and servicing hundreds of home buyers and sellers=8Awhile you sleep? Guess what? Right now, today, you can be one of the first to arm yourself with the Nation=B9s first and only fully automated service system. In fact you can us= e this dynamic new Productivity Center System with every feature listed below= , fully activated and personalized just for you, for a full 30 days FREE of charge. And that=B9s just the beginning. I know your skeptical but please take a minute and read on=8A Here=B9s what you will get when you go to http://www.iProCenter.com: v On-Line Email System in your name v Complete Automated On-Line Follow-up system. (Auto-responders.) v FREE site name. (Whatever you choose.) v Unlimited listings at no extra charge. (Plus Instant Flyer Feature) v Easy-edit format (Change anything, anytime, with ease.) v Insta-Site feature. (You'll be up and running with your very own customized website and Productivity Command Center within 5 minutes or less) v Weekly Marketing Workshops hosted by Master Marketer Rand Smith and many other top national marketing experts. v Unlimited links you can add or change easily, anytime. v Daily motivational quote or hot marketing tip. (Or both!) v Database functionality. Do broadcast emails or send snail mail with a simple click of a mouse. v Complete online calendar with action plans. v You get access to over 3,000,000 million properties framed in your site=8A(#1 reason buyers go on line is to view homes) For a limited time, all up-front fees are waived. Hurry, you can get 30 day= s to see if this isn=B9t the hottest marketing system ever offered on line or off!! Go to=20 http://www.iProCenter.com right now and get armed with the most potent on-line arsenal of automated system and tools ever offered in one place. Fast-Action Idea: DON'T GET LEFT OUT! Go to http://www.iProCenter.com , register, then wrap your arms around the world's first Productivity Center for real estate agents. So easy to use, i= t almost seems unfair. Finally, a utility that will deliver you what you want: productivity, real world systems, qualified leads and, of course, CASH IN THE PANTS! So go ahead, get a jump on your competition and sign up today! Be blessed, Rand Smith Real Estate by Rand --MS_Mac_OE_3046093197_3610269_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable re:  An On-Line Real Estate System So Automated it Works Even i= f You Don't Own a Computer!
The world's first On-Line= Automated Real Estate System and Custom Consumer Web Site FREE to You for 3= 0 Full Days:

http://www.iProCenter.c= om

Yes, today you can log onto http://w= ww.iProCenter.com and discover for yourself, FREE of charge= for a full 30 days, the awesome power of the world's first REAL E= STATE PRODUCTIVITY CENTER! You have never seen anything like this before= =8Auntil today, it simply hasn=B9t existed!

Would you like a simple-to-use automated system which includes your own pri= vate on line office?  Would you like to harness the awesome power of te= chnology without having to spend time having to learn how to do it?  Ar= e you are sick and tired of waiting for technology to get cheap enough to ma= ke sense for you to use it?  Would you love to have a custom web site a= nd on line automated assistant working around the clock attracting and servi= cing hundreds of home buyers and sellers=8Awhile you sleep? Guess what?

Right now, today, you can be one of the first to arm yourself with the Nati= on=B9s first and only fully automated service system.  In fact you= can use this dynamic new Productivity Center System with every feature list= ed below, fully activated and personalized just for you, for a full 30 da= ys FREE of charge.  And that=B9s just the beginning.  I know you= r skeptical but please take a minute and read on=8A

Here=B9s what you will get when you go to http://www.iProCenter.com:

v On-Line Email System in your name
v Complete Automated On-Line Follow-up system. (Auto-respo= nders.)
v FREE site name. (Whatever you choose.)
v Unlimited listings at no extra charge. (Plus Instant Fly= er Feature)
v Easy-edit format (Change anything, anytime, with ease.)<= BR> v Insta-Site feature. (You'll be up and running with your = very own customized     website and Productivity Command= Center within 5 minutes or less)
v Weekly Marketing Workshops hosted by Master Marke= ter Rand Smith and many other top national marketing experts.
v Unlimited links you can add or change easily, anytime. v Daily motivational quote or hot marketing tip. (Or both!= )
v Database functionality. Do broadcast emails or send snai= l mail with a simple click of a mouse.
v Complete online calendar with action plans.
v You get access to over 3,000,000 million properties fram= ed in your site=8A(#1 reason buyers go on line is to view homes)

For a limited time, all up-front fees are waived. Hurry, you can get 30 day= s to see if this isn=B9t the hottest marketing system ever offered on line or = off!! Go to
http:= //www.iProCenter.com= right now and get a= rmed with the most potent on-line arsenal of automated system and tools ever= offered in one place.  

Fast-Action Idea: DON'T GET LEFT OUT!

Go to http://www.iProCenter.com , register, then wrap your arms around the wor= ld's first Productivity Center for real estate agents. So easy to use, it al= most seems unfair.

Finally, a utility that will deliver you what you want: productivity, real = world systems, qualified leads and, of course, CASH IN THE PANTS!

So go ahead, get a jump on your competition and sign up today!

Be blessed,

Rand Smith
Real Estate by Rand
--MS_Mac_OE_3046093197_3610269_MIME_Part-- From owner-manet@itd.nrl.navy.mil Tue Jul 11 08:37:33 2000 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 IAA28158 for ; Tue, 11 Jul 2000 08:37:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA22439 for manet-outgoing; Tue, 11 Jul 2000 05:05:56 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id FAA22434 for ; Tue, 11 Jul 2000 05:05:54 -0400 (EDT) Received: (qmail 28752 invoked by uid 11205); 11 Jul 2000 09:05:42 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14698.58213.81953.143245@cupidon.inria.fr> Date: Tue, 11 Jul 2000 11:05:41 +0200 (CEST) To: Richard Cc: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <200007101731.KAA09656@pit.erg.sri.com> References: <14697.50715.422459.847207@cupidon.inria.fr> <200007101731.KAA09656@pit.erg.sri.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Richard writes: > > Hello Laurent, > > > Both protocol approaches behave differently according to mobility and > > activity mainly. To summarize: flooding (reactive) protocols react > > better to high mobility and hello (pro-active) protocols react better > > to high activity. We agree on this. > > Yes, we agree on this. But what if there is both high mobility > and high activity? My *guess* is that in this case, an efficient > proactive protocol generates less control traffic. > My reasoning is that every node needs to maintain frequently > updated paths to every other node, and efficient proactive protocols > do this more efficiently than flooding. > Yes, this is confirmed by our analysis. We can get regions of the plane mobility x activity favorable to each protocol flavor. This gives something like this : activity ^ |---------------| | | |** | | * proactive | | * | | * | | **** | | *****| | reactive | | | ----------------|-------> mobility An activity of 2 or 3 active routes per node is sufficient for proactive protocols to outperform on-demand protocols. All the nodes talking to all of the other nodes corresponds to an activity of N active routes per node. You don't need so high activity to see proactive protocols behaving better than reactive protocols. You can find similar curves for the random graph model, the geometric model (strip and square) and the grid in our research report RR-3965 http://menetou.inria.fr/~viennot/postscripts/overhead.ps laurent From owner-manet@itd.nrl.navy.mil Tue Jul 11 11:01:31 2000 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 LAA03182 for ; Tue, 11 Jul 2000 11:01:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA24535 for manet-outgoing; Tue, 11 Jul 2000 08:00:22 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA24530 for ; Tue, 11 Jul 2000 08:00:20 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA05791; Tue, 11 Jul 2000 08:00:04 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id HAA08960; Tue, 11 Jul 2000 07:58:18 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub1.mitre.org with SMTP id 3837040; Tue, 11 Jul 2000 07:59:13 EST Message-ID: <396B0C44.37345B56@mitre.org> Date: Tue, 11 Jul 2000 08:00:04 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nitin H Vaidya CC: manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw References: <200007101919.OAA29261@sun.cs.tamu.edu> 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 Nitin, > Note that with exponential backoff schemes, the time between route > discoveries can be increased very rapidly, particularly in the case > of partitions (i.e., a backoff scheme would tend to make T large). An exponential backoff will indeed reduce overhead but at the cost of increasing the delay in discovering a route to a recently reconnected node. As the protocol designer, you have now consciously made the choice that efficiency is more important than delay and imposed a "one size fits all" treatment of the bits. Not all bits are the same, however, and a time sensitive message may now be delayed significantly for the sake of efficiency. As a network user, I don't think I'd like this behavior when I wanted to send a "I need help now!" message. > I am not suggesting that on-demand is going to be the method > of choice in general. Agreed! Regards, -Kevin Nitin H Vaidya wrote: > > hi Kevin > > >> From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:35:29 2000 > >> From: Kevin Grace > ... > >> We know for a link state protocol that its worst case and average case > >> overhead are both O(N^2). We also know that for on-demand protocols, > >> worst case overhead is O(N^3) though we don't know what its average > >> case overhead is. But, we do know that as soon as an on-demand > >> protocol has N route requests for disconnected destinations, its > >> overhead exceeds that of link state. > >> > >> Regardless of average case overhead, the more scalable routing > >> approach is the one with the lower worst case overhead: link state. > > Your conclusion may very well be right in certain situations - personally, > I do not believe any one approach is going to be a winner in all realistic > environments (as characterized by mobility patterns, traffic patterns, > performance metrics, capabilities of the mobile nodes, etc.). > Trying to prove such a conclusion in general is probably futile. > > Unless I am missing something, the above analysis ignores time between > route discoveries performed by an on-demand protocol. For the > sake of argument, suppose that a minimum time interval of T is > enforced on consecutive route discoveries by a given node, with tau > being the time between link state updates transmitted by a node using > a link state protocol. > > The results of your analysis could change depending on the > relationship between T and tau - for instance, what if T/tau > N ? > > Note that with exponential backoff schemes, the time between route > discoveries can be increased very rapidly, particularly in the case > of partitions (i.e., a backoff scheme would tend to make T large). > > I am not suggesting that on-demand is going to be the method > of choice in general. > > The devil is in the details. > > Cheerio. > > - nitin > > >> Also, the advantage of using a link state approach is that we can know > >> ahead of time for a given network size, whether the network will have > >> enough capacity to disseminate routing information. Contrast this to > >> the on-demand approach where we don't know the amount of overhead it > >> will generate apriori even when we know the traffic model (who talks > >> to whom) since we don't know which nodes will become disconnected. > >> > >> ********************************************************* > >> Kevin H. Grace > >> The MITRE Corporation > >> 202 Burlington Rd > >> Bedford, MA 01730 > >> (781) 271-8388 > >> kgrace@mitre.org > >> > >> > >> Laurent Viennot wrote: > >> > > >> > With such a heavy traffic, you'd rather consider a pro-active protocol > >> > like OLSR. > >> > > >> > You can model the traffic with the average number a of active routes > >> > per node. Simulations I have read often suppose a<1. If you consider > >> > the connections you initiate with your own computer in an every day > >> > use, you wouldn't expect a to be greater than 2 or 3. > >> > > >> > However there may be some applications producing such traffics. If you > >> > know some serious examples, I am curious to know them. > >> > > >> > laurent > >> > > >> > Kevin Grace writes: > >> > > Hi Laurent, > >> > > > >> > > >> If you call scalable a protocol that has a cost > >> > > >> proportional to the size of the topology, you should not be alarmed by > >> > > >> what you call the on demand flaw... > >> > > > >> > > The problem is that on-demand protocols can actually have an overhead > >> > > of O(N^3). This is much worse than the overhead of a link state > >> > > protocol which is O(N^2). > >> > > > >> > > To see why an on-demand protocol has an overhead of O(N^3) consider a > >> > > network of N nodes in which every node communicates to every other > >> > > node. Now consider that the network is severed into two halves, each > >> > > with N/2 nodes. Each node in a partition now sends flooded route > >> > > requests for N/2 disconnected destinations resulting in N/2 * N/2 > >> > > flooded route requests and since each flood consumes N/2 > >> > > transmissions, the total resources consumed is O(N^3). > >> > > > >> > > It still appears to me that on-demand protocols have a fatal flaw that > >> > > precludes them from scaling well. > >> > > > >> > > ********************************************************* > >> > > Kevin H. Grace > >> > > The MITRE Corporation > >> > > 202 Burlington Rd > >> > > Bedford, MA 01730 > >> > > (781) 271-8388 > >> > > kgrace@mitre.org > >> > > > >> > > > >> > > > >> > > Laurent Viennot wrote: > >> > > > > >> > > > Hi Kevin, > >> > > > > >> > > > The analysis I have mentionned in a previous mail shows that all > >> > > > protocols include at least a O(N^2) control overhead where N is the > >> > > > number of nodes. This is not surprising since the topology of a radio > >> > > > network is certainly proportional to O(N^2) (imagine for example an > >> > > > IETF meeting room). If you call scalable a protocol that has a cost > >> > > > proportional to the size of the topology, you should not be alarmed by > >> > > > what you call the on demand flaw... > >> > > > > >> > > > laurent > >> > > > > >> > > > >> > >> -- > >> Kevin Grace The MITRE Corporation > >> 781-271-8388 202 Burlington Rd > >> kgrace@mitre.org Bedford MA, 01730 > >> > >> -- Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Tue Jul 11 11:01:31 2000 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 LAA03183 for ; Tue, 11 Jul 2000 11:01:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA24890 for manet-outgoing; Tue, 11 Jul 2000 08:19:10 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA24885 for ; Tue, 11 Jul 2000 08:19:08 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA08013; Tue, 11 Jul 2000 08:18:53 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA11071; Tue, 11 Jul 2000 08:17:07 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub2.mitre.org with SMTP id 3896534; Tue, 11 Jul 2000 08:18:50 EST Message-ID: <396B10AC.62E7BD10@mitre.org> Date: Tue, 11 Jul 2000 08:18:52 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "M. Scott Corson" CC: manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.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 Scott, > We are amending this behavior so that the time a RR flag remains set > is configurable (perhaps 30 seconds or so), we've not yet chosen a > figure. After this time the RR flag settings time out. > Nodes with RR flags set do not generate new querys for the same > destination, so the mechanism suppresses multiple query floods and the > behavior you mentioned does not occur. Hmmm...this appears to make an on-demand protocol much more vulnerable to lost route requests and route replies. If a route request or route reply is lost, the source is prevented from trying to reinitiate a route discovery until the "configurable" time expires. You have, like a previous poster, made the decision that efficiency is more important than delay. I don't believe this is a desirable property for messages that are time sensitive. Again, the underlying problem here is that for on-demand protocols, a node does not know which nodes are disconnected from the network. To overcome this problem, which is a direct result of the decision not to distribute topology information, a node must occasionally retry the route request. This results in the protocol designer being forced to choose whether efficiency or delay is more important. I think it more wise to avoid this dilemma altogether and distribute topology information. Regards, -Kevin "M. Scott Corson" wrote: > > At 06:04 PM 7/6/00 -0400, you wrote: > >It appears to me that the on demand routing protocols have a fatal flaw > >which preclude them from scaling well and that the link state approach > >is superior. > > The behavior you mention is (or can be) true for on-demand protocols that > utilize memoryless, non-suppressed query/route-request mechanisms, > depending on application behavior. Assuming rather worst-case application > behavior (e.g. a frustrated surfer continuously issuing HTTP > requests--translated into route requests--for a mobile server currently > disconnected), the amount of flooding traffic could indeed be large. This > is not such an issue for small ad hoc nets, but becomes a consideration for > those attempting to build larger ones. > > The following is NOT intended to be a shameless plug ;-), just an example > of a protocol using suppression. If others know of any, please contribute > as well. > > A little known feature of TORA is its approach to query suppression during > route discovery. When a node issues a query for a destination, it is > flooded throughout the network. Nodes that receive and process the query > _remember_ this fact by setting a Route-Requested (RR) flag for the given > destination. Thus the query process is not memoryless. It is > destination-oriented and independent of the source node issuing the query. > When a new link appears with a neighbor at a node with its RR flag set, it > transmits a query for that destination to the neighbor. Thus the query > propagates like a virus, and is rather similar to the epidemic routing > concept, and some forms of reliable persistent flooding. The current > specification states that a node retains its memory of the query > indefinitely so that, in effect, once issued a query is active forever. We > are amending this behavior so that the time a RR flag remains set is > configurable (perhaps 30 seconds or so), we've not yet chosen a figure. > After this time the RR flag settings time out. Nodes with RR flags set do > not generate new querys for the same destination, so the mechanism > suppresses multiple query floods and the behavior you mentioned does not > occur. We are also adding an approach for query localization that can be > turned on if desired, and are sorting this out in the simulator as well. > > I also do not think it is difficult to add memory/suppression behaviors to > other on-demand algorithms, so the on-demand vs. proactive debate will > likely continue. > > -scott -- Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Tue Jul 11 12:41:32 2000 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 MAA08463 for ; Tue, 11 Jul 2000 12:41:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA28052 for manet-outgoing; Tue, 11 Jul 2000 10:26:15 -0400 (EDT) Received: from sextant (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA28046; Tue, 11 Jul 2000 10:26:08 -0400 (EDT) Message-Id: <3.0.1.32.20000711102226.00b765f0@pop.itd.nrl.navy.mil> X-Sender: vpark@pop.itd.nrl.navy.mil X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 11 Jul 2000 10:22:26 -0400 To: Kevin Grace From: "Vincent D. Park" Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil In-Reply-To: <396B10AC.62E7BD10@mitre.org> References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 08:18 AM 7/11/00 -0400, Kevin Grace wrote: >Hi Scott, > >> We are amending this behavior so that the time a RR flag remains set >> is configurable (perhaps 30 seconds or so), we've not yet chosen a >> figure. After this time the RR flag settings time out. >> Nodes with RR flags set do not generate new querys for the same >> destination, so the mechanism suppresses multiple query floods and the >> behavior you mentioned does not occur. > > >Hmmm...this appears to make an on-demand protocol much more vulnerable >to lost route requests and route replies. If a route request or route >reply is lost, the source is prevented from trying to reinitiate a >route discovery until the "configurable" time expires. You have, like >a previous poster, made the decision that efficiency is more important >than delay. I don't believe this is a desirable property for messages >that are time sensitive. Kevin, I think that any proactive routing protocol would be equally vulnerable to lost control packets. Loss of routing updates or link-state advertisements can result in an inability to route to certain destinations or worse (e.g., routing table loops). You are correct that a more persistent route request approach leads to a robustness issue, thus the need for at least a long term periodic refresh, but this is not unlike the need to periodically refresh routing updates in almost any proactive approach. As in any protocol design the balance between the amount persistence in the route request and the frequency of the refresh is an engineering tradeoff. > >Again, the underlying problem here is that for on-demand protocols, a >node does not know which nodes are disconnected from the network. To >overcome this problem, which is a direct result of the decision not to >distribute topology information, a node must occasionally retry the >route request. This results in the protocol designer being forced to >choose whether efficiency or delay is more important. I disagree. Under reasonable operating conditions (i.e., packet loss rates tolerable by a proactive routing protocol design), the use of a persistent route request approach will minimize the delay. I think it more >wise to avoid this dilemma altogether and distribute topology >information. I think you will find it difficult to convince many that both on-demand and proactive routing approaches don't have their place. Most of the discussion on the mailing list lately seems to support the notion that each has a region of applicability. -Vince > >Regards, >-Kevin > > > >"M. Scott Corson" wrote: >> >> At 06:04 PM 7/6/00 -0400, you wrote: >> >It appears to me that the on demand routing protocols have a fatal flaw >> >which preclude them from scaling well and that the link state approach >> >is superior. >> >> The behavior you mention is (or can be) true for on-demand protocols that >> utilize memoryless, non-suppressed query/route-request mechanisms, >> depending on application behavior. Assuming rather worst-case application >> behavior (e.g. a frustrated surfer continuously issuing HTTP >> requests--translated into route requests--for a mobile server currently >> disconnected), the amount of flooding traffic could indeed be large. This >> is not such an issue for small ad hoc nets, but becomes a consideration for >> those attempting to build larger ones. >> >> The following is NOT intended to be a shameless plug ;-), just an example >> of a protocol using suppression. If others know of any, please contribute >> as well. >> >> A little known feature of TORA is its approach to query suppression during >> route discovery. When a node issues a query for a destination, it is >> flooded throughout the network. Nodes that receive and process the query >> _remember_ this fact by setting a Route-Requested (RR) flag for the given >> destination. Thus the query process is not memoryless. It is >> destination-oriented and independent of the source node issuing the query. >> When a new link appears with a neighbor at a node with its RR flag set, it >> transmits a query for that destination to the neighbor. Thus the query >> propagates like a virus, and is rather similar to the epidemic routing >> concept, and some forms of reliable persistent flooding. The current >> specification states that a node retains its memory of the query >> indefinitely so that, in effect, once issued a query is active forever. We >> are amending this behavior so that the time a RR flag remains set is >> configurable (perhaps 30 seconds or so), we've not yet chosen a figure. >> After this time the RR flag settings time out. Nodes with RR flags set do >> not generate new querys for the same destination, so the mechanism >> suppresses multiple query floods and the behavior you mentioned does not >> occur. We are also adding an approach for query localization that can be >> turned on if desired, and are sorting this out in the simulator as well. >> >> I also do not think it is difficult to add memory/suppression behaviors to >> other on-demand algorithms, so the on-demand vs. proactive debate will >> likely continue. >> >> -scott > >-- >Kevin Grace The MITRE Corporation >781-271-8388 202 Burlington Rd >kgrace@mitre.org Bedford MA, 01730 > > Vincent D. Park Email: vpark@itd.nrl.navy.mil Information Technology Division Voice: 202.767.5098 Naval Research Laboratory Fax: 202.767.1191 4555 Overlook Avenue SW Washington, DC 20375-5000 From owner-manet@itd.nrl.navy.mil Tue Jul 11 12:41:41 2000 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 MAA08481 for ; Tue, 11 Jul 2000 12:41:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA29166 for manet-outgoing; Tue, 11 Jul 2000 10:51:56 -0400 (EDT) Received: from mintaka.isr.umd.edu (mintaka.isr.umd.edu [128.8.111.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA29160 for ; Tue, 11 Jul 2000 10:51:55 -0400 (EDT) Received: from segfault.isr.umd.edu (root@segfault.isr.umd.edu [128.8.111.130]) by mintaka.isr.umd.edu (8.9.3/8.9.3) with ESMTP id KAA08773 for ; Tue, 11 Jul 2000 10:51:39 -0400 (EDT) Received: from segfault.isr.umd.edu (sendmail@localhost [127.0.0.1]) by segfault.isr.umd.edu (8.9.3/8.9.3) with SMTP id KAA23523 for ; Tue, 11 Jul 2000 10:51:42 -0400 (EDT) Received: from localhost (corson@localhost) by segfault.isr.umd.edu (8.9.3/8.9.3) with ESMTP id KAA23519 for ; Tue, 11 Jul 2000 10:51:42 -0400 (EDT) X-Authentication-Warning: segfault.isr.umd.edu: corson owned process doing -bs Date: Tue, 11 Jul 2000 10:51:42 -0400 (EDT) From: "M. Scott Corson" X-Sender: corson@segfault.isr.umd.edu To: MANET WG Subject: MANET Agenda Items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk All, The date for the MANET WG meeting is still not fixed. However, our request for a single mtg slot has been approved. Please submit requests for inclusion on the agenda to Joe or myself. Regards, -scott ******************************************************************************* M. Scott Corson Institute for Systems Research corson@isr.umd.edu A.V. Williams Bldg. (115) Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland Fax: 301-314-8586 College Park, MD 20742 ******************************************************************************* From owner-manet@itd.nrl.navy.mil Tue Jul 11 12:55:00 2000 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 MAA09038 for ; Tue, 11 Jul 2000 12:55:00 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA28955 for manet-outgoing; Tue, 11 Jul 2000 10:45:03 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA28949; Tue, 11 Jul 2000 10:44:59 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA02302; Tue, 11 Jul 2000 10:44:47 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA04113; Tue, 11 Jul 2000 10:43:00 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub1.mitre.org with SMTP id 3839839; Tue, 11 Jul 2000 10:43:55 EST Message-ID: <396B32DE.2D51E09A@mitre.org> Date: Tue, 11 Jul 2000 10:44:46 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Vincent D. Park" CC: manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> <3.0.1.32.20000711102226.00b765f0@pop.itd.nrl.navy.mil> 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 Vincent, >I disagree. Under reasonable operating conditions (i.e., packet loss rates >tolerable by a proactive routing protocol design), the use of a persistent >route request approach will minimize the delay. It appears to me that lost route requests or route replies will result in 1) no route being returned and 2) the network blocking a subsequent route request until the "configurable" time expires. After this time expires, another route request may be initiated which may again get lost. This leads to an increase in delay...not a minimization. >I think you will find it difficult to convince many that both on-demand and >proactive routing approaches don't have their place. Most of the discussion >on the mailing list lately seems to support the notion that each has a >region of applicability. My intention is only to point out that there is a problem that disconnected destinations create and I don't see a solution that is efficient and minimizes delay. -Kevin "Vincent D. Park" wrote: > > At 08:18 AM 7/11/00 -0400, Kevin Grace wrote: > >Hi Scott, > > > >> We are amending this behavior so that the time a RR flag remains set > >> is configurable (perhaps 30 seconds or so), we've not yet chosen a > >> figure. After this time the RR flag settings time out. > >> Nodes with RR flags set do not generate new querys for the same > >> destination, so the mechanism suppresses multiple query floods and the > >> behavior you mentioned does not occur. > > > > > >Hmmm...this appears to make an on-demand protocol much more vulnerable > >to lost route requests and route replies. If a route request or route > >reply is lost, the source is prevented from trying to reinitiate a > >route discovery until the "configurable" time expires. You have, like > >a previous poster, made the decision that efficiency is more important > >than delay. I don't believe this is a desirable property for messages > >that are time sensitive. > > Kevin, > > I think that any proactive routing protocol would be equally vulnerable to > lost control packets. Loss of routing updates or link-state advertisements > can result in an inability to route to certain destinations or worse (e.g., > routing table loops). You are correct that a more persistent route request > approach leads to a robustness issue, thus the need for at least a long > term periodic refresh, but this is not unlike the need to periodically > refresh routing updates in almost any proactive approach. As in any > protocol design the balance between the amount persistence in the route > request and the frequency of the refresh is an engineering tradeoff. > > > > >Again, the underlying problem here is that for on-demand protocols, a > >node does not know which nodes are disconnected from the network. To > >overcome this problem, which is a direct result of the decision not to > >distribute topology information, a node must occasionally retry the > >route request. This results in the protocol designer being forced to > >choose whether efficiency or delay is more important. > > I disagree. Under reasonable operating conditions (i.e., packet loss rates > tolerable by a proactive routing protocol design), the use of a persistent > route request approach will minimize the delay. > > I think it more > >wise to avoid this dilemma altogether and distribute topology > >information. > > I think you will find it difficult to convince many that both on-demand and > proactive routing approaches don't have their place. Most of the discussion > on the mailing list lately seems to support the notion that each has a > region of applicability. > > -Vince > > > > >Regards, > >-Kevin > > > > > > > >"M. Scott Corson" wrote: > >> > >> At 06:04 PM 7/6/00 -0400, you wrote: > >> >It appears to me that the on demand routing protocols have a fatal flaw > >> >which preclude them from scaling well and that the link state approach > >> >is superior. > >> > >> The behavior you mention is (or can be) true for on-demand protocols that > >> utilize memoryless, non-suppressed query/route-request mechanisms, > >> depending on application behavior. Assuming rather worst-case application > >> behavior (e.g. a frustrated surfer continuously issuing HTTP > >> requests--translated into route requests--for a mobile server currently > >> disconnected), the amount of flooding traffic could indeed be large. This > >> is not such an issue for small ad hoc nets, but becomes a consideration for > >> those attempting to build larger ones. > >> > >> The following is NOT intended to be a shameless plug ;-), just an example > >> of a protocol using suppression. If others know of any, please contribute > >> as well. > >> > >> A little known feature of TORA is its approach to query suppression during > >> route discovery. When a node issues a query for a destination, it is > >> flooded throughout the network. Nodes that receive and process the query > >> _remember_ this fact by setting a Route-Requested (RR) flag for the given > >> destination. Thus the query process is not memoryless. It is > >> destination-oriented and independent of the source node issuing the query. > >> When a new link appears with a neighbor at a node with its RR flag set, it > >> transmits a query for that destination to the neighbor. Thus the query > >> propagates like a virus, and is rather similar to the epidemic routing > >> concept, and some forms of reliable persistent flooding. The current > >> specification states that a node retains its memory of the query > >> indefinitely so that, in effect, once issued a query is active forever. We > >> are amending this behavior so that the time a RR flag remains set is > >> configurable (perhaps 30 seconds or so), we've not yet chosen a figure. > >> After this time the RR flag settings time out. Nodes with RR flags set do > >> not generate new querys for the same destination, so the mechanism > >> suppresses multiple query floods and the behavior you mentioned does not > >> occur. We are also adding an approach for query localization that can be > >> turned on if desired, and are sorting this out in the simulator as well. > >> > >> I also do not think it is difficult to add memory/suppression behaviors to > >> other on-demand algorithms, so the on-demand vs. proactive debate will > >> likely continue. > >> > >> -scott > > > >-- > >Kevin Grace The MITRE Corporation > >781-271-8388 202 Burlington Rd > >kgrace@mitre.org Bedford MA, 01730 > > > > > > Vincent D. Park Email: vpark@itd.nrl.navy.mil > Information Technology Division Voice: 202.767.5098 > Naval Research Laboratory Fax: 202.767.1191 > 4555 Overlook Avenue SW > Washington, DC 20375-5000 -- Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Tue Jul 11 13:06:11 2000 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 NAA09619 for ; Tue, 11 Jul 2000 13:06:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA00496 for manet-outgoing; Tue, 11 Jul 2000 11:30:42 -0400 (EDT) Received: from po3.glue.umd.edu (po3.glue.umd.edu [128.8.10.123]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA00491 for ; Tue, 11 Jul 2000 11:30:41 -0400 (EDT) Received: from jewels (macscott.isr.umd.edu [128.8.140.119]) by po3.glue.umd.edu (8.10.1/8.10.1) with SMTP id e6BFUC527336; Tue, 11 Jul 2000 11:30:12 -0400 (EDT) Message-Id: <3.0.6.32.20000711113421.0086b700@popd.ix.netcom.com> X-Sender: mscorson@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 11 Jul 2000 11:34:21 -0400 To: Kevin Grace From: "M. Scott Corson" Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil In-Reply-To: <396B10AC.62E7BD10@mitre.org> References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 08:18 AM 7/11/00 -0400, you wrote: >Hi Scott, > >> We are amending this behavior so that the time a RR flag remains set >> is configurable (perhaps 30 seconds or so), we've not yet chosen a >> figure. After this time the RR flag settings time out. >> Nodes with RR flags set do not generate new querys for the same >> destination, so the mechanism suppresses multiple query floods and the >> behavior you mentioned does not occur. > > >Hmmm...this appears to make an on-demand protocol much more vulnerable >to lost route requests and route replies. If a route request or route >reply is lost, the source is prevented from trying to reinitiate a >route discovery until the "configurable" time expires. You have, like >a previous poster, made the decision that efficiency is more important >than delay. I don't believe this is a desirable property for messages >that are time sensitive. Not really Kevin, but you have to look at TORA a bit more closely to understand the way the RR flag interacts route discovery and construction, the way TORA reliably sends about routing objects and other things. In short, while the RR flag is set, nodes will immediately detect reconnection to a previously partitioned destination and routes will be built at once...TORA's on-demand mode is actually a bit more proactive than some other on-demand algorithms. -scott From owner-manet@itd.nrl.navy.mil Tue Jul 11 13:18:29 2000 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 NAA10196 for ; Tue, 11 Jul 2000 13:18:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA00858 for manet-outgoing; Tue, 11 Jul 2000 11:39:29 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA00852; Tue, 11 Jul 2000 11:39:25 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA11693; Tue, 11 Jul 2000 11:39:10 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id LAA13249; Tue, 11 Jul 2000 11:37:25 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub1.mitre.org with SMTP id 3841026; Tue, 11 Jul 2000 11:38:19 EST Message-ID: <396B3F9E.B86F93F8@mitre.org> Date: Tue, 11 Jul 2000 11:39:10 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Vincent D. Park" CC: manet@itd.nrl.navy.mil Subject: Re: On Demand Flaw References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> <3.0.1.32.20000711102226.00b765f0@pop.itd.nrl.navy.mil> <3.0.1.32.20000711111426.00b765a0@pop.itd.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit >>>I disagree. Under reasonable operating conditions (i.e., packet loss rates >>>tolerable by a proactive routing protocol design), the use of a persistent >>>route request approach will minimize the delay. >> >>It appears to me that lost route requests or route replies will result >>in 1) no route being returned and 2) the network blocking a subsequent >>route request until the "configurable" time expires. After this time >>expires, another route request may be initiated which may again get >>lost. This leads to an increase in delay...not a minimization. >> > >So, when new link rejoins two previously partitioned portions of a network >and the proactive routing protocol advertisement regarding the new link is >lost. How long will 1) no routes between the previously partitioned >portions be unavailable and 2) subsequent route requests?/repairs? be >blocked. ;^) > >-Vince Answers: 1) As I think you know, it depends upon the rate at which Link State Packets are sourced and relayed. The nice thing is that if we know apriori the maximum size of the network and the expected packet error and data rates of the links, we can knowingly tune this rate to provide whatever tradeoff of efficiency and delay we'd like. Contrast this to the on-demand approach where there is no way of predicting overhead. 2) Hmmm...you do know that there are no route requests in a link state protocol, yes? -Kevin "Vincent D. Park" wrote: > > At 10:44 AM 7/11/00 -0400, Kevin Grace wrote: > >Hi Vincent, > > > >>I disagree. Under reasonable operating conditions (i.e., packet loss rates > >>tolerable by a proactive routing protocol design), the use of a persistent > >>route request approach will minimize the delay. > > > >It appears to me that lost route requests or route replies will result > >in 1) no route being returned and 2) the network blocking a subsequent > >route request until the "configurable" time expires. After this time > >expires, another route request may be initiated which may again get > >lost. This leads to an increase in delay...not a minimization. > > > > So, when new link rejoins two previously partitioned portions of a network > and the proactive routing protocol advertisement regarding the new link is > lost. How long will 1) no routes between the previously partitioned > portions be unavailable and 2) subsequent route requests?/repairs? be > blocked. ;^) > > -Vince > > Vincent D. Park Email: vpark@itd.nrl.navy.mil > Information Technology Division Voice: 202.767.5098 > Naval Research Laboratory Fax: 202.767.1191 > 4555 Overlook Avenue SW > Washington, DC 20375-5000 -- Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Tue Jul 11 13:21:17 2000 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 NAA10382 for ; Tue, 11 Jul 2000 13:21:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA27536 for manet-outgoing; Tue, 11 Jul 2000 10:14:39 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA27520 for ; Tue, 11 Jul 2000 10:14:37 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id JAA29172; Tue, 11 Jul 2000 09:14:24 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id JAA00185; Tue, 11 Jul 2000 09:14:13 -0500 (CDT) Date: Tue, 11 Jul 2000 09:14:13 -0500 (CDT) Message-Id: <200007111414.JAA00185@sun.cs.tamu.edu> To: kgrace@mitre.org Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> From kgrace@mitre.org Tue Jul 11 07:00:10 2000 >> >> Hi Nitin, >> >> > Note that with exponential backoff schemes, the time between route >> > discoveries can be increased very rapidly, particularly in the case >> > of partitions (i.e., a backoff scheme would tend to make T large). >> >> An exponential backoff will indeed reduce overhead but at the cost of >> increasing the delay in discovering a route to a recently reconnected >> node. As the protocol designer, you have now consciously made the >> choice that efficiency is more important than delay and imposed a "one Indeed true, although I made that choice only for the sake of illustration. Like I said earlier, we have too many variables to deal with, including mobility patterns, traffic patterns, performance metrics, capabilities of the mobile nodes, etc. Delay falls in the "performance metrics" category. My point was that it is not possible to claim that one scheme is more scalable than another one without defining all of the above, including whether you care about delay, message overhead, which bits can tolerate delay and which cannot, etc. - nitin >> size fits all" treatment of the bits. Not all bits are the same, >> however, and a time sensitive message may now be delayed significantly >> for the sake of efficiency. As a network user, I don't think I'd like >> this behavior when I wanted to send a "I need help now!" message. >> >> > I am not suggesting that on-demand is going to be the method >> > of choice in general. >> >> Agreed! >> >> Regards, >> -Kevin >> >> >> >> Nitin H Vaidya wrote: >> > >> > hi Kevin >> > >> > >> From owner-manet@itd.nrl.navy.mil Mon Jul 10 13:35:29 2000 >> > >> From: Kevin Grace >> > ... >> > >> We know for a link state protocol that its worst case and average case >> > >> overhead are both O(N^2). We also know that for on-demand protocols, >> > >> worst case overhead is O(N^3) though we don't know what its average >> > >> case overhead is. But, we do know that as soon as an on-demand >> > >> protocol has N route requests for disconnected destinations, its >> > >> overhead exceeds that of link state. >> > >> >> > >> Regardless of average case overhead, the more scalable routing >> > >> approach is the one with the lower worst case overhead: link state. >> > >> > Your conclusion may very well be right in certain situations - personally, >> > I do not believe any one approach is going to be a winner in all realistic >> > environments (as characterized by mobility patterns, traffic patterns, >> > performance metrics, capabilities of the mobile nodes, etc.). >> > Trying to prove such a conclusion in general is probably futile. >> > >> > Unless I am missing something, the above analysis ignores time between >> > route discoveries performed by an on-demand protocol. For the >> > sake of argument, suppose that a minimum time interval of T is >> > enforced on consecutive route discoveries by a given node, with tau >> > being the time between link state updates transmitted by a node using >> > a link state protocol. >> > >> > The results of your analysis could change depending on the >> > relationship between T and tau - for instance, what if T/tau > N ? >> > >> > Note that with exponential backoff schemes, the time between route >> > discoveries can be increased very rapidly, particularly in the case >> > of partitions (i.e., a backoff scheme would tend to make T large). >> > >> > I am not suggesting that on-demand is going to be the method >> > of choice in general. >> > >> > The devil is in the details. >> > >> > Cheerio. >> > >> > - nitin >> > >> > >> Also, the advantage of using a link state approach is that we can know >> > >> ahead of time for a given network size, whether the network will have >> > >> enough capacity to disseminate routing information. Contrast this to >> > >> the on-demand approach where we don't know the amount of overhead it >> > >> will generate apriori even when we know the traffic model (who talks >> > >> to whom) since we don't know which nodes will become disconnected. >> > >> >> > >> ********************************************************* >> > >> Kevin H. Grace >> > >> The MITRE Corporation >> > >> 202 Burlington Rd >> > >> Bedford, MA 01730 >> > >> (781) 271-8388 >> > >> kgrace@mitre.org >> > >> >> > >> >> > >> Laurent Viennot wrote: >> > >> > >> > >> > With such a heavy traffic, you'd rather consider a pro-active protocol >> > >> > like OLSR. >> > >> > >> > >> > You can model the traffic with the average number a of active routes >> > >> > per node. Simulations I have read often suppose a<1. If you consider >> > >> > the connections you initiate with your own computer in an every day >> > >> > use, you wouldn't expect a to be greater than 2 or 3. >> > >> > >> > >> > However there may be some applications producing such traffics. If you >> > >> > know some serious examples, I am curious to know them. >> > >> > >> > >> > laurent >> > >> > >> > >> > Kevin Grace writes: >> > >> > > Hi Laurent, >> > >> > > >> > >> > > >> If you call scalable a protocol that has a cost >> > >> > > >> proportional to the size of the topology, you should not be alarmed by >> > >> > > >> what you call the on demand flaw... >> > >> > > >> > >> > > The problem is that on-demand protocols can actually have an overhead >> > >> > > of O(N^3). This is much worse than the overhead of a link state >> > >> > > protocol which is O(N^2). >> > >> > > >> > >> > > To see why an on-demand protocol has an overhead of O(N^3) consider a >> > >> > > network of N nodes in which every node communicates to every other >> > >> > > node. Now consider that the network is severed into two halves, each >> > >> > > with N/2 nodes. Each node in a partition now sends flooded route >> > >> > > requests for N/2 disconnected destinations resulting in N/2 * N/2 >> > >> > > flooded route requests and since each flood consumes N/2 >> > >> > > transmissions, the total resources consumed is O(N^3). >> > >> > > >> > >> > > It still appears to me that on-demand protocols have a fatal flaw that >> > >> > > precludes them from scaling well. >> > >> > > >> > >> > > ********************************************************* >> > >> > > Kevin H. Grace >> > >> > > The MITRE Corporation >> > >> > > 202 Burlington Rd >> > >> > > Bedford, MA 01730 >> > >> > > (781) 271-8388 >> > >> > > kgrace@mitre.org >> > >> > > >> > >> > > >> > >> > > >> > >> > > Laurent Viennot wrote: >> > >> > > > >> > >> > > > Hi Kevin, >> > >> > > > >> > >> > > > The analysis I have mentionned in a previous mail shows that all >> > >> > > > protocols include at least a O(N^2) control overhead where N is the >> > >> > > > number of nodes. This is not surprising since the topology of a radio >> > >> > > > network is certainly proportional to O(N^2) (imagine for example an >> > >> > > > IETF meeting room). If you call scalable a protocol that has a cost >> > >> > > > proportional to the size of the topology, you should not be alarmed by >> > >> > > > what you call the on demand flaw... >> > >> > > > >> > >> > > > laurent >> > >> > > > >> > >> > > >> > >> >> > >> -- >> > >> Kevin Grace The MITRE Corporation >> > >> 781-271-8388 202 Burlington Rd >> > >> kgrace@mitre.org Bedford MA, 01730 >> > >> >> > >> >> >> -- >> Kevin Grace The MITRE Corporation >> 781-271-8388 202 Burlington Rd >> kgrace@mitre.org Bedford MA, 01730 >> >> From owner-manet@itd.nrl.navy.mil Tue Jul 11 13:34:20 2000 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 NAA11015 for ; Tue, 11 Jul 2000 13:34:20 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA29919 for manet-outgoing; Tue, 11 Jul 2000 11:18:19 -0400 (EDT) Received: from sextant (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA29913; Tue, 11 Jul 2000 11:18:11 -0400 (EDT) Message-Id: <3.0.1.32.20000711111426.00b765a0@pop.itd.nrl.navy.mil> X-Sender: vpark@pop.itd.nrl.navy.mil X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 11 Jul 2000 11:14:26 -0400 To: Kevin Grace From: "Vincent D. Park" Subject: Re: On Demand Flaw Cc: manet@itd.nrl.navy.mil In-Reply-To: <396B32DE.2D51E09A@mitre.org> References: <3.0.6.32.20000710170043.0083cc50@popd.ix.netcom.com> <3.0.1.32.20000711102226.00b765f0@pop.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 10:44 AM 7/11/00 -0400, Kevin Grace wrote: >Hi Vincent, > >>I disagree. Under reasonable operating conditions (i.e., packet loss rates >>tolerable by a proactive routing protocol design), the use of a persistent >>route request approach will minimize the delay. > >It appears to me that lost route requests or route replies will result >in 1) no route being returned and 2) the network blocking a subsequent >route request until the "configurable" time expires. After this time >expires, another route request may be initiated which may again get >lost. This leads to an increase in delay...not a minimization. > So, when new link rejoins two previously partitioned portions of a network and the proactive routing protocol advertisement regarding the new link is lost. How long will 1) no routes between the previously partitioned portions be unavailable and 2) subsequent route requests?/repairs? be blocked. ;^) -Vince Vincent D. Park Email: vpark@itd.nrl.navy.mil Information Technology Division Voice: 202.767.5098 Naval Research Laboratory Fax: 202.767.1191 4555 Overlook Avenue SW Washington, DC 20375-5000 From owner-manet@itd.nrl.navy.mil Tue Jul 11 15:27:43 2000 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 PAA17035 for ; Tue, 11 Jul 2000 15:27:42 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA04377 for manet-outgoing; Tue, 11 Jul 2000 13:21:34 -0400 (EDT) Received: from hnl.erg.sri.com (hnl.erg.sri.com [128.18.100.13]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA04371 for ; Tue, 11 Jul 2000 13:21:31 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by hnl.erg.sri.com (8.9.1/8.9.0) with ESMTP id KAA05586; Tue, 11 Jul 2000 10:21:18 -0700 (PDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10587; Tue, 11 Jul 2000 10:21:04 -0700 (PDT) Message-Id: <200007111721.KAA10587@pit.erg.sri.com> To: Laurent.Viennot@inria.fr cc: manet@itd.nrl.navy.mil, ogier@erg.sri.com Subject: Re: Overhead analysis In-reply-to: Your message of "Tue, 11 Jul 2000 11:05:41 +0200." <14698.58213.81953.143245@cupidon.inria.fr> Date: Tue, 11 Jul 2000 10:21:04 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Larent writes: > Richard writes: > > > > Hello Laurent, > > > > > Both protocol approaches behave differently according to mobility and > > > activity mainly. To summarize: flooding (reactive) protocols react > > > better to high mobility and hello (pro-active) protocols react better > > > to high activity. We agree on this. > > > > Yes, we agree on this. But what if there is both high mobility > > and high activity? My *guess* is that in this case, an efficient > > proactive protocol generates less control traffic. > > My reasoning is that every node needs to maintain frequently > > updated paths to every other node, and efficient proactive protocols > > do this more efficiently than flooding. > > > > Yes, this is confirmed by our analysis. We can get regions of the > plane mobility x activity favorable to each protocol flavor. This > gives something like this : > > > activity > ^ > |---------------| > | | > |** | > | * proactive | > | * | > | * | > | **** | > | *****| > | reactive | > | | > ----------------|-------> mobility > > An activity of 2 or 3 active routes per node is sufficient for > proactive protocols to outperform on-demand protocols. All the > nodes talking to all of the other nodes corresponds to an activity of > N active routes per node. You don't need so high activity to see > proactive protocols behaving better than reactive protocols. > > You can find similar curves for the random graph model, the geometric > model (strip and square) and the grid in our research report RR-3965 > http://menetou.inria.fr/~viennot/postscripts/overhead.ps > > laurent Laurent, Your analysis is interesting, and I am glad to see it confirms my intuition. But your plane diagram seems contrary to your earlier statement (which I agree with) that reactive protocols favor high mobility (or proactive protocols favor low mobility). Can you explain this discrepancy? I would expect that the diagram would look more like the following: activity ^ |---------------| | | | | | proactive | | ** | | ** | | ***** | |**** | | reactive | | | ----------------|-------> mobility Regards, Richard ----------------------- 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 ------------------------ From owner-manet@itd.nrl.navy.mil Wed Jul 12 09:02:28 2000 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 JAA20546 for ; Wed, 12 Jul 2000 09:02:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA20472 for manet-outgoing; Wed, 12 Jul 2000 07:04:06 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id HAA20467 for ; Wed, 12 Jul 2000 07:04:04 -0400 (EDT) Received: (qmail 3506 invoked by uid 11205); 12 Jul 2000 11:03:47 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14700.20625.683703.678624@cupidon.inria.fr> Date: Wed, 12 Jul 2000 13:03:45 +0200 (CEST) To: Richard Cc: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <200007111721.KAA10587@pit.erg.sri.com> References: <14698.58213.81953.143245@cupidon.inria.fr> <200007111721.KAA10587@pit.erg.sri.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Richard, Both diagrams are possible depending on the topology profile of the network. The size of the packets flooded for the reactive protocols versus the size the topology update packets for proactive protocols is also very important. laurent Richard writes: > > > Larent writes: > > Yes, this is confirmed by our analysis. We can get regions of the > > plane mobility x activity favorable to each protocol flavor. This > > gives something like this : > > > > > > activity > > ^ > > |---------------| > > | | > > |** | > > | * proactive | > > | * | > > | * | > > | **** | > > | *****| > > | reactive | > > | | > > ----------------|-------> mobility > > > > Laurent, > > Your analysis is interesting, and I am glad to see it confirms > my intuition. But your plane diagram seems contrary to your earlier > statement (which I agree with) that reactive protocols favor > high mobility (or proactive protocols favor low mobility). > Can you explain this discrepancy? I would expect that the > diagram would look more like the following: > > activity > ^ > |---------------| > | | > | | > | proactive | > | ** | > | ** | > | ***** | > |**** | > | reactive | > | | > ----------------|-------> mobility > From owner-manet@itd.nrl.navy.mil Wed Jul 12 11:03:27 2000 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 LAA26224 for ; Wed, 12 Jul 2000 11:03:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA22842 for manet-outgoing; Wed, 12 Jul 2000 09:19:54 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA22837 for ; Wed, 12 Jul 2000 09:19:52 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e6CDJYf16514; Wed, 12 Jul 2000 15:19:34 +0200 (MET DST) Message-Id: <3.0.1.32.20000712152448.022a5670@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 12 Jul 2000 15:24:48 +0200 To: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis Cc: laurent.viennot@inria.fr In-Reply-To: <200007111721.KAA10587@pit.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Zygmunt As promized, we tried to get into an analysis of ZRP in the framework of our report. We first try to analyse ZRP over DSDV in order to cross check with your paper. And second, we try to do the analysis of ZRP over OLSR. It comes that the two plots are very different. To simplify we only consider mobility parameter. overheads are expressed in packet number per second (as in your paper). A more involved analysis will need to consider the bandwidth in packets. We also consider the case where the network is a narrow strip of length L, because it is easier to handle. We could also add the activity parameter but the formulas would be longer. Unfortunately we don't have a complete analysis of DSDV, so that we borrow some results from your paper. What is important is the order of magnitude of the parameters before Z_R and 1/Z_R. In summary we obtain for Z_R>0 ZRP over DSDV: h*N+tau*N+mu*N^2*a*L*(1-Z_R/L)/Z_R+beta*mu*N^2*Z_R/L ZRP over OLSR: h*N+4*tau*N*Z_R+mu*N^2*a*L*(1-Z_R/L)/Z_R+4*mu*N*Z_R Notice that OLSR transforms some pro-active O(N^2) overheads in O(N) overheads because of multipoint relay optimization. As you can see the order change in overheads complexity significantly modifies the plot shapes. Indeed the optimal Z_R with DSDV is the closest value between 1 and L to sqrt(a*beta)*L. For OLSR the optimal Z_R is the closest value between 1 and L to sqrt(a*N*mu*L/(tau+mu)). When N increases, this value will be likely be L. Therefore the optimal ZRP will act as a pure proactive scheme. Warning: It does not mean that pure pro-active protocols systematically outperform pure reactive protocols, since our model only holds for Z_R > 0. >ZRP/DSDV > ^ > | > | * * > | * * > | * * > | * * > | * * > | * * > | * * > | *** > | > ---------|--------------> Zone Radius > the optimal ZR > > ^ZRP/OLSR > | > | * > | * > | * > | * > | * > | * > | * > | * > | * > -------------------|----> Zone Radius > the optimal ZR Best regards, Philippe Detailled analysis for ZRP over DSDV 1. The fixed overhead of ZRP/DSDV seems to be h*N+tau*N packets per second where h: hello period tau: periodic route update N: total number of nodes in the network Let mu be the mobility parameter defined in our repport. The variable overhead is in two components. 2. the interzone bordercast flooding: mu*a*L*N^2*(1-Z_R/L)/Z_R a: number of active routes per node L: half length of the strip Z_R: zone radius Notice that (1-Z_R/L) is the probability that a route length exceeds Z_R and mu*L is the rate at which a route of length L fails. We assume that the flooding via bordercast is ideal and costs only N/Z_R (omitting transmissions over multicast trees and possible loop back in flooding due to non-overlapping multicast tree). 3. the intrazone topology change update: mu*beta*N^2*Z_R/L beta*N*Z(R)/L is the number of packets generated by a neighbor change. Your paper suggests beta approximatively equal to 2. Is the rate of neighbor change be mu*N, as suggested in your paper? Consequently the total overhead should be h*N+tau*N+mu*a*L*N^2*(1-Z_R/L)/Z_R+mu*beta*N^2*Z_R/L This quantity attains its maximum at Z_R=sqrt(a/beta)L independently of mu, which is confirmed by your paper. Detailled analysis for ZRP over OLSR we have 1. fixed overhead: h*N+2*tau*N*Z_R packet per second h: hello frequency tau: TC-PDU frequency Notice that the number of multipoint relays is actually finite (2 per node in a strip, 4 or little more in 2D) and that each TC-PDU must be repeated 2*ZR times to cover the intra-zone area. This is the intend of OLSR protocol to have O(1) multipoint relay set size (O(log N) in random graphs). The variable overheads are in two components: 2. the interzone bordercast flooding: mu*a*L*N^2*(1-Z_R/L)/Z_R 3. the intrazone component: mu*4*Z_R*N A node will generate an extra TC-PDU only if one of its two multipoint relays is changed, thus a rate of 2*mu*N. The TC-PDU is retransmitted ZR times in the intra-zone area. The total overhead is therefore h*N+2*tau*N*Z_R+mu*a*L*N^2*(1-Z_R/L)/Z_R+mu*4*Z_R*N Notice that this overhead is significantly lower than the overhead with DSDV, since many terms in N^2 have been changed in N. The maximum is attained at the closest value of Z_R to sqrt(N*a*L/(2*tau+4*mu)), i.e O(sqrt(N)). When the number of nodes N is important the optimal value is very likely L. From owner-manet@itd.nrl.navy.mil Wed Jul 12 12:22:59 2000 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 MAA00638 for ; Wed, 12 Jul 2000 12:22:59 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24949 for manet-outgoing; Wed, 12 Jul 2000 10:27:56 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24941 for ; Wed, 12 Jul 2000 10:27:54 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13CNUA-0000oP-00 for manet@itd.nrl.navy.mil; Wed, 12 Jul 2000 15:27:38 +0100 Date: Wed, 12 Jul 2000 15:27:37 +0100 (BST) From: Eleftheria Menegou To: manet@itd.nrl.navy.mil Subject: PRMA Implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear All: I am working towards my MSc thesis and currently studying the PRMA protocol. As I am new in this field, is any one that can provide me with a prototype implementation of PRMA to have this as a reference point on my study? I am working with MAISIE/PARSEC and C. Thanks in advance. Eleftheria From owner-manet@itd.nrl.navy.mil Wed Jul 12 18:02:13 2000 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 SAA16589 for ; Wed, 12 Jul 2000 18:02:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA02822 for manet-outgoing; Wed, 12 Jul 2000 15:02:55 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA02815 for ; Wed, 12 Jul 2000 15:02:53 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA11611 for ; Wed, 12 Jul 2000 15:02:34 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id PAA09476 for ; Wed, 12 Jul 2000 15:00:47 -0400 (EDT) Received: from kbrayer.mitre.org (129.83.36.88) by mailhub1.mitre.org with SMTP id 3855318; Wed, 12 Jul 2000 15:02:36 EST Message-ID: <396CC512.9F3A8737@mitre.org> Date: Wed, 12 Jul 2000 15:20:54 -0400 From: Kenneth Brayer Reply-To: kb@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.73C-20000509M (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil CC: "Roome Jr.,Theodore F." Subject: Need Paper Reviewers X-Priority: 1 (Highest) References: <3.0.1.32.20000712152448.022a5670@menetou.inria.fr> Content-Type: multipart/mixed; boundary="------------51683B580E387AAD045121CD" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. --------------51683B580E387AAD045121CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I hope this isn't a violation of list practice but a friend of mine is an Editor for the IEEE Trans. on Aerospace and Electronic Systems and he has received a paper which unfortunately got lost for a while and feels under pressure to get it reviewed. It is entitled, Layernet: An Ad Hoc Radio Network Self-Organization Protocol, by H.Y. Huang, A. Khendry, and T.G. Robertazzi, of ATT, Univ. of NY at Stony Brook, and Satyam Computer services of India. The paper references publications by S. Corson, J. Macker, M. Gerla, Z. Haas, M. Pearlman, N.H. Vaidya, V. Park, and C.E. Perkins among others. Would it be possible to find 2 or 3 volunreers who could look at the paper for us. Kenneth Brayer --------------51683B580E387AAD045121CD Content-Type: text/x-vcard; charset=us-ascii; name="kb.vcf" Content-Description: Card for Kenneth Brayer Content-Disposition: attachment; filename="kb.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brayer;Kenneth tel;fax:781-271-3803 tel;work:781-271-5254 x-mozilla-html:FALSE org:The MITRE Corporation version:2.1 email;internet:kb@mitre.org title:Principal Network and Distributed Systems Engineer adr;quoted-printable:;;Mail Stop S209=0D=0A202 Burlington Road=0D=0A;Bedford;MA;01730;USA x-mozilla-cpt:;1 fn:Kenneth Brayer end:vcard --------------51683B580E387AAD045121CD-- From owner-manet@itd.nrl.navy.mil Wed Jul 12 20:43:59 2000 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 UAA19118 for ; Wed, 12 Jul 2000 20:43:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA07603 for manet-outgoing; Wed, 12 Jul 2000 18:52:03 -0400 (EDT) Received: from mintaka.isr.umd.edu (mintaka.isr.umd.edu [128.8.111.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA07598 for ; Wed, 12 Jul 2000 18:52:01 -0400 (EDT) Received: from segfault.isr.umd.edu (root@segfault.isr.umd.edu [128.8.111.130]) by mintaka.isr.umd.edu (8.9.3/8.9.3) with ESMTP id SAA27352 for ; Wed, 12 Jul 2000 18:51:41 -0400 (EDT) Received: from segfault.isr.umd.edu (sendmail@localhost [127.0.0.1]) by segfault.isr.umd.edu (8.9.3/8.9.3) with SMTP id SAA01195 for ; Wed, 12 Jul 2000 18:51:44 -0400 (EDT) Received: from localhost (corson@localhost) by segfault.isr.umd.edu (8.9.3/8.9.3) with ESMTP id SAA01191 for ; Wed, 12 Jul 2000 18:51:44 -0400 (EDT) X-Authentication-Warning: segfault.isr.umd.edu: corson owned process doing -bs Date: Wed, 12 Jul 2000 18:51:44 -0400 (EDT) From: "M. Scott Corson" X-Sender: corson@segfault.isr.umd.edu To: MANET WG Subject: 48th IETF DRAFT Agenda (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk For everyone's information...MANET is currently scheduled for thursday afternoon. ******************************************************************************* M. Scott Corson Institute for Systems Research corson@isr.umd.edu A.V. Williams Bldg. (115) Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland Fax: 301-314-8586 College Park, MD 20742 ******************************************************************************* ---------- Forwarded message ---------- Date: Wed, 12 Jul 2000 18:32:32 -0400 From: agenda@ietf.org To: iesg@ietf.org, wgchairs@ietf.org Subject: 48th IETF DRAFT Agenda I have posted the following DRAFT agenda on the web site. ======================================================================== This is a DRAFT agenda and therefore changes will most likely occur. The following requests have not been scheduled yet: DNSEXT AAA DISMAN POLICY SNMPV3 A final agenda should be posted by Monday, July 17, 2000. DRAFT Agenda of the Forty-eighth IETF July 30-August 4, 2000 As of 07/12/00 SUNDAY, July 30, 2000 1200-1900 Registration - 1530-1600 Newcomer's Orientation - 1600-1630 IETF Standards Process Orientation - 1700-1900 Welcome Reception - MONDAY, July 31, 2000 0800-1930 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting INT ipobt IP Over Bluetooth BOF OPS bmwg Benchmarking Methodology WG OPS rap Resource Allocation Protocol WG RTG ipo IP Over Optical WG SEC stime Secure Network Time Protocol WG TSV rmt Reliable Multicast Transport WG TSV spirits Service in the PSTN/IN Requesting Internet Service WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG APP msgtrk Message Tracking WG OPS sgm Small Group Multicast BOF SEC aft Authenticated Firewall Traversal WG TSV ecm Endpoint Congestion Management WG TSV sip Session initiation Protocol WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP imapext Internet Message Access Protocol Extension WG INT idn Internationalized Domain Names WG OPS tewg Traffic Engineering WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG RTG ospf Open Shortest Path First IGP WG SEC smime S/MIME Mail Security WG 1730-1930 Break 1930-2200 Evening Sessions APP spatial Spatial Location BOF INT dhc Dynamic Host Configuration WG INT ipcdn IP Over Cable Data Network WG OPS mboned MBONE Depoloyement WG SEC ipsra IP Security Remote Access WG TSV diffserv Differentiated Services WG TSV mmusic Multiparty Multimedia Session Control WG TUESDAY, August 1, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP vpim Voice Profile for Internet Mail WG INT dhc Dynamic Host Configuration WG OPS snmpconf Configuration Management with SNMP WG RTG pim Protocol Independent Multicast WG SEC pkix Public-Key Infrastructure (X.509) WG TSV enum Telephone Number Mapping WG TSV issll Integrated Services over Specific Link Layers WG TSV nfsv4 Network File System Version 4 WG 1130-1300 Break 1300-1400 Afternoon Sessions I INT zeroconf Zero Configuration Networking WG OPS adslmib ADSL MIB WG OPS tewg Traffic Engineering WG TSV ieps International Emergency Preparedness Scheme BOF TSV ippm IP Performance Metrics WG TSV nfsv4 Network File System Version 4 WG 1415-1515 Afternoon Sessions II APP nntpext NNTP Extensions WG INT frnetmib Frame Relay Service MIB WG OPS grip G & R for Security Incident Processing WG OPS rap Resource Allocation Protocol WG TSV sin SIP/IN Interworking BOF TSV rmt Reliable Multicast Transport WG 1515-1545 Break (Refreshments provided) - 1545-1645 Afternoon Sessions III APP impp Instant Messaging and Presence Protocol WG APP ipp Internet Printing Protocol WG INT ipngwg IPNG WG RTG ssm Source-Specific Multicast BOF SEC tls Transport Layer Security WG TSV tsvwg Transport Area Working Group 1700-1800 Afternoon Sessions IV APP impp Instant Messaging and Presence Protocol WG APP ipp Internet Printing Protocol WG RTG idmr Inter-Domain Multicast Routing WG SEC tls Transport Layer Security WG TSV rspool Reliable Server Pooling BOF WEDNESDAY, August 2, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP fax Internet Fax WG INT idn Internationalized Domain Names WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC pkix Public-Key Infrastructure (X.509) WG TSV avt Audio/Video Transport WG TSV diffserv Differentiated Services WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP calsch Calendaring and Scheduling WG INT ipngwg IPNG WG OPS rmonmib Remote Network Monitoring WG RTG msdp Multicast Source Discovery Protocol WG SEC secsh Secure Shell WG TSV pilc Performance Implications of Link Characteristics WG TSV sip Session initiation Protocol WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP deltav Web Versioning and Configuration Management WG INT l2tpext Layer Two Tunneling Protocol Extensions WG OPS ngtrans Next Generation Transition WG RTG rtgarea Routing Area Meeting SEC krbwg Kerberos BOF TSV ips IP Storage BOF TSV mmusic Multiparty Multimedia Session Control WG 1730-1930 Break 1930-2200 Open Plenary - o Welcome - Fred Baker, IETF Chair o IAB Open Plenary o IESG Open Plenary THURSDAY, August 3, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP beep Blocks Extensible Exchange Protocol WG APP webdav WWW Distributed Authoring and Versioning WG INT dnsop Domain Name Server Operations WG RTG mpls Multiprotocol Label Switching WG SEC idwg Intrusion Detection Exchange Format WG TSV nat Network Address Translators WG TSV iptel IP Telephony WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP trade Internet Open Trading Protocol WG APP vpim Voice Profile for Internet Mail WG INT ipngwg IPNG WG OPS rmonmib Remote Network Monitoring WG RTG manet Mobile Ad-hoc Networks WG SEC saag Open Security Area Directorate Meeting TSV avt Audio/Video Transport WG TSV sigtran Signaling Transport WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP webdav WWW Distributed Authoring and Versioning WG INT ipfc IP Over Fibre Channel WG OPS opsarea Operation and Management Area Open Meeting RTG nbvpn Network-Based VPNs BOF SEC xmldsig XML Digital Signatures WG TSV megaco Media Gateway Control WG TSV rohc Robust Header Compression WG FRIDAY, August 4, 2000 0800-1000 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP beep Blocks Extensible Exchange Protocol WG INT ipoptr IP over Packet Transport Rings BOF OPS snmpconf Configuration Management with SNMP WG RTG gsmp General Switch Management Protocol WG SEC idwg Intrusion Detection Exchange Format WG TSV rohc Robust Header Compression WG AREA DIRECTORS APP Applications Patrik Faltstrom/Cisco and Ned Freed/Innosoft International, Inc. GEN General Interest Fred Baker/Cisco Systems INT Internet Thomas Narten/IBM Corp. and Erik Nordmark/Sun Microsystems OPS Operations & Management Randy Bush/Verio, Inc. and Bert Wijnen/Lucent Technologies RTG Routing Rob Coltun/Siara Systems and Dave Oran/Cisco Systems SEC Security Jeff Schiller/MIT and Marcus Leech/Nortel TSV Transport Scott Bradner/Harvard Univ. and Allison Mankin/USC/ISI USV User Services April Marine/Nominum, Inc. ========================================================================= From owner-manet@itd.nrl.navy.mil Thu Jul 13 14:09:13 2000 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 OAA03510 for ; Thu, 13 Jul 2000 14:09:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA22808 for manet-outgoing; Thu, 13 Jul 2000 12:02:31 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA22802 for ; Thu, 13 Jul 2000 12:02:29 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA10031 for ; Thu, 13 Jul 2000 12:02:27 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA08716 for ; Thu, 13 Jul 2000 12:00:38 -0400 (EDT) Received: from kbrayer.mitre.org (129.83.36.88) by mailhub2.mitre.org with SMTP id 3924435; Thu, 13 Jul 2000 12:02:24 EST Message-ID: <396DEC5D.A3D41DA0@mitre.org> Date: Thu, 13 Jul 2000 12:20:44 -0400 From: Kenneth Brayer Reply-To: kb@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.73C-20000509M (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Paper Reviwer Request Followup Content-Type: multipart/mixed; boundary="------------54AD5323AB1E94DFE30DDDD8" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. --------------54AD5323AB1E94DFE30DDDD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks all for your responses. I am over subscribed. Please don't send any more responses. Ken --------------54AD5323AB1E94DFE30DDDD8 Content-Type: text/x-vcard; charset=us-ascii; name="kb.vcf" Content-Description: Card for Kenneth Brayer Content-Disposition: attachment; filename="kb.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brayer;Kenneth tel;fax:781-271-3803 tel;work:781-271-5254 x-mozilla-html:FALSE org:The MITRE Corporation version:2.1 email;internet:kb@mitre.org title:Principal Network and Distributed Systems Engineer adr;quoted-printable:;;Mail Stop S209=0D=0A202 Burlington Road=0D=0A;Bedford;MA;01730;USA x-mozilla-cpt:;1 fn:Kenneth Brayer end:vcard --------------54AD5323AB1E94DFE30DDDD8-- From owner-manet@itd.nrl.navy.mil Fri Jul 14 00:38:33 2000 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 AAA12696 for ; Fri, 14 Jul 2000 00:38:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA04845 for manet-outgoing; Thu, 13 Jul 2000 22:35:00 -0400 (EDT) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA04840 for ; Thu, 13 Jul 2000 22:34:59 -0400 (EDT) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6E2YuJ16104 for ; Thu, 13 Jul 2000 22:34:57 -0400 (EDT) Message-Id: <200007140234.e6E2YuJ16104@breeze.research.telcordia.com> To: manet@itd.nrl.navy.mil Subject: "MobiCom 2000: Discounted registration ends on July 15" Date: Thu, 13 Jul 2000 22:34:56 -0400 From: Ashutosh Dutta Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk (Our apologies for duplicate transmission) ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from: IBM Research, HP Laboratories, Compaq,Nokia, TRW, AT&T Laboratories Cambridge, Xerox PARC, 3Com, BBN/GTE, Aether Systems, Nortel Networks, Metricom, Boston Communications Group, Toshiba America Research,ThinAirApps CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-manet@itd.nrl.navy.mil Fri Jul 14 17:26:42 2000 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 RAA26631 for ; Fri, 14 Jul 2000 17:26:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA24893 for manet-outgoing; Fri, 14 Jul 2000 15:29:56 -0400 (EDT) Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA24888 for ; Fri, 14 Jul 2000 15:29:53 -0400 (EDT) Received: from pearlman (140.new-york-05.ny.dial-access.att.net [12.68.4.140]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with SMTP id PAA11220; Fri, 14 Jul 2000 15:29:39 -0400 (EDT) Received: by localhost with Microsoft MAPI; Fri, 14 Jul 2000 15:29:21 -0400 Message-ID: <01BFEDA8.48861A60.mrp12@cornell.edu> From: Marc Pearlman Reply-To: "mrp12@cornell.edu" To: "'jacquet@menetou.inria.fr'" , "manet@itd.nrl.navy.mil" Cc: "laurent.viennot@inria.fr" , "'haas@ee.cornell.edu'" Subject: RE: Overhead analysis Date: Fri, 14 Jul 2000 15:25:26 -0400 Organization: Cornell University X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 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 Philippe, > In summary we obtain for Z_R>0 > ZRP over DSDV: h*N+tau*N+mu*N^2*a*L*(1-Z_R/L)/Z_R+beta*mu*N^2*Z_R/L > ZRP over OLSR: h*N+4*tau*N*Z_R+mu*N^2*a*L*(1-Z_R/L)/Z_R+4*mu*N*Z_R First of all, thank you for taking the time to extend your protocol analyses to the ZRP framework. I've looked over your ZRP traffic equations for the 1-D narrow strip, and they look fine to me. Your results seem to support the assertions that we've made thus far about the ZRP. Decomposing your final traffic equations into their respective proactive and reactive components, we have: reactive proactive DSDV mu*N^2*a*L*(1-Z_R/L)/Z_R h*N + tau*N + beta*mu*N^2*Z_R/L OLSR mu*N^2*a*L*(1-Z_R/L)/Z_R h*N + 4*tau*N*Z_R + 4*mu*N*Z_R For the DSDV and OLSR implementations of IARP, the reactive (IERP) traffic is identical, and of the form C*(1/Z_R) - B. The DSDV and OLSR implementations of IARP generate different amounts of proactive traffic, but both expressions take on the form A*(Z_R)+ B. Thus, the total ZRP traffic takes on the form A*(Z_R) + B + C*(1/Z_R). A and C are positive, B may be positive or negative. (Please excuse my reuse of the coefficients A,B,C. They're just intended to serve as place holders) If you plot the equation A*(Z_R) + B + C*(1/Z_R), you'll *always* end up with a convex ("U-shaped") curve. Depending on the actual values of A,B and C, you may only get the increasing or decreasing section of the "U". An example of this is your ZRP/OLSR curve. > ^ZRP/OLSR > | > | * > | * > | * > | * > | * > | * > | * > | * > | * > -------------------|----> Zone Radius > the optimal ZR The fact that your curve is strictly decreasing is due to your assumption of large N. > For OLSR the optimal Z_R is the closest value between 1 and L to sqrt(a*N*mu*L/(tau+mu)). When N increases, > this value will be likely be L. Therefore the optimal ZRP will act as a pure proactive scheme. As N decreases, the optimal zone radius may be smaller than L, indicating that a hybrid approach outperforms purely proactive routing. The important point to walk away with here is that the ZRP/DSDV and ZRP/OLSR curves aren't really shaped so differently. They both belong to the family of convex (U-shaped) curves. Given that OLSR is a very efficient proactive protocol, it seems reasonable to expect that *any* IARP implementation will produce a convex (U-shaped) traffic curve. regards, Marc From owner-manet@itd.nrl.navy.mil Fri Jul 14 22:59:10 2000 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 WAA23497 for ; Fri, 14 Jul 2000 22:59:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA29913 for manet-outgoing; Fri, 14 Jul 2000 21:14:15 -0400 (EDT) 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 VAA29908 for ; Fri, 14 Jul 2000 21:14:14 -0400 (EDT) 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 SAA12547; Fri, 14 Jul 2000 18:14:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id SAA21846; Fri, 14 Jul 2000 18:14:02 -0700 X-Virus-Scanned: Fri, 14 Jul 2000 18:14:02 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdhbj3Xf; Fri, 14 Jul 2000 18:13:54 PDT Message-ID: <396FBA36.151E8DFA@iprg.nokia.com> Date: Fri, 14 Jul 2000 18:11:18 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mobile Ad Hoc IETF working group CC: Elizabeth Royer , "Samir R. Das" Subject: New AODV drafts available 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 folks, We have broken down the previous draft specification for AODV as follows: - A base specification, which is ready for working group Last Call - A multicast specification, which still needs more implementation experience - A broadcast specification, which is now completely independent of AODV - An autoconfiguration specification, which is similarly independent of AODV - A specification for Quality of Service extensions, which uses AODV. I also expect to submit a Service Location draft whenever the Internet Draft directories become available again. This draft will consist of the text that was removed from version ...-03 of the base protocol. The specifications are available at: http://www.iprg.nokia.com/~charliep/txt/aodvid/. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Sun Jul 16 21:49:24 2000 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 VAA27887 for ; Sun, 16 Jul 2000 21:49:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA21276 for manet-outgoing; Sun, 16 Jul 2000 19:58:38 -0400 (EDT) Received: from hnl.erg.sri.com (hnl.erg.sri.com [128.18.100.13] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA21271 for ; Sun, 16 Jul 2000 19:58:36 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by hnl.erg.sri.com (8.9.1/8.9.0) with ESMTP id QAA04307 for ; Sun, 16 Jul 2000 16:58:33 -0700 (PDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.8.8+Sun/8.8.8) with ESMTP id QAA13385 for ; Sun, 16 Jul 2000 16:58:22 -0700 (PDT) Message-Id: <200007162358.QAA13385@pit.erg.sri.com> To: Mobile Ad Hoc IETF working group Subject: Internet draft for TBRPF is available Date: Sun, 16 Jul 2000 16:58:21 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk A new Internet draft is available that describes TBRPF: http://www.ietf.org/internet-drafts/draft-ogier-manet-tbrpf-00.txt Title: Topology Broadcast based on Reverse-Path Forwarding (TBRPF) Authors: Bhargav Bellur, Richard G. Ogier, Fred L. Templin Abstract: Topology Broadcast based on Reverse-Path Forwarding (TBRPF) is a link-state routing protocol designed for use in a mobile ad-hoc network (MANET) or an internet. TBRPF provides each node with the state of each link in the network, but does so much more efficiently than flooding (e.g., OSPF). TBRPF uses the concept of reverse-path forwarding to efficiently and reliably broadcast each link-state update along the minimum-hop-path tree rooted at the source of the update. The broadcast trees (one tree per source) are updated dynamically using the topology information that is received along the trees themselves, thus requiring very little additional overhead for maintaining the trees. This document describes TBRPF and discusses details for the implementation of TBRPF in IPv4-based MANETs. Richard ----------------------- 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 ------------------------ From owner-manet@itd.nrl.navy.mil Mon Jul 17 16:51:05 2000 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 QAA02118 for ; Mon, 17 Jul 2000 16:51:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA10451 for manet-outgoing; Mon, 17 Jul 2000 15:07:28 -0400 (EDT) Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA10445 for ; Mon, 17 Jul 2000 15:07:24 -0400 (EDT) Received: from localhost by cse.uta.edu (8.9.0/8.9.0) with SMTP id OAA13946; Mon, 17 Jul 2000 14:01:17 -0500 (CDT) Date: Mon, 17 Jul 2000 14:01:17 -0500 (CDT) From: Ramesh Yeraballi X-Sender: ramesh@cse Reply-To: Ramesh Yeraballi To: Sajal Das Subject: WoWMoM-2000 Call for Participation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Please accept my apologies if you receive multiple copies of this announcment. --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA --------------------------------------------------------------------- Sponsors: * ACM SigMobile Support from: * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Panel -- TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-manet@itd.nrl.navy.mil Tue Jul 18 18:24:49 2000 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 SAA22784 for ; Tue, 18 Jul 2000 18:24:48 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA13680 for manet-outgoing; Tue, 18 Jul 2000 16:49:40 -0400 (EDT) Received: from hotmail.com (f43.law4.hotmail.com [216.33.149.43]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA13675 for ; Tue, 18 Jul 2000 16:49:39 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Jul 2000 13:49:40 -0700 Received: from 143.167.2.14 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 18 Jul 2000 GMT X-Originating-IP: [143.167.2.14] From: "Saket Agarwal" To: manet@itd.nrl.navy.mil Subject: IP Address Allocation Date: Tue, 18 Jul 2000 20:49:39 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2000 20:49:40.0210 (UTC) FILETIME=[B1519520:01BFF0F9] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi everyone, I have recently joined the manet group and am currently pursuing a theoretical analysis of different ad hoc networks as a thesis After a lot of background reading(maybe not enough), i was wondering about how IP addresses are going to be assigned to each node i.e. if each node will have a permanent address or if it will change as the node moves in the network. What is the criteria for the latter. Is this problem protocol-specific, being different in AODV to DSR to any other protocol, I am sorry if this issue has been discussed previously, Thanks Rgds Saket Agarwal ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Tue Jul 18 20:02:12 2000 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 UAA27558 for ; Tue, 18 Jul 2000 20:02:11 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA16385 for manet-outgoing; Tue, 18 Jul 2000 18:38:40 -0400 (EDT) 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 SAA16380 for ; Tue, 18 Jul 2000 18:38:38 -0400 (EDT) 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 PAA06008; Tue, 18 Jul 2000 15:38:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA07507; Tue, 18 Jul 2000 15:38:35 -0700 X-Virus-Scanned: Tue, 18 Jul 2000 15:38:35 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdUZd1YR; Tue, 18 Jul 2000 15:38:31 PDT Message-ID: <3974DBC6.5381F1CB@iprg.nokia.com> Date: Tue, 18 Jul 2000 15:35:50 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Saket Agarwal CC: manet@itd.nrl.navy.mil Subject: Re: IP Address Allocation 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 Saket, The problem of IP address allocation has been discussed quite a bit, but I am certain it needs yet more discussion. It is possible for IP addresses to remain static or to be reassigned after movement. The problem is not protocol specific. We have made an attempt at a generic protocol specification. See the following for details: http://www.iprg.nokia.com/~charliep/txt/aodvid/autoconf.txt Regards, Charlie P. Saket Agarwal wrote: > Hi everyone, > I have recently joined the manet group and am currently pursuing a > theoretical analysis of different ad hoc networks as a thesis > After a lot of background reading(maybe not enough), i was wondering about > how IP addresses are going to be assigned to each node i.e. if each node > will have a permanent address or if it will change as the node moves in the > network. What is the criteria for the latter. Is this problem > protocol-specific, being different in AODV to DSR to any other protocol, > I am sorry if this issue has been discussed previously, > Thanks > Rgds > Saket Agarwal > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Wed Jul 19 08:15:19 2000 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 IAA01958 for ; Wed, 19 Jul 2000 08:15:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA24718 for manet-outgoing; Wed, 19 Jul 2000 06:22:57 -0400 (EDT) Received: from hotmail.com (f50.law4.hotmail.com [216.33.149.50]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA24713 for ; Wed, 19 Jul 2000 06:22:56 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Jul 2000 03:22:55 -0700 Received: from 143.167.2.14 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 19 Jul 2000 GMT X-Originating-IP: [143.167.2.14] From: "Saket Agarwal" To: manet@itd.nrl.navy.mil Subject: IP Address Allocation Date: Wed, 19 Jul 2000 10:22:55 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jul 2000 10:22:55.0978 (UTC) FILETIME=[4DDCE4A0:01BFF16B] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Further to the discussion of IP Address Alloc., why not have a static identity for each mobile node similar to the IMEI number of a mobile phone, it stays with the node throughout its lifetime, is this possible rather than allocating and detecting existing IP addresses(a cause for inefficient utilisation of bandwidth) Could you direct me to the archive where this discussion has taken place Thanks Regards Saket >From: Charlie Perkins >To: Saket Agarwal >CC: manet@itd.nrl.navy.mil >Subject: Re: IP Address Allocation >Date: Tue, 18 Jul 2000 15:35:50 -0700 >Hello Saket, > >The problem of IP address allocation has been discussed quite a >bit, but I am certain it needs yet more discussion. It is possible >for IP addresses to remain static or to be reassigned after movement. >The problem is not protocol specific. > >We have made an attempt at a generic protocol specification. >See the following for details: > http://www.iprg.nokia.com/~charliep/txt/aodvid/autoconf.txt > >Regards, >Charlie P. > >Saket Agarwal wrote: > > > Hi everyone, > > I have recently joined the manet group and am currently pursuing a >theoretical analysis of different ad hoc networks as a thesis > > After a lot of background reading(maybe not enough), i was wondering >about how IP addresses are going to be assigned to each node i.e. if each >node will have a permanent address or if it will change as the node moves >in the network. What is the criteria for the latter. Is this problem >protocol-specific, being different in AODV to DSR to any other protocol, I >am sorry if this issue has been discussed previously, > > Thanks > > Rgds > > Saket Agarwal ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Wed Jul 19 19:52:03 2000 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 TAA08177 for ; Wed, 19 Jul 2000 19:52:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA15858 for manet-outgoing; Wed, 19 Jul 2000 18:02:04 -0400 (EDT) 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 SAA15853 for ; Wed, 19 Jul 2000 18:02:02 -0400 (EDT) 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 PAA21883; Wed, 19 Jul 2000 15:02:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA23357; Wed, 19 Jul 2000 15:01:56 -0700 X-Virus-Scanned: Wed, 19 Jul 2000 15:01:56 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdisavMg; Wed, 19 Jul 2000 15:01:48 PDT Message-ID: <397624A1.414ECEAC@iprg.nokia.com> Date: Wed, 19 Jul 2000 14:58:57 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Saket Agarwal CC: manet@itd.nrl.navy.mil Subject: Re: IP Address Allocation 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 Saket, Pushing the identification problem to the IMEI doesn't solve anything, and just has the effect of introducing a need for yet another address resolution function. Finding such a function in an ad-hoc network is a challenge that most people do not wish to meet, at least in the general case. Of course if you have some sort of magic layer-2 wand that you would like to wave over the entire ad-hoc network, who knows what good things might result. You would still have to show that the magic wand consumes less bandwidth than a layer-3 solution. Regards, Charlie P. Saket Agarwal wrote: > Hi > Further to the discussion of IP Address Alloc., why not have a static > identity for each mobile node similar to the IMEI number of a mobile phone, > it stays with the node throughout its lifetime, is this possible rather than > allocating and detecting existing IP addresses(a cause for inefficient > utilisation of bandwidth) > Could you direct me to the archive where this discussion has taken place > Thanks > Regards > Saket > > >From: Charlie Perkins > >To: Saket Agarwal > >CC: manet@itd.nrl.navy.mil > >Subject: Re: IP Address Allocation > >Date: Tue, 18 Jul 2000 15:35:50 -0700 > > >Hello Saket, > > > >The problem of IP address allocation has been discussed quite a > >bit, but I am certain it needs yet more discussion. It is possible > >for IP addresses to remain static or to be reassigned after movement. > >The problem is not protocol specific. > > > >We have made an attempt at a generic protocol specification. > >See the following for details: > > http://www.iprg.nokia.com/~charliep/txt/aodvid/autoconf.txt > > > >Regards, > >Charlie P. > > > >Saket Agarwal wrote: > > > > > Hi everyone, > > > I have recently joined the manet group and am currently pursuing a > >theoretical analysis of different ad hoc networks as a thesis > > > After a lot of background reading(maybe not enough), i was wondering > >about how IP addresses are going to be assigned to each node i.e. if each > >node will have a permanent address or if it will change as the node moves > >in the network. What is the criteria for the latter. Is this problem > >protocol-specific, being different in AODV to DSR to any other protocol, I > >am sorry if this issue has been discussed previously, > > > Thanks > > > Rgds > > > Saket Agarwal > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Thu Jul 20 08:39:26 2000 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 IAA10558 for ; Thu, 20 Jul 2000 08:39:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA27459 for manet-outgoing; Thu, 20 Jul 2000 06:46:24 -0400 (EDT) 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 GAA27452 for ; Thu, 20 Jul 2000 06:46:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11722; Thu, 20 Jul 2000 06:46:21 -0400 (EDT) Message-Id: <200007201046.GAA11722@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-aodv-06.txt Date: Thu, 20 Jul 2000 06:46:21 -0400 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 : Ad Hoc On Demand Distance Vector (AODV) Routing Author(s) : C. Perkins, E. Royer, S. Das Filename : draft-ietf-manet-aodv-06.txt Pages : 24 Date : 19-Jul-00 The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast between sources and destinations. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), solving problems (such as ``counting to infinity'') associated with classical distance vector protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-aodv-06.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-aodv-06.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: <20000719141434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-aodv-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-aodv-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141434.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Thu Jul 20 12:04:14 2000 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 MAA28998 for ; Thu, 20 Jul 2000 12:04:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA02392 for manet-outgoing; Thu, 20 Jul 2000 09:59:14 -0400 (EDT) Received: from kashmir.inria.fr (kashmir.inria.fr [128.93.17.53]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA02386 for ; Thu, 20 Jul 2000 09:59:10 -0400 (EDT) Received: (from qayyum@localhost) by kashmir.inria.fr (8.9.3/8.9.3) id PAA16393; Thu, 20 Jul 2000 15:10:44 +0200 From: Amir Qayyum MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lvW05TzvOd" Content-Transfer-Encoding: 7bit Message-ID: <14710.64083.618687.870598@kashmir.inria.fr> Date: Thu, 20 Jul 2000 15:10:43 +0200 (CEST) To: manet@itd.nrl.navy.mil Subject: OLSR draft X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: Amir.Qayyum@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --lvW05TzvOd Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Hi, A new version of Internet Draft on OLSR protocol is available and is attached with this mail. It will be submitted to IETF when the submission will re-open. -- Amir Optimized Link State Routing Protocol Abstract This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the pure link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs) [1] & [2]. MPRs are selected nodes which forward broadcast packets during the flooding process. This technique substantially reduces the packet overhead as compared to pure flooding mechanism where every node retransmits the packet when it receives the first copy of the packet. In OLSR protocol, the information flooded in the network "through" these multipoint relays is also "about" the multipoint relays. Thus a second optimization is achieved by minimizing the "contents" of the control packets flooded in the network. Hence, as contrary to the classic link state algorithm, only a small subset of links with the neighbor nodes are declared instead of all the links. This information is then used by the OLSR protocol for route calculation. As a consequence hereof, the routes contain only the MPRs as intermediate nodes from a Source to a Destination. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of multipoint relays works well in this context. --lvW05TzvOd Content-Type: application/octet-stream Content-Disposition: attachment; filename="draft-ietf-manet-olsr-02.txt" Content-Transfer-Encoding: base64 CklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUGhpbGlwcGUgSmFjcXVldApJRVRGIE1BTkVUIFdvcmtpbmcgR3JvdXAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFBhdWwgTXVobGV0aGFsZXIKRXhwaXJhdGlvbjogMTgg SmFudWFyeSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFtaXIgUWF5 eXVtCgkJCQkJCQkgICAgQW5pcyBMYW91aXRpCgkJCQkJCQkgTGF1cmVudCBWaWVubm90CgkJ CQkJCQkgIFRob21hcyBDbGF1c2VuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJTlJJQSBSb2NxdWVuY291cnQsIEZyYW5jZQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxOCBKdWx5 IDIwMDAKCgoJCU9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wKICAgICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLW1hbmV0LW9sc3ItMDIudHh0CgpTdGF0dXMgb2Yg dGhpcyBNZW1vCgogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBp cyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgKICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlv biAxMCBvZiBSRkMgMjAyNiBleGNlcHQgdGhhdCB0aGUgcmlnaHQgdG8KICAgcHJvZHVjZSBk ZXJpdmF0aXZlIHdvcmtzIGlzIG5vdCBncmFudGVkLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFz ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90 ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzCiAgIEludGVybmV0LURyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4CiAgIG1vbnRocyBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIKICAg ZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMKICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv dGhlciB0aGFuIGFzICJ3b3JrIGluCiAgIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4KCkFic3RyYWN0CgogICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyAoT0xTUikK ICAgcHJvdG9jb2wgZm9yIG1vYmlsZSBhZCBob2MgbmV0d29ya3MuIFRoZSBwcm90b2NvbCBp cyBhbgogICBvcHRpbWl6YXRpb24gb2YgdGhlIHB1cmUgbGluayBzdGF0ZSBhbGdvcml0aG0g dGFpbG9yZWQgdG8gdGhlCiAgIHJlcXVpcmVtZW50cyBvZiBhIG1vYmlsZSB3aXJlbGVzcyBM QU4uIFRoZSBrZXkgY29uY2VwdCB1c2VkIGluIHRoZQogICBwcm90b2NvbCBpcyB0aGF0IG9m IG11bHRpcG9pbnQgcmVsYXlzIChNUFJzKSBbMV0gJiBbMl0uIE1QUnMgYXJlCiAgIHNlbGVj dGVkIG5vZGVzIHdoaWNoIGZvcndhcmQgYnJvYWRjYXN0IHBhY2tldHMgZHVyaW5nIHRoZSBm bG9vZGluZwogICBwcm9jZXNzLiBUaGlzIHRlY2huaXF1ZSBzdWJzdGFudGlhbGx5IHJlZHVj ZXMgdGhlIHBhY2tldCBvdmVyaGVhZAogICBhcyBjb21wYXJlZCB0byBwdXJlIGZsb29kaW5n IG1lY2hhbmlzbSB3aGVyZSBldmVyeSBub2RlIHJldHJhbnNtaXRzCiAgIHRoZSBwYWNrZXQg d2hlbiBpdCByZWNlaXZlcyB0aGUgZmlyc3QgY29weSBvZiB0aGUgcGFja2V0LiBJbiBPTFNS CiAgIHByb3RvY29sLCB0aGUgaW5mb3JtYXRpb24gZmxvb2RlZCBpbiB0aGUgbmV0d29yayAi dGhyb3VnaCIgdGhlc2UKICAgbXVsdGlwb2ludCByZWxheXMgaXMgYWxzbyAiYWJvdXQiIHRo ZSBtdWx0aXBvaW50IHJlbGF5cy4gVGh1cyBhCgoKCkphY3F1ZXQsIE11aGxldGhhbGVyLCBR YXl5dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAgIFtQYWdlIDFdCgwKSU5U RVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyAgICAgICAg ICAxOCBKdWx5IDIwMDAKCgoKICAgc2Vjb25kIG9wdGltaXphdGlvbiBpcyBhY2hpZXZlZCBi eSBtaW5pbWl6aW5nIHRoZSAiY29udGVudHMiIG9mIHRoZQogICBjb250cm9sIHBhY2tldHMg Zmxvb2RlZCBpbiB0aGUgbmV0d29yay4gSGVuY2UsIGFzIGNvbnRyYXJ5IHRvIHRoZQogICBj bGFzc2ljIGxpbmsgc3RhdGUgYWxnb3JpdGhtLCBvbmx5IGEgc21hbGwgc3Vic2V0IG9mIGxp bmtzIHdpdGggdGhlCiAgIG5laWdoYm9yIG5vZGVzIGFyZSBkZWNsYXJlZCBpbnN0ZWFkIG9m IGFsbCB0aGUgbGlua3MuIFRoaXMKICAgaW5mb3JtYXRpb24gaXMgdGhlbiB1c2VkIGJ5IHRo ZSBPTFNSIHByb3RvY29sIGZvciByb3V0ZQogICBjYWxjdWxhdGlvbi4gQXMgYSBjb25zZXF1 ZW5jZSBoZXJlb2YsIHRoZSByb3V0ZXMgY29udGFpbiBvbmx5IHRoZQogICBNUFJzIGFzIGlu dGVybWVkaWF0ZSBub2RlcyBmcm9tIGEgU291cmNlIHRvIGEgRGVzdGluYXRpb24uIE9MU1IK ICAgcHJvdmlkZXMgb3B0aW1hbCByb3V0ZXMgKGluIHRlcm1zIG9mIG51bWJlciBvZiBob3Bz KS4gVGhlIHByb3RvY29sCiAgIGlzIHBhcnRpY3VsYXJseSBzdWl0YWJsZSBmb3IgbGFyZ2Ug YW5kIGRlbnNlIG5ldHdvcmtzIGFzIHRoZQogICB0ZWNobmlxdWUgb2YgbXVsdGlwb2ludCBy ZWxheXMgd29ya3Mgd2VsbCBpbiB0aGlzIGNvbnRleHQuCgoKCQkJICAgQ29udGVudHMKClN0 YXR1cyBvZiBUaGlzIE1lbW8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxCgpBYnN0cmFjdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMQoKIDEuIEludHJvZHVjdGlvbiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIKIDIuIENoYW5nZXMJCQkJCQkJ MwogMy4gT0xTUiB0ZXJtaW5vbG9neQkJCQkJCTQKIDQuIEFwcGxpY2FiaWxpdHkgU2VjdGlv bgkJCQkJNQogICAgIDQuMSBOZXR3b3JraW5nIENvbnRleHQJCQkJCTUKICAgICA0LjIgUHJv dG9jb2wgQ2hhcmFjdGVyaXN0aWNzIGFuZCBNZWNoYW5pc21zCQk1CiA1LiBQcm90b2NvbCBP dmVydmlldwkJCQkJCTcKIDYuIE11bHRpcG9pbnQgcmVsYXlzCQkJCQkJOQogNy4gUHJvdG9j b2wgZnVuY3Rpb25pbmcJCQkJICAgICAgIDEwCiAgICAgNy4xIFBhY2tldCBmb3JtYXQJCQkJ CSAgICAgICAxMAogICAgICAgICAgNy4xLjEgUGFja2V0IEhlYWRlcgkJCQkgICAgICAgMTEK CSAgNy4xLjIgRXh0ZW5zaW9uIEhlYWRlcgkJCSAgICAgICAxMgoJICA3LjEuMyBQYWNrZXQg UHJvY2Vzc2luZwkJCSAgICAgICAxMgogICAgIDcuMiBOZWlnaGJvciBzZW5zaW5nCQkJCSAg ICAgICAxMwogICAgICAgICAgNy4yLjEgSEVMTE8gbWVzc2FnZSBicm9hZGNhc3QJCQkgICAg ICAgMTMKCSAgNy4yLjIgSEVMTE8gbWVzc2FnZSBwcm9jZXNzaW5nCQkgICAgICAgMTYKCSAg Ny4yLjMgTGluayBOb3RpZmljYXRpb24JCQkgICAgICAgMTgKICAgICA3LjMgTXVsdGlwb2lu dCByZWxheSBzZWxlY3Rpb24JCQkgICAgICAgMTkKICAgICA3LjQgTXVsdGlwb2ludCByZWxh eSBpbmZvcm1hdGlvbiBkZWNsYXJhdGlvbgkgICAgICAgMjAKICAgICAgICAgIDcuNC4xIFRD IG1lc3NhZ2UgYnJvYWRjYXN0CQkJICAgICAgIDIwCgkgIDcuNC4yIFRDIG1lc3NhZ2UgcHJv Y2Vzc2luZwkJCSAgICAgICAyMwogICAgIDcuNSBSb3V0aW5nIHRhYmxlIGNhbGN1bGF0aW9u CQkJICAgICAgIDI1CiA4LiBQYWNrZXQgRm9yd2FyZGluZwkJCQkJICAgICAgIDI3CiAgICAg OC4xIERhdGEgcGFja2V0IGZvcndhcmRpbmcJCQkJICAgICAgIDI3CiAgICAgOC4yIFRvcG9s b2d5IENvbnRyb2wgKFRDKSBwYWNrZXQgZm9yd2FyZGluZwkgICAgICAgMjcKIDkuIFByb3Bv c2VkIHZhbHVlcyBmb3IgY29uc3RhbnRzCQkJICAgICAgIDI3CjEwLiBSZWZlcmVuY2VzCQkJ CQkJICAgICAgIDI4CjExLiBBdXRob3JzJyBhZGRyZXNzZXMJCQkJCSAgICAgICAyOQoKCgpK YWNxdWV0LCBNdWhsZXRoYWxlciBhbmQgUWF5eXVtICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAyXQoMCklOVEVSTkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5r IFN0YXRlIFJvdXRpbmcgICAgICAgICAgMTggSnVseSAyMDAwCgoKCjEuIEludHJvZHVjdGlv bgoKICAgVGhpcyBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nIHByb3RvY29sIGluaGVy aXRzIHRoZSBjb25jZXB0IG9mCiAgIGZvcndhcmRpbmcgYW5kIHJlbGF5aW5nIGZyb20gSElQ RVJMQU4gKGEgTUFDIGxheWVyIHByb3RvY29sKSB3aGljaAogICBpcyBzdGFuZGFyZGl6ZWQg YnkgRVRTSSBbM10uIFRoZSBPTFNSIHByb3RvY29sIGlzIGRldmVsb3BlZCBpbiB0aGUKICAg SVBBTkVNQSBwcm9qZWN0IChwYXJ0IG9mIEV1Y2xpZCBwcm9ncmFtKSBhbmQgaW4gdGhlIFBS SU1BIHByb2plY3QKICAgKHBhcnQgb2YgUk5SVCBwcm9ncmFtKS4KCiAgIFRoaXMgcHJvdG9j b2wgaXMgZGV2ZWxvcGVkIGZvciBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzLiBJdCBvcGVyYXRl cwogICBhcyBhIHRhYmxlIGRyaXZlbiBvciBwcm9hY3RpdmUgcHJvdG9jb2wgYW5kIGV4Y2hh bmdlcyB0b3BvbG9neQogICBpbmZvcm1hdGlvbiB3aXRoIG90aGVyIG5vZGVzIG9mIHRoZSBu ZXR3b3JrIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLgogICBUaGUgbm9kZXMgd2hpY2ggYXJlIHNl bGVjdGVkIGFzIGEgbXVsdGlwb2ludCByZWxheSBieSBzb21lIG5laWdoYm9yCiAgIG5vZGVz IGFubm91bmNlIHRoaXMgaW5mb3JtYXRpb24gcGVyaW9kaWNhbGx5IGluIHRoZWlyIGNvbnRy b2wKICAgbWVzc2FnZXMuIFRoZSBwcm90b2NvbCB1c2VzIHRoZSBtdWx0aXBvaW50IHJlbGF5 cyB0byBmYWNpbGl0YXRlCiAgIGVmZmljaWVudCBmbG9vZGluZyBvZiBjb250cm9sIG1lc3Nh Z2VzIGluIHRoZSBuZXR3b3JrLiBJbiByb3V0ZQogICBjYWxjdWxhdGlvbiwgdGhlIG11bHRp cG9pbnQgcmVsYXlzIGFyZSB1c2VkIHRvIGZvcm0gdGhlIHJvdXRlIGZyb20KICAgYSBnaXZl biBub2RlIHRvIGFueSBkZXN0aW5hdGlvbiBpbiB0aGUgbmV0d29yay4KCiAgIE11bHRpcG9p bnQgcmVsYXlzIGFyZSBzZWxlY3RlZCBieSBhIG5vZGUgYW1vbmcgaXRzIG9uZSBob3AKICAg bmVpZ2hib3JzIHdpdGggInN5bW1ldHJpYyIsIGkuZS4gYmktZGlyZWN0aW9uYWwsIGxpbmsu IFRoZXJlZm9yZSwKICAgc2VsZWN0aW5nIHRoZSByb3V0ZSB0aHJvdWdoIG11bHRpcG9pbnQg cmVsYXlzIGF1dG9tYXRpY2FsbHkgYXZvaWRzCiAgIHRoZSBwcm9ibGVtcyBhc3NvY2lhdGVk IHdpdGggZGF0YSBwYWNrZXQgdHJhbnNmZXIgb24KICAgdW5pLWRpcmVjdGlvbmFsIGxpbmtz IChzdWNoIGFzIHRoZSBwcm9ibGVtIG9mIGdldHRpbmcgdGhlCiAgIGFja25vd2xlZGdlbWVu dCBmb3IgdGhlIGRhdGEgcGFja2V0cyBhdCBlYWNoIGhvcCkKCiAgIFRoZSBPTFNSIHByb3Rv Y29sIGlzIGRldmVsb3BlZCB0byB3b3JrIGluZGVwZW5kZW50bHkgZnJvbSBvdGhlcgogICBw cm90b2NvbHMuIEJ1dCBpdCBjYW4gYmUgYWRhcHRlZCB0byBvcGVyYXRlIHdpdGggYSBwcm90 b2NvbCAobGlrZQogICBJTUVQIFs0XSkgd2hpY2ggY291bGQgcHJvdmlkZSBjb21tb24gZnVu Y3Rpb25hbGl0aWVzIHN1Y2ggYXMKICAgbmVpZ2hib3Igc2Vuc2luZywgbXVsdGlwb2ludCBy ZWxheWluZywgc2VjdXJpdHkgYXV0aGVudGljYXRpb24sCiAgIGV0Yy4KCgoyLiBDaGFuZ2Vz CiAgIAogICBNYWpvciBjaGFuZ2VzIGZyb20gdmVyc2lvbiAwMSB0byB2ZXJzaW9uIDAyCgog ICAtICBJbnRyb2R1Y3Rpb24gb2YgYSB1bmlmaWVkIHBhY2tldCBmb3JtYXQgZm9yIGVuY2Fw c3VsYXRpb24gb2YKICAgICAgYWxsIG1lc3NhZ2VzIGJlaW5nIGV4Y2hhbmdlZCBiZXR3ZWVu IG5vZGVzLiBUaGlzIGFsc28gc2VydmVzCiAgICAgIHRvIGZhY2lsaXRhdGUgZXh0ZW5zaW9u cyBpbiBmdXR1cmUgdmVyc2lvbnMgb2YgdGhlIHByb3RvY29sCiAgICAgIChpLmUuIGludHJv ZHVjdGlvbiBvZiBuZXcgcHJvdG9jb2wgbWVzc2FnZXMpIHdpdGhvdXQgYnJlYWtpbmcgCiAg ICAgIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LgogICAgICAKICAgLSAgUmVtb3ZhbCBvZiAi UG93ZXIgQ29uc2VydmF0aW9uIiBmcm9tIHRoaXMgZHJhZnQuIFBvd2VyIAogICAgICBDb25z ZXJ2YXRpb24gbWF5IGJlIGNvbnNpZGVyZWQgYXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBiYXNp YwogICAgICByb3V0aW5nIGNhcGFiaWxpdGllcywgYW5kIHRoZSBpbmZvcm1hdGlvbiBpcyB0 aGVyZWZvcmUgbW92ZWQKICAgICAgdG8gZHJhZnQtaWV0Zi1tYW5ldC1vbHNyLWV4dGVuc2lv bnMtMDAudHh0LgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciBhbmQgUWF5eXVtICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCklOVEVSTkVULURSQUZUICAgICAg IE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAgMTggSnVseSAyMDAwCgoK CjMuIE9MU1IgVGVybWlub2xvZ3kKCiAgIFRoZSBrZXl3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDQ09NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4KICAg dGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJG QzIxMTkgWzldLgogICBUaGUgT0xTUiBwcm90b2NvbCB1c2VzIHRoZSBmb2xsb3dpbmcgdGVy bWlub2xvZ3ksIGluIGFkZGl0aW9uIHRvCiAgIHRoZSB0ZXJtcyBkZWZpbmVkIGluIFs1XS4K CiAgIGNvbm5lY3Rpb24KCiAgICAgIEEgY29tbXVuaWNhdGlvbiBjaGFubmVsIG9yIG1lZGl1 bSAqb24gdGhlIHNhbWUgcGh5c2ljYWwKICAgICAgaW50ZXJmYWNlKiwgb3ZlciB3aGljaCB0 aGUgbm9kZXMgY2FuIGNvbW11bmljYXRlIHdpdGggZWFjaAogICAgICBvdGhlci4KCiAgIGhv bGRpbmcgdGltZQoKICAgICAgVGhlIGxpZmV0aW1lIGFzc29jaWF0ZWQgd2l0aCBhbiBlbnRy eSBpbiBhbnkgdGFibGUuIEFuIGVudHJ5IGlzCiAgICAgIGtlcHQgaW4gdGhlIHRhYmxlIGZv ciBhIHBlcmlvZCBvZiB0aW1lLCBlcXVhbCB0byBpdHMgaG9sZGluZwogICAgICB0aW1lLiBJ ZiB0aGUgZW50cnkgaXMgbm90IHJlZnJlc2hlZCBkdXJpbmcgdGhpcyBwZXJpb2QsIGl0IGlz CiAgICAgIHJlbW92ZWQgZnJvbSB0aGUgdGFibGUgd2hlbiB0aGUgaG9sZGluZyB0aW1lIGV4 cGlyZXMuCgogICBtdWx0aXBvaW50IHJlbGF5IChNUFIpCgogICAgICBBIG5vZGUgd2hpY2gg aXMgc2VsZWN0ZWQgYnkgaXRzIG9uZS1ob3AgbmVpZ2hib3IsIG5vZGUgWCwgdG8KICAgICAg InJlLXRyYW5zbWl0IiBhbGwgdGhlIGJyb2FkY2FzdCBwYWNrZXRzIHRoYXQgaXQgcmVjZWl2 ZSBmcm9tIFgsCiAgICAgIHByb3ZpZGVkIHRoYXQgdGhlIHNhbWUgcGFja2V0IGlzIG5vdCBh bHJlYWR5IHJlY2VpdmVkLCBhbmQgdGhlCiAgICAgIGhvcCBjb3VudCBmaWVsZCBvZiB0aGUg cGFja2V0IGlzIGdyZWF0ZXIgdGhhbiB6ZXJvLgoKICAgbXVsdGlwb2ludCByZWxheSBzZWxl Y3RvciAoTVBSLVMpCgogICAgICBBIG5vZGUgd2hpY2ggaGFzIHNlbGVjdGVkIGl0cyBvbmUt aG9wIG5laWdoYm9yLCBub2RlIFgsIGFzIGl0cwogICAgICBtdWx0aXBvaW50IHJlbGF5LCB3 aWxsIGJlIGNhbGxlZCB0aGUgbXVsdGlwb2ludCByZWxheSBzZWxlY3RvcgogICAgICBvZiBu b2RlIFguCgogICBub2RlCgogICAgICBBIE1BTkVUIHJvdXRlciB3aGljaCBpbXBsZW1lbnRz IHRoaXMgT3B0aW1pemVkIExpbmsgU3RhdGUKICAgICAgUm91dGluZyBwcm90b2NvbC4KCiAg IHN5bW1ldHJpYyBsaW5rCgogICAgICBBIGJpLWRpcmVjdGlvbmFsICpsaW5rKiAobm90IGNv bm5lY3Rpb24pIGJldHdlZW4gdHdvIG5laWdoYm9yCiAgICAgIG5vZGVzLCBpLmUuIG5vZGUg WCBhbmQgbm9kZSBZIHdoZXJlIGJvdGggY2FuIGhlYXIgZWFjaAogICAgICBvdGhlci4gVGhp cyBiaS1kaXJlY3Rpb25hbCBsaW5rIGNhbiBiZSBhIHVuaW9uIG9mIHR3bwogICAgICBvcHBv c2l0ZWx5LWRpcmVjdGVkIHVuaS1kaXJlY3Rpb25hbCBjb25uZWN0aW9ucyB1c2luZyBkaWZm ZXJlbnQKICAgICAgaW50ZXJmYWNlcy4KCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1 bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICAgW1BhZ2UgNF0KDApJTlRFUk5F VC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAgICAgIDE4 IEp1bHkgMjAwMAoKCgo0LiBBcHBsaWNhYmlsaXR5IFNlY3Rpb24KCiAgIFRoaXMgc2VjdGlv biBkaWN0YXRlcyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBPTFNSIHByb3RvY29sIGFz CiAgIHNwZWNpZmllZCBpbiB0aGUgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgZHJhZnQgWzZd LgoKNC4xLiBOZXR3b3JraW5nIENvbnRleHQKCiAgIFRoZSBwcm90b2NvbCBpcyBiZXN0IHN1 aXRlZCB0byBsYXJnZSBhbmQgZGVuc2UgbmV0d29ya3MsIGFzIHRoZQogICBvcHRpbWl6YXRp b24gYWNoaWV2ZWQgdXNpbmcgdGhlIG11bHRpcG9pbnQgcmVsYXlzIHdvcmtzIHdlbGwgaW4K ICAgdGhpcyBjb250ZXh0LiBUaGUgbGFyZ2VyIGFuZCBtb3JlIGRlbnNlIGEgbmV0d29yaywg dGhlIG1vcmUKICAgb3B0aW1pemF0aW9uIGNhbiBiZSBhY2hpZXZlZCBhcyBjb21wYXJlZCB0 byB0aGUgbm9ybWFsIGxpbmsgc3RhdGUKICAgYWxnb3JpdGhtLiBPTFNSIHVzZXMgaG9wLWJ5 LWhvcCByb3V0aW5nLCBpLmUuIGVhY2ggbm9kZSB1c2VzIGl0cwogICBtb3N0IHJlY2VudCBp bmZvcm1hdGlvbiB0byByb3V0ZSBwYWNrZXRzLiBUaHVzIHdoZW4gYSBub2RlIGlzCiAgIG1v dmluZywgaXRzIHNwZWVkIHNob3VsZCBiZSBzdWNoIHRoYXQgaXRzIG1vdmVtZW50IGNvdWxk IGJlCiAgIGZvbGxvd2VkIGluICphdCBsZWFzdCogaXRzIG5laWdoYm9yaG9vZCwgaW4gb3Jk ZXIgdG8gY29ycmVjdGx5CiAgIHJvdXRlIHBhY2tldHMgdG8gdGhlIGRlc3RpbmF0aW9uLgoK ICAgVGhpcyBwcm90b2NvbCBpcyBiZXN0IHN1aXRlZCBmb3IgbmV0d29ya3Mgd2hlcmUgdGhl IHRyYWZmaWMgaXMKICAgcmFuZG9tIGFuZCBzcG9yYWRpYyBiZXR3ZWVuICJzZXZlcmFsIiBu b2RlcyByYXRoZXIgdGhhbiBiZWluZwogICBhbG1vc3QgZXhjbHVzaXZlbHkgYmV0d2VlbiBh IHNtYWxsIHNwZWNpZmljIHNldCBvZiBub2RlcyBpbiB0aGUKICAgbmV0d29yay4gVGhlIHBl cmZvcm1hbmNlIG9mIHRoZSBwcm90b2NvbCB3aGVuIGNvbXBhcmluZyB0byBhCiAgIHJlYWN0 aXZlIHByb3RvY29sIGlzIGV2ZW4gYmV0dGVyIGlmIHRoZXNlIFtzb3VyY2UsIGRlc3RpbmF0 aW9uXQogICBwYWlycyBjaGFuZ2Ugd2l0aCB0aW1lIFs4XS4gU3VjaCBjaGFuZ2VzIG1heSBp bml0aWF0ZSBzdWJzdGFudGlhbAogICB0cmFmZmljIChRdWVyeSBmbG9vZGluZykgaW4gY2Fz ZSBvZiByZWFjdGl2ZSBwcm90b2NvbCwgYnV0IG5vdGhpbmcKICAgaW4gT0xTUiwgYXMgdGhl IHJvdXRlcyBhcmUgbWFpbnRhaW5lZCBmb3IgZWFjaCBrbm93biBkZXN0aW5hdGlvbgogICBh bGwgdGhlIHRpbWUuCgo0LjIuIFByb3RvY29sIENoYXJhY3RlcmlzdGljcyBhbmQgTWVjaGFu aXNtcwoKICAgKiBEb2VzIHRoZSBwcm90b2NvbCBwcm92aWRlIHN1cHBvcnQgZm9yIHVuaWRp cmVjdGlvbmFsIGxpbmtzPyAoaWYKICAgICBzbywgaG93PykKCiAgICAgIE5vLiBJdCB1c2Vz IG9ubHkgYmktZGlyZWN0aW9uYWwgbGlua3MgKGxpa2UgaW4gODAyLjExKSwgYnV0CiAgICAg IHRoZXNlIGxpbmtzIG1heSBiZSBjb21wb3NlZCBvZiBvcHBvc2l0ZWx5IGRpcmVjdGVkCiAg ICAgIHVuaS1kaXJlY3Rpb25hbCAiY29ubmVjdGlvbnMiLgoKICAgKiBEb2VzIHRoZSBwcm90 b2NvbCByZXF1aXJlIHRoZSB1c2Ugb2YgdHVubmVsaW5nPyAoaWYgc28sIGhvdz8pCgogICAg ICBOby4KCiAgICogRG9lcyB0aGUgcHJvdG9jb2wgcmVxdWlyZSB1c2luZyBzb21lIGZvcm0g b2Ygc291cmNlIHJvdXRpbmc/IChpZgogICAgIHNvLCBob3c/KQoKICAgICAgTm8uIFRoZSBw cm90b2NvbCB1c2VzIGhvcC1ieS1ob3Agcm91dGluZy4KCgoKCgpKYWNxdWV0LCBNdWhsZXRo YWxlciwgUWF5eXVtLCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgICBbUGFnZSA1 XQoMCklOVEVSTkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcg ICAgICAgICAgMTggSnVseSAyMDAwCgoKCiAgICogRG9lcyB0aGUgcHJvdG9jb2wgcmVxdWly ZSB0aGUgdXNlIG9mIHBlcmlvZGljIG1lc3NhZ2luZz8gKGlmIHNvLAogICAgIGhvdz8pCgog ICAgICBZZXMuIFBlcmlvZGljYWxseSwgZWFjaCBub2RlIGluIHRoZSBuZXR3b3JrIHNlbmQg YSBtZXNzYWdlCiAgICAgIGNvbnRhaW5pbmcgdGhlIGFkZHJlc3NlcyBvZiB0aGUgbmVpZ2hi b3JzIHdoaWNoIGhhdmUgc2VsZWN0ZWQKICAgICAgdGhhdCBub2RlIGFzIGEgbXVsdGlwb2lu dCByZWxheS4gVGhpcyBpbmZvcm1hdGlvbiBlbmFibGVzIG90aGVyCiAgICAgIG5vZGVzIHRv IGJ1aWxkIHJvdXRlcyB0byB0aGF0IG5vZGUgdGhyb3VnaCB0aGUgbXVsdGlwb2ludAogICAg ICByZWxheXMuCgogICAqIERvZXMgdGhlIHByb3RvY29sIHJlcXVpcmUgdGhlIHVzZSBvZiBy ZWxpYWJsZSBvciBzZXF1ZW5jZWQgcGFja2V0CiAgICAgZGVsaXZlcnk/IChpZiBzbywgaG93 PykKCiAgICAgIE5vLiBBcyB0aGUgcGFja2V0cyBhcmUgc2VudCBwZXJpb2RpY2FsbHksIHRo ZXkgbmVlZCBub3QgYmUgc2VudAogICAgICByZWxpYWJseS4gRWFjaCBwYWNrZXQgbm90IG9u bHkgY29udGFpbnMgYSB1bmlxdWUgUGFja2V0IFNlcXVlbmNlCiAgICAgIE51bWJlciwgYnV0 IGl0IGFsc28gY29udGFpbnMgdGhlIHNlcXVlbmNlIG51bWJlciBmb3IgdGhlIG1vc3QKICAg ICAgcmVjZW50IGluZm9ybWF0aW9uIChmb3IgZXhhbXBsZSAiTVBSIFNlcXVlbmNlIE51bWJl ciIgaW4gdGhlIFRDCiAgICAgIHBhY2tldCksIHNvIHVuLXNlcXVlbmNlZCBkZWxpdmVyeSBv ZiBwYWNrZXRzIHdpbGwgYWxzbyBub3QKICAgICAgY3JlYXRlIGFueSBwcm9ibGVtLgoKICAg KiBEb2VzIHRoZSBwcm90b2NvbCBwcm92aWRlIHN1cHBvcnQgZm9yIHJvdXRpbmcgdGhyb3Vn aCBhIG11bHRpLQogICAgIHRlY2hub2xvZ3kgcm91dGluZyBmYWJyaWM/IChpZiBzbywgaG93 PykKCiAgICAgIFllcy4gRWFjaCBuZXR3b3JrIGludGVyZmFjZSBpcyBhc3NpZ25lZCBhIHVu aXF1ZSBJUCBhZGRyZXNzLgoKICAgKiBEb2VzIHRoZSBwcm90b2NvbCBwcm92aWRlIHN1cHBv cnQgZm9yIG11bHRpcGxlIGhvc3RzIHBlciByb3V0ZXI/CiAgICAgKGlmIHNvLCBob3c/KQoK ICAgICAgWWVzLiBUaGUgY29uY2VwdCBvZiBSSUQgWzRdIG1heSBiZSB1c2VkIHRvIGFzc29j aWF0ZSB0byBhIHNpbmdsZQogICAgICBSSUQgKHdoaWNoIGNhbiBhbHNvIGJlIGEgdW5pcXVl IElQIGFkZHJlc3MpIG1vcmUgdGhhbiBvbmUgSVAKICAgICAgYWRkcmVzc2VzIHdoaWNoIHJl cHJlc2VudCBkaWZmZXJlbnQgaG9zdHMgYXNzb2NpYXRlZCB0byB0aGUKICAgICAgcm91dGVy LgoKICAgKiBEb2VzIHRoZSBwcm90b2NvbCBzdXBwb3J0IHRoZSBJUCBhZGRyZXNzaW5nIGFy Y2hpdGVjdHVyZT8gKGlmIHNvLAogICAgIGhvdz8pCgogICAgICBZZXMuCgogICAqIERvZXMg dGhlIHByb3RvY29sIHJlcXVpcmUgbGluayBvciBuZWlnaGJvciBzdGF0dXMgc2Vuc2luZyAo aWYgc28sCiAgICAgaG93PykKCiAgICAgIFllcy4gVGhlIHByb3RvY29sIHJlcXVpcmVzIHRo ZSBsaW5rIHN0YXR1cyBzZW5zaW5nLiBUaGlzIHNlcnZpY2UKICAgICAgaXMgcHJvdmlkZWQg Ynkgc2VuZGluZy9yZWNlaXZpbmcgcGVyaW9kaWMgSEVMTE8gbWVzc2FnZXMgdG8vZnJvbQog ICAgICBvbmUgaG9wIG5laWdoYm9ycy4KCgoKCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFh eXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICAgW1BhZ2UgNl0KDApJTlRF Uk5FVC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAgICAg IDE4IEp1bHkgMjAwMAoKCgogICAqIERvZXMgdGhlIHByb3RvY29sIGRlcGVuZCBvbiBhIGNl bnRyYWwgZW50aXR5PyAoaWYgc28sIGhvdz8pCgogICAgICBOby4gQWxsIHRoZSByb3V0ZXJz IGluIHRoZSBuZXR3b3JrIGhhdmUgdGhlaXIgb3duIHJvdXRpbmcgdGFibGVzCiAgICAgIGFu ZCBkbyBub3QgZGVwZW5kIG9uIGFueSBzcGVjaWZpYyBub2RlLgoKICAgKiBEb2VzIHRoZSBw cm90b2NvbCBmdW5jdGlvbiByZWFjdGl2ZWx5PyAoaWYgc28sIGhvdz8pCgogICAgICBOby4g QnV0IGl0IGRlY3JlYXNlcyBhbmQgaW5jcmVhc2VzIHRoZSBpbnRlcnZhbCAod2l0aGluIGNl cnRhaW4KICAgICAgbGltaXRzKSBvZiBzZW5kaW5nIHRoZSBUQyBwYWNrZXQgcGVyaW9kaWNh bGx5LCBkZXBlbmRpbmcgdXBvbgogICAgICB0aGUgcmF0ZSBvZiBsaW5rIGNoYW5nZXMgaW4g aXRzIG5laWdoYm9yaG9vZC4KCiAgICogRG9lcyB0aGUgcHJvdG9jb2wgZnVuY3Rpb24gcHJv YWN0aXZlbHk/IChpZiBzbywgaG93PykKCiAgICAgIFllcy4gSXQgcGVyaW9kaWNhbGx5IHNl bmRzIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBpdHMgbXVsdGlwb2ludAogICAgICByZWxheSBz ZWxlY3RvcnMsIHdoaWNoIGhlbHBzIG90aGVyIG5vZGVzIHRvIGJ1aWxkIHJvdXRlcyB0byBp dC4KCiAgICogRG9lcyB0aGUgcHJvdG9jb2wgcHJvdmlkZSBsb29wLWZyZWUgcm91dGluZz8g KGlmIHNvLCBob3c/KQoKICAgICAgQXMgdGhlIHByb3RvY29sIHVzZXMgYSBsaW5rIHN0YXRl IGFsZ29yaXRobSwgdGhlIHJvdXRpbmcgaXMKICAgICAgbG9vcC1mcmVlIHdoZW4gaW4gYSBz dGFibGUgc3RhdGUuCgogICAqIERvZXMgdGhlIHByb3RvY29sIHByb3ZpZGUgZm9yIHNsZWVw IHBlcmlvZCBvcGVyYXRpb24/IChpZiBzbywgaG93PykKCiAgICAgIFllcywgT0xTUiBjYW4g cHJvdmlkZSBzdXBwb3J0IGZvciBzbGVlcCBwZXJpb2Qgb3BlcmF0aW9uLiBUbwogICAgICBl bmFibGUgdGhpcyBmZWF0dXJlLCBhIG5vZGUgc2hvdWxkIHNlbGVjdCBpdHMgbXVsdGlwb2lu dCByZWxheXMKICAgICAgZnJvbSBhbW9uZyB0aG9zZSBuZWlnaGJvcnMgd2hpY2ggY2FuIChv ciBhZ3JlZSB0bykgc3RvcmUgaXRzCiAgICAgIHBhY2tldHMgd2hpbGUgaXQgaXMgaW4gc2xl ZXAgbW9kZS4KCiAgICogRG9lcyB0aGUgcHJvdG9jb2wgcHJvdmlkZSBzb21lIGZvcm0gb2Yg c2VjdXJpdHk/IChpZiBzbywgaG93PykKCiAgICAgIE5vLCBub3QgaXRzZWxmLiBJdCBjYW4g dXNlIG90aGVyIHByb3RvY29scyAobGlrZSBJTUVQIFs0XSkgd2hpY2gKICAgICAgcHJvdmlk ZSBhdXRoZW50aWNhdGlvbiBhbmQgc2VjdXJpdHkuCgogICAqIERvZXMgdGhlIHByb3RvY29s IHByb3ZpZGUgc3VwcG9ydCBmb3IgdXRpbGl6aW5nIG11bHRpLWNoYW5uZWwsCiAgICAgbGlu ay1sYXllciB0ZWNobm9sb2dpZXM/IChpZiBzbywgaG93PykKCiAgICAgIFllcy4gRWFjaCBp bnRlcmZhY2UgaGFzIGEgdW5pcXVlIElQIGFkZHJlc3MuCgoKNS4gUHJvdG9jb2wgT3ZlcnZp ZXcKCiAgIE9MU1IgaXMgYSBwcm9hY3RpdmUgcm91dGluZyBwcm90b2NvbCBmb3IgbW9iaWxl IGFkIGhvYyBuZXR3b3Jrcy4KICAgVGhlIHByb3RvY29sIGluaGVyaXRzIHRoZSBzdGFiaWxp dHkgb2YgYSBsaW5rIHN0YXRlIGFsZ29yaXRobSBhbmQKICAgaGFzIHRoZSBhZHZhbnRhZ2Ug b2YgaGF2aW5nIHRoZSByb3V0ZXMgaW1tZWRpYXRlbHkgYXZhaWxhYmxlIHdoZW4KICAgbmVl ZGVkIGR1ZSB0byBpdHMgcHJvYWN0aXZlIG5hdHVyZS4gT0xTUiBpcyBhbiBvcHRpbWl6YXRp b24gb3ZlcgogICB0aGUgcHVyZSBsaW5rIHN0YXRlIHByb3RvY29sLCB0YWlsb3JlZCBmb3Ig bW9iaWxlIGFkIGhvYyBuZXR3b3Jrcy4KCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1 bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICAgW1BhZ2UgN10KDApJTlRFUk5F VC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAgICAgIDE4 IEp1bHkgMjAwMAoKCgogICBGaXJzdGx5LCBpdCByZWR1Y2VzIHRoZSBzaXplIG9mIHRoZSBj b250cm9sIHBhY2tldHM6IHJhdGhlciB0aGFuCiAgIGRlY2xhcmluZyBhbGwgbGlua3MsIGEg bm9kZSBkZWNsYXJlcyBvbmx5IGEgc3Vic2V0IG9mIGxpbmtzIHdpdGgKICAgaXRzIG5laWdo Ym9ycywgbmFtZWx5IHRoZSBsaW5rcyB0byB0aG9zZSBub2RlcyB3aGljaCBhcmUgaXRzCiAg IG11bHRpcG9pbnQgcmVsYXkgc2VsZWN0b3JzIChzZWUgc2VjdGlvbiA2IG9uIE11bHRpcG9p bnQgUmVsYXlzKS4KICAgU2Vjb25kbHksIE9MU1IgbWluaW1pemVzIGZsb29kaW5nIG9mIGNv bnRyb2wgdHJhZmZpYyBieSB1c2luZyBvbmx5CiAgIHNlbGVjdGVkIG5vZGVzLCBjYWxsZWQg bXVsdGlwb2ludCByZWxheXMsIHRvIGRpZmZ1c2UgaXRzIG1lc3NhZ2VzLgogICBUaGlzIHRl Y2huaXF1ZSBzaWduaWZpY2FudGx5IHJlZHVjZXMgdGhlIG51bWJlciBvZiByZXRyYW5zbWlz c2lvbnMKICAgaW4gYSBmbG9vZGluZyBvciBicm9hZGNhc3QgcHJvY2VkdXJlLgoKICAgVGhl IHByb3RvY29sIE1BWSBvcHRpbWl6ZSB0aGUgcmVhY3Rpdml0eSB0byB0b3BvbG9naWNhbCBj aGFuZ2VzIGJ5CiAgIHJlZHVjaW5nIHRoZSB0aW1lIGludGVydmFsIGZvciBwZXJpb2RpYyBj b250cm9sIG1lc3NhZ2UKICAgdHJhbnNtaXNzaW9uLiBGdXJ0aGVybW9yZSwgYXMgT0xTUiBw cm90b2NvbCBrZWVwcyB0aGUgcm91dGVzIGZvcgogICBhbGwgZGVzdGluYXRpb25zIGluIHRo ZSBuZXR3b3JrLCB0aGUgcHJvdG9jb2wgaXMgYmVuZWZpY2lhbCBmb3IKICAgdHJhZmZpYyBw YXR0ZXJucyB3aGVyZSBhIGxhcmdlIHN1YnNldCBvZiBub2RlcyBhcmUgY29tbXVuaWNhdGlu ZwogICB3aXRoIGFub3RoZXIgbGFyZ2Ugc3Vic2V0IG9mIG5vZGVzLCBhbmQgd2hlcmUgdGhl CiAgIFtzb3VyY2UsZGVzdGluYXRpb25dIHBhaXJzIGFyZSBjaGFuZ2luZyBvdmVyIHRpbWUu IFRoZSBwcm90b2NvbCBpcwogICBwYXJ0aWN1bGFybHkgc3VpdGVkIGZvciBsYXJnZSBhbmQg ZGVuc2UgbmV0d29ya3MsIGFzIHRoZQogICBvcHRpbWl6YXRpb24gZG9uZSB1c2luZyB0aGUg bXVsdGlwb2ludCByZWxheXMgd29ya3Mgd2VsbCBpbiB0aGlzCiAgIGNvbnRleHQuIFRoZSBs YXJnZXIgYW5kIG1vcmUgZGVuc2UgYSBuZXR3b3JrLCB0aGUgbW9yZSBvcHRpbWl6YXRpb24K ICAgY2FuIGJlIGFjaGlldmVkIGFzIGNvbXBhcmVkIHRvIHRoZSBub3JtYWwgbGluayBzdGF0 ZSBhbGdvcml0aG0uCgogICBUaGUgcHJvdG9jb2wgaXMgZGVzaWduZWQgdG8gd29yayBpbiBh IGNvbXBsZXRlbHkgZGlzdHJpYnV0ZWQgbWFubmVyCiAgIGFuZCB0aHVzIGRvZXMgbm90IGRl cGVuZCBvbiBhbnkgY2VudHJhbCBlbnRpdHkuIFRoZSBwcm90b2NvbCBkb2VzCiAgIE5PVCBS RVFVSVJFIHJlbGlhYmxlIHRyYW5zbWlzc2lvbiBmb3IgY29udHJvbCBtZXNzYWdlczogZWFj aCBub2RlCiAgIHNlbmRzIGNvbnRyb2wgbWVzc2FnZXMgcGVyaW9kaWNhbGx5LCBhbmQgY2Fu IHRoZXJlZm9yZSBzdXN0YWluIGFuCiAgIG9jY2FzaW9uYWwgbG9zcyBvZiBzb21lIHBhY2tl dHMuIFN1Y2ggbG9zc2VzIG9jY3VyIHZlcnkgb2Z0ZW4gaW4KICAgdGhlIHJhZGlvIG5ldHdv cmtzIGR1ZSB0byBjb2xsaXNpb25zIG9yIG90aGVyIHRyYW5zbWlzc2lvbgogICBwcm9ibGVt cy4gQWxzbywgdGhlIHByb3RvY29sIGRvZXMgTk9UIFJFUVVJUkUgc2VxdWVuY2VkIGRlbGl2 ZXJ5IG9mCiAgIG1lc3NhZ2VzLiBFYWNoIGNvbnRyb2wgbWVzc2FnZSBjb250YWlucyBhIHNl cXVlbmNlIG51bWJlciB3aGljaCBpcwogICBpbmNyZW1lbnRlZCBmb3IgZWFjaCBtZXNzYWdl LiBUaHVzIHRoZSByZWNpcGllbnQgb2YgYSBjb250cm9sCiAgIHBhY2tldCBjYW4gZWFzaWx5 IGlkZW50aWZ5IHdoaWNoIGluZm9ybWF0aW9uIGlzIG5ld2VyIC0gZXZlbiBpZgogICBtZXNz YWdlcyBoYXZlIGJlZW4gcmUtb3JkZXJlZCB3aGlsZSBpbiB0cmFuc21pc3Npb24uCgogICBG dXJ0aGVybW9yZSwgT0xTUiBwcm92aWRlcyBzdXBwb3J0IGZvciBwcm90b2NvbCBleHRlbnNp b25zIHN1Y2ggYXMKICAgc2xlZXAgbW9kZSBvcGVyYXRpb24sIG11bHRpY2FzdC1yb3V0aW5n IGV0Yy4gU3VjaCBleHRlbnNpb25zIG1heSBiZQogICBpbnRyb2R1Y2VkIGFzIGFkZGl0aW9u cyB0byB0aGUgcHJvdG9jb2wgd2l0aG91dCBicmVha2luZyBiYWNrd2FyZHMKICAgY29tcGF0 aWJpbGl0eSB3aXRoIGVhcmxpZXIgdmVyc2lvbnMuCgogICBPTFNSIHBlcmZvcm1zIGhvcCBi eSBob3Agcm91dGluZywgaS5lLiBlYWNoIG5vZGUgdXNlcyBpdHMgbW9zdAogICByZWNlbnQg aW5mb3JtYXRpb24gdG8gcm91dGUgdGhlIHBhY2tldC4gSGVuY2UgZm9yIE9MU1IgdG8gYmUg YWJsZQogICB0byByb3V0ZSBwYWNrZXRzLCB0aGUgc3BlZWQgb2YgbW9iaWxlIG5vZGVzIHNo b3VsZCBiZSBsaW1pdGVkIHN1Y2gKICAgdGhhdCB0aGVpciBtb3ZlbWVudHMgY2FuIGJlIHRy YWNrZWQsIGF0IGxlYXN0IGJ5IHRoZWlyIG5laWdoYm9yaG9vZC4KCgoKCgoKCkphY3F1ZXQs IE11aGxldGhhbGVyLCBRYXl5dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAg IFtQYWdlIDhdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUg Um91dGluZyAgICAgICAgICAxOCBKdWx5IDIwMDAKCgoKICAgT0xTUiBkb2VzIE5PVCBSRVFV SVJFIGFueSBjaGFuZ2VzIHRvIHRoZSBmb3JtYXQgb2YgSVAgcGFja2V0cy4gVGh1cwogICBh bnkgZXhpc3RpbmcgSVAgc3RhY2sgY2FuIGJlIHVzZWQgYXMgaXQgaXM6IHRoZSBwcm90b2Nv bCBvbmx5CiAgIGludGVyYWN0cyB3aXRoIHJvdXRpbmcgdGFibGUgbWFuYWdlbWVudC4KCgo2 LiBNdWx0aXBvaW50IFJlbGF5cwoKICAgVGhlIGlkZWEgb2YgbXVsdGlwb2ludCByZWxheXMg aXMgdG8gbWluaW1pemUgZmxvb2Rpbmcgb2YgYnJvYWRjYXN0CiAgIG1lc3NhZ2VzIGluIHRo ZSBuZXR3b3JrIGJ5IHJlZHVjaW5nIGR1cGxpY2F0ZSByZXRyYW5zbWlzc2lvbnMgaW4KICAg dGhlIHNhbWUgcmVnaW9uLiBFYWNoIG5vZGUgaW4gdGhlIG5ldHdvcmsgc2VsZWN0cyBhIHNl dCBvZiBub2RlcyBpbgogICBpdHMgbmVpZ2hib3Job29kIHdoaWNoIG1heSByZXRyYW5zbWl0 IGl0cyBwYWNrZXRzLiBUaGlzIHNldCBvZgogICBzZWxlY3RlZCBuZWlnaGJvciBub2RlcyBp cyBjYWxsZWQgdGhlIG11bHRpcG9pbnQgcmVsYXkgKE1QUikgc2V0IG9mCiAgIHRoYXQgbm9k ZS4gVGhlIG5laWdoYm9ycyBvZiBub2RlIE4gd2hpY2ggYXJlICpOT1QqIGluIGl0cyBNUFIg c2V0LAogICByZWNlaXZlIGFuZCBwcm9jZXNzIGJyb2FkY2FzdCBtZXNzYWdlcyBidXQgZG8g bm90IHJldHJhbnNtaXQKICAgYnJvYWRjYXN0IG1lc3NhZ2VzIHJlY2VpdmVkIGZyb20gbm9k ZSBOLgoKICAgRWFjaCBub2RlIHNlbGVjdHMgaXRzIE1QUiBzZXQgYW1vbmcgaXRzIG9uZSBo b3AgbmVpZ2hib3JzLiBUaGlzIHNldAogICBpcyBzZWxlY3RlZCBzdWNoIHRoYXQgaXQgY292 ZXJzIChpbiB0ZXJtcyBvZiByYWRpbyByYW5nZSkgYWxsIHRoZQogICBub2RlcyB0aGF0IGFy ZSB0d28gaG9wcyBhd2F5LiBUaGUgbmVpZ2hib3Job29kIG9mIGFueSBub2RlIE4gY2FuIGJl CiAgIGRlZmluZWQgYXMgdGhlIHNldCBvZiBub2RlcyB3aGljaCBoYXZlIGEgc3ltbWV0cmlj IGxpbmsgdG8gTi4gVGhlCiAgIHR3byBob3AgbmVpZ2hib3Job29kIG9mIE4gY2FuIGJlIGRl ZmluZWQgYXMgdGhlIHNldCBvZiBub2RlcyB3aGljaAogICBkb24ndCBoYXZlIGEgc3ltbWV0 cmljIGxpbmsgdG8gTiBidXQgaGF2ZSBhIHN5bW1ldHJpYyBsaW5rIHRvIHRoZQogICBuZWln aGJvcmhvb2Qgb2YgTi4gVGhlIG11bHRpcG9pbnQgcmVsYXkgc2V0IG9mIE4sIGRlbm90ZWQg YXMgTVBSKE4pLAogICBpcyB0aGVuIGFuIGFyYml0cmFyeSBzdWJzZXQgb2YgdGhlIG5laWdo Ym9yaG9vZCBvZiBOIHdoaWNoCiAgIHNhdGlzZmllcyB0aGUgZm9sbG93aW5nIGNvbmRpdGlv bjogZXZlcnkgbm9kZSBpbiB0aGUgdHdvIGhvcAogICBuZWlnaGJvcmhvb2Qgb2YgTiBNVVNU IGhhdmUgYSBzeW1tZXRyaWMgbGluayB0b3dhcmQgTVBSKE4pLiBUaGUKICAgc21hbGxlciB0 aGUgbXVsdGlwb2ludCByZWxheSBzZXQgaXMsIHRoZSBtb3JlIG9wdGltYWwgaXMgdGhlCiAg IHJvdXRpbmcgcHJvdG9jb2wuIFsyXSBnaXZlcyBhbiBhbmFseXNpcyBhbmQgZXhhbXBsZSBh Ym91dAogICBtdWx0aXBvaW50IHJlbGF5IHNlbGVjdGlvbiBhbGdvcml0aG1zLgoKICAgRWFj aCBub2RlIG1haW50YWlucyBpbmZvcm1hdGlvbiBhYm91dCBhIHNldCBvZiBpdHMgbmVpZ2hi b3JzLiBUaGlzCiAgIGlzIHRoZSBzZXQgb2YgbmVpZ2hib3JzLCBjYWxsZWQgdGhlICJNdWx0 aXBvaW50IFJlbGF5IFNlbGVjdG9ycyIsCiAgIHdoaWNoIGhhdmUgc2VsZWN0ZWQgdGhlIG5v ZGUgYXMgYSBNUFIuIEEgbm9kZSBvYnRhaW4gdGhpcwogICBpbmZvcm1hdGlvbiBmcm9tIHRo ZSBwZXJpb2RpYyBIRUxMTyBtZXNzYWdlcyByZWNlaXZlZCBmcm9tIHRoZQogICBuZWlnaGJv cnMuIEEgYnJvYWRjYXN0IG1lc3NhZ2UsIGludGVuZGVkIHRvIGJlIGRpZmZ1c2VkIGluIHRo ZQogICB3aG9sZSBuZXR3b3JrLCBjb21pbmcgZnJvbSB0aGVzZSBNUFIgU2VsZWN0b3IgbmVp Z2hib3Igbm9kZXMgaXMKICAgYXNzdW1lZCB0byBiZSByZXRyYW5zbWl0dGVkIGJ5IHRoZSBu b2RlLiBUaGlzIHNldCBjYW4gY2hhbmdlIG92ZXIKICAgdGltZSAoaS5lLiB3aGVuIGEgbm9k ZSBzZWxlY3RzIGFub3RoZXIgTVBSLXNldCkgYW5kIGlzIGluZGljYXRlZCBieQogICB0aGUg c2VsZWN0b3Igbm9kZXMgaW4gdGhlaXIgSEVMTE8gbWVzc2FnZXMuIEVhY2ggbm9kZSBoYXMg YQogICBzcGVjaWZpYyBNdWx0aXBvaW50IHJlbGF5IFNlbGVjdG9yIFNlcXVlbmNlIE51bWJl ciAoTVNTTikKICAgYXNzb2NpYXRlZCB3aXRoIHRoaXMgc2V0LiBXaGVuZXZlciBpdHMgTVBS IHNlbGVjdG9yIHNldCBpcyB1cGRhdGVkLAogICB0aGUgbm9kZSBhbHNvIGluY3JlbWVudHMg aXRzIE1TU04uCgogICBPTFNSIHJlbGllcyBvbiBzZWxlY3Rpb24gb2YgbXVsdGlwb2ludCBy ZWxheXMsIGFuZCBjYWxjdWxhdGVzIHRoZQogICByb3V0ZXMgdG8gYSBkZXN0aW5hdGlvbiB0 aHJvdWdoIHRoZXNlIG5vZGVzLiBJLmUuIE1QUiBub2RlcyBhcmUKICAgc2VsZWN0ZWQgYXMg aW50ZXJtZWRpYXRlIG5vZGVzIGluIHRoZSBwYXRoIGJldHdlZW4gYSBzb3VyY2UgYW5kIGEK CgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQg Q2xhdXNlbiAgICAgW1BhZ2UgOV0KDApJTlRFUk5FVC1EUkFGVCAgICAgICBPcHRpbWl6ZWQg TGluayBTdGF0ZSBSb3V0aW5nICAgICAgICAgIDE4IEp1bHkgMjAwMAoKCgogICBkZXN0aW5h dGlvbi4gVG8gaW1wbGVtZW50IHRoaXMsIGVhY2ggbm9kZSBpbiB0aGUgbmV0d29yawogICBw ZXJpb2RpY2FsbHkgYnJvYWRjYXN0IHRoZSBpbmZvcm1hdGlvbiBkZXNjcmliaW5nIHdoaWNo IG5laWdoYm9ycwogICBoYXZlIHNlbGVjdGVkIGl0IGFzIGEgbXVsdGlwb2ludCByZWxheS4g IFVwb24gcmVjZWlwdCBvZiB0aGlzICJNUFIKICAgU2VsZWN0b3JzIiBpbmZvcm1hdGlvbiwg ZWFjaCBub2RlIGNhbGN1bGF0ZXMgb3IgdXBkYXRlcyB0aGUgcm91dGUKICAgdG8gZWFjaCBr bm93biBkZXN0aW5hdGlvbi4gU28gcHJpbmNpcGFsbHksIHRoZSByb3V0ZSBpcyBhIHNlcXVl bmNlCiAgIG9mIGhvcHMgdGhyb3VnaCB0aGUgbXVsdGlwb2ludCByZWxheXMgZnJvbSBzb3Vy Y2UgdG8gdGhlCiAgIGRlc3RpbmF0aW9uLgoKICAgTXVsdGlwb2ludCByZWxheXMgYXJlIHNl bGVjdGVkIGFtb25nIHRoZSBvbmUgaG9wIG5laWdoYm9ycyB3aXRoCiAgICJzeW1tZXRyaWMi IGkuZS4gYmktZGlyZWN0aW9uYWwgbGluay4gVGhlcmVmb3JlLCBzZWxlY3RpbmcgdGhlCiAg IHJvdXRlIHRocm91Z2ggbXVsdGlwb2ludCByZWxheXMgYXV0b21hdGljYWxseSBhdm9pZHMg dGhlIHByb2JsZW1zCiAgIGFzc29jaWF0ZWQgd2l0aCBkYXRhIHBhY2tldCB0cmFuc2ZlciBv biB1bmktZGlyZWN0aW9uYWwgbGlua3Mgc3VjaAogICBhcyB0aGUgcHJvYmxlbSBvZiBnZXR0 aW5nIGFuIGFja25vd2xlZGdlbWVudCBmb3IgdGhlIGRhdGEgcGFja2V0cwogICBhdCBlYWNo IGhvcC4KCgo3LiBQcm90b2NvbCBGdW5jdGlvbmluZwoKICAgSW4gdGhpcyBzZWN0aW9uIHdl IGRlc2NyaWJlIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbAogICBmdW5jdGlvbmluZy4g VGhpcyBpbmNsdWRlcyBkZXNjcmlwdGlvbnMgb2YgdGhlIGZvcm1hdCBhbmQgY29udGVudHMK ICAgb2YgdGhlIHBhY2tldHMgYmVpbmcgZXhjaGFuZ2VkIGJ5IHJvdXRlcnMsIHRoZSBhbGdv cml0aG1zIChlLmcuIGZvcgogICBwYWNrZXQgaGFuZGxpbmcgYW5kIHJvdXRpbmcgdGFibGUg Y2FsY3VsYXRpb24pIGFuZCBzdWdnZXN0ZWQgZGF0YQogICBzdHJ1Y3R1cmVzIGludGVybmFs bHkgaW4gZWFjaCByb3V0ZXIuCgo3LjEuIFBhY2tldCBGb3JtYXQKCiAgIE9MU1IgY29tbXVu aWNhdGVzIHVzaW5nIGFuIHVuaWZpZWQgcGFja2V0IGZvcm1hdCBmb3IgYWxsIGRhdGEKICAg cmVsYXRlZCB0byB0aGUgcHJvdG9jb2wuIEluc3BpcmVkIGJ5IHRoZSBjb25jZXB0IG9mICJl eHRlbnNpb24KICAgaGVhZGVycyIgZnJvbSBJUHY2LCB0aGUgcHVycG9zZSBvZiB0aGlzIGlz IHRvIGZhY2lsaXRhdGUKICAgZXh0ZW5zaWJpbGl0eSBvZiB0aGUgcHJvdG9jb2wgd2l0aG91 dCBicmVha2luZyBiYWNrd2FyZHMKICAgY29tcGF0aWJpbGl0eSBhcyB3ZWxsIGFzIHRvIHBy b3ZpZGUgYW4gZWFzeSB3YXkgb2YgcGlnZ3liYWNraW5nCiAgIGRpZmZlcmVudCAidHlwZXMi IG9mIGluZm9ybWF0aW9uIGludG8gYSBzaW5nbGUgdHJhbnNtaXNzaW9uLiBUaGVzZQogICBw YWNrZXRzIGFyZSBlbWJlZGRlZCBpbiBVRFAgZGF0YWdyYW1zIGZvciB0cmFuc21pc3Npb24g b3ZlciB0aGUKICAgbmV0d29yay4KCgoKCgoKCgoKCgoKCgoKSmFjcXVldCwgTXVobGV0aGFs ZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICAgW1BhZ2UgMTBd CgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyAg ICAgICAgICAxOCBKdWx5IDIwMDAKCgoKICAgVGhlIGJhc2ljIGxheW91dCBvZiBhbnkgcGFj a2V0IGluIE9MU1Igd2lsbCBiZSBhcyBmb2xsb3dzOgoKICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAgICAgRGVzdGluYXRp b24gQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgU291cmNlIEFkZHJlc3MgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgUGFja2V0IExlbmd0aCAg ICAgICAgIHwgICAgUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICB8ICBNZXNzYWdlIFR5cGUgfCAgIEJyb2FkY2FzdCAgIHwgICAgICAgICAgTmV4dCBN ZXNzYWdlICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICA6ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOgogICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1FU1NBR0UgICAgICAg ICAgICAgICAgICAgICAgICAgICAgOgogICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICB8ICBNZXNzYWdlIFR5cGUgfCAgIEJyb2FkY2FzdCAgIHwgICAg ICAgICAgTmV4dCBNZXNzYWdlICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgOgogICA6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1F U1NBR0UgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICA6ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICA6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICAgICAgICAgICAo ZXRjKQoKCjcuMS4xLiBQYWNrZXQgSGVhZGVyCgogICBEZXN0aW5hdGlvbiBBZGRyZXNzCiAg ICAgIAogICAgICBUaGUgYWRkcmVzcyBvZiB0aGUgbm9kZShzKSB0byByZWNlaXZlIHRoaXMg cGFja2V0LiBUaGlzIHdpbGwKICAgICAgb2Z0ZW4gYmUgdGhlIGJyb2FkY2FzdCBhZGRyZXNz IChpLmUuIGFsbCBub2RlcyBpbiB0aGUKICAgICAgbmVpZ2hib3Job29kKSBidXQgbWF5IGFs c28gYmUgdGhlIHVuaWNhc3QtYWRkcmVzcyBvZiBhIG5vZGUuCgogICBTb3VyY2UgQWRkcmVz cwogICAgICAKICAgICAgVGhlIGFkZHJlc3Mgb2YgdGhlIG5vZGUgd2hpY2ggaXMgdHJhbnNt aXR0aW5nIHRoaXMgcGFja2V0LiBBCiAgICAgIHBhY2tldCBtYXkgY29udGFpbiBtZXNzYWdl cywgd2hpY2ggb3JpZ2luYXRlIGZyb20gb3RoZXIgbm9kZXMKICAgICAgKHNlZSBzZWN0aW9u IDcuNCkuIEluIHRoYXQgY2FzZSwgdGhlIG1lc3NhZ2UgaXRzZWxmIE1VU1QgY29udGFpbgog ICAgICBhbiBvcmlnaW5hdG9yIGFkZHJlc3MsIHNpbmNlIHRoZSBzb3VyY2UgYWRkcmVzcyBv ZiB0aGUgcGFja2V0CiAgICAgIHdpbGwgYmUgdGhlIGFkZHJlc3Mgb2YgdGhlIG5vZGUgcmV0 cmFuc21pdHRpbmcgdGhlIG1lc3NhZ2UuCgoKCkphY3F1ZXQsIE11aGxldGhhbGVyLCBRYXl5 dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAgIFtQYWdlIDExXQoMCklOVEVS TkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAg MTggSnVseSAyMDAwCgoKCiAgIFBhY2tldCBMZW5ndGgKICAgICAgCiAgICAgIFRoZSBsZW5n dGggKGluIGJ5dGVzKSBvZiB0aGUgcGFja2V0CgogICBSZXNlcnZlZCBmb3IgZnV0dXJlIHVz ZQoKICAgICAgTVVTVCBiZSBzZXQgdG8gJzAwMDAwMDAwMDAwMDAwMDAnIHRvIGJlIGluIGNv bXBsaWFuY2Ugd2l0aCB0aGlzCiAgICAgIHZlcnNpb24gb2YgdGhlIGRyYWZ0LgoKICAgVGhl IGluZm9ybWF0aW9uIGluIHRoZSBoZWFkZXIgb2YgdGhpcyBwYWNrZXQgaXMgZXF1aXZhbGVu dCB0byB0aGUKICAgaW5mb3JtYXRpb24gb2J0YWluYWJsZSBmcm9tIHRoZSBVRFAgaGVhZGVy LgoKNy4xLjIuIEV4dGVuc2lvbiBIZWFkZXIKCiAgIE1lc3NhZ2UgVHlwZQoKICAgICAgVGhp cyBmaWVsZCBpbmRpY2F0ZXMgd2hpY2ggdHlwZSBvZiBtZXNzYWdlIGFyZSB0byBiZSBmb3Vu ZCBpbgogICAgICB0aGUgIk1FU1NBR0UiIHBhcnRpdGlvbi4gTWVzc2FnZSB0eXBlcyBpbiB0 aGUgcmFuZ2Ugb2YgMC0xMjcgYXJlCiAgICAgIHJlc2VydmVkIGZvciBtZXNzYWdlcyBpbiB0 aGlzIGRyYWZ0IGFuZCBpbgogICAgICBkcmFmdC1pZXRmLW1hbmV0LW9sc3ItZXh0ZW5zaW9u cy0wMC50eHQuCgogICBCcm9hZGNhc3QKCiAgICAgIFRoaXMgZmllbGQgaW5kaWNhdGVzIHRv IGEgbm9kZSB3aGV0aGVyIHRoZSBtZXNzYWdlIGlzIG1lYW50IGZvcgogICAgICBkaWZmdXNp b24gaW50byB0aGUgZW50aXJlIG5ldHdvcmsuIFRoaXMgZW5hYmxlcyBhIG5vZGUgdG8KICAg ICAgZm9yd2FyZCBtZXNzYWdlcyBjb3JyZWN0bHksIGV2ZW4gaWYgaXQgZG9lc24ndCByZWNv Z25pemUgdGhlCiAgICAgICJNZXNzYWdlIFR5cGUiLgoKICAgTmV4dCBNZXNzYWdlCiAgIAog ICAgICBUaGlzIGZpZWxkIGdpdmVzIHRoZSBvZmZzZXQgd2hlcmUgdGhlIG5leHQgImV4dGVu c2lvbiBoZWFkZXIiCiAgICAgIGNhbiBiZSBmb3VuZCwgYWxsb3dpbmcgYSBub2RlIHRvIHNr aXAgdGhyb3VnaCB0aGUgbWVzc2FnZXMuCgo3LjEuMy4gUGFja2V0IFByb2Nlc3NpbmcKCiAg IFVwb24gcmVjZWl2aW5nIHN1Y2ggYSBiYXNpYyBwYWNrZXQsIHRoZSBwcm90b2NvbCBwYXJz ZXIgZXhhbWluZXMKICAgZWFjaCBvZiB0aGUgImV4dGVuc2lvbiBoZWFkZXJzIi4gQmFzZWQg b24gdGhlIHZhbHVlIG9mIHRoZSAiTWVzc2FnZQogICBUeXBlIiBmaWVsZCwgdGhlIHBhcnNl ciBjYW4gZGV0ZXJtaW5lIHRoZSBmYWl0aCBvZiB0aGUgZGF0YSBwb3J0aW9uCiAgIG9mIHRo ZSBtZXNzYWdlOgoKICAgICAgMS4gSWYgdGhlIGRhdGEgYXJlIG9mIGEgdHlwZSB3aGljaCB0 aGUgcmVjZWl2aW5nIG5vZGUgY2FuCiAgICAgICAgIHByb2Nlc3MsIHRoZW4gdGhpcyBkYXRh IGlzIHByb2Nlc3NlZC4KICAgIAogICAgICAyLiBPdGhlcndpc2UsIGlmIHRoZSAiTWVzc2Fn ZSBUeXBlIiBpbmRpY2F0ZXMgYSB0eXBlLCB1bmtub3duIHRvCiAgICAgICAgIHRoZSBub2Rl LCB0aGUgIkJyb2FkY2FzdCIgZmllbGQgTVVTVCBiZSBleGFtaW5lZC4KCgoKCkphY3F1ZXQs IE11aGxldGhhbGVyLCBRYXl5dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAg W1BhZ2UgMTJdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUg Um91dGluZyAgICAgICAgICAxOCBKdWx5IDIwMDAKCgoKICAgICAgICAgMi4xIElmIHRoZSAi QnJvYWRjYXN0IiBmaWVsZCBpbmRpY2F0ZXMgdGhhdCB0aGUgbWVzc2FnZSBpcwogICAgICAg ICAgICAgdG8gYmUgcmV0cmFuc21pdHRlZCAoaS5lLiBpcyBzZXQgdG8gJ0JST0FEQ0FTVCcp LCBhbmQgaWYKICAgICAgICAgICAgIHRoZSByZWNpcGllbnQgaXMgYSBNUFIgb2YgdGhlIHNl bmRlciwgdGhlbiB0aGUgbWVzc2FnZQogICAgICAgICAgICAgTVVTVCBiZSByZXRyYW5zbWl0 dGVkIGJ5IHRoZSBub2RlLgoKCSAyLjIgT3RoZXJ3aXNlLCB0aGUgbWVzc2FnZSBTSE9VTEQg c2lsZW50bHkgYmUgZHJvcHBlZC4KCiAgIEJ5IGRlZmluaW5nIGEgc2V0IG9mIG1lc3NhZ2Ug dHlwZXMsIHdoaWNoIE1VU1QgYmUgcmVjb2duaXplZCBieSBhbGwKICAgaW1wbGVtZW50YXRp b25zIG9mIE9MU1IsIGl0IHdpbGwgYmUgcG9zc2libGUgdG8gZXh0ZW5kIHRoZSBwcm90b2Nv bAogICB0aHJvdWdoIGludHJvZHVjdGlvbiBvZiBhZGRpdGlvbmFsIG1lc3NhZ2UgdHlwZXMs IHdoaWxlIHN0aWxsIGJlCiAgIGFibGUgdG8gbWFpbnRhaW4gY29tcGF0aWJpbGl0eSB3aXRo IG9sZGVyIGltcGxlbWVudGF0aW9ucy4gVGhlIHR3bwogICBSRVFVSVJFRCBtZXNzYWdlIHR5 cGVzIGZvciBPTFNSIGFyZToKCiAgICAgICAgLSBIRUxMTy1tZXNzYWdlcywgcGVyZm9ybWlu ZyB0aGUgdGFzayBvZiBuZWlnaGJvciBzZW5zaW5nLgogICAgICAgIC0gVEMtbWVzc2FnZXMs IHBlcmZvcm1pbmcgdGhlIHRhc2sgb2YgbXVsdGlwb2ludCByZWxheQoJICBpbmZvcm1hdGlv biBkZWNsYXJhdGlvbi4KCiAgIEV4dGVuc2lvbnMgbWF5IGUuZy4gYmUgUEMtbWVzc2FnZXMg Zm9yIGVuYWJsaW5nIHBvd2VyIGNvbnNlcnZhdGlvbgogICAvIHNsZWVwIG1vZGUsIG11bHRp Y2FzdCByb3V0aW5nLCBnYXRld2F5IGFubm91bmNlbWVudHMgZXRjLgoKNy4yLiBOZWlnaGJv ciBzZW5zaW5nCgo3LjIuMS4gSEVMTE8gbWVzc2FnZSBicm9hZGNhc3QKCiAgIEVhY2ggbm9k ZSBNVVNUIGRldGVjdCB0aGUgbmVpZ2hib3Igbm9kZXMgd2l0aCB3aGljaCBpdCBoYXMgYSBk aXJlY3QKICAgYW5kIHN5bW1ldHJpYyBsaW5rLiBUaGUgdW5jZXJ0YWludGllcyBvdmVyIHJh ZGlvIHByb3BhZ2F0aW9uIG1heQogICBtYWtlIHNvbWUgbGlua3MgYXN5bW1ldHJpYy4gQ29u c2VxdWVudGx5LCBhbGwgbGlua3MgTVVTVCBiZSBjaGVja2VkCiAgIGluIGJvdGggZGlyZWN0 aW9ucyBpbiBvcmRlciB0byBiZSBjb25zaWRlcmVkIHZhbGlkLgoKICAgVG8gYWNjb21wbGlz aCB0aGlzLCBlYWNoIG5vZGUgYnJvYWRjYXN0cyBIRUxMTyBtZXNzYWdlcywgY29udGFpbmlu ZwogICBpbmZvcm1hdGlvbiBhYm91dCBuZWlnaGJvcnMgYW5kIHRoZWlyIGxpbmsgc3RhdHVz LiBUaGUgbGluayBzdGF0dXMKICAgbWF5IGVpdGhlciBiZSAic3ltbWV0cmljIiwgImhlYXJk IiAoYXN5bW1ldHJpYykgb3IgIk1QUiIuCiAgICJTeW1tZXRyaWMiIGluZGljYXRlcywgdGhh dCB0aGUgbGluayBoYXMgYmVlbiB2ZXJpZmllZCB0byBiZQogICBiaS1kaXJlY3Rpb25hbCwg aS5lLiBpdCBpcyBwb3NzaWJsZSB0byB0cmFuc21pdCBkYXRhIGluIGJvdGgKICAgZGlyZWN0 aW9ucy4gIkhlYXJkIiBpbmRpY2F0ZXMgdGhhdCB0aGUgbm9kZSBpcyBoZWFyaW5nIGZyb20g YQogICBuZWlnaGJvciwgYnV0IGl0IGlzIG5vdCBjb25maXJtZWQgdGhhdCB0aGlzIG5laWdo Ym9yIGlzIGFsc28KICAgaGVhcmluZyBmcm9tIHRoZSBub2RlLiAiTVBSIiBpbmRpY2F0ZXMs IHRoYXQgYSBub2RlIGlzIHNlbGVjdGVkIGJ5CiAgIHRoZSBzZW5kZXIgYXMgbXVsdGlwb2lu dCByZWxheS4gTVBSIHN0YXR1cyBpbXBsaWVzIHRoYXQgdGhlIGxpbmsgaXMgCiAgIHN5bW1l dHJpYyB0b28uCgogICBUaGVzZSBjb250cm9sIG1lc3NhZ2VzIGFyZSBicm9hZGNhc3QgdG8g YWxsIG9uZS1ob3AgbmVpZ2hib3JzLCBidXQKICAgYXJlICpub3QgcmVsYXllZCogdG8gZnVy dGhlciBub2Rlcy4gQSBIRUxMTy1tZXNzYWdlIGNvbnRhaW5zIGF0IGEKICAgbWluaW11bToK CiAgICAgIC0gYSBsaXN0IG9mIGFkZHJlc3NlcyBvZiBuZWlnaGJvcnMsIHRvIHdoaWNoIHRo ZXJlIGV4aXN0cyBhCiAgICAgICAgc3ltbWV0cmljIGxpbms7CgoKCkphY3F1ZXQsIE11aGxl dGhhbGVyLCBRYXl5dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAgW1BhZ2Ug MTNdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGlu ZyAgICAgICAgICAxOCBKdWx5IDIwMDAKCgoKICAgICAgLSBhIGxpc3Qgb2YgYWRkcmVzc2Vz IG9mIG5laWdoYm9ycywgd2hpY2ggaGF2ZSBiZWVuICJoZWFyZCI7CgogICAgICAtIGEgbGlz dCBvZiBuZWlnaGJvcnMsIHdoaWNoIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBtdWx0aXBvaW50 CiAgICAgICAgcmVsYXlzLgoKICAgVGhlIGxpc3Qgb2YgbmVpZ2hib3JzIGluIGEgSEVMTE8g bWVzc2FnZSBjYW4gYmUgcGFydGlhbCAoZS5nLiBkdWUKICAgdG8gbWVzc2FnZSBzaXplIGxp bWl0YXRpb25zLCBpbXBvc2VkIGJ5IHRoZSBuZXR3b3JrKSwgdGhlIHJ1bGUKICAgYmVpbmcg dGhhdCBhbGwgbmVpZ2hib3Igbm9kZXMgYXJlIGNpdGVkIGF0IGxlYXN0IG9uY2Ugd2l0aGlu IGEKICAgcHJlZGV0ZXJtaW5lZCByZWZyZXNoaW5nIHBlcmlvZCAoSEVMTE9fSU5URVJWQUwp LgoKICAgVG8gYWNjb21tb2RhdGUgZm9yIHRoZSBhYm92ZSBjb25zdHJhaW50cywgYXMgd2Vs bCBhcyB0byBhY2NvbW1vZGF0ZQogICBmb3IgZnV0dXJlIGV4dGVuc2lvbnMsIGFuIGFwcHJv YWNoIHNpbWlsYXIgdG8gdGhlIG92ZXJhbGwgcGFja2V0CiAgIGZvcm1hdCAoc2VlIHNlY3Rp b24gNi4xKSBpcyB0YWtlbi4gVGh1cyB0aGUgcHJvcG9zZWQgZm9ybWF0IG9mIGEKICAgSEVM TE8gbWVzc2FnZSBpczoKCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgIHwgICAgTWVzc2FnZSBTZXF1ZW5jZSBOdW1iZXIgICAgfCAgICAgIE1QUiBTZXF1 ZW5jZSBudW1iZXIgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBMaW5rIFR5cGUgICB8 ICAgUmVzZXJ2ZWQgICAgfCAgICAgICAgIE5leHQgTGluayBUeXBlICAgICAgICB8CiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIE5laWdoYm9yIEFkZHJlc3Mg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgIE5laWdoYm9yIEFkZHJlc3MgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIDogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4gLiAu ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6CiAgIDogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICBMaW5rIFR5cGUgICB8ICAgUmVzZXJ2ZWQgICAgfCAgICAgICAgIE5l eHQgTGluayBUeXBlICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgIE5laWdoYm9yIEFkZHJlc3MgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICAgICAgIE5laWdoYm9yIEFkZHJl c3MgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIDogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA6CiAgIDoJCQkJCQkJCSAgIDoKCQkJICAgICAgICAgKGV0YykKCgogICBUaGlzIGlzIHNl bnQgYXMgdGhlIGRhdGEtcG9ydGlvbiBvZiB0aGUgZ2VuZXJhbCBwYWNrZXQgZm9ybWF0CiAg IGRlc2NyaWJlZCBpbiA2LjEsIHdpdGggdGhlICJNZXNzYWdlIFR5cGUiIHNldCB0byBIRUxM T19NRVNTQUdFIGFuZAogICB0aGUgYnJvYWRjYXN0IGZpZWxkIHNldCB0byBOT19CUk9BRENB U1QuCgoKCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5v dCBhbmQgQ2xhdXNlbiAgICAgW1BhZ2UgMTRdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0 aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyAgICAgICAgICAxOCBKdWx5IDIwMDAKCgoKNy4y LjEuMS4gRGVzY3JpcHRpb24gb2YgdGhlIGZpZWxkcwoKICAgTWVzc2FnZSBTZXF1ZW5jZSBO dW1iZXIKCiAgICAgIFdoaWxlIGdlbmVyYXRpbmcgYSBIRUxMTyBtZXNzYWdlLCB0aGUgbm9k ZSB3aWxsIGFzc2lnbiBhIHVuaXF1ZQogICAgICBpZGVudGlmaWNhdGlvbiBudW1iZXIgdG8g dGhpcyBtZXNzYWdlLiBUaGlzIG51bWJlciBpcyBwdXQgaW50bwogICAgICB0aGUgU2VxdWVu Y2UgTnVtYmVyIGZpZWxkLiBUaGlzIHNlcXVlbmNlIG51bWJlciB3aWxsIGJlCiAgICAgIGRp ZmZlcmVudCBmb3IgYWxsIHRoZSBtZXNzYWdlcyBvcmlnaW5hdGVkIGJ5IHRoYXQgbm9kZS4K CiAgIE1QUiBTZXF1ZW5jZSBOdW1iZXIKCiAgICAgIFRoaXMgZmllbGQgaW5kaWNhdGVzIHRo ZSBzZXF1ZW5jZSBudW1iZXIgY29ycmVzcG9uZGluZyB0byB0aGUKICAgICAgbW9zdCByZWNl bnQgbXVsdGlwb2ludCByZWxheSBzZXQsIGNhbGN1bGF0ZWQgYnkgdGhlIHNlbmRlciBub2Rl LgoKICAgUmVzZXJ2ZWQKCiAgICAgIFRoaXMgZmllbGQgaXMgcmVzZXJ2ZWQgZm9yIGZ1dHVy ZSB1c2FnZSwgYW5kIE1VU1QgYmUgc2V0IHRvCiAgICAgIDAwMDAwMDAwIGZvciBjb21wbGlh bmNlIHdpdGggdGhpcyBkcmFmdC4KCiAgIExpbmsgVHlwZQoKICAgICAgVGhpcyBmaWVsZCBz cGVjaWZpZXMgdGhlIHR5cGUgb2YgbGluayB0aGUgc2VuZGluZyBub2RlIGhhcyB0bwogICAg ICB0aGUgZm9sbG93aW5nIGxpc3Qgb2YgbmVpZ2hib3JzLiBBcyBhIG1pbmltdW0sIHRoZSBm b2xsb3dpbmcKICAgICAgdGhyZWUgbGluayB0eXBlcyBhcmUgUkVRVUlSRUQgYnkgT0xTUjoK CgkgICAtIEFTWU1fTElOSyAtIGluZGljYXRpbmcgdGhhdCB0aGUgbGlua3MgYmV0d2VlbiB0 aGUgc2VuZGVyIAoJICAgICBhbmQgdGhlIG5laWdoYm9ycyBpbiB0aGUgZm9sbG93aW5nIGxp c3QgYXJlIGFzeW1tZXRyaWMgCgkgICAgIChpLmUuIHRoZSBuZWlnaGJvciBpcyAiaGVhcmQi KS4KCgkgICAtIFNZTV9MSU5LIC0gaW5kaWNhdGluZyB0aGF0IHRoZSBsaW5rcyBiZXR3ZWVu IHRoZSBzZW5kZXIgCgkgICAgIGFuZCB0aGUgbmVpZ2hib3JzIGluIHRoZSBmb2xsb3dpbmcg bGlzdCBhcmUgc3ltbWV0cmljLgoKCSAgIC0gTVBSX0xJTksgLSBpbmRpY2F0aW5nLCB0aGF0 IHRoZSBub2RlcyBpbiB0aGUgZm9sbG93aW5nCgkgICAgIGxpc3QgaGF2ZSBiZWVuIHNlbGVj dGVkIGJ5IHRoZSBzZW5kZXIgYXMgbXVsdGlwb2ludCAKCSAgICAgcmVsYXlzLiAKCSAgICAg KE5vdGljZTogdGhpcyBpbXBsaWVzLCB0aGF0IHRoZSBsaW5rcyBmcm9tIHRoZSBzZW5kZXIg CgkgICAgIG9mIHRoZSBIRUxMTyBhbmQgdG8gdGhlIG5vZGVzIGluIHRoZSBsaXN0IGFyZSBz eW1tZXRyaWMpLgoKICAgICAgSXQgaXMgcG9zc2libGUgdG8gcHJvdmlkZSBhZGRpdGlvbmFs IGluZm9ybWF0aW9uIGJ5IHNwZWNpZnlpbmcKICAgICAgYWRkaXRpb25hbCBsaW5rLXR5cGVz LCBlLmcuIExPU1RfTElOSyAtIGluZGljYXRpbmcgdGhhdCB0aGUgbGluawogICAgICBiZXR3 ZWVuIHRoZSBzZW5kZXIgYW5kIHRoZSBuZWlnaGJvcnMgaW4gdGhlIGZvbGxvd2luZyBsaXN0 IGhhcwogICAgICBiZWVuIGxvc3QuCgogICBOZWlnaGJvciBBZGRyZXNzCgogICAgICBUaGUg YWRkcmVzcyBvZiBhIG5laWdoYm9yLgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciwgUWF5eXVt LCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgIFtQYWdlIDE1XQoMCklOVEVSTkVU LURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAgMTgg SnVseSAyMDAwCgoKCjcuMi4yLiAgSEVMTE8gbWVzc2FnZSBwcm9jZXNzaW5nCgogICBUaGUg SEVMTE8gbWVzc2FnZXMgcGVybWl0IGVhY2ggbm9kZSB0byBhY3F1aXJlIGluZm9ybWF0aW9u IGFib3V0CiAgIGl0cyBuZWlnaGJvcmhvb2QgdXAgdG8gdHdvIGhvcHMuIEEgbm9kZSBtYWlu dGFpbnMgYSBOZWlnaGJvciB0YWJsZQogICBpbiB3aGljaCBpdCByZWNvcmRzIHRoZSBpbmZv cm1hdGlvbiAob2J0YWluZWQgZnJvbSB0aGUgSEVMTE8KICAgbWVzc2FnZXMpIGFib3V0IGl0 cyBvbmUgaG9wIG5laWdoYm9ycywgdGhlIHN0YXR1cyBvZiB0aGUgbGluayB3aXRoCiAgIHRo ZXNlIG5laWdoYm9ycywgYW5kIGEgbGlzdCBvZiB0d28gaG9wIG5laWdoYm9ycyB0aGF0IHRo ZXNlIG9uZSBob3AKICAgbmVpZ2hib3JzIGdpdmUgYWNjZXNzIHRvLiBUaGUgaW5mb3JtYXRp b24gaXMgcmVjb3JkZWQgaW4gdGhlCiAgIE5laWdoYm9yIHRhYmxlIGFzIGEgbmVpZ2hib3Ig ZW50cnksIHdoaWNoIG1heSBoYXZlIHRoZSBmb2xsb3dpbmcKICAgZm9ybWF0OgoKICAgICAg ICAgICAgICBOX01QUl9zZXEKCiAgICAgIDEuICBOX2FkZHIgICAgTl9zdGF0dXMgICAgTl8y aG9wX2xpc3QgICAgTl90aW1lCiAgICAgIDIuICBOX2FkZHIgICAgTl9zdGF0dXMgICAgTl8y aG9wX2xpc3QgICAgTl90aW1lCiAgICAgIDMuICAgICwsICAgICAgICAgLCwgICAgICAgICAg ICAsLCAgICAgICAgICAsLAoKICAgRWFjaCBlbnRyeSBpbiB0aGUgdGFibGUgY29uc2lzdHMg b2YgTl9hZGRyLCBOX3N0YXR1cywgTl8yaG9wX2xpc3QsCiAgIGFuZCBOX3RpbWUuIFRoaXMg c3BlY2lmaWVzIHRoYXQgdGhlIG5vZGUgd2l0aCBhZGRyZXNzIE5fYWRkciBpcyBhCiAgIG9u ZS1ob3AgbmVpZ2hib3IgdG8gdGhpcyBub2RlLCB0aGUgc3RhdHVzIG9mIHRoZSBsaW5rIGJl dHdlZW4gdGhlbQogICBpcyBOX3N0YXR1cywgYW5kIHRoaXMgbmVpZ2hib3IgcHJvdmlkZXMg YWNjZXNzIHRvIHRoZSB0d28gaG9wCiAgIG5laWdoYm9ycyBsaXN0ZWQgaW4gTl8yaG9wX2xp c3QuIFRoZSBOX3N0YXR1cyBjYW4gYmUgQVNZTV9MSU5LLAogICBTWU1fTElOSyBvciBNUFJf TElOSy4gQSBsaW5rIHN0YXR1cyBvZiBNUFJfTElOSyBpbXBsaWVzIHRoYXQgdGhlCiAgIGxp bmsgd2l0aCB0aGUgbmVpZ2hib3Igbm9kZSBOX2FkZHIgaXMgc3ltbWV0cmljICpBTkQqIHRo ZSBub2RlCiAgIE5fYWRkciBpcyBzZWxlY3RlZCBhcyBhIG11bHRpcG9pbnQgcmVsYXkgYnkg dGhpcyBub2RlLiBFYWNoCiAgIG5laWdoYm9yIGVudHJ5IGhhcyBhbiBhc3NvY2lhdGVkIGhv bGRpbmcgdGltZSBOX3RpbWUsIHVwb24KICAgZXhwaXJhdGlvbiBvZiB3aGljaCBpdCBpcyBu byBsb25nZXIgdmFsaWQgYW5kIGhlbmNlIE1VU1QgYmUKICAgcmVtb3ZlZC4KCiAgIFRoZSBu ZWlnaGJvciB0YWJsZSBhbHNvIGNvbnRhaW5zIGEgc2VxdWVuY2UgbnVtYmVyIE5fTVBSX3Nl cS4gVGhpcwogICBzcGVjaWZpZXMgdGhhdCB0aGUgbm9kZSBrZWVwaW5nIHRoaXMgbmVpZ2hi b3IgdGFibGUgaGFzIHNlbGVjdGVkCiAgIGl0cyBtb3N0IHJlY2VudCBNUFIgc2V0IHdpdGgg dGhlIHNlcXVlbmNlIG51bWJlciBOX01QUl9zZXEuIEV2ZXJ5CiAgIHRpbWUgYSBub2RlIHNl bGVjdHMgb3IgdXBkYXRlcyBpdHMgbXVsdGlwb2ludCByZWxheSBzZXQsIE5fTVBSX3NlcQog ICBpcyBpbmNyZW1lbnRlZCB0byBhIGhpZ2hlciB2YWx1ZS4gVGhpcyBudW1iZXIgaXMgcHV0 IGludG8gdGhlIEhFTExPCiAgIG1lc3NhZ2VzIGFzIGRlc2NyaWJlZCBpbiA2LjIuMS4KCiAg IFVwb24gcmVjZWl2aW5nIGEgSEVMTE8gbWVzc2FnZSwgdGhlIG5vZGUgdXBkYXRlcyB0aGUg bmVpZ2hib3IgZW50cnkKICAgY29ycmVzcG9uZGluZyB0byB0aGUgc2VuZGVyIG5vZGUgYWRk cmVzczoKCiAgICAgIDEuIElmIHRoZSBlbnRyeSBhbHJlYWR5IGV4aXN0czoKCiAgICAgICAg IDEuMSB0aGUgaG9sZGluZyB0aW1lIG9mIHRoZSBlbnRyeSBpcyByZWZyZXNoZWQgdG8KICAg ICAgICAgICAgIE5FSUdIQl9IT0xEX1RJTUUKCgoKCgoKSmFjcXVldCwgTXVobGV0aGFsZXIs IFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICBbUGFnZSAxNl0KDApJ TlRFUk5FVC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAg ICAgIDE4IEp1bHkgMjAwMAoKCgogICAgICAgICAxLjIgaWYgdGhlIG5vZGUgZmluZHMgaXRz IG93biBhZGRyZXNzIGFtb25nIHRoZSBhZGRyZXNzZXMKICAgICAgICAgICAgIGxpc3RlZCBp biB0aGUgSEVMTE8gbWVzc2FnZSwgaXQgdXBkYXRlcyB0aGUgc3RhdHVzIG9mIHRoZQogICAg ICAgICAgICAgbGluayB0byB0aGUgc2VuZGVyIG5vZGUgYXMgU1lNX0xJTksgaWYgaXQgd2Fz IEFTWU1fTElOSwogICAgICAgICAgICAgYmVmb3JlLgoKCSAxLjMgdGhlIE5fMmhvcF9saXN0 IG9mIHRoZSBlbnRyeSBpcyB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlCgkgICAgIGNvbnRlbnRz IG9mIHRoZSBIRUxMTy1tZXNzYWdlLiAKCiAgICAgIDIuIE90aGVyd2lzZSwgYSBuZXcgZW50 cnkgaXMgcmVjb3JkZWQgaW4gdGhlIE5laWdoYm9yIHRhYmxlIHdpdGg6CgogICAgICAgICAy LjEgTl9hZGRyIGlzIHNldCB0byB0aGUgYWRkcmVzcyBvZiB0aGUgc2VuZGVyIG5vZGUKCiAg ICAgICAgIDIuMiBOX3N0YXR1cyBpcyBzZXQgdG8gdGhlIHZhbHVlIG9mIEFTWU1fTElOSyAo YXN5bW1ldHJpYwogICAgICAgICAgICAgbGluaykKCiAgICAgICAgIDIuMyBOXzJob3BfbGlz dCBpcyBmaWxsZWQgd2l0aCB0aGUgbGlzdCBvZiBhZGRyZXNzZXMKICAgICAgICAgICAgIGNv bnRhaW5lZCBpbiB0aGUgSEVMTE8gbWVzc2FnZSB3aGljaCBoYXZlIGEgbGluayB0eXBlIG9m CiAgICAgICAgICAgICBTWU1fTElOSyBvciBNUFJfTElOSywgYW5kIHdoaWNoIGFyZSBub3Qg YWxyZWFkeSBwcmVzZW50CiAgICAgICAgICAgICBpbiB0aGUgTmVpZ2hib3IgdGFibGUgKGku ZS4sIHRoZXkgYXJlIG5vdCBvbmUtaG9wCiAgICAgICAgICAgICBuZWlnaGJvcnMpLgoKCSAg ICAgSWYgYSBub2RlIGZpbmRzIGl0cyBvd24gYWRkcmVzcyBpbiBhIEhFTExPIG1lc3NhZ2Ug d2l0aCBhCgkgICAgIGxpbmsgdHlwZSBvZiBBU1lNX0xJTkssIFNZTV9MSU5LIG9yIE1QUl9M SU5LLCBpdCBkb2VzIG5vdAoJICAgICByZWdpc3RlciBpdHNlbGYgaW4gdGhlIE5fMmhvcF9s aXN0LiBSYXRoZXIsIGl0IGNoYW5nZXMKCSAgICAgdGhlIGxpbmsgc3RhdHVzIHRvIHRoZSBz ZW5kZXIgb2YgdGhlIEhFTExPIGZyb20gQVNZTV9MSU5LCgkgICAgIHRvIFNZTV9MSU5LLgoK CSAyLjQgTl90aW1lIGlzIHNldCB0byB0aGUgdmFsdWUgb2YgTkVJR0hCX0hPTERfVElNRQoK ICAgQmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIG9idGFpbmVkIGZyb20gdGhlIEhFTExPIG1l c3NhZ2VzLCBlYWNoCiAgIG5vZGUgY29uc3RydWN0IGl0cyBNUFIgU2VsZWN0b3IgdGFibGUu IEluIHRoaXMgdGFibGUsIHRoZSBub2RlCiAgIHJlZ2lzdGVycyB0aGUgYWRkcmVzc2VzIG9m IHRob3NlIG9uZSBob3AgbmVpZ2hib3Igbm9kZXMgd2hpY2ggaGF2ZQogICBzZWxlY3RlZCB0 aGUgbm9kZSBhcyBhIG11bHRpcG9pbnQgcmVsYXkuIFRoZSBNUFIgU2VsZWN0b3IgdGFibGUg bWF5CiAgIGhhdmUgdGhlIGZvbGxvd2luZyBmb3JtYXQ6CgogICAgICAgICAgICAgICAgIE1T U04KICAgICAgMS4gIE1TX2FkZHIgICAgTVNfc2VxX251bSAgICBNU190aW1lCiAgICAgIDIu ICBNU19hZGRyICAgIE1TX3NlcV9udW0gICAgTVNfdGltZQogICAgICAzLiAgICAgLCwgICAg ICAgICAgLCwgICAgICAgICAgLCwKCiAgIEVhY2ggZW50cnkgaW4gdGhlIHRhYmxlIGNvbnNp c3RzIG9mIE1TX2FkZHIsIE1TX3NlcV9udW0gYW5kCiAgIE1TX3RpbWUsIHdoaWNoIHNwZWNp ZmllcyB0aGF0IHRoZSBub2RlIHdpdGggYWRkcmVzcyBNU19hZGRyIGhhcwogICBzZWxlY3Rl ZCB0aGlzIG5vZGUgYXMgaXRzIG11bHRpcG9pbnQgcmVsYXkgd2l0aCB0aGUgTVBSIHNlcXVl bmNlCiAgIG51bWJlciBlcXVhbCB0byBNU19zZXFfbnVtLiBFYWNoIGVudHJ5IGhhcyBhbiBh c3NvY2lhdGVkIGhvbGRpbmcKICAgdGltZSBNU190aW1lLCB1cG9uIGV4cGlhdGlvbiBvZiB3 aGljaCBpdCBpcyBubyBsb25nZXIgdmFsaWQgYW5kCiAgIGhlbmNlIHJlbW92ZWQuCgoKCkph Y3F1ZXQsIE11aGxldGhhbGVyLCBRYXl5dW0sIExhb3VpdGksIFZpZW5ub3QgYW5kIENsYXVz ZW4gICAgW1BhZ2UgMTddCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVkIExpbmsg U3RhdGUgUm91dGluZyAgICAgICAgICAxOCBKdWx5IDIwMDAKCgoKICAgQSBzZXF1ZW5jZSBu dW1iZXIsIE1TU04sIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGlzIHRhYmxlLiBUaGlzIG51bWJl cgogICBzcGVjaWZpZXMgdGhhdCB0aGUgbXVsdGlwb2ludCByZWxheSBzZWxlY3RvciBzZXQg b2YgdGhlIG5vZGUKICAga2VlcGluZyB0aGlzIE1QUiBTZWxlY3RvciB0YWJsZSBpcyBtb3N0 IHJlY2VudGx5IG1vZGlmaWVkIHdpdGggdGhlCiAgIHNlcXVlbmNlIG51bWJlciBNU1NOLiBU aGUgbm9kZSBtb2RpZmllcyBpdHMgTVBSIFNlbGVjdG9yIHNldAogICBhY2NvcmRpbmcgdG8g dGhlIGluZm9ybWF0aW9uIGl0IHJlY2VpdmVzIGluIHRoZSBIRUxMTyBtZXNzYWdlcywgYW5k CiAgIGluY3JlbWVudCB0aGlzIHNlcXVlbmNlIG51bWJlciB1cG9uIGVhY2ggbW9kaWZpY2F0 aW9uLgoKICAgVXBvbiByZWNlaXZpbmcgYSBIRUxMTyBtZXNzYWdlLCBpZiBhIG5vZGUgZmlu ZHMgaXRzIG93biBhZGRyZXNzIGluCiAgIHRoZSB0aGUgYWRkcmVzcyBsaXN0IHdpdGggYSBs aW5rIHR5cGUgb2YgIk1QUiIsIGl0IE1VU1QgdXBkYXRlIHRoZQogICBlbnRyeSBjb3JyZXNw b25kaW5nIHRvIHRoZSBzZW5kZXIgbm9kZSdzIGFkZHJlc3MgaW4gdGhlIE1QUgogICBTZWxl Y3RvciB0YWJsZToKCiAgICAgIDEuIElmIHRoZSBlbnRyeSBhbHJlYWR5IGV4aXN0czoKCiAg ICAgICAgIDEuMSBpZiB0aGUgTVBSIFNlcXVlbmNlIE51bWJlciBmaWVsZCBvZiB0aGUgSEVM TE8gbWVzc2FnZSBpcwogICAgICAgICAgICAgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIHRo ZSBNU19zZXFfbnVtIGZpZWxkIG9mIHRoZQogICAgICAgICAgICAgZW50cnkgaW4gdGhlIHRh YmxlLCB0aGVuIHRoZSBNU190aW1lIGlzIHJlZnJlc2hlZCB0bwogICAgICAgICAgICAgTkVJ R0hCX0hPTERfVElNRS4KCiAgICAgICAgIDEuMiBpZiB0aGUgTVBSIFNlcXVlbmNlIE51bWJl ciBmaWVsZCBvZiB0aGUgSEVMTE8gbWVzc2FnZSBpcwogICAgICAgICAgICAgZ3JlYXRlciB0 aGFuIHRoZSBNU19zZXFfbnVtIGZpZWxkIG9mIHRoYXQgZW50cnksIHRoZQogICAgICAgICAg ICAgTVNfc2VxX251bSBmaWVsZCBpcyB1cGRhdGVkIHRvIHRoZSB2YWx1ZSBvZiBNUFIgU2Vx dWVuY2UKICAgICAgICAgICAgIE51bWJlciBmaWVsZCBvZiB0aGUgSEVMTE8gbWVzc2FnZS4K CiAgICAgIDIuIE90aGVyd2lzZSwgYSBuZXcgZW50cnkgaXMgcmVjb3JkZWQgaW4gdGhlIE1Q UiBTZWxlY3RvciB0YWJsZSwKICAgICAgICAgd2l0aDoKCiAgICAgICAgIDIuMSBNU19hZGRy IGlzIHNldCB0byB0aGUgYWRkcmVzcyBvZiBzZW5kZXIgb2YgdGhlIEhFTExPCiAgICAgICAg ICAgICBtZXNzYWdlCgogICAgICAgICAyLjIgTVNfc2VxX251bSBpcyBzZXQgdG8gdGhlIE1Q UiBTZXF1ZW5jZSBOdW1iZXIgZmllbGQgb2YgdGhlCiAgICAgICAgICAgICBIRUxMTyBtZXNz YWdlCgogICAgICAgICAyLjMgTVNfdGltZSBpcyBzZXQgdG8gdGhlIHZhbHVlIG9mIE5FSUdI Ql9IT0xEX1RJTUUKCjcuMi4zLiBMaW5rIE5vdGlmaWNhdGlvbgoKICAgSWYgbGluayBsYXll ciBpbmZvcm1hdGlvbiBkZXNjcmliaW5nIGNvbm5lY3Rpdml0eSB0byBuZWlnaGJvcmluZwog ICBub2RlcyBpcyBhdmFpbGFibGUgKGkuZS4gbG9zcyBvZiBjb25uZWN0aXZpdHkgc3VjaCBh cyB0aHJvdWdoCiAgIGFic2VuY2Ugb2YgYW4gYWNrbm93bGVkZ21lbnQpLCB0aGlzIFNIT1VM RCBiZSB1c2VkIGluIGFkZGl0aW9uIHRvCiAgIHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBI RUxMTy1tZXNzYWdlcyB0byBtYWludGFpbiB0aGUgbmVpZ2hib3IKICAgdGFibGUgYW5kIHRo ZSBNUFIgc2VsZWN0b3IgdGFibGUuCgoKCgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciwgUWF5 eXVtLCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgIFtQYWdlIDE4XQoMCklOVEVS TkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAg MTggSnVseSAyMDAwCgoKCjcuMy4gTXVsdGlwb2ludCByZWxheSBzZWxlY3Rpb24KCiAgIEVh Y2ggbm9kZSBpbiB0aGUgbmV0d29yayBzZWxlY3RzIGluZGVwZW5kZW50bHkgaXRzIG93biBz ZXQgb2YKICAgbXVsdGlwb2ludCByZWxheXMuIE11bHRpcG9pbnQgcmVsYXlzIGFyZSB1c2Vk IHRvIGZsb29kIHRoZSBjb250cm9sCiAgIG1lc3NhZ2VzIG9mIHRoYXQgbm9kZSBpbnRvIHRo ZSBuZXR3b3JrLiBUaGUgTVBSIHNldCBpcyBjYWxjdWxhdGVkCiAgIGluIGEgd2F5IHN1Y2gg dGhhdCBpdCBjb250YWlucyBhIHN1YnNldCBvZiBvbmUgaG9wIG5laWdoYm9ycyB3aGljaAog ICBjb3ZlcnMgYWxsIHRoZSB0d28gaG9wIG5laWdoYm9ycy4gVGhpcyBtZWFucywgdGhhdCB0 aGUgdW5pb24gb2YgdGhlCiAgIG5laWdoYm9yIHNldHMgb2YgYWxsIE1QUnMgY29udGFpbnMg dGhlIGVudGlyZSB0d28gaG9wIG5laWdoYm9yCiAgIHNldC4gSW4gb3JkZXIgdG8gYnVpbGQg dGhlIGxpc3Qgb2YgdGhlIHR3byBob3Agbm9kZXMgZnJvbSBhIGdpdmVuCiAgIG5vZGUsIGl0 IHN1ZmZpY2VzIHRvIHRyYWNrIHRoZSBsaXN0IG9mIHN5bW1ldHJpYyBsaW5rIG5vZGVzIGZv dW5kCiAgIGluIHRoZSBIRUxMTyBtZXNzYWdlcyByZWNlaXZlZCBieSB0aGlzIG5vZGUgKHRo aXMgdHdvLWhvcCBuZWlnaGJvcgogICBpbmZvcm1hdGlvbiBpcyByZWNvcmRlZCBpbiB0aGUg bmVpZ2hib3IgdGFibGUgYXMKICAgTl8yaG9wX2xpc3QpLiBNdWx0aXBvaW50IHJlbGF5cyBv ZiBhIGdpdmVuIG5vZGUgYXJlIGRlY2xhcmVkIGluIHRoZQogICBzdWJzZXF1ZW50IEhFTExP cyB0cmFuc21pdHRlZCBieSB0aGlzIG5vZGUsIHNvIHRoYXQgdGhlIGluZm9ybWF0aW9uCiAg IHJlYWNoZXMgdGhlIG11bHRpcG9pbnQgcmVsYXlzIHRoZW1zZWx2ZXMuIFRoZXNlIHNlbGVj dGVkIG11bHRpcG9pbnQKICAgcmVsYXlzIGFyZSBpbmRpY2F0ZWQgaW4gdGhlIEhFTExPIG1l c3NhZ2VzIHdpdGggYSBsaW5rIHN0YXR1cyBvZgogICAiTVBSIi4gVGhlIG11bHRpcG9pbnQg cmVsYXkgc2V0IGlzIHJlLWNhbGN1bGF0ZWQgd2hlbjoKCiAgICAgIC0gYSBjaGFuZ2UgaW4g dGhlIG5laWdoYm9yaG9vZCBpcyBkZXRlY3RlZCwgaS5lLiBlaXRoZXIgYQogICAgICAgIHN5 bW1ldHJpYyBsaW5rIHdpdGggYSBuZWlnaGJvciBpcyBmYWlsZWQsIG9yIGEgbmV3IG5laWdo Ym9yCiAgICAgICAgd2l0aCBhIHN5bW1ldHJpYyBsaW5rIGlzIGFkZGVkOyBvcgogICAgICAt IGEgY2hhbmdlIGlzIGRldGVjdGVkIGluIHRoZSB0d28taG9wIG5laWdoYm9yaG9vZCBzdWNo IHRoYXQKICAgICAgICBhIHN5bW1ldHJpYyBsaW5rIGlzIGVpdGhlciBkZXRlY3RlZCBvciBi cm9rZW4gYmV0d2VlbiBhIAoJdHdvLWhvcCBuZWlnaGJvciBhbmQgYSBuZWlnaGJvci4KCiAg IFRoZSBNUFIgc2V0IG5lZWRzIG5vdCBiZSBvcHRpbWFsLiBIb3dldmVyIGl0IFNIT1VMRCBi ZSBzbWFsbCBlbm91Z2gKICAgdG8gYWNoaWV2ZSB0aGUgYmVuZWZpdCBvZiB0aGUgbXVsdGlw b2ludCByZWxheXMuIFRoZSBjb25jZXB0IG9mCiAgIG11bHRpcG9pbnQgcmVsYXlzIGlzIGFu IG9wdGltaXphdGlvbiBvZiBhIHB1cmUgZmxvb2RpbmcgbWVjaGFuaXNtLgogICBJdCBpcyBu b3QgZXNzZW50aWFsIHRoYXQgdGhlIG11bHRpcG9pbnQgcmVsYXkgc2V0IGJlIG1pbmltYWwg b3IKICAgb3B0aW1hbC4gQnV0IGl0IGlzIGVzc2VudGlhbCB0aGF0IGFsbCB0d28taG9wIG5l aWdoYm9ycyBjYW4gYmUKICAgcmVhY2hlZCB0aHJvdWdoIHRoZSBzZWxlY3RlZCBNUFIncy4g QnkgZGVmYXVsdCwgdGhlIG11bHRpcG9pbnQKICAgcmVsYXkgc2V0IGNhbiBjb2luY2lkZSB3 aXRoIHRoZSBlbnRpcmUgbmVpZ2hib3Igc2V0LiBUaGlzIHdpbGwgYmUKICAgdGhlIGNhc2Ug YXQgbmV0d29yayBpbml0aWFsaXphdGlvbi4gRWFjaCBub2RlIHdpbGwgbWFuYWdlIGEKICAg ZGVkaWNhdGVkIHNlcXVlbmNlIG51bWJlciBpbiBvcmRlciB0byB0cmFjayB0aGUgY2hhbmdl cyBpbiBpdHMKICAgbXVsdGlwb2ludCByZWxheSBzZXQuIFRoaXMgc2VxdWVuY2UgbnVtYmVy IHdpbGwgYWxzbyBhcHBlYXIsIGFsb25nCiAgIHdpdGggdGhlIE1QUiBsaXN0LCBpbiB0aGUg SEVMTE8gbWVzc2FnZXMuCgogICBXZSBwcm9wb3NlIGEgaGV1cmlzdGljIGZvciB0aGUgc2Vs ZWN0aW9uIG9mIG11bHRpcG9pbnQgcmVsYXlzCiAgIFsyXS4gV2UgdXNlIHRoZSBmb2xsb3dp bmcgdGVybWlub2xvZ3kgaW4gZGVzY3JpYmluZyB0aGlzIGFsZ29yaXRobToKCiAgICAgIE1Q Uih4KTogTXVsdGlwb2ludCByZWxheSBzZXQgb2Ygbm9kZSB4IHdoaWNoIGlzIHJ1bm5pbmcg dGhpcwogICAgICAgICAgICAgIGFsZ29yaXRobQogICAgICBOKHgpOiAgIE9uZSBob3AgbmVp Z2hib3Igc2V0IG9mIG5vZGUgeCAoY29udGFpbmluZyBvbmx5IHN5bW1ldHJpYwogICAgICAg ICAgICAgIG5laWdoYm9ycykKCgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciwgUWF5eXVtLCBM YW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgIFtQYWdlIDE5XQoMCklOVEVSTkVULURS QUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAgMTggSnVs eSAyMDAwCgoKCiAgICAgIE4yKHgpOiAgVHdvIGhvcCBuZWlnaGJvciBzZXQgb2Ygbm9kZSB4 IChjb250YWluaW5nIG9ubHkgc3ltbWV0cmljCiAgICAgICAgICAgICAgbmVpZ2hib3JzIG9m IG5vZGVzIGluIE4oeCkgKS4gVGhlIHR3byBob3AgbmVpZ2hib3Igc2V0CiAgICAgICAgICAg ICAgTjIoeCkgb2Ygbm9kZSB4IGRvZXMgbm90IGNvbnRhaW4gYW55IG9uZSBob3AgbmVpZ2hi b3Igb2YKICAgICAgICAgICAgICBub2RlIHgKCiAgICAgIEQoeCx5KTogRGVncmVlIG9mIG9u ZSBob3AgbmVpZ2hib3Igbm9kZSB5ICh3aGVyZSB5IGlzIGEgbWVtYmVyCiAgICAgICAgICAg ICAgb2YgTih4KSApLCBpcyBkZWZpbmVkIGFzIHRoZSBudW1iZXIgb2Ygc3ltbWV0cmljIG9u ZSBob3AKICAgICAgICAgICAgICBuZWlnaGJvcnMgb2Ygbm9kZSB5IEVYQ0xVRElORyB0aGUg bm9kZSB4IGFuZCBhbGwgdGhlCiAgICAgICAgICAgICAgc3ltbWV0cmljIG9uZSBob3AgbmVp Z2hib3JzIG9mIG5vZGUgeCB3aGljaCBleGl0IGFsc28KICAgICAgICAgICAgICBpbiBOKHkp LCBpLmUuLAogICAgICAgICAgICAgICAgIEQoeCx5KSA9IE4oeSkgLSB4IC0gTih4KQoKICAg VGhlIHByb3Bvc2VkIGhldXJpc3RpYyBpcyBhcyBmb2xsb3dzOgoKICAgICAgMS4gU3RhcnQg d2l0aCBhbiBlbXB0eSBNUFIoeCkKICAgICAgMi4gQ2FsY3VsYXRlIEQoeCx5KSwgd2hlcmUg eSBpcyBhIG1lbWJlciBvZiBOKHgpLCBmb3IgYWxsIG5vZGVzCiAgICAgICAgIGluIE4oeCkK ICAgICAgMy4gRmlyc3Qgc2VsZWN0IGFzIE1QUnMgdGhvc2Ugbm9kZXMgaW4gTih4KSB3aGlj aCBwcm92aWRlIHRoZQogICAgICAgICAib25seSBwYXRoIiB0byByZWFjaCBzb21lIG5vZGVz IGluIE4yKHgpCiAgICAgIDQuIFdoaWxlIHRoZXJlIHN0aWxsIGV4aXN0IHNvbWUgbm9kZXMg aW4gTjIoeCkgdGhhdCBhcmUgbm90CiAgICAgICAgIGNvdmVyZWQgYnkgTVBSKHgpOgoKICAg ICAgICAgNC4xIEZvciBlYWNoIG5vZGUgaW4gTih4KSwgY2FsY3VsYXRlIHRoZSBudW1iZXIg b2Ygbm9kZXMgaW4KICAgICAgICAgICAgIE4yKHgpIHdoaWNoIGFyZSBub3QgeWV0IGNvdmVy ZWQgYnkgTVBSKHgpIGFuZCBhcmUKICAgICAgICAgICAgIHJlYWNoYWJsZSB0aHJvdWdoIHRo aXMgb25lIGhvcCBuZWlnaGJvcjsKICAgICAgICAgNC4yIFNlbGVjdCBhcyBhIE1QUiB0aGF0 IG5vZGUgb2YgTih4KSB3aGljaCByZWFjaGVzIHRoZQogICAgICAgICAgICAgbWF4aW11bSBu dW1iZXIgb2YgdW5jb3ZlcmVkIG5vZGVzIGluIE4yKHgpLiBJbiBjYXNlIG9mIGEKICAgICAg ICAgICAgIHRpZSwgc2VsZWN0IHRoYXQgbm9kZSBhcyBNUFIgd2hvc2UgRCh4LHkpIGlzIGdy ZWF0ZXIuCgogICAgICA1LiBUbyBvcHRpbWl6ZSwgcmVtb3ZlIGVhY2ggbm9kZSBpbiBNUFIo eCksIG9uZSBhdCBhIHRpbWUsIGFuZAogICAgICAgICBjaGVjayBpZiBNUFIoeCkgc3RpbGwg Y292ZXJzIGFsbCBub2RlcyBpbiBOMih4KQoKICAgQWZ0ZXIgc2VsZWN0aW5nIHRoZSBtdWx0 aXBvaW50IHJlbGF5cyBhbW9uZyB0aGUgbmVpZ2hib3JzLCB0aGUgbGluawogICBzdGF0dXMg b2YgdGhlIGNvcnJlc3BvbmRpbmcgb25lIGhvcCBuZWlnaGJvcnMgaXMgY2hhbmdlZCBmcm9t CiAgIFNZTV9MSU5LIHRvIE1QUl9MSU5LIGluIHRoZSBuZWlnaGJvciB0YWJsZS4gTVBSX1Nl cV9OdW0gdmFsdWUgaW4KICAgdGhlIE5laWdoYm9yIHRhYmxlIGlzIGFsc28gaW5jcmVtZW50 ZWQgYnkgb25lLgoKNy40LiBNdWx0aXBvaW50IHJlbGF5IGluZm9ybWF0aW9uIGRlY2xhcmF0 aW9uCgo3LjQuMS4gVEMgTWVzc2FnZSBCcm9hZGNhc3QKCiAgIEluIG9yZGVyIHRvIGJ1aWxk IHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiBkYXRhYmFzZSBuZWVkZWQgZm9yCiAgIHJvdXRp bmcgdGhlIHBhY2tldHMsIGVhY2ggcmVsYXkgbm9kZSBicm9hZGNhc3RzIHNwZWNpZmljIHNl cnZpY2UKICAgbWVzc2FnZXMgY2FsbGVkIFRvcG9sb2d5IENvbnRyb2wgKFRDKSBtZXNzYWdl cy4gVEMgbWVzc2FnZXMgYXJlCgoKCkphY3F1ZXQsIE11aGxldGhhbGVyLCBRYXl5dW0sIExh b3VpdGksIFZpZW5ub3QgYW5kIENsYXVzZW4gICAgW1BhZ2UgMjBdCgwKSU5URVJORVQtRFJB RlQgICAgICAgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyAgICAgICAgICAxOCBKdWx5 IDIwMDAKCgoKICAgZm9yd2FyZGVkLCBsaWtlIHVzdWFsIGJyb2FkY2FzdCBtZXNzYWdlcywg dG8gYWxsIG5vZGVzIGluIHRoZQogICBuZXR3b3JrIGFuZCB0YWtlIGFkdmFudGFnZSBvZiBt dWx0aXBvaW50IHJlbGF5cy4gTXVsdGlwb2ludCByZWxheXMKICAgZW5hYmxlIGEgYmV0dGVy IHNjYWxhYmlsaXR5IGluIHRoZSBkaXN0cmlidXRpb24gb2YgdG9wb2xvZ3kKICAgaW5mb3Jt YXRpb24gWzFdLgoKICAgQSBUQyBtZXNzYWdlIGlzIHNlbnQgYnkgYSBub2RlIGluIHRoZSBu ZXR3b3JrIHRvIGRlY2xhcmUgaXRzIE1QUgogICBTZWxlY3RvciBzZXQuIEkuZS4sIHRoZSBU QyBtZXNzYWdlIGNvbnRhaW5zIHRoZSBsaXN0IG9mIG5laWdoYm9ycwogICB3aGljaCBoYXZl IHNlbGVjdGVkIHRoZSBzZW5kZXIgbm9kZSBhcyBhIG11bHRpcG9pbnQgcmVsYXkuIFRoZQog ICBzZXF1ZW5jZSBudW1iZXIgKE1TU04pIGFzc29jaWF0ZWQgd2l0aCB0aGlzIG11bHRpcG9p bnQgcmVsYXkKICAgc2VsZWN0b3Igc2V0IGlzIGFsc28gc2VudCB3aXRoIHRoZSBsaXN0LiBU aGUgbGlzdCBvZiBhZGRyZXNzZXMgY2FuCiAgIGJlIHBhcnRpYWwgaW4gZWFjaCBUQyBtZXNz YWdlIChlLmcuIGR1ZSB0byBtZXNzYWdlIHNpemUKICAgbGltaXRhdGlvbnMsIGltcG9zZWQg YnkgdGhlIG5ldHdvcmspLCBidXQgcGFyc2luZyBvZiBhbGwgVEMKICAgbWVzc2FnZXMgZGVz Y3JpYmluZyBhIG5vZGVzIE1QUiBzZWxlY3RvciBzZXQgTVVTVCBiZSBjb21wbGV0ZQogICB3 aXRoaW4gYSBjZXJ0YWluIHJlZnJlc2hpbmcgcGVyaW9kIChUQ19JTlRFUlZBTCkuIFRoZSBp bmZvcm1hdGlvbgogICBkaWZmdXNlZCBpbiB0aGUgbmV0d29yayBieSB0aGVzZSBUQyBtZXNz YWdlcyB3aWxsIGhlbHAgZWFjaCBub2RlIHRvCiAgIGNhbGN1bGF0ZSBpdHMgcm91dGluZyB0 YWJsZS4gQSBub2RlIHdoaWNoIGhhcyBhbiBlbXB0eSBNUFIgU2VsZWN0b3IKICAgc2V0LCBp LmUuIG5vYm9keSBoYXMgc2VsZWN0ZWQgaXQgYXMgYSBtdWx0aXBvaW50IHJlbGF5LCBNVVNU IE5PVAogICBnZW5lcmF0ZSBhbnkgVEMgbWVzc2FnZS4KCiAgIEEgbm9kZSBNQVkgdHJhbnNt aXQgYWRkaXRpb25hbCBUQy1tZXNzYWdlcyB0byBpbmNyZWFzZSBpdHMKICAgcmVhY3RpdmVu ZXNzIHRvIGxpbmsgZmFpbHVyZXMuIEkuZS4gd2hlbiBhIGNoYW5nZSB0byB0aGUgTVBSCiAg IHNlbGVjdG9yIHNldCBpcyBkZXRlY3RlZCBhbmQgdGhpcyBjaGFuZ2UgY2FuIGJlIGF0dHJp YnV0ZWQgdG8gYQogICBsaW5rIGZhaWx1cmUsIGEgVEMtbWVzc2FnZSBNQVkgYmUgdHJhbnNt aXR0ZWQgYWZ0ZXIgYSBzaG9ydGVyCiAgIGludGVydmFsIHRoYW4gVENfSU5URVJWQUwuCgog ICBUaGUgcHJvcG9zZWQgZm9ybWF0IG9mIGEgVEMgbWVzc2FnZSBpcwoKICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMK ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgTWVzc2FnZSBTZXF1ZW5jZSBO dW1iZXIgICAgIHwgICAgICAgICAgICAgIE1TU04gICAgICAgICAgICAgfAogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICB8ICAgSG9wIENvdW50ICAgfCAgICAgICAgICAgICAgICAgICAgVW51c2VkICAg ICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAg ICAgICAgIE9yaWdpbmF0b3IgQWRkcmVzcyAgICAgICAgICAgICAgICAgICAgICAgfAogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgTXVsdGlwb2ludCBSZWxheSBTZWxlY3Rv ciBBZGRyZXNzICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAg ICAgICAgTXVsdGlwb2ludCBSZWxheSBTZWxlY3RvciBBZGRyZXNzICAgICAgICAgICAgICAg fAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4u ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgVGhp cyBpcyBzZW50IGFzIHRoZSBkYXRhLXBvcnRpb24gb2YgdGhlIGdlbmVyYWwgbWVzc2FnZSBm b3JtYXQKICAgZGVzY3JpYmVkIGluIDYuMSwgd2l0aCB0aGUgIk1lc3NhZ2UgVHlwZSIgc2V0 IHRvIFRDX01FU1NBR0UgYW5kCiAgIHRoZSBicm9hZGNhc3QgZmllbGQgc2V0IHRvIEJST0FE Q0FTVC4KCgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciwgUWF5eXVtLCBMYW91aXRpLCBWaWVu bm90IGFuZCBDbGF1c2VuICAgIFtQYWdlIDIxXQoMCklOVEVSTkVULURSQUZUICAgICAgIE9w dGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgICAgICAgICAgMTggSnVseSAyMDAwCgoKCjcu NC4xLjEuIERlc2NyaXB0aW9uIG9mIHRoZSBmaWVsZHMKCiAgIE1lc3NhZ2UgU2VxdWVuY2Ug TnVtYmVyCgogICAgICBXaGlsZSBnZW5lcmF0aW5nIHRoZSBUQyBtZXNzYWdlLCB0aGUgIm9y aWdpbmF0b3IiIG5vZGUgd2lsbAogICAgICBhc3NpZ24gYSB1bmlxdWUgaWRlbnRpZmljYXRp b24gbnVtYmVyIHRvIHRoaXMgbWVzc2FnZSwgYW5kIHdpbGwKICAgICAgcHV0IHRoaXMgbnVt YmVyIGluIHRoZSBTZXF1ZW5jZSBOdW1iZXIgZmllbGQuIFRoaXMgc2VxdWVuY2UKICAgICAg bnVtYmVyIHdpbGwgYmUgZGlmZmVyZW50IGZvciBhbGwgbWVzc2FnZXMgb3JpZ2luYXRlZCBi eSB0aGF0CiAgICAgIG5vZGUsIGFuZCB3aWxsIGJlIHVzZWQgdG8gcmVjb2duaXplIGR1cGxp Y2F0ZSByZWNlcHRpb24gb2YKICAgICAgbWVzc2FnZXMuCgogICBNUFIgU2VsZWN0b3IgU2Vx dWVuY2UgTnVtYmVyIChNU1NOKQoKICAgICAgQSBzZXF1ZW5jZSBudW1iZXIgaXMgYXNzb2Np YXRlZCB3aXRoIHRoZSBtdWx0aXBvaW50IHJlbGF5CiAgICAgIHNlbGVjdG9yIHNldC4gRXZl cnkgdGltZSBhIG5vZGUgZGV0ZWN0cyBhIGNoYW5nZSBpbiBpdHMKICAgICAgbXVsdGlwb2lu dCByZWxheSBzZWxlY3RvciBzZXQsIGl0IGluY3JlbWVudHMgdGhpcyBzZXF1ZW5jZQogICAg ICBudW1iZXIuIFRoaXMgbnVtYmVyIGlzIHNlbnQgaW4gdGhpcyBNU1NOIGZpZWxkIG9mIHRo ZSBUQyBtZXNzYWdlCiAgICAgIHRvIGtlZXAgdHJhY2sgb2YgdGhlIG1vc3QgcmVjZW50IGlu Zm9ybWF0aW9uLiBXaGVuIGEgbm9kZQogICAgICByZWNlaXZlcyBhIFRDIG1lc3NhZ2UsIGl0 IGNhbiBkZWNpZGUgb24gdGhlIGJhc2lzIG9mIHRoaXMgTVBSCiAgICAgIFNlcXVlbmNlIE51 bWJlciwgd2hldGhlciBvciBub3QgdGhlIHJlY2VpdmVkIGluZm9ybWF0aW9uIGFib3V0CiAg ICAgIHRoZSBtdWx0aXBvaW50IHJlbGF5IHNlbGVjdG9ycyBvZiB0aGUgb3JpZ2luYXRvciBu b2RlIGlzIG1vcmUKICAgICAgcmVjZW50IHRoYW4gd2hhdCBpdCBhbHJlYWR5IGhhcy4KCiAg IEhvcCBDb3VudAoKICAgICAgVGhpcyBmaWVsZCB3aWxsIGNvbnRhaW4gdGhlIG1heGltdW0g bnVtYmVyIG9mIGhvcHMgYSBUQyBtZXNzYWdlCiAgICAgIGNhbiBhdHRhaW4uIEV2ZXJ5IHRp bWUgYSBUQyBtZXNzYWdlIGlzIHJlLXRyYW5zbWl0dGVkLCB0aGlzCiAgICAgIGZpZWxkIGlz IGRlY3JlbWVudGVkIGJ5IDEuIFdoZW4gdGhpcyBmaWVsZCByZWFjaGVzIHplcm8sIHRoZSBU QwogICAgICBtZXNzYWdlIGlzIG5vIG1vcmUgcmUtdHJhbnNtaXR0ZWQgYW5kIGlzIGRpc2Nh cmRlZC4KCiAgIE9yaWdpbmF0b3IgQWRkcmVzcwoKICAgICAgVGhpcyBmaWVsZCBjb250YWlu cyB0aGUgYWRkcmVzcyBvZiB0aGUgbm9kZSwgd2hpY2ggaGFzCiAgICAgIG9yaWdpbmFsbHkg Z2VuZXJhdGVkIHRoaXMgVEMgbWVzc2FnZS4gVGhpcyBmaWVsZCBNVVNUIG5vdCBiZQogICAg ICBjb25mdXNlZCB3aXRoIHRoZSBTb3VyY2UgQWRkcmVzcyBmaWVsZCwgd2hpY2ggaXMgY2hh bmdlZCBlYWNoCiAgICAgIHRpbWUgdG8gdGhlIGFkZHJlc3Mgb2YgdGhlIGludGVybWVkaWF0 ZSBub2RlIHdoaWNoIGlzCiAgICAgICJyZS10cmFuc21pdHRpbmciIHRoaXMgVEMgbWVzc2Fn ZS4gVGhlIE9yaWdpbmF0b3IgQWRkcmVzcyBmaWVsZAogICAgICBpcyAqbmV2ZXIqIGNoYW5n ZWQgaW4gdGhlIHJldHJhbnNtaXNzaW9ucy4KCiAgIE11bHRpcG9pbnQgUmVsYXkgU2VsZWN0 b3IgQWRkcmVzcyAoTVBSLVMpCgogICAgICBUaGlzIGZpZWxkIGNvbnRhaW5zIHRoZSBhZGRy ZXNzIG9mIGEgbm9kZSwgd2hpY2ggaGFzIHNlbGVjdGVkCiAgICAgIHRoZSBPcmlnaW5hdG9y IG5vZGUgKG9mIHRoZSBUQyBtZXNzYWdlKSBhcyBhIG11bHRpcG9pbnQgcmVsYXkuCiAgICAg IEFsbCBhZGRyZXNzZXMgb2YgdGhlIG11bHRpcG9pbnQgcmVsYXkgc2VsZWN0b3JzIG9mIHRo ZQogICAgICBPcmlnaW5hdG9yIG5vZGUgYXJlIHB1dCBpbiB0aGUgVEMgbWVzc2FnZS4gSWYg dGhlIG1heGltdW0KICAgICAgYWxsb3dlZCBtZXNzYWdlIHNpemUgKGFzIGltcG9zZWQgYnkg dGhlIG5ldHdvcmspIGlzIHJlYWNoZWQKCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1 bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICBbUGFnZSAyMl0KDApJTlRFUk5F VC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAgICAgIDE4 IEp1bHkgMjAwMAoKCgogICAgICB3aGlsZSB0aGVyZSBhcmUgc3RpbGwgbXVsdGlwb2ludCBy ZWxheSBzZWxlY3RvciBhZGRyZXNzZXMgd2hpY2gKICAgICAgd2hpY2ggaGF2ZSBub3QgYmVl biBpbnNlcnRlZCBpbnRvIHRoZSBUQy1tZXNzYWdlLCBtb3JlIFRDCiAgICAgIG1lc3NhZ2Vz IHdpbGwgYmUgZ2VuZXJhdGVkIHVudGlsIHRoZSBlbnRpcmUgTVBSIHNlbGVjdG9yIHNldCBo YXMKICAgICAgYmVlbiBzZW50LgoKNy40LjIuIFRDIE1lc3NhZ2UgUHJvY2Vzc2luZwoKICAg SW4gdGhlIE9MU1IgcHJvdG9jb2wsIFRDIG1lc3NhZ2VzIGFyZSBicm9hZGNhc3RlZCBhbmQg YXJlCiAgIHJldHJhbnNtaXR0ZWQgYnkgdGhlIG11bHRpcG9pbnQgcmVsYXlzIGluIG9yZGVy IHRvIGRpZmZ1c2UgdGhlCiAgIG1lc3NhZ2VzIGluIHRoZSBlbnRpcmUgbmV0d29yay4gSW4g dGhpcyBwcm9jZXNzLCBhIG5vZGUgTUFZIHJlY2VpdmUKICAgdGhlIHNhbWUgVEMgbWVzc2Fn ZSBtb3JlIHRoYW4gb25jZS4gVG8gYXZvaWQgcmUtcHJvY2Vzc2luZyBvZiBhIFRDCiAgIG1l c3NhZ2Ugd2hpY2ggd2FzIGFscmVhZHkgcmVjZWl2ZWQgYW5kIHByb2Nlc3NlZCwgZWFjaCBu b2RlCiAgIG1haW50YWlucyBhIER1cGxpY2F0ZSB0YWJsZS4gSW4gdGhpcyB0YWJsZSwgdGhl IG5vZGUgcmVjb3JkcwogICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbW9zdCByZWNlbnRseSBy ZWNlaXZlZCBUQyBtZXNzYWdlcy4gVGhlCiAgIGluZm9ybWF0aW9uIGlzIHJlY29yZGVkIGlu IHRoZSBEdXBsaWNhdGUgdGFibGUgYXMgRHVwbGljYXRlCiAgIGVudHJpZXMuCiAKICAgIFRo ZSB0YWJsZSBtYXkgaGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdDoKCiAgICAgIDEuICBEX2Fk ZHIgICAgRF9zZXFfbnVtICAgIERfdGltZQogICAgICAyLiAgRF9hZGRyICAgIERfc2VxX251 bSAgICBEX3RpbWUKICAgICAgMy4gICAgLCwgICAgICAgICAgLCwgICAgICAgICAsLAoKICAg RWFjaCBlbnRyeSBpbiB0aGUgdGFibGUgY29uc2lzdHMgb2YgRF9hZGRyLCBEX3NlcV9udW0g YW5kIERfdGltZSwKICAgd2hpY2ggc3BlY2lmaWVzIHRoYXQgYSBUQyBtZXNzYWdlIHdhcyBy ZWNlaXZlZCBmcm9tIHRoZSBub2RlIHdpdGgKICAgYWRkcmVzcyBEX2FkZHIsIGhhdmluZyB0 aGUgbWVzc2FnZSBzZXF1ZW5jZSBudW1iZXIgYXMgRC1zZXFfbnVtLgogICBFYWNoIER1cGxp Y2F0ZSBlbnRyeSBhbHNvIGhhcyBhbiBhc3NvY2lhdGVkIGhvbGRpbmcgdGltZSBEX3RpbWUs CiAgIHVwb24gZXhwaXJhdGlvbiBvZiB3aGljaCBpdCBpcyBubyBsb25nZXIgdmFsaWQgYW5k IGhlbmNlIE1VU1QgYmUKICAgcmVtb3ZlZC4KCiAgIFVwb24gcmVjZWl2aW5nIGEgVEMgbWVz c2FnZSwgYSBub2RlIGNoZWNrcyBpbiBpdHMgRHVwbGljYXRlIHRhYmxlCiAgIHRvIHNlZSBp ZiBpdCBoYXMgYWxyZWFkeSByZWNlaXZlZCB0aGUgc2FtZSBtZXNzYWdlLiBJZiBpdCBmaW5k cyBhCiAgIGNvcnJlc3BvbmRpbmcgZW50cnksIHRoZSBtZXNzYWdlIGlzIGRpc2NhcmRlZC4g T3RoZXJ3aXNlLCBhIG5ldwogICBlbnRyeSBpcyByZWNvcmRlZCBpbiB0aGUgRHVwbGljYXRl IHRhYmxlIGZvciB0aGlzIG5ld2x5IHJlY2VpdmVkIFRDCiAgIG1lc3NhZ2UsIGFuZCB0aGUg bWVzc2FnZSBpcyBwcm9jZXNzZWQuIFdoZW4gYSBub2RlIHJlY2VpdmVzIGEgVEMKICAgbWVz c2FnZSBmcm9tIGEgbmVpZ2hib3Igbm9kZSB3aXRoIHdoaWNoIGl0IGhhcyBhbiBhc3ltbWV0 cmljIChvcgogICB1bmktZGlyZWN0aW9uYWwpIGxpbmssIGl0IG5laXRoZXIgcmVnaXN0ZXJz IHRoZSBtZXNzYWdlIGluIHRoZQogICBEdXBsaWNhdGUgdGFibGUgbm9yIGl0IHByb2Nlc3Nl cyB0aGUgbWVzc2FnZS4KCiAgIEVhY2ggbm9kZSBpbiB0aGUgbmV0d29yayBtYWludGFpbnMg YSB0b3BvbG9neSB0YWJsZSwgaW4gd2hpY2ggaXQKICAgcmVjb3JkcyB0aGUgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHRvcG9sb2d5IG9mIHRoZSBuZXR3b3JrIGFzCiAgIG9idGFpbmVkIGZy b20gdGhlIFRDIG1lc3NhZ2VzLiBCYXNlZCBvbiB0aGlzIGluZm9ybWF0aW9uLCB0aGUKICAg cm91dGluZyB0YWJsZSBpcyBjYWxjdWxhdGVkLiBBIG5vZGUgcmVjb3JkcyBpbmZvcm1hdGlv biBhYm91dCB0aGUKICAgbXVsdGlwb2ludCByZWxheXMgb2Ygb3RoZXIgbm9kZXMgaW4gdGhl IG5ldHdvcmsgaW4gaXRzIHRvcG9sb2d5CiAgIHRhYmxlIGFzIGEgdG9wb2xvZ3kgZW50cnks IHdoaWNoIG1heSBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgoKCgoKSmFjcXVldCwgTXVo bGV0aGFsZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQgQ2xhdXNlbiAgICBbUGFn ZSAyM10KDApJTlRFUk5FVC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0 aW5nICAgICAgICAgIDE4IEp1bHkgMjAwMAoKCgogICAgICAxLiAgVF9kZXN0ICAgIFRfbGFz dCAgICBUX3NlcSAgICBUX3RpbWUKICAgICAgMi4gIFRfZGVzdCAgICBUX2xhc3QgICAgVF9z ZXEgICAgVF90aW1lCiAgICAgIDMuICAgICwsICAgICAgICAsLCAgICAgICAgLCwgICAgICAg LCwKCiAgIEVhY2ggZW50cnkgaW4gdGhlIHRhYmxlIGNvbnNpc3RzIG9mIFRfZGVzdCwgVF9s YXN0LCBUX3NlcSwgYW5kCiAgIFRfdGltZSwgd2hpY2ggc3BlY2lmaWVzIHRoYXQgdGhlIG5v ZGUgVF9kZXN0IGhhcyBzZWxlY3RlZCB0aGUgbm9kZQogICBUX2xhc3QgYXMgYSBtdWx0aXBv aW50IHJlbGF5IGFuZCB0aGF0IHRoZSBub2RlIFRfbGFzdCBoYXMgYW5ub3VuY2VkCiAgIHRo aXMgaW5mb3JtYXRpb24gb2YgaXRzIG11bHRpcG9pbnQgcmVsYXkgc2VsZWN0b3Igc2V0IHdp dGggdGhlCiAgIHNlcXVlbmNlIG51bWJlciBUX3NlcS4gVGhlcmVmb3JlLCB0aGUgbm9kZSBU X2Rlc3QgY2FuIGJlIHJlYWNoZWQgaW4KICAgdGhlIGxhc3QgaG9wIHRocm91Z2ggdGhlIG5v ZGUgVF9sYXN0LiBFYWNoIHRvcG9sb2d5IGVudHJ5IGhhcyBhbgogICBhc3NvY2lhdGVkIGhv bGRpbmcgdGltZSBUX3RpbWUsIHVwb24gZXhwaXJhdGlvbiBvZiB3aGljaCBpdCBpcyBubwog ICBsb25nZXIgdmFsaWQgYW5kIGhlbmNlIE1VU1QgYmUgcmVtb3ZlZC4KCiAgIFRoZSBlbnRy aWVzIGluIHRoZSB0b3BvbG9neSB0YWJsZSBhcmUgcmVjb3JkZWQgd2l0aCB0aGUgdG9wb2xv Z3kKICAgaW5mb3JtYXRpb24gdGhhdCBpcyBleGNoYW5nZWQgdGhyb3VnaCBUQyBtZXNzYWdl cy4KCiAgIFVwb24gcmVjZWl2aW5nCiAgIGEgVEMgbWVzc2FnZSwgdGhlIGZvbGxvd2luZyBw cm9jZWR1cmUgaXMgZXhlY3V0ZWQgdG8gcmVjb3JkIHRoZQogICBpbmZvcm1hdGlvbiBpbiB0 aGUgdG9wb2xvZ3kgdGFibGU6CgogICAgICAxLiBJZiB0aGVyZSBleGlzdCBzb21lIGVudHJ5 IGluIHRoZSB0b3BvbG9neSB0YWJsZSB3aG9zZSBUX2xhc3QKICAgICAgICAgY29ycmVzcG9u ZHMgdG8gdGhlIG9yaWdpbmF0b3IgYWRkcmVzcyBvZiB0aGUgVEMgbWVzc2FnZSBhbmQKICAg ICAgICAgd2hvc2UgVF9zZXEgaXMgZ3JlYXRlciBpbiB2YWx1ZSB0aGFuIHRoZSBNU1NOIGlu IHRoZSByZWNlaXZlZAogICAgICAgICBtZXNzYWdlLCB0aGVuIG5vIGZ1cnRoZXIgcHJvY2Vz c2luZyBvZiB0aGlzIFRDIG1lc3NhZ2UgaXMKICAgICAgICAgcGVyZm9ybWVkIGFuZCBpdCBp cyBzaWxlbnRseSBkaXNjYXJkZWQgKGNhc2U6IG1lc3NhZ2UKICAgICAgICAgcmVjZWl2ZWQg b3V0IG9mIG9yZGVyKS4KCiAgICAgIDIuIElmIHRoZXJlIGV4aXN0IHNvbWUgZW50cnkgaW4g dGhlIHRvcG9sb2d5IHRhYmxlIHdob3NlIFRfbGFzdAogICAgICAgICBjb3JyZXNwb25kcyB0 byB0aGUgb3JpZ2luYXRvciBhZGRyZXNzIG9mIHRoZSBUQyBtZXNzYWdlIGFuZAogICAgICAg ICB3aG9zZSBUX3NlcSBpcyBsZXNzZXIgaW4gdmFsdWUgdGhhbiB0aGUgTVNTTiBpbiB0aGUg cmVjZWl2ZWQKICAgICAgICAgbWVzc2FnZSwgdGhlbiB0aGF0IHRvcG9sb2d5IGVudHJ5IGlz IHJlbW92ZWQuCgogICAgICAzLiBGb3IgZWFjaCBvZiB0aGUgTVBSIFNlbGVjdG9yIGFkZHJl c3MgcmVjZWl2ZWQgaW4gdGhlIFRDCiAgICAgICAgIG1lc3NhZ2U6CgogICAgICAgICAzLjEg SWYgdGhlcmUgZXhpc3Qgc29tZSBlbnRyeSBpbiB0aGUgdG9wb2xvZ3kgdGFibGUgd2hvc2UK ICAgICAgICAgICAgIFRfZGVzdCBjb3JyZXNwb25kcyB0byB0aGUgTVBSIFNlbGVjdG9yIGFk ZHJlc3MgYW5kIHRoZQogICAgICAgICAgICAgVF9sYXN0IGNvcnJlc3BvbmRzIHRvIHRoZSBv cmlnaW5hdG9yIGFkZHJlc3Mgb2YgdGhlIFRDCiAgICAgICAgICAgICBtZXNzYWdlLCB0aGVu IHRoZSBob2xkaW5nIHRpbWUgVF90aW1lIG9mIHRoYXQgdG9wb2xvZ3kKICAgICAgICAgICAg IGVudHJ5IGlzIHJlZnJlc2hlZCB0byBUT1BfSE9MRF9USU1FLgoKICAgICAgICAgMy4yIE90 aGVyd2lzZSwgYSBuZXcgdG9wb2xvZ3kgZW50cnkgaXMgcmVjb3JkZWQgaW4gdGhlCiAgICAg ICAgICAgICB0b3BvbG9neSB0YWJsZSB3aGVyZWFzOgoKCgoKCgpKYWNxdWV0LCBNdWhsZXRo YWxlciwgUWF5eXVtLCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgIFtQYWdlIDI0 XQoMCklOVEVSTkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcg ICAgICAgICAgMTggSnVseSAyMDAwCgoKCiAgICAgICAgICAgICAgICAtIFRfZGVzdCBpcyBz ZXQgdG8gdGhlIE1QUiBTZWxlY3RvciBhZGRyZXNzLAogICAgICAgICAgICAgICAgLSBUX2xh c3QgaXMgc2V0IHRvIHRoZSBvcmlnaW5hdG9yIGFkZHJlc3Mgb2YgdGhlIFRDCiAgICAgICAg ICAgICAgICAgIG1lc3NhZ2UsCiAgICAgICAgICAgICAgICAtIFRfc2VxIGlzIHNldCB0byB0 aGUgdmFsdWUgb2YgTVNTTiByZWNlaXZlZCBpbiB0aGUgVEMKICAgICAgICAgICAgICAgICAg bWVzc2FnZSwKICAgICAgICAgICAgICAgIC0gVF90aW1lIGlzIHNldCB0byB0aGUgdmFsdWUg b2YgVE9QX0hPTERfVElNRS4KCjcuNS4gUm91dGluZyB0YWJsZSBjYWxjdWxhdGlvbgoKICAg RWFjaCBub2RlIG1haW50YWlucyBhIHJvdXRpbmcgdGFibGUgd2hpY2ggYWxsb3dzIGl0IHRv IHJvdXRlIHRoZQogICBtZXNzYWdlcyBmb3IgdGhlIG90aGVyIGRlc3RpbmF0aW9ucyBpbiB0 aGUgbmV0d29yay4gVGhlIG5vZGVzIHdoaWNoCiAgIHJlY2VpdmUgVEMgbWVzc2FnZXMgcGFy c2UgYW5kIHN0b3JlIHNvbWUgb2YgdGhlIGNvbm5lY3RlZCBwYWlycyBvZgogICBmb3JtIFtu b2RlLCBzb3VyY2VdIHdoZXJlICJub2RlcyIgYXJlIGlkZW50aWZpZWQgd2l0aCB0aGUgYWRk cmVzc2VzCiAgIGZvdW5kIGluIHRoZSBUQyBtZXNzYWdlLiBUaGUgcm91dGluZyB0YWJsZSBp cyBidWlsdCBmcm9tIHRoaXMKICAgZGF0YWJhc2UgYnkgdHJhY2tpbmcgdGhlIGNvbm5lY3Rl ZCBwYWlycyBpbiBhIGRlc2NlbmRpbmcgb3JkZXIuIFRvCiAgIGZpbmQgYSBwYXRoIGZyb20g YSBnaXZlbiBvcmlnaW4gdG8gYSByZW1vdGUgbm9kZSBSLCBvbmUgaGFzIHRvIGZpbmQKICAg YSBjb25uZWN0ZWQgcGFpciAoUixYKSwgdGhlbiBhIGNvbm5lY3RlZCBwYWlyIChYLFkpLCBh bmQgc28gZm9ydGgKICAgdW50aWwgb25lIGZpbmRzIGEgbm9kZSBZIGluIHRoZSBuZWlnaGJv ciBzZXQgb2YgdGhlIG9yaWdpbi4gSW4KICAgb3JkZXIgdG8gcmVzdHJpY3QgdG8gb3B0aW1h bCBwYXRocywgdGhlIHJlbGF5IG5vZGVzIHdpbGwgY29uc2lkZXIKICAgb25seSB0aGUgY29u bmVjdGVkIHBhaXJzIG9uIHRoZSBtaW5pbWFsIHBhdGguIFRoaXMgc2VsZWN0aW9uIGNhbiBi ZQogICBkb25lIGR5bmFtaWNhbGx5IGFuZCB3aXRoIG1pbmltYWwgc3RvcmFnZSBmYWNpbGl0 aWVzLiBUaGUgc2VxdWVuY2UKICAgbnVtYmVycyBhcmUgdXNlZCB0byBkZXRlY3QgY29ubmVj dGVkIHBhaXJzIHdoaWNoIGhhdmUgYmVlbgogICBpbnZhbGlkYXRlZCBieSBmdXJ0aGVyIHRv cG9sb2d5IGNoYW5nZXMuIFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQKICAgaW4gdGhlIHRv cG9sb2d5IGRhdGFiYXNlLCB3aGljaCBoYXMgbm90IGJlZW4gcmVmcmVzaGVkIGlzCiAgIGRp c2NhcmRlZC4KCiAgIFRoZSByb3V0aW5nIHRhYmxlIGlzIGJhc2VkIG9uIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhlCiAgIG5laWdoYm9yIHRhYmxlIGFuZCB0aGUgdG9wb2xv Z3kgdGFibGUuIFRoZXJlZm9yZSwgaWYgYW55IG9mIHRoZXNlCiAgIHRhYmxlcyBpcyBjaGFu Z2VkLCB0aGUgcm91dGluZyB0YWJsZSBpcyByZS1jYWxjdWxhdGVkIHRvIHVwZGF0ZSB0aGUK ICAgcm91dGUgaW5mb3JtYXRpb24gYWJvdXQgZWFjaCBkZXN0aW5hdGlvbiBpbiB0aGUgbmV0 d29yay4gVGhlIHJvdXRlCiAgIGVudHJpZXMgYXJlIHJlY29yZGVkIGluIHRoZSByb3V0aW5n IHRhYmxlIGluIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgoKICAgICAgMS4gIFJfZGVzdCAgICBS X25leHQgICAgUl9kaXN0CiAgICAgIDIuICBSX2Rlc3QgICAgUl9uZXh0ICAgIFJfZGlzdAog ICAgICAzLiAgICAsLCAgICAgICAgLCwgICAgICAgICwsCgogICBFYWNoIGVudHJ5IGluIHRo ZSB0YWJsZSBjb25zaXN0cyBvZiBSX2Rlc3QsIFJfbmV4dCBhbmQgUl9kaXN0LAogICB3aGlj aCBzcGVjaWZpZXMgdGhhdCB0aGUgbm9kZSBpZGVudGlmaWVkIGJ5IFJfZGVzdCBpcyBlc3Rp bWF0ZWQgdG8KICAgYmUgUl9kaXN0IGhvcHMgYXdheSBmcm9tIHRoZSBsb2NhbCBub2RlLCBh bmQgdGhhdCB0aGUgb25lIGhvcAogICBuZWlnaGJvciBub2RlIHdpdGggYWRkcmVzcyBSX25l eHQgaXMgdGhlIG5leHQgaG9wIG5vZGUgaW4gdGhlIHJvdXRlCiAgIHRvIFJfZGVzdC4gRW50 cmllcyBhcmUgcmVjb3JkZWQgaW4gdGhlIHRhYmxlIGZvciBlYWNoIGRlc3RpbmF0aW9uCiAg IGluIHRoZSBuZXR3b3JrIGZvciB3aGljaCB0aGUgcm91dGUgaXMga25vd24uIEFsbCB0aGUg ZGVzdGluYXRpb25zCiAgIGZvciB3aGljaCB0aGUgcm91dGUgaXMgYnJva2VuIG9yIHBhcnRp YWxseSBrbm93biBhcmUgbm90IGVudGVyZWQgaW4KICAgdGhlIHRhYmxlLgoKICAgVGhpcyBy b3V0aW5nIHRhYmxlIGluZm9ybWF0aW9uIGlzIHVwZGF0ZWQgd2hlbgoKCgpKYWNxdWV0LCBN dWhsZXRoYWxlciwgUWF5eXVtLCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgIFtQ YWdlIDI1XQoMCklOVEVSTkVULURSQUZUICAgICAgIE9wdGltaXplZCBMaW5rIFN0YXRlIFJv dXRpbmcgICAgICAgICAgMTggSnVseSAyMDAwCgoKCiAgICAgIC0gYSBjaGFuZ2UgaW4gdGhl IG5laWdoYm9yaG9vZCBpcyBkZXRlY3RlZCBjb25jZXJuaW5nIGEKICAgICAgICBzeW1tZXRy aWMgbGluazsKICAgICAgLSBhIHJvdXRlIHRvIGFueSBkZXN0aW5hdGlvbiBpcyBleHBpcmVk IChiZWNhdXNlIHRoZQogICAgICAgIGNvcnJlc3BvbmRpbmcgdG9wb2xvZ3kgZW50cnkgaXMg ZXhwaXJlZCkgb3IKICAgICAgLSBhIGJldHRlciAoZS5nLiBzaG9ydGVyKSByb3V0ZSBpcyBm b3VuZCBmb3IgYSBkZXN0aW5hdGlvbi4KCiAgIFRoZXJlZm9yZSwgdGhlIHJvdXRpbmcgdGFi bGUgaXMgcmUtY2FsY3VsYXRlZCBsb2NhbGx5IGVhY2ggdGltZSB0aGUKICAgbmVpZ2hib3Ig dGFibGUgb3IgdGhlIHRvcG9sb2d5IHRhYmxlIChvciBib3RoKSBhcmUgY2hhbmdlZC4gVGhl CiAgIHVwZGF0ZSBvZiB0aGlzIHJvdXRpbmcgdGFibGUgZG9lcyBub3QgZ2VuZXJhdGUgb3Ig dHJpZ2dlciBhbnkKICAgbWVzc2FnZXMgdG8gYmUgdHJhbnNtaXR0ZWQsIG5laXRoZXIgaW4g dGhlIG5ldHdvcmssIG5vciBpbiB0aGUKICAgb25lLWhvcCBuZWlnaGJvcmhvb2QuCgogICBU aGUgZm9sbG93aW5nIHByb2NlZHVyZSBpcyBleGVjdXRlZCB0byBjYWxjdWxhdGUgKG9yIHJl LWNhbGN1bGF0ZSkKICAgdGhlIHJvdXRpbmcgdGFibGUgOgoKICAgMS4gQWxsIHRoZSBlbnRy aWVzIG9mIHRoZSByb3V0aW5nIHRhYmxlIGFyZSByZW1vdmVkLgoKICAgMi4gVGhlIG5ldyBl bnRyaWVzIGFyZSByZWNvcmRlZCBpbiB0aGUgdGFibGUgc3RhcnRpbmcgd2l0aCB0aGUgb25l CiAgICAgIGhvcCBuZWlnaGJvcnMgKGg9MSkgYXMgdGhlIGRlc3RpbmF0aW9uIG5vZGVzLiBG b3IgZWFjaCBuZWlnaGJvcgogICAgICBlbnRyeSBpbiB0aGUgbmVpZ2hib3IgdGFibGUsIHdo b3NlIGxpbmsgc3RhdHVzIGlzIG5vdAogICAgICBhc3ltbWV0cmljLCBhIG5ldyByb3V0ZSBl bnRyeSBpcyByZWNvcmRlZCBpbiB0aGUgcm91dGluZyB0YWJsZQogICAgICB3aGVyZSBSX2Rl c3QgYW5kIFJfbmV4dCBhcmUgYm90aCBzZXQgdG8gdGhlIGFkZHJlc3Mgb2YgdGhlCiAgICAg IG5laWdoYm9yIGFuZCBSX2Rpc3QgaXMgc2V0IHRvIDEuCgogICAzLiBUaGVuIHRoZSBuZXcg cm91dGUgZW50cmllcyBmb3IgdGhlIGRlc3RpbmF0aW9uIG5vZGVzIGgrMSBob3BzCiAgICAg IGF3YXkgYXJlIHJlY29yZGVkIGluIHRoZSByb3V0aW5nIHRhYmxlLiBUaGUgZm9sbG93aW5n IHByb2NlZHVyZQogICAgICBpcyBleGVjdXRlZCBmb3IgZWFjaCB2YWx1ZSBvZiBoLCBzdGFy dGluZyB3aXRoIGg9MSBhbmQKICAgICAgaW5jcmVtZW50aW5nIGl0IGJ5IDEgZWFjaCB0aW1l LiBUaGUgZXhlY3V0aW9uIHdpbGwgc3RvcCBpZiBubwogICAgICBuZXcgZW50cnkgaXMgcmVj b3JkZWQgaW4gYW4gaXRlcmF0aW9uLgoKICAgICAgICAgMy4xIEZvciBlYWNoIHRvcG9sb2d5 IGVudHJ5IGluIHRoZSB0b3BvbG9neSB0YWJsZSwgaWYgaXRzCiAgICAgICAgICAgICBUX2Rl c3QgZG9lcyBub3QgY29ycmVzcG9uZCB0byBSX2Rlc3Qgb2YgYW55IHJvdXRlIGVudHJ5CiAg ICAgICAgICAgICBpbiB0aGUgcm91dGluZyB0YWJsZSBBTkQgaXRzIFRfbGFzdCBjb3JyZXNw b25kcyB0byBSX2Rlc3QKICAgICAgICAgICAgIG9mIGEgcm91dGUgZW50cnkgd2hvc2UgUl9k aXN0IGlzIGVxdWFsIHRvIGgsIHRoZW4gYSBuZXcKICAgICAgICAgICAgIHJvdXRlIGVudHJ5 IGlzIHJlY29yZGVkIGluIHRoZSByb3V0aW5nIHRhYmxlIHdoZXJlIDoKCiAgICAgICAgICAg ICAgICAtIFJfZGVzdCBpcyBzZXQgdG8gVF9kZXN0OwogICAgICAgICAgICAgICAgLSBSX25l eHQgaXMgc2V0IHRvIFJfbmV4dCBvZiB0aGUgcm91dGUgZW50cnkgd2hvc2UKICAgICAgICAg ICAgICAgICAgUl9kZXN0IGlzIGVxdWFsIHRvIFRfbGFzdDsgYW5kCiAgICAgICAgICAgICAg ICAtIFJfZGlzdCBpcyBzZXQgdG8gaCsxLgoKICAgNC4gQWZ0ZXIgY2FsY3VsYXRpbmcgdGhl IHJvdXRpbmcgdGFibGUsIHRoZSB0b3BvbG9neSB0YWJsZSBlbnRyaWVzCiAgICAgIHdoaWNo IGFyZSBub3QgdXNlZCBpbiBjYWxjdWxhdGluZyB0aGUgcm91dGVzIE1VU1QgYmUgcmVtb3Zl ZCwgaWYKICAgICAgdGhlcmUgaXMgYSBuZWVkIHRvIHNhdmUgbWVtb3J5IHNwYWNlLiBPdGhl cndpc2UsIHRoZXNlIGVudHJpZXMKICAgICAgbWF5IHByb3ZpZGUgbXVsdGlwbGUgcm91dGVz LgoKCgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBh bmQgQ2xhdXNlbiAgICAgW1BhZ2UgMjZdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1p emVkIExpbmsgU3RhdGUgUm91dGluZyAgICAgICAgICAgMTggSnVseSAyMDAwCgoKCjguIFBh Y2tldCBmb3J3YXJkaW5nCgo4LjEuIERhdGEgcGFja2V0IGZvcndhcmRpbmcKCiAgIERhdGEg cGFja2V0cyBhcmUgcmVsYXllZCBvbiBhIGhvcCBieSBob3AgYmFzaXMuIEluIHRoZSBzb3Vy Y2UKICAgcm91dGVyIGFuZCBpbiBhbnkgaW50ZXJtZWRpYXRlIHJvdXRlciwgdGhlIG5leHQg aG9wIHJvdXRlciBpcwogICBpZGVudGlmaWVkIGJ5IHRoZSBlbnRyeSBvZiB0aGUgZGVzdGlu YXRpb24gaW4gdGhlIGhvc3Qgcm91dGluZwogICB0YWJsZS4KCiAgIFdoZW5ldmVyIGEgZGF0 YSBwYWNrZXQgaXMgcmVjZWl2ZWQgdG8gcm91dGUgdG8gYSBkZXN0aW5hdGlvbiBhbmQKICAg aXRzIFRUTCBmaWVsZCAoaW4gSVAgaGVhZGVyKSBpcyBncmVhdGVyIHRoYW4gemVybywgdGhl IG5vZGUgTVVTVAogICBleGFtaW5lIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBmaWVsZCBpbiB0 aGUgcGFja2V0LiBJZiB0aGUgcm91dGUgaXMKICAga25vd24sIGkuZS4gYW4gZW50cnkgaXMg Zm91bmQgaW4gdGhlIHJvdXRpbmcgdGFibGUgaW4gd2hpY2ggUl9kZXN0CiAgIGNvcnJlc3Bv bmRzIHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiwgdGhlbiB0aGUgcGFja2V0IGlzCiAgIHRy YW5zbWl0dGVkIHRvIHRoZSBuZXh0IGhvcCBub2RlLiBXaGlsZSBmb3J3YXJkaW5nIGEgdW5p Y2FzdAogICBwYWNrZXQsIHRoZSBvcmlnaW5hdG9yIGFkZHJlc3MsIGFuZCB0aGUgZmluYWwg ZGVzdGluYXRpb24gYWRkcmVzcwogICBvZiB0aGUgcGFja2V0cyBhcmUgbm90IGNoYW5nZWQu IFRoZSBwYWNrZXQgdHJhdmVyc2VzIHRoZQogICBpbnRlcm1lZGlhdGUgc291cmNlIGFuZCBk ZXN0aW5hdGlvbiBwYWlycywgaG9wIGJ5IGhvcCwgdW50aWwgaXQKICAgcmVhY2hlcyBpdHMg ZmluYWwgZGVzdGluYXRpb24uCgo4LjIuIFRvcG9sb2d5IENvbnRyb2wgKFRDKSBwYWNrZXQg Zm9yd2FyZGluZwoKICAgVEMgcGFja2V0cyBhcmUgcmVsYXllZCBieSB0aGUgbXVsdGlwb2lu dCByZWxheXMgdmlhIHRoZSBmb2xsb3dpbmcKICAgcnVsZToKCiAgICAgIEEgbm9kZSByZXRy YW5zbWl0cyBhIFRDIHBhY2tldCBvbmx5IHdoZW4gaXQgcmVjZWl2ZXMgaXRzIGZpcnN0CiAg ICAgIGNvcHkgZnJvbSBhIG5vZGUgd2hpY2ggaXMgaXRzIG11bHRpcG9pbnQgcmVsYXkgc2Vs ZWN0b3IuCgogICBXaGVuIGEgVEMgcGFja2V0IGlzIHJlY2VpdmVkIHdpdGggYSBob3AgY291 bnQgaXMgZ3JlYXRlciB0aGFuIHplcm8sCiAgIHRoZW4gaXQgaXMgcmV0cmFuc21pdHRlZCBi eSB0aGUgbXVsdGlwb2ludCByZWxheXMgb2YgdGhlIHNlbmRlcgogICBub2RlLiBCZWZvcmUg cmV0cmFuc21pdHRpbmcsIHRoZSBob3AgY291bnQgaXMgZGVjcmVtZW50ZWQgYnkgb25lLgoK CjkuICBQcm9wb3NlZCB2YWx1ZXMgZm9yIHRoZSBjb25zdGFudHMKCiAgIFRoaXMgc2VjdGlv biBsaXN0IHRoZSB2YWx1ZXMgZm9yIHRoZSBjb25zdGFudHMgdXNlZCBpbiB0aGUKICAgZGVz Y3JpcHRpb24gb2YgdGhlIHByb3RvY29sLgoKICAgSEVMTE9fSU5URVJWQUwgICA9IDIgc2Vj b25kcwogICBUQ19JTlRFUlZBTCAgICAgID0gNSBzZWNvbmRzCiAgIFRDX01JTl9JTlRFUlZB TCAgPSAyIHNlY29uZHMKCiAgIE5FSUdIQl9IT0xEX1RJTUUgPSA2IHNlY29uZHMKICAgVE9Q X0hPTERfVElNRSAgICA9IDE1IHNlY29uZHMKCgoKCgpKYWNxdWV0LCBNdWhsZXRoYWxlciwg UWF5eXVtLCBMYW91aXRpLCBWaWVubm90IGFuZCBDbGF1c2VuICAgICBbUGFnZSAyN10KDApJ TlRFUk5FVC1EUkFGVCAgICAgICBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nICAgICAg ICAgICAxOCBKdWx5IDIwMDAKCgoKICAgSEVMTE9fUEFDS0VUICAgICA9IDEKICAgVENfUEFD S0VUICAgICAgICA9IDIKCiAgIEFTWU1fTElOSyAgICAgICAgPSAxCiAgIFNZTV9MSU5LICAg ICAgICAgPSAyCiAgIE1QUl9MSU5LICAgICAgICAgPSAzCgoKMTAuIFJlZmVyZW5jZXMKCiAg IDEuIFAuIEphY3F1ZXQsIFAuIE1pbmV0LCBQLiBNdWhsZXRoYWxlciwgTi4gUml2aWVycmUu ICBJbmNyZWFzaW5nCiAgICAgIHJlbGlhYmlsaXR5IGluIGNhYmxlIGZyZWUgcmFkaW8gTEFO czogTG93IGxldmVsIGZvcndhcmRpbmcgaW4KICAgICAgSElQRVJMQU4uIFdpcmVsZXNzIFBl cnNvbmFsIENvbW11bmljYXRpb25zLCAxOTk2CgogICAyLiBBLiBRYXl5dW0sIEwuIFZpZW5u b3QsIEEuIExhb3VpdGkuICBNdWx0aXBvaW50IHJlbGF5aW5nOiBBbgogICAgICBlZmZpY2ll bnQgdGVjaG5pcXVlIGZvciBmbG9vZGluZyBpbiBtb2JpbGUgd2lyZWxlc3MgbmV0d29ya3Mu CiAgICAgIElOUklBIHJlc2VhcmNoIHJlcG9ydCBSUi0zODk4LCAyMDAwCgogICAzLiBFVFNJ IFNUQy1SRVMxMCBDb21taXR0ZWUuICBSYWRpbyBlcXVpcG1lbnQgYW5kIHN5c3RlbXM6IEhJ UEVSTEFOCiAgICAgIHR5cGUgMSwgZnVuY3Rpb25hbCBzcGVjaWZpY2F0aW9ucyBFVFMgMzAw LTY1MiwgRVRTSSwgSnVuZSAxOTk2CgogICA0LiBDb3Jzb24gZXQgYWwuICBJbnRlcm5ldCBN QU5FVCBFbmNhcHN1bGF0aW9uIFByb3RvY29sLiBJbnRlcm5ldAogICAgICBkcmFmdCwgZHJh ZnQtaWV0Zi1tYW5ldC1pbWVwLXNwZWMtMDEudHh0LCBXb3JrIGluIHByb2dyZXNzLgoKICAg NS4gUGVya2lucywgQy5FLiwgIE1vYmlsZSBBZCBIb2MgTmV0d29ya2luZyBUZXJtaW5vbG9n eSwgSW50ZXJuZXQKICAgICAgZHJhZnQsIGRyYWZ0LWlldGYtbWFuZXQtdGVybS0wMC50eHQs IHdvcmsgaW4gcHJvZ3Jlc3MuCgogICA2LiBDb3Jzb24sIFMuLCAgTUFORVQgUm91dGluZyBQ cm90b2NvbCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCwKICAgICAgSW50ZXJuZXQgZHJhZnQs IGRyYWZ0LWlldGYtbWFuZXQtYXBwbC0wMC50eHQsIFdvcmsgaW4gcHJvZ3Jlc3MuCgogICA3 LiBTLiBCcmFkbmVyLiAgS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBS ZXF1aXJlbWVudAogICAgICBMZXZlbHMuICBSZXF1ZXN0IGZvciBDb21tZW50cyAoQmVzdCBD dXJyZW50IFByYWN0aWNlKSAyMTE5LAogICAgICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNr IEZvcmNlLCBNYXJjaCAxOTk3LgoKICAgOC4gUGhpbGlwcGUgSmFjcXVldCBhbmQgTGF1cmVu dCBWaWVubm90LCBPdmVyaGVhZCBpbiBNb2JpbGUgQWQtaG9jCiAgICAgIE5ldHdvcmsgUHJv dG9jb2xzLCBJTlJJQSByZXNlYXJjaCByZXBvcnQgUlItMzk2NSwgMjAwMAoKCgoKCgoKCgoK CgoKSmFjcXVldCwgTXVobGV0aGFsZXIsIFFheXl1bSwgTGFvdWl0aSwgVmllbm5vdCBhbmQg Q2xhdXNlbiAgICAgW1BhZ2UgMjhdCgwKSU5URVJORVQtRFJBRlQgICAgICAgT3B0aW1pemVk IExpbmsgU3RhdGUgUm91dGluZyAgICAgICAgICAgMTggSnVseSAyMDAwCgoKCjEyLiBBdXRo b3JzJyBBZGRyZXNzZXMKCiAgIEFtaXIgUWF5eXVtCiAgIFByb2plY3QgSElQRVJDT00KICAg SU5SSUEgUm9jcXVlbmNvdXJ0CiAgIEJQIDEwNQogICA3ODE1MyBMZSBDaGVzbmF5IENlZGV4 LCBGcmFuY2UKICAgUGhvbmU6ICszMyAxIDM5NjMgNTI3MwogICBFbWFpbDogQW1pci5RYXl5 dW1AaW5yaWEuZnIKCiAgIFBoaWxpcHBlIEphY3F1ZXQKICAgUHJvamVjdCBISVBFUkNPTQog ICBJTlJJQSBSb2NxdWVuY291cnQKICAgQlAgMTA1CiAgIDc4MTUzIExlIENoZXNuYXkgQ2Vk ZXgsIEZyYW5jZQogICBQaG9uZTogKzMzIDEgMzk2MyA1MjYzCiAgIEVtYWlsOiBQaGlsaXBw ZS5KYWNxdWV0QGlucmlhLmZyCgogICBQYXVsIE11aGxldGhhbGVyCiAgIFByb2plY3QgSElQ RVJDT00KICAgSU5SSUEgUm9jcXVlbmNvdXJ0CiAgIEJQIDEwNQogICA3ODE1MyBMZSBDaGVz bmF5IENlZGV4LCBGcmFuY2UKICAgUGhvbmU6ICszMyAxIDM5NjMgNTI3OAogICBFbWFpbDog QW5pcy5MYW91aXRpQGlucmlhLmZyCgogICBBbmlzIExhb3VpdGkKICAgUHJvamVjdCBISVBF UkNPTQogICBJTlJJQSBSb2NxdWVuY291cnQKICAgQlAgMTA1CiAgIDc4MTUzIExlIENoZXNu YXkgQ2VkZXgsIEZyYW5jZQogICBQaG9uZTogKzMzIDEgMzk2MyA1MDg4CiAgIEVtYWlsOiBB bmlzLkxhb3VpdGlAaW5yaWEuZnIKCiAgIExhdXJlbnQgVmllbm5vdAogICBQcm9qZWN0IEhJ UEVSQ09NCiAgIElOUklBIFJvY3F1ZW5jb3VydAogICBCUCAxMDUKICAgNzgxNTMgTGUgQ2hl c25heSBDZWRleCwgRnJhbmNlCiAgIFBob25lOiArMzMgMSAzOTYzIDUyMjUKICAgRW1haWw6 IExhdXJlbnQuVmllbm5vdEBpbnJpYS5mcgoKICAgVGhvbWFzIENsYXVzZW4KICAgUHJvamVj dCBISVBFUkNPTQogICBJTlJJQSBSb2NxdWVuY291cnQKICAgQlAgMTA1CiAgIDc4MTUzIExl IENoZXNuYXkgQ2VkZXgsIEZyYW5jZQogICBQaG9uZTogKzMzIDEgMzk2MyA1MTMzCiAgIEVt YWlsOiBUaG9tYXMuQ2xhdXNlbkBpbnJpYS5mcgoKCkphY3F1ZXQsIE11aGxldGhhbGVyLCBR YXl5dW0gZXQuIGFsLiAgRXhwaXJlcyAxOCBKYW51YXJ5IDIwMDEgICBbUGFnZSAyOV0K --lvW05TzvOd-- From owner-manet@itd.nrl.navy.mil Thu Jul 20 12:59:03 2000 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 MAA26262 for ; Thu, 20 Jul 2000 12:59:03 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA05043 for manet-outgoing; Thu, 20 Jul 2000 11:09:50 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA05033 for ; Thu, 20 Jul 2000 11:09:36 -0400 (EDT) Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e6KF75520080; Thu, 20 Jul 2000 17:07:05 +0200 (MET DST) Received: from alcatel.be (bt00t9 [138.203.66.143]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id RAA09310; Thu, 20 Jul 2000 17:05:05 +0200 (MET DST) Message-ID: <39771510.44594B9F@alcatel.be> Date: Thu, 20 Jul 2000 17:04:48 +0200 From: Omar Elloumi Organization: Alcatel Corporate Research Center X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "diffserv@ietf.org" , "tcplw@bsdi.com" , cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, DMANET@zpr.uni-koeln.de, end2end-interest@isi.edu, enternet@BBN.COM, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, itc@ieee.org, kuvs-elg@fokus.gmd.de, manet@itd.nrl.navy.mil, mobile-ip@smallworks.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov, tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@dartmouth.edu, testnet@canarie.ca, theorynt@listserv.nodak.edu, xtp-relay@cs.concordia.ca, "Dr. wahab" Subject: 6th ISCC - CFP References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit ****************************************** This e-mail has been sent to several distribution lists. We apologize if you receive multiple copies of it. ****************************************** The 6th IEEE Symposium on Computers and Communications 3-5 July, 2001 Hammamet, Tunisia http://www.cs.unc.edu/~jeffay/meetings/iscc2001/ http://www.ComSoc.org/ISCC/ Preliminary Call for Papers Sponsored by* IEEE Communications Society and IEEE Computer Society** General Chairs H. Abdel-Wahab, Old Dominion U., USA C. Savolaine, AT&T, USA Steering Committee H. Abdel-Wahab, Old Dominion U., USA T. N. Saadawi, City U of N.Y., USA M. H. Sherif, AT&T, USA A. Tantawy, IBM T.J. Watson Research Ctr., USA Technical Program Committee H. Akimaru, Asahi U., Japan K. Al-Tawil, KFUPM, Saudi Arabia M. Ammar, Georgia Tech, USA J. Ash, AT&T, USA A. Bestavros, Boston U., USA R. Boutaba, U. Waterloo, Canada K. Calvert, U. Kentucky, USA R. Chang, Polytech. Uni., Hong Kong M. Daneshmand, AT&T, USA J. Diaz, U. La Plata, Argentina M. T. El-Hadidi, Cairo U., Egypt N. Georganas, U. Ottawa S. Goddard, U. of Nebraska, Lincoln, USA M. Gouda, UTexas, USA S. Guan, National U. Singapore, Singapore A. Karmouch, U. Ottawa, Canada F. Kamoun, ENSI, Tunisia M. Karsten, Darmstadt U. of Tech., Germany A. Kujoory, AT&T, USA I. Matta, Boston U., USA K. Mills, NIST, USA K. Mori, Tokyo Inst. Tech., Japan H. Mouftah, Queens U., Canada H. Mueller, Siemens, Germany C. Perkins, Nokia,USA A. Pitsillides, U of Cyprus, Cyprus B. Plattner, ETH Zurich, Switzerland R. Popescu-Zeletin, GMD Fokus, Germany A. Puliafito, IIT, Italy I. Rhee, North Carolina State U., USA L. Saidane, ENSI, Tunisia D. Smith, UNC-Chapel Hill, USA G. Stassinopoulos, NTUA, Greece A. Tantawi, IBM T.J. Watson Research Ctr, USA S. Tohme, ENST-Paris, France M. Ulema, Daewoo Telecom, Ltd., USA A. Vahdat, Duke U., USA J. E. Wieselthier, Naval Research Lab, USA A. Youssef, George Washington U., USA Registration & Finance R. Ammar, U. Connecticut, USA A. Elmaghraby, U. Louisville, USA Local Organization Committee A. Ben-Youssef, ENSI, Tunisia K. Ben Rhouma, ENSI, Tunisia A. Ghedamsi, FST, Tunisia S. M'Hiri, ENSI, Tunisia Tutorials Committee H. Akhtar, AT&T, USA S. Fdida, U. Paris, France A. Yongacoglu, U. Ottawa Publicity Committee H. Afifi, INRIA, France O. Elloumi, Alcatel, France F. Gheni, ENSI, Tunisia G. Schaefer, ENST, France Continuing the tradition of this series of symposia, ISCC’2001 will provide an international technical forum for experts from industry and academia to exchange ideas and present results of ongoing research in the areas listed below. This year, special focus will be on the challenging issues related to the creation, management, dissemination, and communication of information. You are invited to submit a full paper, or a proposal for a panel, invited session, or tutorial, related to the following topics: Internet Services and Applications Electronic Commerce Security, Privacy and Information Access Multimedia Information Management and Exchange Distributed Systems Architecture and Management Wireless, Cellular and Mobile Communications Agent Technology Ad'hoc Networks High Performance Networking and Protocols Data Mining and Knowledge Discovery and Applications Programmable and Active Networks Network Design, Operation, and Management Control and Optimization of Communication Systems Network Reliability and Quality of Service Software Testing and Reliability Access Networks Management of Information Technology Signal Processing in Communications and Networking Cable Telephony and Broadband Service Please send four copies of your original unpublished paper (not to exceed 20 double-spaced pages) to reach either Technical Program Co-Chair at the addresses below by November 20, 2000. A concise and representative abstract should be included. The paper should clearly indicate the complete postal and electronic mailing addresses, as well as the phone and fax numbers of the corresponding author. Electronic submissions (e.g., Word, or PDF) are encouraged. Prof. Dr. Kevin Jeffay Prof. Dr. Ralf Steinmetz Dept. of Computer Science Dept. of EE & Info. Technology UNC-Chapel Hill Darmstadt U. of Technology Chapel Hill Merckstr. 25, D-64283 N.C. 27599, USA Darmstadt, Germany Tel: +1 919 962-1938 Tel: +49.6151.16.6151 Fax: +1 919 962-1799 Fax: +49.6151.16.6152 jeffay@cs.unc.edu ralf.steinmetz@kom.tu-darmstadt.de Important Dates: ----------------- November 20, 2000 Paper submission deadline February 19, 20 Notification of acceptance mailedto authors April 9, 2001 Final camera-ready manuscripts due Web Site http://www.ComSoc.org/ISCC http://www.cs.unc.edu/iscc2001 * Approval Pending ** Technical Committee on Simulation ISCC'2001 is hosted by the Ecole Nationale des Sciences de l'Informatique (ENSI), Tunisia. From owner-manet@itd.nrl.navy.mil Thu Jul 20 20:02:41 2000 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 UAA22029 for ; Thu, 20 Jul 2000 20:02:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA17333 for manet-outgoing; Thu, 20 Jul 2000 17:31:58 -0400 (EDT) Received: from hub.eng.wayne.edu (hub.eng.wayne.edu [141.217.13.43]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA17328 for ; Thu, 20 Jul 2000 17:31:56 -0400 (EDT) Received: from vajrasuchika.eng.wayne.edu ([141.217.183.92]) by hub.eng.wayne.edu (8.9.3/8.9.3) with ESMTP id RAA11551 for ; Thu, 20 Jul 2000 17:31:55 -0400 (EDT) Received: from vajrasuchika (vajrasuchika [141.217.183.92]) by vajrasuchika.eng.wayne.edu (8.9.1b+Sun/8.9.1) with SMTP id RAA08449 for ; Thu, 20 Jul 2000 17:33:25 -0400 (EDT) Message-Id: <200007202133.RAA08449@vajrasuchika.eng.wayne.edu> Date: Thu, 20 Jul 2000 17:33:25 -0400 (EDT) From: Manish Kochhal Reply-To: Manish Kochhal Subject: Please help with ad hoc network simulation with NS To: manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eRipqJAC231SZeGFYToNSg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi! I am Manish Kochhal pursuing my MS + PHD in Wayne State University .....I am stuck with the simulation of Mobile Ad hoc Networks Routing Protocols.... I have some questions: 1. Does the current version of ns ie ns-2.1b6 supports mobile ad hoc network routing protocol simulation.....Does it have CBT ( core based tree ) as its routing protocol, if not then which routing protocol does it support... 2. Are u aware of any Reference material which would serve as a guidance for me in order to simulate Ad hoc networks.....Is Marc Greis Tutorial Sufficient enough, particularly the CMU Monarch Wireless extensions to NS 3. If current version of NS doesnt support any Mobile Ad hoc Network Simulation this implies that I have to virtually create the Test Bed for my simulation from the scratch.....Are u aware of any software which has implemented NS for MANET and can u send me the link of that Software for NS..... Awaiting for ur suggestions Thanks in advance Sincerely Manish ******************************************************* * * * Name : Manish M Kochhal * * * * Address : 5200 Anthony Wayne Drive * * Apt #1312, De Roy Apartments * * Detroit , MI 48202 * * USA. * * * * Phone Number : 313 832 1724 (Home) * * 313 577 5802 (Work) * * * * email : manisk@vajrasuchika.eng.wayne.edu * * manishkochhal@acm.org * * kochhal_manish@hotmail.com * * * +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=* * We receive three educations: * * one from our parents, one from our schoolmaster, * * and one from the world. * * * * The third contradicts all that the first two teach* * us * * - Baron de Montesquieu * * * ******************************************************* From owner-manet@itd.nrl.navy.mil Fri Jul 21 06:56:02 2000 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 GAA11295 for ; Fri, 21 Jul 2000 06:56:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA25058 for manet-outgoing; Fri, 21 Jul 2000 03:51:32 -0400 (EDT) Received: from monza.eurecom.fr (monza.eurecom.fr [193.55.113.133]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA25053 for ; Fri, 21 Jul 2000 03:51:29 -0400 (EDT) Received: from madiran (madiran.eurecom.fr [193.55.114.219]) by monza.eurecom.fr (Postfix) with ESMTP id 45F0F18BDD; Fri, 21 Jul 2000 09:51:26 +0200 (MET DST) X-Mailer: exmh version 1.6.9 8/22/96 To: Manish Kochhal Cc: manet@itd.nrl.navy.mil Subject: Re: Please help with ad hoc network simulation with NS In-reply-to: Your message of "Thu, 20 Jul 2000 17:33:25 EDT." <200007202133.RAA08449@vajrasuchika.eng.wayne.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jul 2000 09:51:26 +0200 From: Shiyi Wus Message-Id: <20000721075126.45F0F18BDD@monza.eurecom.fr> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We can find four routing protocol are implemented in ns-2.1b6, they are DSDV, DSR, TORA, AODV. Of course you can realise your routing protocol in ns. The extensions has been added to cmu model in order to simulate both wired and wireless nodes. You can find this information in the NS's document: ns Notes and Documentation. Best Regards Shiyi From owner-manet@itd.nrl.navy.mil Fri Jul 21 07:18:13 2000 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 HAA21294 for ; Fri, 21 Jul 2000 07:18:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA25897 for manet-outgoing; Fri, 21 Jul 2000 05:10:45 -0400 (EDT) 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 FAA25892 for ; Fri, 21 Jul 2000 05:10:43 -0400 (EDT) Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6L9AXn25590 for ; Fri, 21 Jul 2000 12:10:34 +0300 (EET DST) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6L9AVD21456 for ; Fri, 21 Jul 2000 12:10:32 +0300 (EET DST) Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA04059 for ; Fri, 21 Jul 2000 12:10:31 +0300 (EETDST) Received: from nokia.com (tarom@tarom.research.nokia.com [172.21.41.34]) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id MAA03270 for ; Fri, 21 Jul 2000 12:10:30 +0300 (EET DST) Message-ID: <39783DAB.3D80BB91@nokia.com> Date: Fri, 21 Jul 2000 15:10:19 +0300 From: Manel Guerrero Zapata X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: About redistributing routes 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: I've been thinking about the following: In a router that uses different router protocols (one of them is AODV). Let's say than the other router protocols redistribute (or might do it) routes between each other. Taking into account the nature of AODV, should AODV make and/or accept some kind of redistribution with them? Although AODV would be the only routing protocol for adhoc networks in that router? What do you think about it? BR/ManelG From owner-manet@itd.nrl.navy.mil Fri Jul 21 09:25:48 2000 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 JAA11865 for ; Fri, 21 Jul 2000 09:25:47 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA27534 for manet-outgoing; Fri, 21 Jul 2000 07:09:46 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA27529 for ; Fri, 21 Jul 2000 07:09:44 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id HAA12625; Fri, 21 Jul 2000 07:09:34 -0400 (EDT) Date: Fri, 21 Jul 2000 07:09:30 -0400 (EDT) From: Zygmunt Haas To: Shiyi Wus cc: Manish Kochhal , manet@itd.nrl.navy.mil Subject: Re: Please help with ad hoc network simulation with NS In-Reply-To: <20000721075126.45F0F18BDD@monza.eurecom.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Shiyi, The ZRP protocol is being currently implemented in ns as well. We expect the implementation to be completed within the next month or so. Zygmunt. ==---==-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Fri, 21 Jul 2000, Shiyi Wus wrote: > We can find four routing protocol are implemented in ns-2.1b6, they are DSDV, > DSR, TORA, AODV. Of course you can realise your routing protocol in ns. The > extensions has been added to cmu model in order to simulate both wired and > wireless nodes. You can find this information in the NS's document: ns Notes > and Documentation. > > Best Regards > Shiyi > > From owner-manet@itd.nrl.navy.mil Fri Jul 21 09:48:46 2000 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 JAA13360 for ; Fri, 21 Jul 2000 09:48:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA28048 for manet-outgoing; Fri, 21 Jul 2000 07:30:54 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA28043 for ; Fri, 21 Jul 2000 07:30:52 -0400 (EDT) Received: from pearlman (pearlman.ee.cornell.edu [128.84.224.56]) by ee.cornell.edu (8.9.3/8.9.1) with SMTP id HAA12841; Fri, 21 Jul 2000 07:30:49 -0400 (EDT) Received: by localhost with Microsoft MAPI; Fri, 21 Jul 2000 07:30:20 -0400 Message-ID: <01BFF2E5.861AD040.pearlman@ee.cornell.edu> From: Marc Pearlman Reply-To: "pearlman@ee.cornell.edu" To: "'Laurent Viennot'" Cc: "'haas@ee.cornell.edu'" , "manet@itd.nrl.navy.mil" Subject: Zone Radius = 0 Date: Fri, 21 Jul 2000 07:30:13 -0400 Organization: Cornell University EE X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 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, > Something I do not understand is why your curve does not have a > discontinuity at ZR=0. > > total traffic > ^ > | > | * * > | * * > | * * > | * * > |* * * > |. * * > |. * * > |. *** > |. > -.-------|--------------> Zone Radius > . the optimal ZR > . > .<--- hello packets ----> > . > . > no hello > (pure reactive) You are right.. There is a "discontinuity" at ZR=0. In general, when the zone radius (ZR) increases, more proactive routing traffic is generated, but reactive route discovery traffic is reduced through zone-based bordercasting. The exception to this rule is the zone radius increase from ZR = 0 to ZR = 1 hops. In this case, we incur the proactive overhead of neighbor discovery traffic (ie. HELLOs), but we get *no* savings in reactive route discovery (bordercasting defaults to "flood searching" for both ZR=0 and ZR=1). As a result, ZR=0 (purely reactive routing) outperforms ZR=1, as illustrated by your figure above. For ZR >=1 hop, the control traffic is convex ("U-shaped") with respect to the zone radius. Therefore, there is only one local minimum in this "U-shaped" region. We can call the corresponding zone radius ZR_Lmin. The behavior of ZR_Lmin is well understood. In particular, this *locally* minimum zone radius steadily increases with the call-to-mobility ratio (CMR). In order for ZR_Lmin to be the *globally* optimal zone radius, the control traffic produced at ZR_Lmin must be less than the control traffic produced by ZR=0. Consider a broadcast channel ad-hoc network exhibiting very low CMR (ie. low traffic load and/or high node mobility). The optimal zone radius will be ZR = 0 (purely reactive routing). As we increase the CMR (ie. increase data traffic / slow down mobility) ZR_Lmin will gradually increase from 1 hop, but the optimal zone radius will still remain at 0 hops. At some critical CMR level, the optimal zone radius will jump from 0 hops to ZR_Lmin, skipping over the zone radii in between. For even higher CMR, the optimal zone radius will follow ZR_Lmin. The option of a purely reactive ZR=0 configuration adds an interesting threshold behavior to the ZRP. However, this does not change the simple premise on which ZRP is based: For every network there is an optimal zone radius. For some networks, the optimal radius is 0 (purely reactive). For other networks, the optimal radius is \inf (purely proactive). For the rest of the networks, a zone radius somewhere between the two extremes is best. regards, Marc From owner-manet@itd.nrl.navy.mil Fri Jul 21 12:13:50 2000 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 MAA17396 for ; Fri, 21 Jul 2000 12:13:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA03024 for manet-outgoing; Fri, 21 Jul 2000 10:21:35 -0400 (EDT) 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 KAA03019 for ; Fri, 21 Jul 2000 10:21:32 -0400 (EDT) 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 HAA15991; Fri, 21 Jul 2000 07:21:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA30917; Fri, 21 Jul 2000 07:21:28 -0700 X-Virus-Scanned: Fri, 21 Jul 2000 07:21:28 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdBRCWqs; Fri, 21 Jul 2000 07:21:26 PDT Message-ID: <39785C67.3E36F88F@iprg.nokia.com> Date: Fri, 21 Jul 2000 07:21:27 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: manet@itd.nrl.navy.mil Subject: Re: About redistributing routes References: <39783DAB.3D80BB91@nokia.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 Manel, AODV will happily accept routes as long as: - The routes have a destination sequence number, and - The routes have a lifetime. If you would like to have AODV interact with another routing protocol, then either the above may be satisfied directly by the other routing protocol, or you can try to make up some way to fool AODV into thinking its conditions are satisfied. However, if the sequence numbers aren't handled correctly, you will lose AODV's guarantee against routing loops. Regards, Charlie P. Manel Guerrero Zapata wrote: > > Hi: > > I've been thinking about the following: > > In a router that uses different router protocols (one of them is AODV). > Let's say than the other router protocols redistribute (or might do it) > routes between each other. > > Taking into account the nature of AODV, should AODV make and/or accept > some kind of redistribution with them? Although AODV would be the only > routing protocol for adhoc networks in that router? > > What do you think about it? > > BR/ManelG From owner-manet@itd.nrl.navy.mil Sun Jul 23 13:31:58 2000 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 NAA25742 for ; Sun, 23 Jul 2000 13:31:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA07177 for manet-outgoing; Sun, 23 Jul 2000 09:59:43 -0400 (EDT) Received: from NS.r-net.sk (NS.r-net.sk [193.58.193.10]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA07172 for ; Sun, 23 Jul 2000 09:59:40 -0400 (EDT) Received: from jakab (Kosice53.r-net.sk [193.58.192.181]) by NS.r-net.sk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA25566; Sun, 23 Jul 2000 15:57:37 +0200 X-Authentication-Warning: NS.r-net.sk: Host Kosice53.r-net.sk [193.58.192.181] claimed to be jakab Message-ID: <055c01bff4af$c1922da0$b5c03ac1@jakab> From: "jakab frantisek" To: Cc: , , , , , , Subject: Symposium ATMTU 2000 - Second Announcement and Call for Participation, Kosice, Slovakia Date: Sun, 23 Jul 2000 15:15:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BFF4B8.E1C04FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BFF4B8.E1C04FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive this mail more than once...] Dear Sirs, you can find the second announcement on our web serever: = www.elfa.sk/index-4-en.html and new information about the international symposium ATMTU 2000 (Second ATM Technology Users Symposium) , which is = held on 13 - 15 September 2000 in Kosice, Slovak Republic. In = particular, you will find the registration forms there. It is just another two months until the ATMTU 2000 will take place here = in Kosice, Slovakia. Therefore, we want to invite you to join us and participate at the symposium. We are looking forward to seeing you! Best regards, Frantisek Jakab ATMTU 2000 Symposium Org. Comm. Chair ___________________________ Preliminary List of presentations: 1. Broadband wireless access systems based on ATM Raks=E1ny P., Hargas J., Ericsson Slovakia, Bratislava, Slovakia 2. Broadband fixed line access Raks=E1ny P., Kostrej A., Ericsson Slovakia, Bratislava, Slovakia 3. Information about facts and experiences from the integration of ATM networks with IP protocol Francisci C., VUS, Bansk=E1 Bystrica, Slovakia 4. IP versus ATM Kukura P., Lucent Technologies Slovensko, Bratislava, Slovakia 5. Channels versus packets - conflict or symbiosis Chal=E1s P., ICN Siemens, Bratislava, Slovakia 6. Signalisation at the estabilishment of connection between broadband = and narrowband end-users Janetka A., Martinec L., Kevick=FD F., SWH Siemens Business Services, = Bratislava, Slovakia 7. VoIP or VoATM Lunter P., SWH Siemens Business Services, Bratislava, Slovakia 8. QOS in IP versus ATM Dekan R., SWH Siemens Business Services, Bratislava, Slovakia 9. ATM solutions in end-to-end solutions at the Alcatel 2iP Fiacan I., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 10. Applications of ATM technologies in wireless LMDS access systems Kub=EDk E., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 11. Telematics Services over ATM Networks: The case of Teleteaching Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., Computer Technology = Institute Patras, Greece 12. Migration to Broadband Networks Baron=E1k I., Poliak P., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 13. ATM access equipment of the RAD manufacturer Man=E1k V., ITM Bratislava, Slovakia 14. Design of an ATM Network Control and Monitoring System Gizelis C., National Technical University of Athens, Greece 15. Plasma PNNI 1.0: ATMIPNNI network simulation program Somogyi H., Ericsson Hungary, Hungary 16. Videoconferencing and applications of the TTC Telecom based on PictureTel Salzer E., TTC Telecom, Kosice, Slovakia 17. The utilisation of the ATM in the access technologies Koprda L., BGS Bratislava, Slovakia 18. Broadening of the activities of the Z-ATM in Slovakia with the = accesses to the end-users Sebo J., The ATM Association in the Slovak Republic Bratislava, Slovakia 19. MPLS (Multiprotocol Label Switching) and IP QoS in Service Provider = ATMNeworks Janovic R., Cisco Systems Slovakia 20. Perspectives for QoS in IP Public Networks Basso E., TTC Marconi, Prague, Czech Republic 21. Distribution MPEG2 streams in ATM end-to-end environments Danthine O., TOLMA SA, Paris, France 22. Liberalisation versus regulation in electronic communication = networks and services Scehovic A., V=DAS Bansk=E1 Bystrica, Slovakia 23. Steps Towards a World-Wide Broadband Multimedia Network Finley Marion R. Jr., Asahi University, Japan 24. ATM services and applications integration access to a large = community of users in the region of Aveiro Fontes F., Portugal Telecom, Aveiro, Portugal 25. The necessity of the building of academic "information = superhighways" Horvath P., SANET Bratislava, Slovakia 26. The effectivity of the extranets in companies Lavrin A., Zelko M., Technical University of Kosice, Slovakia 27. Operator of the broadband services - the vision Zirko M1., Jakab F2., Cizm=E1r A2., Slovak Telecom Bratislava1, = Technical University of Kosice, Slovakia 28. Some remarks to the implementation maintance of the ST-ATM network Trstensk=FD D., et al., Slovak Telecom, Bansk=E1 Bystrica, Slovakia 29. Presentation 1 Ambasador ATM FORUM 30. Presentation 2 Ambasador ATM FORUM 31. Preparation and developing strategy of the information society in = the Slovak Republic Podhorsk=FD V., Ministry of Transport, Post and Telecommunications in = SR, Bratislava. Slovakia 32. Information highways in information society Karovic K., SAV Bratislava, Slovakia 33. Experiences of the Corinex company with the ATM technologies Sl=E1nicka, CORINEX Group, Slovakia 34. Experiences of the IBM company with the ATM technologies Labanc, IBM Slovensko, Slovakia 35. IP net next generation - voice/multimedia transport Linhart Z., CONTACTEL, Czech Republic 36. Next Generation Networks and Services - ATM and IP Asatani K., Kogakuin University, Tokyo, Japan 37. Secure services Tomasov P., University of Zilina, Slovakia 38. Algoritmics and tool for virtual audience training Tsejtlin G.T., International Solomon University, Kiev, Ukraine 39. Expert estimations of validity and reliability of programme and technical maintance of computer networks Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute of = Informatics Science, Ukraine 40. The algebraic approach to minimization of computing Expences in = computer networks Olegovich N.M., Uzhgorod State Institute of Informatics Science, Ukraine 41. ATM Subscriber Access Multiplexer: the complete ADSL solution Lizuch P., Alcatel Slovakia, Liptovsk=FD Hr=E1dok, Slovakia 42. Design of an Input-queueded ATM Switch supporting multicast and = research on its Scheduling Policy Minguy Z., Nanjing University, China 43. Videoconferencing room=20 Baron=E1k I., Moln=E1r M., Department of Telecommunications, Faculty of Electrical Engineering and Informatics, Slovak University of Technology, = Bratislava, Slovakia 44. Application of the implementation models of the broadband networks Zabka J., Faculty of Mechatronics, University of Trenc=EDn, Slovakia 45. VPN networks based on MPLS Kollar S., BGS, Bratislava, Slovakia 46. Virtual networks in ATM Skorpil V., FEI, VUT, Brno, Czech Republic 47. Distributed Speech Recognition Syst=E9m over ATM Cizm=E1r A., Dobos L., Hintos L., Juh=E1r J., Faculty of Electrical = Engineering and Informatics of the Technical University of Kosice, Slovakia 48. Wireles ATM Physical Layer Simulation Dobos L., Palifetka R., Cizm=E1r A., Juh=E1r J., Faculty of Electrical Engineering and Informatics of the Technical University of Kosice, = Slovakia 49. Teleeducation services in broadband networks Jakab F., Samuelis L., Faculty of Electrical Engineering and Informatics = of the Technical University of Kosice, Slovakia 50. Methods of the evaluation of the QoS in ATM networks Jakab F., Faculty of Electrical Engineering and Informatics of the = Technical University of Kosice, Slovakia ______________________________________ ATMTU 2000 Symposium Symposium Secretariat elfa, s.r.o., Letna 9 042 00 Kosice, Slovakia Tel./fax.: +421 95 6253839, 6253200, 6253202 e-mail: elfa@elfa.sk www.elfa.sk/index-4-en.html ------=_NextPart_000_0012_01BFF4B8.E1C04FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
[Please accept our apologies if you receive this = mail more=20 than once...]

Dear Sirs,

you can find the second = announcement on=20 our web serever: www.elfa.sk/index-4-en.html and=20 new information about the international
symposium ATMTU 2000 (Second = ATM=20 Technology Users Symposium)  , which is held on 13 - 15 September = 2000 in=20 Kosice, Slovak Republic. In particular,
you will find the = registration forms=20 there.

It is just another two months until the ATMTU 2000 will = take place=20 here in Kosice, Slovakia. Therefore, we want to invite you to join us=20 and
participate at the symposium.

We are looking forward to = seeing=20 you!

 Best regards,

Frantisek Jakab
ATMTU 2000 = Symposium=20 Org. Comm. Chair
___________________________

Preliminary List = of=20 presentations:

1. Broadband wireless access systems based on=20 ATM
Rakš=E1ny P., Hargaš J., Ericsson Slovakia, Bratislava, = Slovakia

2.=20 Broadband fixed line access
Rakš=E1ny P., Kostrej A., Ericsson = Slovakia,=20 Bratislava, Slovakia

3. Information about facts and experiences = from the=20 integration of ATM
networks with IP protocol
Francisci C., VUS, = Bansk=E1=20 Bystrica, Slovakia

4. IP versus ATM
Kukura P., Lucent = Technologies=20 Slovensko, Bratislava, Slovakia

5. Channels versus packets - = conflict or=20 symbiosis
Chal=E1s P., ICN Siemens, Bratislava, Slovakia

6.=20 Signalisation at the estabilishment of connection between broadband and=20 narrowband end-users
Janetka A., Martinec Ľ., Kevick=FD F., SWH = Siemens=20 Business Services, Bratislava, Slovakia

7. VoIP or = VoATM
Lunter P.,=20 SWH Siemens Business Services, Bratislava, Slovakia

8. QOS in IP = versus=20 ATM
Dekan R., SWH Siemens Business Services, Bratislava, = Slovakia

9.=20 ATM solutions in end-to-end solutions at the Alcatel 2iP
Fiačan = I., Alcatel=20 Slovakia, Liptovsk=FD Hr=E1dok, Slovakia

10. Applications of ATM = technologies=20 in wireless LMDS access systems
Kub=EDk E., Alcatel Slovakia, = Liptovsk=FD Hr=E1dok,=20 Slovakia

11. Telematics Services over ATM Networks: The case of=20 Teleteaching
Bouras Ch., Gkamas A., Kapoulas V., Tsiatsos Th., = Computer=20 Technology Institute Patras, Greece

12. Migration to Broadband=20 Networks
Baroň=E1k I., Poliak P., Department of = Telecommunications, Faculty=20 of
Electrical Engineering and Informatics, Slovak University of = Technology,=20 Bratislava, Slovakia

13. ATM access equipment of the RAD=20 manufacturer
Man=E1k V., ITM Bratislava, Slovakia

14. Design = of an ATM=20 Network Control and Monitoring System
Gizelis C., National Technical=20 University of Athens, Greece

15. Plasma PNNI 1.0: ATMIPNNI = network=20 simulation program
Somogyi H., Ericsson Hungary, Hungary

16.=20 Videoconferencing and applications of the TTC Telecom based=20 on
PictureTel
Salzer E., TTC Telecom, Košice, = Slovakia

17. The=20 utilisation of the ATM in the access technologies
Koprda L., BGS = Bratislava,=20 Slovakia

18. Broadening of the activities of the Z-ATM in = Slovakia with=20 the accesses to the end-users
Šebo J., The ATM Association in = the Slovak=20 Republic Bratislava, Slovakia

19. MPLS (Multiprotocol Label = Switching)=20 and IP QoS in Service Provider ATMNeworks
Janovic R., Cisco Systems=20 Slovakia

20. Perspectives for QoS in IP Public Networks
Basso = E., TTC=20 Marconi, Prague, Czech Republic

21. Distribution MPEG2 streams in = ATM=20 end-to-end environments
Danthine O., TOLMA SA, Paris, = France

22.=20 Liberalisation versus regulation in electronic communication networks = and=20 services
Ščehovič A., V=DAS Bansk=E1 Bystrica, = Slovakia

23. Steps Towards=20 a World-Wide Broadband Multimedia Network
Finley Marion R. Jr., Asahi = University, Japan

24. ATM services and applications integration = access to=20 a large community of
users in the region of Aveiro
Fontes F., = Portugal=20 Telecom, Aveiro, Portugal

25. The necessity of the building of = academic=20 "information superhighways"
Horvath P., SANET Bratislava, = Slovakia

26.=20 The effectivity of the extranets in companies
Lavrin A., Zelko M., = Technical=20 University of Košice, Slovakia

27. Operator of the broadband = services -=20 the vision
Žirko M1., Jakab F2., Čižm=E1r A2., Slovak = Telecom Bratislava1,=20 Technical
University of Košice, Slovakia

28. Some remarks = to the=20 implementation maintance of the ST-ATM network
Trstensk=FD D., et = al., Slovak=20 Telecom, Bansk=E1 Bystrica, Slovakia

29. Presentation = 1
Ambasador ATM=20 FORUM

30. Presentation 2
Ambasador ATM FORUM

31. = Preparation=20 and developing strategy of the information society in the Slovak=20 Republic
Podhorsk=FD V., Ministry of Transport, Post and = Telecommunications in=20 SR, Bratislava. Slovakia

32. Information highways in information=20 society
Karovič K., SAV Bratislava, Slovakia

33. = Experiences of the=20 Corinex company with the ATM technologies
Sl=E1nička, CORINEX = Group,=20 Slovakia

34. Experiences of the IBM company with the ATM=20 technologies
Labanc, IBM Slovensko, Slovakia

35. IP net next=20 generation - voice/multimedia transport
Linhart Z., CONTACTEL, Czech=20 Republic

36. Next Generation Networks and Services - ATM and=20 IP
Asatani K., Kogakuin University, Tokyo, Japan

37. Secure=20 services
Tomašov P., University of Žilina, = Slovakia

38. Algoritmics=20 and tool for virtual audience training
Tsejtlin G.T., International = Solomon=20 University, Kiev, Ukraine

39. Expert estimations of validity and=20 reliability of programme and
technical maintance of computer=20 networks
Grygorovych V.F., Oleksiivna M.O., Uzhgorod State Institute = of=20 Informatics Science, Ukraine

40. The algebraic approach to = minimization=20 of computing Expences in computer networks
Olegovich N.M., Uzhgorod = State=20 Institute of Informatics Science, Ukraine

41. ATM Subscriber = Access=20 Multiplexer: the complete ADSL solution
Lizuch P., Alcatel Slovakia,=20 Liptovsk=FD Hr=E1dok, Slovakia

42. Design of an Input-queueded = ATM Switch=20 supporting multicast and research on its Scheduling Policy
Minguy Z., = Nanjing=20 University, China

43. Videoconferencing room
Baroň=E1k = I., Moln=E1r M.,=20 Department of Telecommunications, Faculty of
Electrical Engineering = and=20 Informatics, Slovak University of Technology, Bratislava, = Slovakia

44.=20 Application of the implementation models of the broadband = networks
Žabka J.,=20 Faculty of Mechatronics, University of Trenč=EDn, = Slovakia

45. VPN networks=20 based on MPLS
Kollar S., BGS, Bratislava, Slovakia

46. Virtual = networks in ATM
Škorpil V., FEI, VUT, Brno, Czech = Republic

47.=20 Distributed Speech Recognition Syst=E9m over ATM
Čižm=E1r = A., Doboš Ľ., Hintoš=20 L., Juh=E1r J., Faculty of Electrical Engineering
and Informatics of = the=20 Technical University of Košice, Slovakia

48. Wireles ATM = Physical Layer=20 Simulation
Doboš Ľ., Palifetka R., Čižm=E1r A., = Juh=E1r J., Faculty of=20 Electrical
Engineering and Informatics of the Technical University of = Košice,=20 Slovakia

49. Teleeducation services in broadband = networks
Jakab F.,=20 Samuelis L., Faculty of Electrical Engineering and Informatics of
the = Technical University of Košice, Slovakia

50.  Methods = of the=20 evaluation of the QoS in ATM networks
Jakab F., Faculty of Electrical = Engineering and Informatics of the Technical
University of = Košice,=20 Slovakia
______________________________________

ATMTU 2000=20 Symposium
Symposium Secretariat
elfa, s.r.o., Letna 9
042 00 = Kosice,=20 Slovakia
Tel./fax.: +421 95 6253839, 6253200, 6253202
e-mail: elfa@elfa.sk
www.elfa.sk/index-4-en.html

------=_NextPart_000_0012_01BFF4B8.E1C04FE0-- From owner-manet@itd.nrl.navy.mil Sun Jul 23 23:55:21 2000 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 XAA14397 for ; Sun, 23 Jul 2000 23:55:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA13091 for manet-outgoing; Sun, 23 Jul 2000 20:20:44 -0400 (EDT) Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.230.10]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA13086 for ; Sun, 23 Jul 2000 20:20:40 -0400 (EDT) Received: from duchess.ee.gatech.edu (duchess.ee.gatech.edu [130.207.230.13]) by mail.ee.gatech.edu (8.9.3/8.9.3) with ESMTP id UAA11049; Sun, 23 Jul 2000 20:20:21 -0400 (EDT) Received: from localhost (cktoh@localhost) by duchess.ee.gatech.edu (8.8.4/8.8.4) with ESMTP id UAA23312; Sun, 23 Jul 2000 20:20:21 -0400 (EDT) X-Authentication-Warning: duchess.ee.gatech.edu: cktoh owned process doing -bs Date: Sun, 23 Jul 2000 20:20:21 -0400 (EDT) From: Chai Keong Toh To: manet@itd.nrl.navy.mil cc: rcoltun@redback.com, vasosv@ee.gatech.edu, gguichal@ieee.org, cktoh@ee.gatech.edu Subject: Re: ABR MANET Draft & Implementation Paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello, Someone informed me that they cannot find the ABR (Long-lived Associativity-Based Ad Hoc Routing) MANET Draft for which I presented in the IETF Meeting on March 1999. It is available in: http://users.ece.gatech.edu/~cktoh/o.txt Our protocol implementation status can be found in: http://tonnant.itd.nrl.navy.mil/manet/survey/cktohreport.html A paper discussing ABR protocol implementation with performance results obtained from field trials will soon appear in Proceedings of IEEE International Conference on Computer Communications & Networks, 2000. Comments are welcome. Prof. C-K. Toh School of Electrical and Computer Engineering Georgia Institute of Technology, Atlanta, Georgia GA 30332, USA. Fax: 404 894 7883 Tel: 404 894 7468 URL: www.ece.gatech.edu/~cktoh/ -------------------------------------------------- From owner-manet@itd.nrl.navy.mil Mon Jul 24 08:07:47 2000 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 IAA06082 for ; Mon, 24 Jul 2000 08:07:47 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA19277 for manet-outgoing; Mon, 24 Jul 2000 06:37:49 -0400 (EDT) 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 GAA19272 for ; Mon, 24 Jul 2000 06:37:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08887; Mon, 24 Jul 2000 06:37:33 -0400 (EDT) Message-Id: <200007241037.GAA08887@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-ddm-00.txt Date: Mon, 24 Jul 2000 06:37:33 -0400 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 : Differential Destination Multicast (DDM) Specification Author(s) : L. Ji, S. Corson Filename : draft-ietf-manet-ddm-00.txt Pages : 21 Date : 21-Jul-00 This draft describes a multicast routing protocol for mobile ad hoc networks (MANETs). The protocol---termed Differential Destination Multicast (DDM)---differs from common approaches proposed for ad hoc multicast routing in two ways. Firstly, instead of distributing membership control throughout the network, DDM concentrates this authority at the data sources (i.e. senders) thereby giving senders knowledge of group membership. Secondly, differentially-encoded, variable-length destination headers are inserted in data packets which are used in combination with unicast routing tables to forward multicast packets towards multicast receivers. Instead of requiring that multicast forwarding state be stored in participating nodes, this approach also provides the option of stateless multicasting. Each node independently has the choice of maintaining cached forwarding state, or requesting its upstream neighbor to insert this state into self-routed data packets, or some combination thereof. The protocol is best suited for use with small multicast groups operating in dynamic networks of any size. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-ddm-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-ddm-00.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-ddm-00.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: <20000721172221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-ddm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-ddm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172221.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Mon Jul 24 08:20:45 2000 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 IAA10783 for ; Mon, 24 Jul 2000 08:20:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA19284 for manet-outgoing; Mon, 24 Jul 2000 06:37:53 -0400 (EDT) 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 GAA19279 for ; Mon, 24 Jul 2000 06:37:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08927; Mon, 24 Jul 2000 06:37:37 -0400 (EDT) Message-Id: <200007241037.GAA08927@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-olsr-02.txt Date: Mon, 24 Jul 2000 06:37:37 -0400 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 : Optimized Link State Routing Protocol Author(s) : P. Jacquet, P. Muhlethaler, A. Qayyum et al. Filename : draft-ietf-manet-olsr-02.txt Pages : 29 Date : 21-Jul-00 This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the pure link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs) [1] & [2]. MPRs are the selected nodes which forward the broadcast packets during the flooding process. This technique substantially reduces the packet overhead as compared to pure flooding mechanism where every node retransmits the packet when it receives the first copy of the packet. In OLSR protocol, the information flooded in the network 'through' these multipoint relays is also 'about' the multipoint relays. Hence, a second optimization is achieved here by minimizing the 'contents' of the control packet flooded in the network. Hence, as contrary to the classic link state algorithm, only a small subset of links with the neighbor nodes are declared instead of all the links. This information is then used by OLSR protocol for route calculation, and therefore the routes contain only the MPRs as the intermediate nodes from Source to Destination. It results in providing the optimal routes (in terms of number of hops), and hence another optimization. The protocol is particularly suitable for the large dense networks as the technique of multipoint relays works well in this context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-olsr-02.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-olsr-02.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: <20000721172230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-olsr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-olsr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172230.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Mon Jul 24 08:32:32 2000 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 IAA14318 for ; Mon, 24 Jul 2000 08:32:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA19702 for manet-outgoing; Mon, 24 Jul 2000 06:57:21 -0400 (EDT) Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA19697 for ; Mon, 24 Jul 2000 06:57:19 -0400 (EDT) From: conf@colmar.uha.fr Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA15188; Mon, 24 Jul 2000 12:17:02 +0200 Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07734; Mon, 24 Jul 2000 12:47:52 +0100 (WET DST) Message-Id: <3.0.1.32.20000724135349.0090d940@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 24 Jul 2000 13:53:49 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for papers of ICN'01 & Final program of ECUMN'00 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following : - call for papers of ICN'01 (see 0000,0000,fefehttp://iutsun1.colmar.uha.fr/= ICN01.html ) AND=20 - final program of ECUMN'00 (see= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ECUMN2000.html ) to interested colleagues. Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ---
CALL FOR PAPERS=20 IEEE International Conference on Networking=20 ICN'01=20 July 11-13, 2001 - CREF, Colmar, France=20
GENERAL INFORMATION=20 The 2001 International Conference on Networking (ICN'01) is sponsored by= IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized= by academic, research and industrial societies will be held at the= Technical Institute, Colmar, part of the University of Haute Alsace,= France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of= Colmar is ideally situated in the eastern part of France, near the German= and Swiss borders. The city of Colmar has been working on its own= Metropolitan Area Network (MAN) project, called OASICE, including LAN= interconnection, PBX interconnection and interactive video. An exhibition= illustrating these topics will be organized for industrial companies and= development research institutes.=20 In order to encourage closer interaction between academic and industrial ATM= research communities, we solicit both academic research papers and= industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 =20 Communications switching and routing =20 Communications modeling =20 Communications security =20 Computer communications =20 Multimedia and multicast communications =20 Internet environment =20 Network Management and control =20 Quality of Service (IntServ, DiffServ, =85) =20 Wireless Communications (Satellite, WLL, 3G) =20 Voice over IP =20 Java, Tina, Corba architectures Network signaling =20 ATM networks =20 ATM/IP integration =20 Integrated services =20 Traffic engineering =20 Telecommunication networks architectures =20 Performance evaluation, simulation =20 Mobile agents, active and intelligent networks =20 Applications and case studies =20 Protocol design and evaluation =20 MPLS=20 These topics can be discussed in term of concepts, state of the art,= standards, implementations, running experiments and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four papers or E-mail preferably in Word 6 format, or alternately a= postscript version of a 2000-word extended abstract summarizing an original= work. All the manuscripts must be written in English. The top of the first= page of each paper should include the title of the paper, authors' name,= position, address, telephone and fax numbers, e-mail of the author= responsible for correspondence and a list of four keywords. The deadline= for submission of all extended abstracts is December 10, 2000 with= notification of acceptance by February 20, 2001. Submission of camera-ready= paper is by March 30, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts= for inclusion in the proceedings with ISBN.=20 All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 Check our Web page at= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ICN01.html for the latest information concerning the= conference.=20 Best papers will be forwarded for consideration in a special issue of a= journal.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by December 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort-Montbeliard=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) =96 Mitsubishi=20 J. Crowcroft (UK) =96 University College London=20 S. Fdida (France) =96 LIP6=20 B. Gavish (USA) - Vanderbilt University=20 H. Guyennet (France) - University of Franche-Comte=20 J. Halpern (USA) =96 Newbridge=20 Z. Hulicki (Poland) =96 University of Cracow=20 R. Israel (France) - IEEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy=20 A. Jamalipour (Australia) - University of Sydney=20 S. Kota (USA) - Lockeed Martin=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) =96 Ericsson=20 G.S. Kuo (Taiwan) =96 National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) =96 Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 H.. Mouftah (Canada) - Queen's University=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) =96 Clemessy=20 M. Trehel (France) =96 University of Franche-Comte=20 V.A. Villagra (Spain) =96 University of Madrid=20 E. Vazquez Gallo (Spain) =96 University of Madrid=20 O. Yang (Canada) - University of Ottawa=20 IMPORTANT DATES=20 Extended Abstract due: December 10, 2000=20 Notification of acceptance: February 20, 2001=20 Deadline for full-length camera-ready manuscript: March 30, 2001=20 ---------------------------------------------------------------------------
1st IEEE European Conference on Universal Multiservice= Networks ECUMN'2000 October 2-4, 2000 - CREF, Colmar, France FINAL PROGRAM
=20 08:30 - 18:30 Conference Registration Monday October 2, 2000 09:00 - 09:20 Opening Address=20 09:20 - 10:30 Tutorial Session 1 Internet Services over Mobile and Wireless Networks: Architectures and= Protocols G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,= USA 10:30 - 11:00 Coffee Break 11:00 - 12:15 Network Architecture and Convergence Chair: S. Ritzenthaler, Newbridge, France MPLS and Next Generation Access Network A. Kankkunen, Integral Access Inc, USA Deutsche Telekom's View on Network Convergence L. Falkenhagen Deutsche Telekom AG, Germany A Functional Architecture for End-to-end Quality-of-Service in a= Multi-domain Network E. Pagani, G.P. Rossi, University of Milano, Italy 12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence 13:00 - 14:30 Lunch 14:30 - 16:15 Traffic=20 Chair: M. Villen, Telefonica I+D, Spain The Relevance of the Bufferless Analysis for Traffic Management in= Telecommunication Networks G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,= University of Karlskrona/Ronneby, Sweden Mapping of Loss and Delay Between IntServ and DiffServ T. Chahed, G. H=E9buterne, C. Fayet, National Institute of= Telecommunications, France Resource Demand of Aggregated Resource Reservations J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland Characterization of the MPEG-2 Video Traffic Generated by DVD Applications A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,= University of Mining and Metallurgy, Poland 14:30 - 16:15 Interworking between narrow band and broadband networks Chair: S. Chakraborty, Technical University of Helsinki, Finland Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and= Services Support L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.= Papadopoulos, University of Patras, Greece Extending the Internet with the Intelligent Network Capabilities B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,= France A Suitable Service Discipline for ATM-Ethernet Interconnection J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain Interoperability of ATM-Ethernet Interworking System: Design and Congestion= Control R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,= Tinisia ; K. Torki, INPG, France 16:15 - 16:45 Coffee Break 16:45 - 18:30 Routing Chair: P. Chemouil, France Telecom R&D, France Adaptive Routing and Load Balancing of Ephemeral Connections M. Heusse, ENST de Bretagne, France A new Multi-Services Rerouting Algorithm A. Gueroui, University of Versailles, France ; L. Mokdad University of= Dauphine, France ; J. Ben-Othman University of Paris 6, France Extending Mobile IP-v6 with Multicast to Support Mobile Networks in IPv6 T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola= Labs, France 16:45 - 18:30 Interworking between IP and ATM Chair: M. Potts, Martel, Switzerland Topology Optimization of IP over ATM L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland Resource Reservation with Boomerang via Open Interfaces M. Maliosz, Budapest University of Technology and Economics, Hungary Efficient Translation of Network Performance Parameters for Transport of IP= Packets over Cell-Switched Subnetworks J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,= Germany Design of Adaptive Access Network and Control Protocol H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform= Laboratories, Japan 19:15 Reception - Town Hall Tuesday October 3, 2000 09:00 - 10:45 End to end traffic Control (1) Chair: U. Krieger, Deutsche Telecom, Germany Guaranteed QoS for TCP flows in ATM-based DiffServ Networks T. M=FCller, Dresden University of Technology, Germany Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,= National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,= Taiwan An Efficient Weight Assignment Process for GPS Servers G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des= T=E9l=E9communications, France Some Aspects of RTP - TCP Coexistence in Universal Multiservice Networks R. Chodorek, University of Mining and Metallurgy, Poland 09:00 - 10:45 Mobile Networks and Mobile Services Chair: G. Omidyar, Computer Sciences Corp, USA Voice Enabled Request and Response for Mobile Devices Supporting WAP= Protocol: the Constraints A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian= Institute of Technology, India IP based enhanced Data Casting Services over Radio Broadcast Networks W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,= Germany Location-Dependant and Value Added Services (VAS) for Mobile Communications P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20 The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony= Operators in the Liberalization of Telecommunications D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National= Technical University of Athens, Greece 10:45 - 11:15 Coffee Break 11:15 - 13:00 Multicast Chair: G. Girardi, CSELT, Italy A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain= Multicast Routing Environment M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco A New Routing Algorithm for Delay-Constrained Dynamic Multicast T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.= Tanaka, Waseda University, Japan Remote Time-Alignment of Interactive Services through Efficient Multicast= Algorithms A. Borella, G. Cancellieri, University of Ancona, Italy Key Establishment for IGMP Authentication in IP Multicast T. Hardjono, B. Cain, Nortel Networks, USA 11:15 - 13:00 IP Test-beds Chair: H. Tobiet, NMG, France Real-Time Multimedia Services over Internet A. Benslimane, Technical University of Belfort-Montb=E9liard, France Telephony over IP: Theoretical Modelling and Lab Experiments P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy User-domain Multiservice Architecture for Wired and Wireless IP Networks L. Cheng, I. Marsic, The State University of New Jersey, USA A Testbed Environment for the Performance Evaluation of Modular Network= Architectures D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy 13:00 - 14:30 Lunch 14:30 - 16:15 Modeling Chair: G. H=E9buterne, INT, France Estimation of the Renewal Function by Empiral Data - A Bayesian Approach N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova= Deutsche Telekom, Germany Modeling Access Networks for Quality of Service F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and= Technology, USA ; D.R. Vaman, Megaxess, USA Managing Wireless Internet Information of Electronic Advertising E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,= Tohoku University, Japan Performance Evaluation of a full Memory Multidestination Protocol for= Satellite Based Reliable Multicast with and without Local Recovery H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological= University, Singapore 14:30 - 16:15 Tariffs and Bandwidth Allocation Chair: P. Lorenz, University of Haute Alsace, France INEDAC Project: A Tool to Calculate Interconnection Tariff based on a= Bottom-up Method J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;= R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany Auction Method and its Performance in a Dynamic Bandwidth Allocation Service E. Takahashi, Y. Tanaka, Waseda Universiy, Japan Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video= Streams to Variable Channel Bandwidth H.F. Raynaud, M. Luong, University of Paris Nord, France Robust Topology for Enterprise Networks against Diverse Tariff Structures T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT= Service Integration Laboratories, Japan 16:15 - 16:45 Coffee Break 16:45 - 18:30 End to end Traffic Control (2) Chair: G. H=E9buterne, INT, France An Architecture of QoS Services for a Core Internet Network over DTM C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.= Moreno, University Carlos III of Madrid, Spain Congestion Avoidance for Unicast and Multicast Traffic A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France MPOA and QoS Support in LIS Internetworking Environments I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK A Method for Increasing Throughput based on Packet Striping F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France 16:45 - 18:30 Advanced Networking Chair: G.V. Morson, Cambridge Network, England A New Network Service Environment using Active Network K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan Adaptive Applications over Active Networks: Case Study on Layered Multicast L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium Integrated Performance Monitoring of Client/Server Software C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany Who needs Addresses ? V. Guruprasad, IBM, USA 20:00 Gala Dinner - Restaurant Meistermann Wednesday October 4, 2000 09:00 - 10:00 Tutorial Session 2 Chair: P. Rolin, France Telecom R&D, France Active Networks and its Management M. Brunner, NEC Europe Ltd, Germany 10:00- 10:30 Coffee Break 10:30 - 11:45 New Architectures for New Services Chair: A. Gravey, ENST-Bretagne, France A Novel Architecture for Efficient Protocol Processing in High Speed= Communication Environments G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,= Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,= Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),= Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,= J.A. Sanchez, Lucent Technologies, The Netherlands Using T=E9l=E9domotis Interface for a new Multiservice Network applied to= Monitoring the Elderly T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,= University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,= France Video and Interactive Internet access in a DVB Network R. Jaeger, BetaResearch, Germany 11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services 13:00 - 14:30 Lunch 14:30 Visit of Vialis From owner-manet@itd.nrl.navy.mil Mon Jul 24 17:28:07 2000 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 RAA12609 for ; Mon, 24 Jul 2000 17:28:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA07461 for manet-outgoing; Mon, 24 Jul 2000 15:37:55 -0400 (EDT) Received: from mintaka.isr.umd.edu (mintaka.isr.umd.edu [128.8.111.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA07454; Mon, 24 Jul 2000 15:37:53 -0400 (EDT) Received: from segfault.isr.umd.edu (root@segfault.isr.umd.edu [128.8.111.130]) by mintaka.isr.umd.edu (8.9.3/8.9.3) with ESMTP id PAA04034; Mon, 24 Jul 2000 15:37:34 -0400 (EDT) Received: from segfault.isr.umd.edu (sendmail@localhost [127.0.0.1]) by segfault.isr.umd.edu (8.9.3/8.9.3) with SMTP id PAA15601; Mon, 24 Jul 2000 15:37:39 -0400 (EDT) Received: from localhost (corson@localhost) by segfault.isr.umd.edu (8.9.3/8.9.3) with ESMTP id PAA15597; Mon, 24 Jul 2000 15:37:38 -0400 (EDT) X-Authentication-Warning: segfault.isr.umd.edu: corson owned process doing -bs Date: Mon, 24 Jul 2000 15:37:38 -0400 (EDT) From: "M. Scott Corson" X-Sender: corson@segfault.isr.umd.edu To: agenda@ietf.org cc: Joseph Macker , MANET WG Subject: MANET Agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk All, The agenda for the upcoming Manet WG mtg is below. Please read the relevant drafts in preparation. -scott ******************************************************************************* M. Scott Corson Institute for Systems Research corson@isr.umd.edu A.V. Williams Bldg. (115) Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland Fax: 301-314-8586 College Park, MD 20742 ******************************************************************************* Mobile Ad Hoc Networks (manet) Agenda Thursday, Aug 3, 13:00-15:00 Agenda Bashing (5 min) Unicast draft-related presentations AODV Draft Update - C. Perkins (15 min) OLSR Simulation Results/Implementation Report - A. Qayyum (15 min) TBRPF Draft Overview - R. Ogier (20 min) Multicast draft-related presentations DDM Draft Overview - L. Ji (20 min) General MANET Discussion Items (45 min) * Working Group Protocol Status (10+ min) * Discussion on MANET Broadcast (10+ min) * Discussion on MANET Autoconfiguration (10+ min) * Discussion on Proactive vs. Reactive Routing (time permitting) From owner-manet@itd.nrl.navy.mil Mon Jul 24 17:55:16 2000 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 RAA18868 for ; Mon, 24 Jul 2000 17:55:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA05960 for manet-outgoing; Mon, 24 Jul 2000 14:51:12 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA05955 for ; Mon, 24 Jul 2000 14:51:10 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id NAA23862 for ; Mon, 24 Jul 2000 13:50:54 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id NAA13960 for manet@itd.nrl.navy.mil; Mon, 24 Jul 2000 13:50:24 -0500 (CDT) Date: Mon, 24 Jul 2000 13:50:24 -0500 (CDT) Message-Id: <200007241850.NAA13960@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil Subject: Special issue on Mobile Ad Hoc Networking Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Call for Papers IEEE Personal Communications Magazine Special Issue on Advances in Mobile Ad Hoc Networking ------------------------------------ Motivation and Scope A mobile ad hoc network is a collection of wireless nodes that can dynamically form a network without using any pre-existing network infrastructure. Due to the potential ease of deployment, many applications have been conceived for such networks, including personal area networking, home networking, and battlefield applications. The objective of the proposed special issue is to provide the readers with an overview of the recent progress in the field of wireless ad hoc networks. Ad hoc networking is gaining importance with the increasingly widespread application of wireless technology in day-to-day civilian applications as well as military applications. Scope of the proposed special issue will include various issues related to mobile ad hoc networks -- papers related to upper layers of the protocol stack, including applications, are particularly encouraged. Topics of interest include, but are not limited to, the following: * Ad hoc mobile applications * Routing protocols * Energy-efficient protocols * Sensor-based Ad Hoc Networks * Quality of service issues * Security-related issues * Implementation and operational experiences Important Dates * Paper submission due date: August 15, 2000 * Accept/reject decisions by: October 30, 2000 * Revised papers due: November 30, 2000 * Publication date: February 2001 Submission Instructions Electronic paper submission is requested -- acceptable formats are MS Word, PostScript and Portable Document Format (PDF). Submissions should not exceed 24 double-spaced pages. List of references may be single-spaced. Please e-mail your submission to vaidya@cs.tamu.edu (Nitin Vaidya). In addition, please e-mail a plain-text abstract and title for your paper to parviz@us.ibm.com (Parviz Kermani). Due date for all submissions is August 15, 2000. Important: After a paper is submitted for review, the submitting author would be sent an acknowledgement, including the number assigned to the paper. If such an acknowledgement is not received within a week of submitting the paper, the authors are requested to contact the guest editors. It is anticipated that approximately 7 papers will be accepted for publication in this special issue. Guest Editors: Parviz Kermani Nitin H. Vaidya IBM T. J. Watson Research Center Computer Science Dept. 30 Saw Mill River Road 301 H.R.Bright Building Hawthorne, NY 10532 Texas A&M University U.S.A. College Station, TX 77843-3112 U.S.A. Phone: 914-784-7769 Phone: 979-845-0512 Fax: 914-784-6205 Fax: 979-847-8578 E-mail: parviz@us.ibm.com E-mail: vaidya@cs.tamu.edu From owner-manet@itd.nrl.navy.mil Tue Jul 25 12:04:57 2000 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 MAA09372 for ; Tue, 25 Jul 2000 12:04:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA27974 for manet-outgoing; Tue, 25 Jul 2000 10:07:08 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA27963 for ; Tue, 25 Jul 2000 10:06:55 -0400 (EDT) Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6PE6UT07443 for ; Tue, 25 Jul 2000 17:06:40 +0300 (EET DST) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6PE6HD19811 for ; Tue, 25 Jul 2000 17:06:18 +0300 (EET DST) Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA11901; Tue, 25 Jul 2000 17:06:17 +0300 (EETDST) Received: from nokia.com (tarom@tarom.research.nokia.com [172.21.41.34]) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id RAA01017; Tue, 25 Jul 2000 17:06:16 +0300 (EET DST) Message-ID: <397D9FD1.5CDD5C12@nokia.com> Date: Tue, 25 Jul 2000 17:10:25 +0300 From: Manel Guerrero Zapata X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: EXT Charlie Perkins CC: manet@itd.nrl.navy.mil Subject: Re: New AODV drafts available References: <396FBA36.151E8DFA@iprg.nokia.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, I guess you have already realized about it. (Otherwise I'm missing something). In the draft of the aodv-06 the Message type number 4 corresponds to RREP-ACK. But in the draft maodv-00, it corresponds to MACT. I'm sure there is a lot of people that have already mention that to you. I understand that it has been caused by the split of the draft in 5 and the addition of the RREP-ACK Message. Then, I guess, that MACT type should be 5, GRPH 6, MDEF 7(aodvqos-00), MBEF 8, and IQLM 9. Isn't it? BR/ManelG From owner-manet@itd.nrl.navy.mil Wed Jul 26 09:07:51 2000 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 JAA06198 for ; Wed, 26 Jul 2000 09:07:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA23513 for manet-outgoing; Wed, 26 Jul 2000 06:50:41 -0400 (EDT) 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 GAA23508 for ; Wed, 26 Jul 2000 06:50:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03581; Wed, 26 Jul 2000 06:50:35 -0400 (EDT) Message-Id: <200007261050.GAA03581@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-maodv-00.txt Date: Wed, 26 Jul 2000 06:50:34 -0400 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 : Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing Author(s) : E. Royer, C. Perkins Filename : draft-ietf-manet-maodv-00.txt Pages : 24 Date : 25-Jul-00 The multicast operation of the Ad hoc On-Demand Distance Vector (AODV) routing protocol (MAODV) is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, and low network utilization. It creates bi-directional shared multicast trees connecting multicast sources and receivers. These multicast trees are maintained as long as group members exist within the connected portion of the network. Each multicast group has a group leader whose responsibility is maintaining the group sequence number, which is used to ensure freshness of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-maodv-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-maodv-00.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-maodv-00.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: <20000725113240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-maodv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-maodv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000725113240.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-manet@itd.nrl.navy.mil Wed Jul 26 11:38:12 2000 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 LAA03681 for ; Wed, 26 Jul 2000 11:38:11 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA27486 for manet-outgoing; Wed, 26 Jul 2000 09:35:53 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA27478 for ; Wed, 26 Jul 2000 09:35:46 -0400 (EDT) Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6QDZIT05593 for ; Wed, 26 Jul 2000 16:35:29 +0300 (EET DST) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6Q9LjD23708 for ; Wed, 26 Jul 2000 12:21:46 +0300 (EET DST) Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA21490 for ; Wed, 26 Jul 2000 12:17:43 +0300 (EETDST) Received: from nokia.com (tarom@tarom.research.nokia.com [172.21.41.34]) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id MAA19587 for ; Wed, 26 Jul 2000 12:17:41 +0300 (EET DST) Message-ID: <397EADAE.CABC1E72@nokia.com> Date: Wed, 26 Jul 2000 12:21:50 +0300 From: Manel Guerrero Zapata X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Interaction between AODV and other routing protocols References: <39783DAB.3D80BB91@nokia.com> <39785C67.3E36F88F@iprg.nokia.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 :) Is there any draft, RFC, or some paper in where is discused the interaction between AODV and other routing protocols. In the same manner than between BGP4/IDRP and OSPF there is: "BGP4/IDRP for IP---OSPF Interaction" (RFC 1745) BR/ManelG From owner-manet@itd.nrl.navy.mil Wed Jul 26 13:54:39 2000 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 NAA04651 for ; Wed, 26 Jul 2000 13:54:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA02141 for manet-outgoing; Wed, 26 Jul 2000 11:44:10 -0400 (EDT) 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 LAA02133 for ; Wed, 26 Jul 2000 11:44:08 -0400 (EDT) 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 IAA03835; Wed, 26 Jul 2000 08:44:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA15272; Wed, 26 Jul 2000 08:44:01 -0700 X-Virus-Scanned: Wed, 26 Jul 2000 08:44:01 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdPOhwFq; Wed, 26 Jul 2000 08:43:58 PDT Message-ID: <397F0741.FBA4E747@iprg.nokia.com> Date: Wed, 26 Jul 2000 08:44:01 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: Mobile Ad Hoc IETF working group Subject: Re: Interaction between AODV and other routing protocols References: <39783DAB.3D80BB91@nokia.com> <39785C67.3E36F88F@iprg.nokia.com> <397EADAE.CABC1E72@nokia.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 Manel, Thanks for your previous note about the misnumbering for AODV message types. The extension numbering was already O.K., so we left those numbers alone. The documents with new numbers are available at: http://www.iprg.nokia.com/~charliep/txt/aodvid/. and we expect to resubmit them not too long after the IETF meeting in Pittsburgh. Regarding your question: > Is there any draft, RFC, or some paper in where > is discused the interaction between AODV and other > routing protocols. Since AODV is not yet promulgated as a standard of any type, one might not expect much to be available within the manet working group to cover this topic. However, I can offer the following observation. AODV should interact well with any other routing protocol as long as the destination has the same kind of monotonic sequence number as is needed by AODV. If this sequence number is not available, or if it is supplied as a dummy substitute not created by the destination, then it may not be possible for AODV to continue to guarantee loop free routes. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Wed Jul 26 21:23:34 2000 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 VAA10197 for ; Wed, 26 Jul 2000 21:23:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA16266 for manet-outgoing; Wed, 26 Jul 2000 18:23:30 -0400 (EDT) Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA16261 for ; Wed, 26 Jul 2000 18:23:28 -0400 (EDT) Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e6QMNNL16651 for ; Wed, 26 Jul 2000 18:23:24 -0400 (EDT) From: Samir Das Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id SAA25702 for manet@itd.nrl.navy.mil; Wed, 26 Jul 2000 18:22:43 -0400 (EDT) Message-Id: <200007262222.SAA25702@wayward.ececs.uc.edu> Subject: Final Call for Participation: MobiCom 2000, Aug 6-11, Boston To: manet@itd.nrl.navy.mil Date: Wed, 26 Jul 2000 18:22:43 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Final Call for Participation MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA The complete program for paper, panel and tutorial sessions, as well as registration and hotel information are available at the conference web site below. http://www.research.telcordia.com/mobicom2000/ Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. We look forward to seeing you in MobiCom 2000. Registration by mail or fax will be accepted until July 31. Registrations beyond this date will be accepted on site only. From owner-manet@itd.nrl.navy.mil Thu Jul 27 15:28:29 2000 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 PAA08064 for ; Thu, 27 Jul 2000 15:28:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA07908 for manet-outgoing; Thu, 27 Jul 2000 13:28:49 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA07900 for ; Thu, 27 Jul 2000 13:28:47 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id MAA22296 for ; Thu, 27 Jul 2000 12:28:31 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id MAA16295 for manet@itd.nrl.navy.mil; Thu, 27 Jul 2000 12:27:57 -0500 (CDT) Date: Thu, 27 Jul 2000 12:27:57 -0500 (CDT) Message-Id: <200007271727.MAA16295@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil Subject: references needed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hello all I am looking for papers/tech reports on the following topics: * TCP in mobile ad hoc networks (I know of two papers, Holland99 and Chandran98) * Security issues in mobile ad hoc networks - I know a handful of papers, but not enough * Implementation reports. I have the CMU implementation paper - other implementations have been "reported", but not much written technical material seems available on those If you know any relevant (and publicly available) papers/reports, please e-mail me the pointers. I am looking for these as a source of additional material for my tutorial to be presented at MobiCom 2000. Best regards. - nitin From owner-manet@itd.nrl.navy.mil Thu Jul 27 18:12:21 2000 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 SAA19893 for ; Thu, 27 Jul 2000 18:12:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA14337 for manet-outgoing; Thu, 27 Jul 2000 16:37:08 -0400 (EDT) Received: from ridley.nist.gov (ridley.nist.gov [129.6.13.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA14307 for ; Thu, 27 Jul 2000 16:36:46 -0400 (EDT) Received: from antd.nist.gov (stratus.antd.nist.gov [129.6.50.8]) by ridley.nist.gov (8.9.3/8.9.3) with ESMTP id QAA00357; Thu, 27 Jul 2000 16:41:04 -0400 (EDT) Message-ID: <39809D0D.71D2F594@antd.nist.gov> Date: Thu, 27 Jul 2000 16:35:25 -0400 From: Leonard Miller Organization: NIST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nitin H Vaidya CC: MANET Discussion Subject: Re: references needed References: <200007271727.MAA16295@sun.cs.tamu.edu> 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, Nitin I am not sure if you mean a simulation when you say "implementation," but for tutorial purposes you will find the Larsson/Hedman thesis very good: http://www.ietf.org/proceedings/99mar/slides/ Look for manet-thesis-99mar.pdf -- Len Miller ________________________________________________________ *._..*.*_.***__*..*._..*._..*.*._.***._*_***_.*..*...*_* -------------------------------------------------------- Dr. Leonard E. Miller Wireless Communications Technologies Group National Institute of Standards & Technology (NIST) Address: 100 Bureau Drive Stop 8920, Bldg. 820, Room 445 Gaithersburg, Maryland 20899-8920 Phone: 301-975-8018 Fax: 301-590-0932 email: lmiller@antd.nist.gov, leonard.miller@nist.gov Len_Miller@compuserve.com http://w3.antd.nist.gov/wctg/