From mailman-owner@ietf.org Sat Jun 1 06:38:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17346 for ; Sat, 1 Jun 2002 06:38:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29984 for ; Sat, 1 Jun 2002 06:39:04 -0400 (EDT) Date: Sat, 1 Jun 2002 06:39:04 -0400 (EDT) Message-Id: <200206011039.GAA29984@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: manet-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, manet-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for manet-archive@lists.ietf.org: List Password // URL ---- -------- manet@ietf.org FtOz https://www1.ietf.org/mailman/options/manet/manet-archive@lists.ietf.org From manet-admin@ietf.org Wed Jun 5 20:44:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01251 for ; Wed, 5 Jun 2002 20:44:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10489; Wed, 5 Jun 2002 20:02:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10461 for ; Wed, 5 Jun 2002 20:02:12 -0400 (EDT) Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28986 for ; Wed, 5 Jun 2002 20:01:40 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maila.telia.com (8.11.6/8.11.6) with ESMTP id g56023a20585; Thu, 6 Jun 2002 02:02:03 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g56022119716; Thu, 6 Jun 2002 02:02:02 +0200 (CEST) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST Cc: AODV LIST Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 01:59:44 +0200 Message-Id: <1023321585.11971.25.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA10462 Subject: [manet] AODV: Lifetime of reverse routes... Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello The AODV draft say (section 6.2) that the next hop along the reverse path of a route should be updated when a data packet is forwarded (along with the destination and next hop of the forward route). However, since it is impossible to tell from the packet which node the packet is received from, without keeping track of MAC-addresses, one must check the reverse route entry for its next hop. The problem is that the draft does not mention anything about updating the destination of the reverse route (or did I miss this?), so if the communication is one way, the reverse route entry eventually is deleted and the information about the reverse route's next hop is lost. Therefore it is also impossible to update the lifetime of the next hop along the reverse route when data packets along the forward route are received. The result is that the next hop along the reverse route also gets deleted. This may hinder forwarding of RERRs and the source generating the data is never informed when the route breaks. The solution is of course to update the lifetime of the destination of the reverse route too, so that the information about its next hop is kept while the forward route is active. Comments? Best Regards Erik Nordström _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 5 20:44:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01262 for ; Wed, 5 Jun 2002 20:44:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA12761 for manet-archive@odin.ietf.org; Wed, 5 Jun 2002 20:45:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10489; Wed, 5 Jun 2002 20:02:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10461 for ; Wed, 5 Jun 2002 20:02:12 -0400 (EDT) Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28986 for ; Wed, 5 Jun 2002 20:01:40 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maila.telia.com (8.11.6/8.11.6) with ESMTP id g56023a20585; Thu, 6 Jun 2002 02:02:03 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g56022119716; Thu, 6 Jun 2002 02:02:02 +0200 (CEST) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST Cc: AODV LIST Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 01:59:44 +0200 Message-Id: <1023321585.11971.25.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA10462 Subject: [manet] AODV: Lifetime of reverse routes... Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello The AODV draft say (section 6.2) that the next hop along the reverse path of a route should be updated when a data packet is forwarded (along with the destination and next hop of the forward route). However, since it is impossible to tell from the packet which node the packet is received from, without keeping track of MAC-addresses, one must check the reverse route entry for its next hop. The problem is that the draft does not mention anything about updating the destination of the reverse route (or did I miss this?), so if the communication is one way, the reverse route entry eventually is deleted and the information about the reverse route's next hop is lost. Therefore it is also impossible to update the lifetime of the next hop along the reverse route when data packets along the forward route are received. The result is that the next hop along the reverse route also gets deleted. This may hinder forwarding of RERRs and the source generating the data is never informed when the route breaks. The solution is of course to update the lifetime of the destination of the reverse route too, so that the information about its next hop is kept while the forward route is active. Comments? Best Regards Erik Nordström _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 5 21:14:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03115 for ; Wed, 5 Jun 2002 21:14:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12269; Wed, 5 Jun 2002 20:37:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12238 for ; Wed, 5 Jun 2002 20:37:47 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00700 for ; Wed, 5 Jun 2002 20:37:15 -0400 (EDT) Received: from waysideececs (wayside-ececs.rhod.uc.edu [10.63.7.45] (may be forged)) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g560bCVN028663; Wed, 5 Jun 2002 20:37:12 -0400 (EDT) From: "Samir R. Das" To: "=?iso-8859-1?Q?'Erik_Nordstr=F6m'?=" , "'Charles E. Perkins'" , "Elizabeth M. Belding-Royer" Cc: "'AODV LIST'" , "'MANET LIST'" Subject: RE: [manet] AODV: Lifetime of reverse routes... Date: Wed, 5 Jun 2002 20:37:11 -0400 Organization: University of Cincinnati Message-ID: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1023321585.11971.25.camel@Replicator> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA12239 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Erik, I somehow do not follow your arguments. The source IP address in a data packet can be used as the destination of the reverse path. The next hop for this routing entry is the next hop towards the destination of the reverse path. I guess here the language in the draft should be changed to remove the words "previous hop." You are right in that it is not "directly" known in the routing layer. Also, refreshing the reverse path is an optimization. Even if the reverse path is deleted, it does not hinder the RERR propagation. Typically, RERRs are broadcast or even if unicast, the precursor list is used to get the next hop for RERR. Samir > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet- > admin@ietf.org] On Behalf Of Erik Nordström > Sent: Wednesday, June 05, 2002 8:00 PM > To: MANET LIST > Cc: AODV LIST > Subject: [manet] AODV: Lifetime of reverse routes... > > Hello > > The AODV draft say (section 6.2) that the next hop > along the reverse > path of a route should be updated when a data packet > is forwarded (along > with the destination and next hop of the forward > route). However, since > it is impossible to tell from the packet which node > the packet is > received from, without keeping track of MAC- > addresses, one must check > the reverse route entry for its next hop. > > The problem is that the draft does not mention > anything about updating > the destination of the reverse route (or did I miss > this?), so if the > communication is one way, the reverse route entry > eventually is deleted > and the information about the reverse route's next > hop is lost. > Therefore it is also impossible to update the > lifetime of the next hop > along the reverse route when data packets along the > forward route are > received. > > The result is that the next hop along the reverse > route also gets > deleted. This may hinder forwarding of RERRs and the > source generating > the data is never informed when the route breaks. > > The solution is of course to update the lifetime of > the destination of > the reverse route too, so that the information about > its next hop is > kept while the forward route is active. > > Comments? > > Best Regards > > Erik Nordström > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 5 21:14:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03125 for ; Wed, 5 Jun 2002 21:14:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14788 for manet-archive@odin.ietf.org; Wed, 5 Jun 2002 21:14:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12269; Wed, 5 Jun 2002 20:37:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12238 for ; Wed, 5 Jun 2002 20:37:47 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00700 for ; Wed, 5 Jun 2002 20:37:15 -0400 (EDT) Received: from waysideececs (wayside-ececs.rhod.uc.edu [10.63.7.45] (may be forged)) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g560bCVN028663; Wed, 5 Jun 2002 20:37:12 -0400 (EDT) From: "Samir R. Das" To: "=?iso-8859-1?Q?'Erik_Nordstr=F6m'?=" , "'Charles E. Perkins'" , "Elizabeth M. Belding-Royer" Cc: "'AODV LIST'" , "'MANET LIST'" Subject: RE: [manet] AODV: Lifetime of reverse routes... Date: Wed, 5 Jun 2002 20:37:11 -0400 Organization: University of Cincinnati Message-ID: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1023321585.11971.25.camel@Replicator> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA12239 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Erik, I somehow do not follow your arguments. The source IP address in a data packet can be used as the destination of the reverse path. The next hop for this routing entry is the next hop towards the destination of the reverse path. I guess here the language in the draft should be changed to remove the words "previous hop." You are right in that it is not "directly" known in the routing layer. Also, refreshing the reverse path is an optimization. Even if the reverse path is deleted, it does not hinder the RERR propagation. Typically, RERRs are broadcast or even if unicast, the precursor list is used to get the next hop for RERR. Samir > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet- > admin@ietf.org] On Behalf Of Erik Nordström > Sent: Wednesday, June 05, 2002 8:00 PM > To: MANET LIST > Cc: AODV LIST > Subject: [manet] AODV: Lifetime of reverse routes... > > Hello > > The AODV draft say (section 6.2) that the next hop > along the reverse > path of a route should be updated when a data packet > is forwarded (along > with the destination and next hop of the forward > route). However, since > it is impossible to tell from the packet which node > the packet is > received from, without keeping track of MAC- > addresses, one must check > the reverse route entry for its next hop. > > The problem is that the draft does not mention > anything about updating > the destination of the reverse route (or did I miss > this?), so if the > communication is one way, the reverse route entry > eventually is deleted > and the information about the reverse route's next > hop is lost. > Therefore it is also impossible to update the > lifetime of the next hop > along the reverse route when data packets along the > forward route are > received. > > The result is that the next hop along the reverse > route also gets > deleted. This may hinder forwarding of RERRs and the > source generating > the data is never informed when the route breaks. > > The solution is of course to update the lifetime of > the destination of > the reverse route too, so that the information about > its next hop is > kept while the forward route is active. > > Comments? > > Best Regards > > Erik Nordström > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 5 21:31:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04087 for ; Wed, 5 Jun 2002 21:31:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13047; Wed, 5 Jun 2002 20:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13016 for ; Wed, 5 Jun 2002 20:51:38 -0400 (EDT) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01647 for ; Wed, 5 Jun 2002 20:51:06 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by mailc.telia.com (8.11.6/8.11.6) with ESMTP id g560pYu27593; Thu, 6 Jun 2002 02:51:34 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g560pY107386; Thu, 6 Jun 2002 02:51:34 +0200 (CEST) Subject: Re: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "Elizabeth M. "Belding-Royer , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> References: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 02:49:15 +0200 Message-Id: <1023324556.12534.9.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA13017 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit On Thu, 2002-06-06 at 02:37, Samir R. Das wrote: > Hi Erik, > > I somehow do not follow your arguments. > I knew this would be a problem... :-) > The source IP address in a data packet can be used as the destination of > the reverse path. The next hop for this routing entry is the next hop > towards the destination of the reverse path. > Yes, but my point is that if the routing entry of the reverse route destination does not have its lifetime refreshed, the reverse next hop is lost. The draft does not mention that the destination of the reverse path should be refreshed when forwarding packets on the forward route. > I guess here the language in the draft should be changed to remove the > words "previous hop." You are right in that it is not "directly" known > in the routing layer. > > Also, refreshing the reverse path is an optimization. Even if the > reverse path is deleted, it does not hinder the RERR propagation. > Typically, RERRs are broadcast or even if unicast, the precursor list is > used to get the next hop for RERR. > The propagation of RERRs is broken since there is no way to keep track of next hops along the reverse route if the routing entry of the reverse route is not refreshed, as stated above. Therefore *both* the reverse path routing entry and the next hop entry along that route MUST be refreshed, right? /Erik > Samir > > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet- > > admin@ietf.org] On Behalf Of Erik Nordström > > Sent: Wednesday, June 05, 2002 8:00 PM > > To: MANET LIST > > Cc: AODV LIST > > Subject: [manet] AODV: Lifetime of reverse routes... > > > > Hello > > > > The AODV draft say (section 6.2) that the next hop > > along the reverse > > path of a route should be updated when a data packet > > is forwarded (along > > with the destination and next hop of the forward > > route). However, since > > it is impossible to tell from the packet which node > > the packet is > > received from, without keeping track of MAC- > > addresses, one must check > > the reverse route entry for its next hop. > > > > The problem is that the draft does not mention > > anything about updating > > the destination of the reverse route (or did I miss > > this?), so if the > > communication is one way, the reverse route entry > > eventually is deleted > > and the information about the reverse route's next > > hop is lost. > > Therefore it is also impossible to update the > > lifetime of the next hop > > along the reverse route when data packets along the > > forward route are > > received. > > > > The result is that the next hop along the reverse > > route also gets > > deleted. This may hinder forwarding of RERRs and the > > source generating > > the data is never informed when the route breaks. > > > > The solution is of course to update the lifetime of > > the destination of > > the reverse route too, so that the information about > > its next hop is > > kept while the forward route is active. > > > > Comments? > > > > Best Regards > > > > Erik Nordström > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Aodvimpl-public mailing list > Aodvimpl-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aodvimpl-public _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 5 21:32:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04167 for ; Wed, 5 Jun 2002 21:32:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14173; Wed, 5 Jun 2002 21:04:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14149 for ; Wed, 5 Jun 2002 21:04:42 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02434 for ; Wed, 5 Jun 2002 21:04:12 -0400 (EDT) Received: from waysideececs (wayside-ececs.rhod.uc.edu [10.63.7.45] (may be forged)) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5614AVN029313; Wed, 5 Jun 2002 21:04:10 -0400 (EDT) From: "Samir R. Das" To: "=?iso-8859-1?Q?'Erik_Nordstr=F6m'?=" Cc: "'Charles E. Perkins'" , "'Elizabeth M. Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... Date: Wed, 5 Jun 2002 21:04:09 -0400 Organization: University of Cincinnati Message-ID: <001701c20cf6$10b65c70$2d073f0a@waysideececs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1023324556.12534.9.camel@Replicator> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA14150 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet- > admin@ietf.org] On Behalf Of Erik Nordström > Sent: Wednesday, June 05, 2002 8:49 PM > To: Samir R. Das > Cc: 'Charles E. Perkins'; Elizabeth M. Belding- > Royer; 'AODV LIST'; 'MANET LIST' > Subject: Re: [Aodvimpl] RE: [manet] AODV: Lifetime > of reverse routes... > > On Thu, 2002-06-06 at 02:37, Samir R. Das wrote: > > Hi Erik, > > > > I somehow do not follow your arguments. > > > > I knew this would be a problem... :-) > > > The source IP address in a data packet can be used > as the destination of > > the reverse path. The next hop for this routing > entry is the next hop > > towards the destination of the reverse path. > > > > Yes, but my point is that if the routing entry of > the reverse route > destination does not have its lifetime refreshed, > the reverse next hop > is lost. The draft does not mention that the > destination of the reverse > path should be refreshed when forwarding packets on > the forward route. > OK. I guess the language can be made more specific here .. Regarding your comment on RERR below, I do not see why you need a valid reverse path to propagate RERR! True, RERR goes in the reverse direction, but it does not need to have a valid reverse path entry. It is either simply broadcast or it may be unicast to node(s) in the appropriate precursor list(s). Why do you care for the reverse path? > > I guess here the language in the draft should be > changed to remove the > > words "previous hop." You are right in that it is > not "directly" known > > in the routing layer. > > > > Also, refreshing the reverse path is an > optimization. Even if the > > reverse path is deleted, it does not hinder the > RERR propagation. > > Typically, RERRs are broadcast or even if unicast, > the precursor list is > > used to get the next hop for RERR. > > > > The propagation of RERRs is broken since there is no > way to keep track > of next hops along the reverse route if the routing > entry of the reverse > route is not refreshed, as stated above. Therefore > *both* the reverse > path routing entry and the next hop entry along that > route MUST be > refreshed, right? > > /Erik > > > Samir > > > > > > > -----Original Message----- > > > From: manet-admin@ietf.org [mailto:manet- > > > admin@ietf.org] On Behalf Of Erik Nordström > > > Sent: Wednesday, June 05, 2002 8:00 PM > > > To: MANET LIST > > > Cc: AODV LIST > > > Subject: [manet] AODV: Lifetime of reverse > routes... > > > > > > Hello > > > > > > The AODV draft say (section 6.2) that the next > hop > > > along the reverse > > > path of a route should be updated when a data > packet > > > is forwarded (along > > > with the destination and next hop of the > forward > > > route). However, since > > > it is impossible to tell from the packet which > node > > > the packet is > > > received from, without keeping track of MAC- > > > addresses, one must check > > > the reverse route entry for its next hop. > > > > > > The problem is that the draft does not mention > > > anything about updating > > > the destination of the reverse route (or did I > miss > > > this?), so if the > > > communication is one way, the reverse route > entry > > > eventually is deleted > > > and the information about the reverse route's > next > > > hop is lost. > > > Therefore it is also impossible to update the > > > lifetime of the next hop > > > along the reverse route when data packets along > the > > > forward route are > > > received. > > > > > > The result is that the next hop along the > reverse > > > route also gets > > > deleted. This may hinder forwarding of RERRs > and the > > > source generating > > > the data is never informed when the route > breaks. > > > > > > The solution is of course to update the > lifetime of > > > the destination of > > > the reverse route too, so that the information > about > > > its next hop is > > > kept while the forward route is active. > > > > > > Comments? > > > > > > Best Regards > > > > > > Erik Nordström > > > > > > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > ____________________________________________________ > ___________ > > > > Don't miss the 2002 Sprint PCS Application > Developer's Conference > > August 25-28 in Las Vegas -- > http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Aodvimpl-public mailing list > > Aodvimpl-public@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/aodvimp > l-public > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 5 21:52:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05809 for ; Wed, 5 Jun 2002 21:52:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15373; Wed, 5 Jun 2002 21:24:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15345 for ; Wed, 5 Jun 2002 21:24:39 -0400 (EDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03664 for ; Wed, 5 Jun 2002 21:24:09 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g561OcV17107; Thu, 6 Jun 2002 03:24:38 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g561Ob121010; Thu, 6 Jun 2002 03:24:37 +0200 (CEST) Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. \"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: <001701c20cf6$10b65c70$2d073f0a@waysideececs> References: <001701c20cf6$10b65c70$2d073f0a@waysideececs> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 03:22:19 +0200 Message-Id: <1023326540.12795.17.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit On Thu, 2002-06-06 at 03:04, Samir R. Das wrote: > > > > OK. I guess the language can be made more specific here .. > > Regarding your comment on RERR below, I do not see why you need a valid > reverse path to propagate RERR! True, RERR goes in the reverse > direction, but it does not need to have a valid reverse path entry. It > is either simply broadcast or it may be unicast to node(s) in the > appropriate precursor list(s). Why do you care for the reverse path? Because the reverse path contains the necessary information to keep the next hop in that direction refreshed. If the next hop of the reverse path times out, it is also removed from *all* precursor lists! If no precursors exists we will not send a RERR... It is true that the reverse path is not needed if you broadcast the RERR, but if you only have one precursor on the (broken) forward route, the RERR should be unicasted and then the next hop of the reverse path is needed, right? Are we in agreement that the next hop of the reverse path is needed if we are to unicast the RERR? (Keep in mind if it is removed, it is also removed from all precursor lists). In that case the reverse next hop must be refreshed (which is also stated in the draft). Then tell me, when we forward a data packet on the forward route, how do you figure out the previous hop of that message? - You check the source IP, look it up in the routing table and check the next hop in that entry. But how do you do that if that routing table entry does not exist??? Conclusion: We must also refresh the reverse path entry to keep it from expiring. /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 5 21:52:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05819 for ; Wed, 5 Jun 2002 21:52:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17107 for manet-archive@odin.ietf.org; Wed, 5 Jun 2002 21:53:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15373; Wed, 5 Jun 2002 21:24:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15345 for ; Wed, 5 Jun 2002 21:24:39 -0400 (EDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03664 for ; Wed, 5 Jun 2002 21:24:09 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g561OcV17107; Thu, 6 Jun 2002 03:24:38 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g561Ob121010; Thu, 6 Jun 2002 03:24:37 +0200 (CEST) Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. \"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: <001701c20cf6$10b65c70$2d073f0a@waysideececs> References: <001701c20cf6$10b65c70$2d073f0a@waysideececs> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 03:22:19 +0200 Message-Id: <1023326540.12795.17.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit On Thu, 2002-06-06 at 03:04, Samir R. Das wrote: > > > > OK. I guess the language can be made more specific here .. > > Regarding your comment on RERR below, I do not see why you need a valid > reverse path to propagate RERR! True, RERR goes in the reverse > direction, but it does not need to have a valid reverse path entry. It > is either simply broadcast or it may be unicast to node(s) in the > appropriate precursor list(s). Why do you care for the reverse path? Because the reverse path contains the necessary information to keep the next hop in that direction refreshed. If the next hop of the reverse path times out, it is also removed from *all* precursor lists! If no precursors exists we will not send a RERR... It is true that the reverse path is not needed if you broadcast the RERR, but if you only have one precursor on the (broken) forward route, the RERR should be unicasted and then the next hop of the reverse path is needed, right? Are we in agreement that the next hop of the reverse path is needed if we are to unicast the RERR? (Keep in mind if it is removed, it is also removed from all precursor lists). In that case the reverse next hop must be refreshed (which is also stated in the draft). Then tell me, when we forward a data packet on the forward route, how do you figure out the previous hop of that message? - You check the source IP, look it up in the routing table and check the next hop in that entry. But how do you do that if that routing table entry does not exist??? Conclusion: We must also refresh the reverse path entry to keep it from expiring. /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 5 22:25:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04095 for ; Wed, 5 Jun 2002 21:31:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA16264 for manet-archive@odin.ietf.org; Wed, 5 Jun 2002 21:31:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13047; Wed, 5 Jun 2002 20:51:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13016 for ; Wed, 5 Jun 2002 20:51:38 -0400 (EDT) Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01647 for ; Wed, 5 Jun 2002 20:51:06 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by mailc.telia.com (8.11.6/8.11.6) with ESMTP id g560pYu27593; Thu, 6 Jun 2002 02:51:34 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g560pY107386; Thu, 6 Jun 2002 02:51:34 +0200 (CEST) Subject: Re: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "Elizabeth M. "Belding-Royer , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> References: <001601c20cf2$4ca9ca90$2d073f0a@waysideececs> Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 02:49:15 +0200 Message-Id: <1023324556.12534.9.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA13017 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit On Thu, 2002-06-06 at 02:37, Samir R. Das wrote: > Hi Erik, > > I somehow do not follow your arguments. > I knew this would be a problem... :-) > The source IP address in a data packet can be used as the destination of > the reverse path. The next hop for this routing entry is the next hop > towards the destination of the reverse path. > Yes, but my point is that if the routing entry of the reverse route destination does not have its lifetime refreshed, the reverse next hop is lost. The draft does not mention that the destination of the reverse path should be refreshed when forwarding packets on the forward route. > I guess here the language in the draft should be changed to remove the > words "previous hop." You are right in that it is not "directly" known > in the routing layer. > > Also, refreshing the reverse path is an optimization. Even if the > reverse path is deleted, it does not hinder the RERR propagation. > Typically, RERRs are broadcast or even if unicast, the precursor list is > used to get the next hop for RERR. > The propagation of RERRs is broken since there is no way to keep track of next hops along the reverse route if the routing entry of the reverse route is not refreshed, as stated above. Therefore *both* the reverse path routing entry and the next hop entry along that route MUST be refreshed, right? /Erik > Samir > > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet- > > admin@ietf.org] On Behalf Of Erik Nordström > > Sent: Wednesday, June 05, 2002 8:00 PM > > To: MANET LIST > > Cc: AODV LIST > > Subject: [manet] AODV: Lifetime of reverse routes... > > > > Hello > > > > The AODV draft say (section 6.2) that the next hop > > along the reverse > > path of a route should be updated when a data packet > > is forwarded (along > > with the destination and next hop of the forward > > route). However, since > > it is impossible to tell from the packet which node > > the packet is > > received from, without keeping track of MAC- > > addresses, one must check > > the reverse route entry for its next hop. > > > > The problem is that the draft does not mention > > anything about updating > > the destination of the reverse route (or did I miss > > this?), so if the > > communication is one way, the reverse route entry > > eventually is deleted > > and the information about the reverse route's next > > hop is lost. > > Therefore it is also impossible to update the > > lifetime of the next hop > > along the reverse route when data packets along the > > forward route are > > received. > > > > The result is that the next hop along the reverse > > route also gets > > deleted. This may hinder forwarding of RERRs and the > > source generating > > the data is never informed when the route breaks. > > > > The solution is of course to update the lifetime of > > the destination of > > the reverse route too, so that the information about > > its next hop is > > kept while the forward route is active. > > > > Comments? > > > > Best Regards > > > > Erik Nordström > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Aodvimpl-public mailing list > Aodvimpl-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aodvimpl-public _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 5 22:25:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04176 for ; Wed, 5 Jun 2002 21:32:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA16359 for manet-archive@odin.ietf.org; Wed, 5 Jun 2002 21:32:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14173; Wed, 5 Jun 2002 21:04:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14149 for ; Wed, 5 Jun 2002 21:04:42 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02434 for ; Wed, 5 Jun 2002 21:04:12 -0400 (EDT) Received: from waysideececs (wayside-ececs.rhod.uc.edu [10.63.7.45] (may be forged)) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5614AVN029313; Wed, 5 Jun 2002 21:04:10 -0400 (EDT) From: "Samir R. Das" To: "=?iso-8859-1?Q?'Erik_Nordstr=F6m'?=" Cc: "'Charles E. Perkins'" , "'Elizabeth M. Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... Date: Wed, 5 Jun 2002 21:04:09 -0400 Organization: University of Cincinnati Message-ID: <001701c20cf6$10b65c70$2d073f0a@waysideececs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1023324556.12534.9.camel@Replicator> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA14150 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet- > admin@ietf.org] On Behalf Of Erik Nordström > Sent: Wednesday, June 05, 2002 8:49 PM > To: Samir R. Das > Cc: 'Charles E. Perkins'; Elizabeth M. Belding- > Royer; 'AODV LIST'; 'MANET LIST' > Subject: Re: [Aodvimpl] RE: [manet] AODV: Lifetime > of reverse routes... > > On Thu, 2002-06-06 at 02:37, Samir R. Das wrote: > > Hi Erik, > > > > I somehow do not follow your arguments. > > > > I knew this would be a problem... :-) > > > The source IP address in a data packet can be used > as the destination of > > the reverse path. The next hop for this routing > entry is the next hop > > towards the destination of the reverse path. > > > > Yes, but my point is that if the routing entry of > the reverse route > destination does not have its lifetime refreshed, > the reverse next hop > is lost. The draft does not mention that the > destination of the reverse > path should be refreshed when forwarding packets on > the forward route. > OK. I guess the language can be made more specific here .. Regarding your comment on RERR below, I do not see why you need a valid reverse path to propagate RERR! True, RERR goes in the reverse direction, but it does not need to have a valid reverse path entry. It is either simply broadcast or it may be unicast to node(s) in the appropriate precursor list(s). Why do you care for the reverse path? > > I guess here the language in the draft should be > changed to remove the > > words "previous hop." You are right in that it is > not "directly" known > > in the routing layer. > > > > Also, refreshing the reverse path is an > optimization. Even if the > > reverse path is deleted, it does not hinder the > RERR propagation. > > Typically, RERRs are broadcast or even if unicast, > the precursor list is > > used to get the next hop for RERR. > > > > The propagation of RERRs is broken since there is no > way to keep track > of next hops along the reverse route if the routing > entry of the reverse > route is not refreshed, as stated above. Therefore > *both* the reverse > path routing entry and the next hop entry along that > route MUST be > refreshed, right? > > /Erik > > > Samir > > > > > > > -----Original Message----- > > > From: manet-admin@ietf.org [mailto:manet- > > > admin@ietf.org] On Behalf Of Erik Nordström > > > Sent: Wednesday, June 05, 2002 8:00 PM > > > To: MANET LIST > > > Cc: AODV LIST > > > Subject: [manet] AODV: Lifetime of reverse > routes... > > > > > > Hello > > > > > > The AODV draft say (section 6.2) that the next > hop > > > along the reverse > > > path of a route should be updated when a data > packet > > > is forwarded (along > > > with the destination and next hop of the > forward > > > route). However, since > > > it is impossible to tell from the packet which > node > > > the packet is > > > received from, without keeping track of MAC- > > > addresses, one must check > > > the reverse route entry for its next hop. > > > > > > The problem is that the draft does not mention > > > anything about updating > > > the destination of the reverse route (or did I > miss > > > this?), so if the > > > communication is one way, the reverse route > entry > > > eventually is deleted > > > and the information about the reverse route's > next > > > hop is lost. > > > Therefore it is also impossible to update the > > > lifetime of the next hop > > > along the reverse route when data packets along > the > > > forward route are > > > received. > > > > > > The result is that the next hop along the > reverse > > > route also gets > > > deleted. This may hinder forwarding of RERRs > and the > > > source generating > > > the data is never informed when the route > breaks. > > > > > > The solution is of course to update the > lifetime of > > > the destination of > > > the reverse route too, so that the information > about > > > its next hop is > > > kept while the forward route is active. > > > > > > Comments? > > > > > > Best Regards > > > > > > Erik Nordström > > > > > > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > ____________________________________________________ > ___________ > > > > Don't miss the 2002 Sprint PCS Application > Developer's Conference > > August 25-28 in Las Vegas -- > http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Aodvimpl-public mailing list > > Aodvimpl-public@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/aodvimp > l-public > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 01:37:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19572 for ; Thu, 6 Jun 2002 01:37:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24550; Thu, 6 Jun 2002 01:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24519 for ; Thu, 6 Jun 2002 01:03:41 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17732 for ; Thu, 6 Jun 2002 01:03:10 -0400 (EDT) Received: from ffsli (nr5-66-161-168-149.fuse.net [66.161.168.149]) by mail.ececs.uc.edu (8.12.3/8.12.2) with SMTP id g56537VN005139; Thu, 6 Jun 2002 01:03:08 -0400 (EDT) From: "Samir R. Das" To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. \"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... Date: Thu, 6 Jun 2002 01:03:15 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <1023326540.12795.17.camel@Replicator> Importance: Normal Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Erik, I was trying to find a language in the draft that suggests that when a next hop route expires that next hop is also removed from all precursor lists. Where did you find this? Also, all these are moot anyways as reverse routes can easily be refreshed as you pointed out. I think we meant this except that the draft language was not as specific .. Samir >It is true that the reverse path is not needed if you broadcast the >RERR, but if you only have one precursor on the (broken) forward route, >the RERR should be unicasted and then the next hop of the reverse path >is needed, right? > >Are we in agreement that the next hop of the reverse path is needed if >we are to unicast the RERR? (Keep in mind if it is removed, it is also >removed from all precursor lists). In that case the reverse next hop >must be refreshed (which is also stated in the draft). > >Then tell me, when we forward a data packet on the forward route, how do >you figure out the previous hop of that message? - You check the source >IP, look it up in the routing table and check the next hop in that >entry. But how do you do that if that routing table entry does not >exist??? Conclusion: We must also refresh the reverse path entry to keep >it from expiring. > >/Erik > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 01:37:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19591 for ; Thu, 6 Jun 2002 01:37:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA03646 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 01:37:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24550; Thu, 6 Jun 2002 01:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24519 for ; Thu, 6 Jun 2002 01:03:41 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17732 for ; Thu, 6 Jun 2002 01:03:10 -0400 (EDT) Received: from ffsli (nr5-66-161-168-149.fuse.net [66.161.168.149]) by mail.ececs.uc.edu (8.12.3/8.12.2) with SMTP id g56537VN005139; Thu, 6 Jun 2002 01:03:08 -0400 (EDT) From: "Samir R. Das" To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. \"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... Date: Thu, 6 Jun 2002 01:03:15 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <1023326540.12795.17.camel@Replicator> Importance: Normal Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Erik, I was trying to find a language in the draft that suggests that when a next hop route expires that next hop is also removed from all precursor lists. Where did you find this? Also, all these are moot anyways as reverse routes can easily be refreshed as you pointed out. I think we meant this except that the draft language was not as specific .. Samir >It is true that the reverse path is not needed if you broadcast the >RERR, but if you only have one precursor on the (broken) forward route, >the RERR should be unicasted and then the next hop of the reverse path >is needed, right? > >Are we in agreement that the next hop of the reverse path is needed if >we are to unicast the RERR? (Keep in mind if it is removed, it is also >removed from all precursor lists). In that case the reverse next hop >must be refreshed (which is also stated in the draft). > >Then tell me, when we forward a data packet on the forward route, how do >you figure out the previous hop of that message? - You check the source >IP, look it up in the routing table and check the next hop in that >entry. But how do you do that if that routing table entry does not >exist??? Conclusion: We must also refresh the reverse path entry to keep >it from expiring. > >/Erik > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 01:54:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20230 for ; Thu, 6 Jun 2002 01:54:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02197; Thu, 6 Jun 2002 01:20:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02168 for ; Thu, 6 Jun 2002 01:20:13 -0400 (EDT) Received: from mail.cis.nctu.edu.tw (mail.cis.nctu.edu.tw [140.113.23.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18648 for ; Thu, 6 Jun 2002 01:19:38 -0400 (EDT) Received: (from root@localhost) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) id g565K6g8010312 for manet@ietf.org; Thu, 6 Jun 2002 13:20:06 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Received: from cissol11 (gis86806@cissol11.cis.nctu.edu.tw [140.113.23.111]) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) with ESMTP id g565K4R7010302 for ; Thu, 6 Jun 2002 13:20:04 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Date: Thu, 6 Jun 2002 13:18:42 +0800 (CST) From: Yu-Ching Hsu X-X-Sender: gis86806@cissol11 To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Subject: [manet] 802.11: infrastructure mode and adhoc mode Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 01:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20243 for ; Thu, 6 Jun 2002 01:54:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04729 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 01:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02197; Thu, 6 Jun 2002 01:20:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02168 for ; Thu, 6 Jun 2002 01:20:13 -0400 (EDT) Received: from mail.cis.nctu.edu.tw (mail.cis.nctu.edu.tw [140.113.23.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18648 for ; Thu, 6 Jun 2002 01:19:38 -0400 (EDT) Received: (from root@localhost) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) id g565K6g8010312 for manet@ietf.org; Thu, 6 Jun 2002 13:20:06 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Received: from cissol11 (gis86806@cissol11.cis.nctu.edu.tw [140.113.23.111]) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) with ESMTP id g565K4R7010302 for ; Thu, 6 Jun 2002 13:20:04 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Date: Thu, 6 Jun 2002 13:18:42 +0800 (CST) From: Yu-Ching Hsu X-X-Sender: gis86806@cissol11 To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Subject: [manet] 802.11: infrastructure mode and adhoc mode Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 03:12:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00406 for ; Thu, 6 Jun 2002 03:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07124; Thu, 6 Jun 2002 02:35:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07093 for ; Thu, 6 Jun 2002 02:35:11 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29842 for ; Thu, 6 Jun 2002 02:34:40 -0400 (EDT) Received: from ci1093exch001p.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g566Ycu04502 for ; Thu, 6 Jun 2002 02:34:39 -0400 (EDT) Received: by CI1093EXCH001P with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:34:11 +0800 Message-ID: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> From: "Pei, Ke (Peak)" To: "'Yu-Ching Hsu'" , manet@ietf.org Subject: RE: [manet] 802.11: infrastructure mode and adhoc mode Date: Thu, 6 Jun 2002 14:11:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I think that is depend on standard. Pei, Ke (Peak) Bell Labs China *Tel: 8610-68748088-8727 *Fax: 8610-62532918 *Email: kpei@lucent.com -----Original Message----- From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] Sent: Thursday, June 06, 2002 1:19 PM To: manet@ietf.org Subject: [manet] 802.11: infrastructure mode and adhoc mode Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 03:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00415 for ; Thu, 6 Jun 2002 03:12:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09609 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 03:12:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07124; Thu, 6 Jun 2002 02:35:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07093 for ; Thu, 6 Jun 2002 02:35:11 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29842 for ; Thu, 6 Jun 2002 02:34:40 -0400 (EDT) Received: from ci1093exch001p.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g566Ycu04502 for ; Thu, 6 Jun 2002 02:34:39 -0400 (EDT) Received: by CI1093EXCH001P with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:34:11 +0800 Message-ID: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> From: "Pei, Ke (Peak)" To: "'Yu-Ching Hsu'" , manet@ietf.org Subject: RE: [manet] 802.11: infrastructure mode and adhoc mode Date: Thu, 6 Jun 2002 14:11:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I think that is depend on standard. Pei, Ke (Peak) Bell Labs China *Tel: 8610-68748088-8727 *Fax: 8610-62532918 *Email: kpei@lucent.com -----Original Message----- From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] Sent: Thursday, June 06, 2002 1:19 PM To: manet@ietf.org Subject: [manet] 802.11: infrastructure mode and adhoc mode Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 04:43:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02263 for ; Thu, 6 Jun 2002 04:43:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12642; Thu, 6 Jun 2002 04:07:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12612 for ; Thu, 6 Jun 2002 04:07:41 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01415 for ; Thu, 6 Jun 2002 04:07:10 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id KAA30314; Thu, 6 Jun 2002 10:07:24 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g5687NT14059; Thu, 6 Jun 2002 10:07:23 +0200 (METDST) Received: from ieee.org (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with ESMTP id g5687MH21636; Thu, 6 Jun 2002 10:07:22 +0200 Message-ID: <3CFF17F0.4020202@ieee.org> Date: Thu, 06 Jun 2002 10:06:08 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pei, Ke (Peak)" CC: "'Yu-Ching Hsu'" , manet@ietf.org Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, And what the standard tells you is that MAC behavior is not the same when a station is in ad-hoc mode (DCF) than when it is in infrastructure mode (PCF). Nodes can get random access to the media in a distributed way or a coordinated access by means of the access point (polling). However, in the scenario you present it is still possible for sta2 and sta1 to switch (on the fly) to ad-hoc mode to enable direct communication. The problem is that they will have to share the medium with ap1 and with any other nearby node -if any- (and PCF has a higher access priority) so, unless they also change to an unused channel, it is possible to get a longer delay and lower performance when sta1 talks direct to sta2 than when they use the infrastructure mode. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Pei, Ke (Peak) wrote: >I think that is depend on standard. > >Pei, Ke (Peak) >Bell Labs China >*Tel: 8610-68748088-8727 >*Fax: 8610-62532918 >*Email: kpei@lucent.com > > > > >-----Original Message----- >From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] >Sent: Thursday, June 06, 2002 1:19 PM >To: manet@ietf.org >Subject: [manet] 802.11: infrastructure mode and adhoc mode > > >Dear all, > I have an interesting question regarding the IEEE 802.11b products. >Does anyone know why stations cannot opperate in the hybrid mode, i.e. >infrastructure + ad-hoc. For example, in the following scenario, why >sta1 cannot send to sta2 directly? > > > AP1 > / \ > / \ > / \ > sta1 ---- sta2 > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 04:43:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02272 for ; Thu, 6 Jun 2002 04:43:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14942 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 04:44:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12642; Thu, 6 Jun 2002 04:07:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12612 for ; Thu, 6 Jun 2002 04:07:41 -0400 (EDT) Received: from kuma.upv.es (kuma.cc.upv.es [158.42.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01415 for ; Thu, 6 Jun 2002 04:07:10 -0400 (EDT) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by kuma.upv.es (8.9.3/8.9.3) with ESMTP id KAA30314; Thu, 6 Jun 2002 10:07:24 +0200 Received: from smtp2.upv.es (smtp.cc.upv.es [158.42.250.10]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id g5687NT14059; Thu, 6 Jun 2002 10:07:23 +0200 (METDST) Received: from ieee.org (msanchez.disca.upv.es [158.42.53.17]) by smtp2.upv.es (8.11.4/8.11.4) with ESMTP id g5687MH21636; Thu, 6 Jun 2002 10:07:22 +0200 Message-ID: <3CFF17F0.4020202@ieee.org> Date: Thu, 06 Jun 2002 10:06:08 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pei, Ke (Peak)" CC: "'Yu-Ching Hsu'" , manet@ietf.org Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, And what the standard tells you is that MAC behavior is not the same when a station is in ad-hoc mode (DCF) than when it is in infrastructure mode (PCF). Nodes can get random access to the media in a distributed way or a coordinated access by means of the access point (polling). However, in the scenario you present it is still possible for sta2 and sta1 to switch (on the fly) to ad-hoc mode to enable direct communication. The problem is that they will have to share the medium with ap1 and with any other nearby node -if any- (and PCF has a higher access priority) so, unless they also change to an unused channel, it is possible to get a longer delay and lower performance when sta1 talks direct to sta2 than when they use the infrastructure mode. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Pei, Ke (Peak) wrote: >I think that is depend on standard. > >Pei, Ke (Peak) >Bell Labs China >*Tel: 8610-68748088-8727 >*Fax: 8610-62532918 >*Email: kpei@lucent.com > > > > >-----Original Message----- >From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] >Sent: Thursday, June 06, 2002 1:19 PM >To: manet@ietf.org >Subject: [manet] 802.11: infrastructure mode and adhoc mode > > >Dear all, > I have an interesting question regarding the IEEE 802.11b products. >Does anyone know why stations cannot opperate in the hybrid mode, i.e. >infrastructure + ad-hoc. For example, in the following scenario, why >sta1 cannot send to sta2 directly? > > > AP1 > / \ > / \ > / \ > sta1 ---- sta2 > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 05:17:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03058 for ; Thu, 6 Jun 2002 05:17:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15023; Thu, 6 Jun 2002 04:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14996 for ; Thu, 6 Jun 2002 04:46:08 -0400 (EDT) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02316 for ; Thu, 6 Jun 2002 04:45:37 -0400 (EDT) Received: from ms29 (ms29.net.ie.niigata-u.ac.jp [133.35.156.29]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with SMTP id 28A5368F7; Thu, 6 Jun 2002 17:43:12 +0900 (JST) Date: Thu, 6 Jun 2002 08:41:24 +0900 From: syoshida To: manet@ietf.org Cc: tsato@net.ie.niigata-u.ac.jp, asuzuki@net.ie.niigata-u.ac.jp Message-Id: <20020606084124.126a9667.syoshida@net.ie.niigata-u.ac.jp> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; Linux 2.2.18-0vl4.3; sparc64) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] About TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, all. We have tried to install TBRPF in NS2.1b8 but we have not suceeded it so far. Our install environment is Vine Linux 2.5 (kernel ver. 2.4.18) for i386. We read "README" file in tbrpf directry and followed the procedure written in that file. Our procedure and problems are summarized in the following. I appreciate if anyone could give us some suggestions. 1. We unpacked the TBRPF tar ball in ns-2.1b8/ and did make in ns2.1b8/tbrpf. but make returned error. So, we added the following function to the file priqueue.cc under directory ns-2.1b8/ and added the change of priqueue.h. Packet *PriQueue::filter_for_dest(nsaddr_t dest) After that we passed through make without error. 2. We added the exact code to ns-2.1b8/tcl/lib/ns-lib.tcl, ns-2.1b8/lib/ns-mobilenode.tcl and ns-2.1b8/lib/ex/wireless.tcl. 3. We edited Makefile and did make.(no errors) 4. To run a tbrpf-based simulation, but we have failed. After that, we edited the wireless.tcl file to use "dsr" and execute, but error occured. And Does anyone use ns to simulate TBRPF? Would you please give us some suggestions for us to solve these problems? Best regards, $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Japan, Niigata University Sota Yoshida syoshida@net.ie.niigata-u.ac.jp $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 05:17:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03067 for ; Thu, 6 Jun 2002 05:17:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16809 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 05:17:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15023; Thu, 6 Jun 2002 04:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14996 for ; Thu, 6 Jun 2002 04:46:08 -0400 (EDT) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02316 for ; Thu, 6 Jun 2002 04:45:37 -0400 (EDT) Received: from ms29 (ms29.net.ie.niigata-u.ac.jp [133.35.156.29]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with SMTP id 28A5368F7; Thu, 6 Jun 2002 17:43:12 +0900 (JST) Date: Thu, 6 Jun 2002 08:41:24 +0900 From: syoshida To: manet@ietf.org Cc: tsato@net.ie.niigata-u.ac.jp, asuzuki@net.ie.niigata-u.ac.jp Message-Id: <20020606084124.126a9667.syoshida@net.ie.niigata-u.ac.jp> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; Linux 2.2.18-0vl4.3; sparc64) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] About TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, all. We have tried to install TBRPF in NS2.1b8 but we have not suceeded it so far. Our install environment is Vine Linux 2.5 (kernel ver. 2.4.18) for i386. We read "README" file in tbrpf directry and followed the procedure written in that file. Our procedure and problems are summarized in the following. I appreciate if anyone could give us some suggestions. 1. We unpacked the TBRPF tar ball in ns-2.1b8/ and did make in ns2.1b8/tbrpf. but make returned error. So, we added the following function to the file priqueue.cc under directory ns-2.1b8/ and added the change of priqueue.h. Packet *PriQueue::filter_for_dest(nsaddr_t dest) After that we passed through make without error. 2. We added the exact code to ns-2.1b8/tcl/lib/ns-lib.tcl, ns-2.1b8/lib/ns-mobilenode.tcl and ns-2.1b8/lib/ex/wireless.tcl. 3. We edited Makefile and did make.(no errors) 4. To run a tbrpf-based simulation, but we have failed. After that, we edited the wireless.tcl file to use "dsr" and execute, but error occured. And Does anyone use ns to simulate TBRPF? Would you please give us some suggestions for us to solve these problems? Best regards, $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Japan, Niigata University Sota Yoshida syoshida@net.ie.niigata-u.ac.jp $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 06:11:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04347 for ; Thu, 6 Jun 2002 06:11:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17259; Thu, 6 Jun 2002 05:28:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17229 for ; Thu, 6 Jun 2002 05:28:04 -0400 (EDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03259 for ; Thu, 6 Jun 2002 05:27:30 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g569ROV27474; Thu, 6 Jun 2002 11:27:24 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g569RN119184; Thu, 6 Jun 2002 11:27:23 +0200 (CEST) Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. ""\"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 11:25:05 +0200 Message-Id: <1023355506.1656.28.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Samir, comments below: On Thu, 2002-06-06 at 07:03, Samir R. Das wrote: > Erik, > > I was trying to find a language in the draft that suggests > that when a next hop route expires that next hop is also > removed from all precursor lists. Where did you find this? > You appear to be correct in that this is not specified in draft 10, but it was in draft 9 (section 8.11 last paragraph). This seem to be a subtle change which I have missed. Keeping (potentially stale precursors) will solve the problem with with RERRs mentioned earlier. However, I still maintain that you must refresh the reverse route to be able to refresh the next hop of the reverse route. > Also, all these are moot anyways as reverse routes > can easily be refreshed as you pointed out. I think we meant this > except that the draft language was not as specific .. > As I am implementing AODV, I am not really interested in what you meant when you wrote the draft, but what the draft actually say in its current form. It is clear that the draft say (section 6.2) that only the next hop of the reverse route should be refreshed when forwarding data packets on the forward route. I just want to know if I am correct in my analysis that the reverse route entry must also be refreshed, so that I can create a draft compliant AODV implementation? If this is the case, I strongly believe this should be stated in the draft. Best Regards Erik > Samir > > > >It is true that the reverse path is not needed if you broadcast the > >RERR, but if you only have one precursor on the (broken) forward route, > >the RERR should be unicasted and then the next hop of the reverse path > >is needed, right? > > > >Are we in agreement that the next hop of the reverse path is needed if > >we are to unicast the RERR? (Keep in mind if it is removed, it is also > >removed from all precursor lists). In that case the reverse next hop > >must be refreshed (which is also stated in the draft). > > > >Then tell me, when we forward a data packet on the forward route, how do > >you figure out the previous hop of that message? - You check the source > >IP, look it up in the routing table and check the next hop in that > >entry. But how do you do that if that routing table entry does not > >exist??? Conclusion: We must also refresh the reverse path entry to keep > >it from expiring. > > > >/Erik > > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Aodvimpl-public mailing list > Aodvimpl-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aodvimpl-public _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 06:11:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04357 for ; Thu, 6 Jun 2002 06:11:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA20569 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 06:11:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17259; Thu, 6 Jun 2002 05:28:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17229 for ; Thu, 6 Jun 2002 05:28:04 -0400 (EDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03259 for ; Thu, 6 Jun 2002 05:27:30 -0400 (EDT) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g569ROV27474; Thu, 6 Jun 2002 11:27:24 +0200 (CEST) Received: from h164n1fls31o848.telia.com (h164n1fls31o848.telia.com [213.66.32.164]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g569RN119184; Thu, 6 Jun 2002 11:27:23 +0200 (CEST) Subject: RE: [Aodvimpl] RE: [manet] AODV: Lifetime of reverse routes... From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Samir R. Das" Cc: "'Charles E. Perkins'" , "\"'Elizabeth M. ""\"Belding-Royer'" , "'AODV LIST'" , "'MANET LIST'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 11:25:05 +0200 Message-Id: <1023355506.1656.28.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Samir, comments below: On Thu, 2002-06-06 at 07:03, Samir R. Das wrote: > Erik, > > I was trying to find a language in the draft that suggests > that when a next hop route expires that next hop is also > removed from all precursor lists. Where did you find this? > You appear to be correct in that this is not specified in draft 10, but it was in draft 9 (section 8.11 last paragraph). This seem to be a subtle change which I have missed. Keeping (potentially stale precursors) will solve the problem with with RERRs mentioned earlier. However, I still maintain that you must refresh the reverse route to be able to refresh the next hop of the reverse route. > Also, all these are moot anyways as reverse routes > can easily be refreshed as you pointed out. I think we meant this > except that the draft language was not as specific .. > As I am implementing AODV, I am not really interested in what you meant when you wrote the draft, but what the draft actually say in its current form. It is clear that the draft say (section 6.2) that only the next hop of the reverse route should be refreshed when forwarding data packets on the forward route. I just want to know if I am correct in my analysis that the reverse route entry must also be refreshed, so that I can create a draft compliant AODV implementation? If this is the case, I strongly believe this should be stated in the draft. Best Regards Erik > Samir > > > >It is true that the reverse path is not needed if you broadcast the > >RERR, but if you only have one precursor on the (broken) forward route, > >the RERR should be unicasted and then the next hop of the reverse path > >is needed, right? > > > >Are we in agreement that the next hop of the reverse path is needed if > >we are to unicast the RERR? (Keep in mind if it is removed, it is also > >removed from all precursor lists). In that case the reverse next hop > >must be refreshed (which is also stated in the draft). > > > >Then tell me, when we forward a data packet on the forward route, how do > >you figure out the previous hop of that message? - You check the source > >IP, look it up in the routing table and check the next hop in that > >entry. But how do you do that if that routing table entry does not > >exist??? Conclusion: We must also refresh the reverse path entry to keep > >it from expiring. > > > >/Erik > > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Aodvimpl-public mailing list > Aodvimpl-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aodvimpl-public _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 06:12:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04403 for ; Thu, 6 Jun 2002 06:12:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18272; Thu, 6 Jun 2002 05:35:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18239 for ; Thu, 6 Jun 2002 05:35:09 -0400 (EDT) Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03394 for ; Thu, 6 Jun 2002 05:34:37 -0400 (EDT) Received: from D7KQ4P01 ("port 1536"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #30472) with SMTP id <01KILGVYX9JQA5ULO5@cc.usu.edu> for manet@ietf.org; Thu, 6 Jun 2002 03:35:00 MDT Date: Thu, 06 Jun 2002 03:38:24 -0600 From: Sumeeth Nagaraj To: Miguel Sanchez , "Pei, Ke (Peak)" Cc: manet@ietf.org Message-id: <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> Content-Transfer-Encoding: 7bit Subject: [manet] IEEE 802.11 Broadcast? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi all, In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not to some extent it will hear the other node as noise(interference). If there is no chip synchronization among all the nodes( neighbors) how does broadcast work, Broadcast packets are meant to be sent to all the neighbors, if there is no chip synchronization with all the neighbors some of the broadcast packets could be dropped. Isn't this a problem? or am I missing some thing here? -Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 06:12:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04413 for ; Thu, 6 Jun 2002 06:12:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA20698 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 06:12:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18272; Thu, 6 Jun 2002 05:35:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18239 for ; Thu, 6 Jun 2002 05:35:09 -0400 (EDT) Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03394 for ; Thu, 6 Jun 2002 05:34:37 -0400 (EDT) Received: from D7KQ4P01 ("port 1536"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #30472) with SMTP id <01KILGVYX9JQA5ULO5@cc.usu.edu> for manet@ietf.org; Thu, 6 Jun 2002 03:35:00 MDT Date: Thu, 06 Jun 2002 03:38:24 -0600 From: Sumeeth Nagaraj To: Miguel Sanchez , "Pei, Ke (Peak)" Cc: manet@ietf.org Message-id: <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> Content-Transfer-Encoding: 7bit Subject: [manet] IEEE 802.11 Broadcast? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi all, In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not to some extent it will hear the other node as noise(interference). If there is no chip synchronization among all the nodes( neighbors) how does broadcast work, Broadcast packets are meant to be sent to all the neighbors, if there is no chip synchronization with all the neighbors some of the broadcast packets could be dropped. Isn't this a problem? or am I missing some thing here? -Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 08:36:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10216 for ; Thu, 6 Jun 2002 08:36:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27263; Thu, 6 Jun 2002 07:56:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27162 for ; Thu, 6 Jun 2002 07:56:50 -0400 (EDT) Received: from mail.cis.nctu.edu.tw (mail.cis.nctu.edu.tw [140.113.23.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08530 for ; Thu, 6 Jun 2002 07:56:14 -0400 (EDT) Received: (from root@localhost) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) id g56Btdu6099458; Thu, 6 Jun 2002 19:55:39 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Received: from cissol11 (gis86806@cissol11.cis.nctu.edu.tw [140.113.23.111]) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) with ESMTP id g56Bta2x099448; Thu, 6 Jun 2002 19:55:37 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Date: Thu, 6 Jun 2002 19:54:13 +0800 (CST) From: Yu-Ching Hsu X-X-Sender: gis86806@cissol11 To: Miguel Sanchez cc: "Pei, Ke (Peak)" , Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode In-Reply-To: <3CFF17F0.4020202@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I think there is a mistake here. Infrastructure mode does not imply PCF. Stations in infrastructure mode can also opperate in DCF mode. On Thu, 6 Jun 2002, Miguel Sanchez wrote: > Hi, > > And what the standard tells you is that MAC behavior is not the same > when a station is in ad-hoc mode (DCF) than when it is in infrastructure > mode (PCF). > > Nodes can get random access to the media in a distributed way or a > coordinated access by means of the access point (polling). > > However, in the scenario you present it is still possible for sta2 and > sta1 to switch (on the fly) to ad-hoc mode to enable direct > communication. The problem is that they will have to share the medium > with ap1 and with any other nearby node -if any- (and PCF has a higher > access priority) so, unless they also change to an unused channel, it is > possible to get a longer delay and lower performance when sta1 talks > direct to sta2 than when they use the infrastructure mode. > > > Regards, > > Miguel Sanchez > Universidad Politecnica de Valencia, Spain > > Pei, Ke (Peak) wrote: > > >I think that is depend on standard. > > > >Pei, Ke (Peak) > >Bell Labs China > >*Tel: 8610-68748088-8727 > >*Fax: 8610-62532918 > >*Email: kpei@lucent.com > > > > > > > > > >-----Original Message----- > >From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] > >Sent: Thursday, June 06, 2002 1:19 PM > >To: manet@ietf.org > >Subject: [manet] 802.11: infrastructure mode and adhoc mode > > > > > >Dear all, > > I have an interesting question regarding the IEEE 802.11b products. > >Does anyone know why stations cannot opperate in the hybrid mode, i.e. > >infrastructure + ad-hoc. For example, in the following scenario, why > >sta1 cannot send to sta2 directly? > > > > > > AP1 > > / \ > > / \ > > / \ > > sta1 ---- sta2 > > > > > > > > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 6 08:36:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10226 for ; Thu, 6 Jun 2002 08:36:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAB29949 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 08:36:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27263; Thu, 6 Jun 2002 07:56:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27162 for ; Thu, 6 Jun 2002 07:56:50 -0400 (EDT) Received: from mail.cis.nctu.edu.tw (mail.cis.nctu.edu.tw [140.113.23.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08530 for ; Thu, 6 Jun 2002 07:56:14 -0400 (EDT) Received: (from root@localhost) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) id g56Btdu6099458; Thu, 6 Jun 2002 19:55:39 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Received: from cissol11 (gis86806@cissol11.cis.nctu.edu.tw [140.113.23.111]) by mail.cis.nctu.edu.tw (8.12.3/8.12.3) with ESMTP id g56Bta2x099448; Thu, 6 Jun 2002 19:55:37 +0800 (CST) (envelope-from gis86806@cis.nctu.edu.tw) Date: Thu, 6 Jun 2002 19:54:13 +0800 (CST) From: Yu-Ching Hsu X-X-Sender: gis86806@cissol11 To: Miguel Sanchez cc: "Pei, Ke (Peak)" , Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode In-Reply-To: <3CFF17F0.4020202@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I think there is a mistake here. Infrastructure mode does not imply PCF. Stations in infrastructure mode can also opperate in DCF mode. On Thu, 6 Jun 2002, Miguel Sanchez wrote: > Hi, > > And what the standard tells you is that MAC behavior is not the same > when a station is in ad-hoc mode (DCF) than when it is in infrastructure > mode (PCF). > > Nodes can get random access to the media in a distributed way or a > coordinated access by means of the access point (polling). > > However, in the scenario you present it is still possible for sta2 and > sta1 to switch (on the fly) to ad-hoc mode to enable direct > communication. The problem is that they will have to share the medium > with ap1 and with any other nearby node -if any- (and PCF has a higher > access priority) so, unless they also change to an unused channel, it is > possible to get a longer delay and lower performance when sta1 talks > direct to sta2 than when they use the infrastructure mode. > > > Regards, > > Miguel Sanchez > Universidad Politecnica de Valencia, Spain > > Pei, Ke (Peak) wrote: > > >I think that is depend on standard. > > > >Pei, Ke (Peak) > >Bell Labs China > >*Tel: 8610-68748088-8727 > >*Fax: 8610-62532918 > >*Email: kpei@lucent.com > > > > > > > > > >-----Original Message----- > >From: Yu-Ching Hsu [mailto:gis86806@cis.nctu.edu.tw] > >Sent: Thursday, June 06, 2002 1:19 PM > >To: manet@ietf.org > >Subject: [manet] 802.11: infrastructure mode and adhoc mode > > > > > >Dear all, > > I have an interesting question regarding the IEEE 802.11b products. > >Does anyone know why stations cannot opperate in the hybrid mode, i.e. > >infrastructure + ad-hoc. For example, in the following scenario, why > >sta1 cannot send to sta2 directly? > > > > > > AP1 > > / \ > > / \ > > / \ > > sta1 ---- sta2 > > > > > > > > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 10:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14218 for ; Thu, 6 Jun 2002 10:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03353; Thu, 6 Jun 2002 09:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03319 for ; Thu, 6 Jun 2002 09:30:39 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12720 for ; Thu, 6 Jun 2002 09:30:08 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56DUUx10566; Thu, 6 Jun 2002 09:30:34 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56DUTN23100; Thu, 6 Jun 2002 09:30:29 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10471721; Thu, 06 Jun 2002 09:29:28 -0400 Message-ID: <3CFF63ED.DC186E51@mitre.org> Date: Thu, 06 Jun 2002 09:30:21 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sumeeth Nagaraj CC: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sumeeth, Potential destinations synchronize to the transmission during the training sequence at the beginning. Once the signal is captured there is a potential advantage over other interfering signals. The DSSS spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs rates) which means the code is orthogonal to itself in all displaced positions. So assuming the time of arrival of an interfering signal is random, a good assumption since a chip with the 1 Mbs data rate corresponds to a difference of ~28 meters propagation distance, there is about a 10/11 chance that the codes will not align and the captured signal will be received with a 10+ dB processing gain. When broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this processing gain is a nice feature. Note that the 4 data rates used in 802.11b are not equivalent. The bandwidth for a channel is constrained to 22MHz. Increasing the data rate to 11Mbs removes the processing gain that comes from spreading. The higher data rates also use a different modulation. The propagation and interference characteristics of each data rate and the interference characteristics between data rates differ. Exploring and defining how to model these differences would be a nice contribution if someone were interested. I have never seen it defined anywhere and don't believe it is adequately modeled in any of the simulation environments that I am familiar with that are used to study ad hoc networks. John Sumeeth Nagaraj wrote: > > Hi all, > > In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not > to some extent it will hear the other node as noise(interference). If there > is no chip synchronization among all the nodes( neighbors) how does > broadcast work, Broadcast packets are meant to be sent to all the > neighbors, if there is no chip synchronization with all the neighbors some > of the broadcast packets could be dropped. Isn't this a problem? or am I > missing some thing here? > > -Sumeeth > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 6 10:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14228 for ; Thu, 6 Jun 2002 10:06:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06006 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 10:06:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03353; Thu, 6 Jun 2002 09:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03319 for ; Thu, 6 Jun 2002 09:30:39 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12720 for ; Thu, 6 Jun 2002 09:30:08 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56DUUx10566; Thu, 6 Jun 2002 09:30:34 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56DUTN23100; Thu, 6 Jun 2002 09:30:29 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10471721; Thu, 06 Jun 2002 09:29:28 -0400 Message-ID: <3CFF63ED.DC186E51@mitre.org> Date: Thu, 06 Jun 2002 09:30:21 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sumeeth Nagaraj CC: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sumeeth, Potential destinations synchronize to the transmission during the training sequence at the beginning. Once the signal is captured there is a potential advantage over other interfering signals. The DSSS spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs rates) which means the code is orthogonal to itself in all displaced positions. So assuming the time of arrival of an interfering signal is random, a good assumption since a chip with the 1 Mbs data rate corresponds to a difference of ~28 meters propagation distance, there is about a 10/11 chance that the codes will not align and the captured signal will be received with a 10+ dB processing gain. When broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this processing gain is a nice feature. Note that the 4 data rates used in 802.11b are not equivalent. The bandwidth for a channel is constrained to 22MHz. Increasing the data rate to 11Mbs removes the processing gain that comes from spreading. The higher data rates also use a different modulation. The propagation and interference characteristics of each data rate and the interference characteristics between data rates differ. Exploring and defining how to model these differences would be a nice contribution if someone were interested. I have never seen it defined anywhere and don't believe it is adequately modeled in any of the simulation environments that I am familiar with that are used to study ad hoc networks. John Sumeeth Nagaraj wrote: > > Hi all, > > In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not > to some extent it will hear the other node as noise(interference). If there > is no chip synchronization among all the nodes( neighbors) how does > broadcast work, Broadcast packets are meant to be sent to all the > neighbors, if there is no chip synchronization with all the neighbors some > of the broadcast packets could be dropped. Isn't this a problem? or am I > missing some thing here? > > -Sumeeth > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 11:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17571 for ; Thu, 6 Jun 2002 11:11:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08016; Thu, 6 Jun 2002 10:41:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07987 for ; Thu, 6 Jun 2002 10:41:36 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16323 for ; Thu, 6 Jun 2002 10:41:03 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56EfPx25651; Thu, 6 Jun 2002 10:41:25 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56EfNN13450; Thu, 6 Jun 2002 10:41:23 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10473565; Thu, 06 Jun 2002 10:40:26 -0400 Message-ID: <3CFF7490.923C3DF3@mitre.org> Date: Thu, 06 Jun 2002 10:41:20 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Reilly, Martin T." CC: Sumeeth Nagaraj , Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <17B3886DFDF9D3118D7E00D0B73E9B6E42FDCF@njway201.hazeltine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Marty, Will you make your model available for others to use and consider? I did something similar for the OPNET 802.11 version 7.0.B wlan_mac process model and supporting pipeline stages but restricted it to just the 1 Mbps data rate to avoid the complexity of modeling simultaneous use of different physical layers. These models can be downloaded by OPNET users at ftp://opguest:opguest@corporate7.opnet.com/433/ It is included as part of a model of Kevin Grace's Mobile Mesh Routing Protocol. John "Reilly, Martin T." wrote: > > with respect to the modeling of a direct sequence spread spectrum modem with > a preamble I have created a very detailed model of a similar system using > Opnet. The channel access protocol is like that of 802.11 (using > RTS/CTS/Data/Ack). > > With a fixed length preamble and varying the burst rate (by factors of 2) of > the data segments for a small net (about 40 nodes all within comm's range of > each other) the overall system throughput does increase but by a factor > smaller than 2. As the data burst rate increases the probability of > collision decreases (channel congestion decreases). > > if one looks at the maximum channel capacity at the various data burst rates > there is not a factor of 2 increase in throughput for a factor of 2 increase > in burst rate due the significant contribution of the fixed length preamble > (which dominates the transmit time at the higher burst rates for small user > payloads) and the performance improvement quickly diminishes. > > Marty Reilly > > -----Original Message----- > From: John Stine [mailto:jstine@mitre.org] > Sent: Thursday, June 06, 2002 9:30 AM > To: Sumeeth Nagaraj > Cc: Miguel Sanchez; Pei, Ke (Peak); manet@ietf.org > Subject: Re: [manet] IEEE 802.11 Broadcast? > > Sumeeth, > > Potential destinations synchronize to the transmission during the > training sequence at the beginning. Once the signal is captured there > is a potential advantage over other interfering signals. The DSSS > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > rates) which means the code is orthogonal to itself in all displaced > positions. So assuming the time of arrival of an interfering signal is > random, a good assumption since a chip with the 1 Mbs data rate > corresponds to a difference of ~28 meters propagation distance, there is > about a 10/11 chance that the codes will not align and the captured > signal will be received with a 10+ dB processing gain. When > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > processing gain is a nice feature. > > Note that the 4 data rates used in 802.11b are not equivalent. The > bandwidth for a channel is constrained to 22MHz. Increasing the data > rate to 11Mbs removes the processing gain that comes from spreading. > The higher data rates also use a different modulation. The propagation > and interference characteristics of each data rate and the interference > characteristics between data rates differ. Exploring and defining how > to model these differences would be a nice contribution if someone were > interested. I have never seen it defined anywhere and don't believe it > is adequately modeled in any of the simulation environments that I am > familiar with that are used to study ad hoc networks. > > John > > Sumeeth Nagaraj wrote: > > > > Hi all, > > > > In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not > > to some extent it will hear the other node as noise(interference). If > there > > is no chip synchronization among all the nodes( neighbors) how does > > broadcast work, Broadcast packets are meant to be sent to all the > > neighbors, if there is no chip synchronization with all the neighbors some > > of the broadcast packets could be dropped. Isn't this a problem? or am I > > missing some thing here? > > > > -Sumeeth > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 6 11:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17580 for ; Thu, 6 Jun 2002 11:11:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09936 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 11:11:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08016; Thu, 6 Jun 2002 10:41:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07987 for ; Thu, 6 Jun 2002 10:41:36 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16323 for ; Thu, 6 Jun 2002 10:41:03 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56EfPx25651; Thu, 6 Jun 2002 10:41:25 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56EfNN13450; Thu, 6 Jun 2002 10:41:23 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10473565; Thu, 06 Jun 2002 10:40:26 -0400 Message-ID: <3CFF7490.923C3DF3@mitre.org> Date: Thu, 06 Jun 2002 10:41:20 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Reilly, Martin T." CC: Sumeeth Nagaraj , Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <17B3886DFDF9D3118D7E00D0B73E9B6E42FDCF@njway201.hazeltine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Marty, Will you make your model available for others to use and consider? I did something similar for the OPNET 802.11 version 7.0.B wlan_mac process model and supporting pipeline stages but restricted it to just the 1 Mbps data rate to avoid the complexity of modeling simultaneous use of different physical layers. These models can be downloaded by OPNET users at ftp://opguest:opguest@corporate7.opnet.com/433/ It is included as part of a model of Kevin Grace's Mobile Mesh Routing Protocol. John "Reilly, Martin T." wrote: > > with respect to the modeling of a direct sequence spread spectrum modem with > a preamble I have created a very detailed model of a similar system using > Opnet. The channel access protocol is like that of 802.11 (using > RTS/CTS/Data/Ack). > > With a fixed length preamble and varying the burst rate (by factors of 2) of > the data segments for a small net (about 40 nodes all within comm's range of > each other) the overall system throughput does increase but by a factor > smaller than 2. As the data burst rate increases the probability of > collision decreases (channel congestion decreases). > > if one looks at the maximum channel capacity at the various data burst rates > there is not a factor of 2 increase in throughput for a factor of 2 increase > in burst rate due the significant contribution of the fixed length preamble > (which dominates the transmit time at the higher burst rates for small user > payloads) and the performance improvement quickly diminishes. > > Marty Reilly > > -----Original Message----- > From: John Stine [mailto:jstine@mitre.org] > Sent: Thursday, June 06, 2002 9:30 AM > To: Sumeeth Nagaraj > Cc: Miguel Sanchez; Pei, Ke (Peak); manet@ietf.org > Subject: Re: [manet] IEEE 802.11 Broadcast? > > Sumeeth, > > Potential destinations synchronize to the transmission during the > training sequence at the beginning. Once the signal is captured there > is a potential advantage over other interfering signals. The DSSS > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > rates) which means the code is orthogonal to itself in all displaced > positions. So assuming the time of arrival of an interfering signal is > random, a good assumption since a chip with the 1 Mbs data rate > corresponds to a difference of ~28 meters propagation distance, there is > about a 10/11 chance that the codes will not align and the captured > signal will be received with a 10+ dB processing gain. When > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > processing gain is a nice feature. > > Note that the 4 data rates used in 802.11b are not equivalent. The > bandwidth for a channel is constrained to 22MHz. Increasing the data > rate to 11Mbs removes the processing gain that comes from spreading. > The higher data rates also use a different modulation. The propagation > and interference characteristics of each data rate and the interference > characteristics between data rates differ. Exploring and defining how > to model these differences would be a nice contribution if someone were > interested. I have never seen it defined anywhere and don't believe it > is adequately modeled in any of the simulation environments that I am > familiar with that are used to study ad hoc networks. > > John > > Sumeeth Nagaraj wrote: > > > > Hi all, > > > > In IEEE 802.11 DCF DSSS mode, are all the nodes chip synchronized? if not > > to some extent it will hear the other node as noise(interference). If > there > > is no chip synchronization among all the nodes( neighbors) how does > > broadcast work, Broadcast packets are meant to be sent to all the > > neighbors, if there is no chip synchronization with all the neighbors some > > of the broadcast packets could be dropped. Isn't this a problem? or am I > > missing some thing here? > > > > -Sumeeth > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 19:17:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11429 for ; Thu, 6 Jun 2002 19:17:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00652; Thu, 6 Jun 2002 18:47:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00623 for ; Thu, 6 Jun 2002 18:47:17 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02594 for ; Thu, 6 Jun 2002 18:46:46 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56Irgx15406; Thu, 6 Jun 2002 14:53:42 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56IrdN13552; Thu, 6 Jun 2002 14:53:40 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10479196; Thu, 06 Jun 2002 14:52:39 -0400 Message-ID: <3CFFAFAC.42752402@mitre.org> Date: Thu, 06 Jun 2002 14:53:32 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sumeeth Nagaraj CC: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> <3CFF63ED.DC186E51@mitre.org> <010701c20d83$4d1cb8c0$8d557b81@D7KQ4P01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sumeeth, Sumeeth Nagaraj wrote: > > Hello John, > > > Potential destinations synchronize to the transmission during the > > training sequence at the beginning. Once the signal is captured there > > is a potential advantage over other interfering signals. The DSSS > > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > > rates) which means the code is orthogonal to itself in all displaced > > positions. So assuming the time of arrival of an interfering signal is > > random, a good assumption since a chip with the 1 Mbs data rate > > corresponds to a difference of ~28 meters propagation distance, there is > > about a 10/11 chance that the codes will not align and the captured > > signal will be received with a 10+ dB processing gain. When > > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > > processing gain is a nice feature. > > Potential does mean all neighbors should synchronise with the node that is > transmitting right?(The chances being low) . Suppose a node synchronises > itself to one of its neighbors and hears its other neighbor transmitting at > the same time(Since no RTS-CTS-ACK exchange takes place in broadcast), as > noise, packets are lost from one of its neighbor because of no > synchronisation with it. Since access attempts are temporally random it is unlikely two nodes will start to send packets at the same time. Say a node starts to broadcast a packet, all nodes that are within range will then try to receive it. This involves synchronizing to the chip sequence. Say all nodes within range have now synchronized and are receiving a packet and then a second node starts to transmit that was not within range of the first source. THe probability any one of the original destinations receives the first packet will depend on its local SIR characteristics. If the interfering nodes chip sequence is out of sync with the first packet transmission then the first packet will have a 10 dB SIR advantage. THe final SIR will depend on a number of factors, e.g. path loss, antenna gains, etc, of each of the transmissions. > > On the other hand, if the receiver node is synchronised with the both > transmitter's then there is collision at the receiver because of two > transmissions. Data packets are lost in both the cases either > synchronisation exists are not. The fact that a node is within range of two transmissions does not mean that it is bound not to receive either. It is likely to be synchronized to the first it receives and the probability of reception of this first packet depends on the noise offered by the second transmission. A way of looking at the processing gain is that it reduces the interference noise that the second transmission causes and thus improves the odds that the first packet will be received. > > Could this be a potential problem for network disconnectivity. If the > broadcast fails to that node for more than the some threshold(RREQ_RETRIES) > in finding routes to destination? Possibly. It really depends on many factors not just the chance that two broadcast transmissions interfere at a destination. However, the performance of access protocols and in turn routing protocols will be very sensitive to congestion (more nodes within range of each other) as these hidden node transmissions will occur more frequently. > > -Sumeeth John _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 19:17:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11437 for ; Thu, 6 Jun 2002 19:17:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04744 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 19:18:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00652; Thu, 6 Jun 2002 18:47:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00623 for ; Thu, 6 Jun 2002 18:47:17 -0400 (EDT) Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02594 for ; Thu, 6 Jun 2002 18:46:46 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g56Irgx15406; Thu, 6 Jun 2002 14:53:42 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g56IrdN13552; Thu, 6 Jun 2002 14:53:40 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.103.205) by mailhub1.mitre.org with SMTP id 10479196; Thu, 06 Jun 2002 14:52:39 -0400 Message-ID: <3CFFAFAC.42752402@mitre.org> Date: Thu, 06 Jun 2002 14:53:32 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sumeeth Nagaraj CC: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Subject: Re: [manet] IEEE 802.11 Broadcast? References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> <3CFF63ED.DC186E51@mitre.org> <010701c20d83$4d1cb8c0$8d557b81@D7KQ4P01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sumeeth, Sumeeth Nagaraj wrote: > > Hello John, > > > Potential destinations synchronize to the transmission during the > > training sequence at the beginning. Once the signal is captured there > > is a potential advantage over other interfering signals. The DSSS > > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > > rates) which means the code is orthogonal to itself in all displaced > > positions. So assuming the time of arrival of an interfering signal is > > random, a good assumption since a chip with the 1 Mbs data rate > > corresponds to a difference of ~28 meters propagation distance, there is > > about a 10/11 chance that the codes will not align and the captured > > signal will be received with a 10+ dB processing gain. When > > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > > processing gain is a nice feature. > > Potential does mean all neighbors should synchronise with the node that is > transmitting right?(The chances being low) . Suppose a node synchronises > itself to one of its neighbors and hears its other neighbor transmitting at > the same time(Since no RTS-CTS-ACK exchange takes place in broadcast), as > noise, packets are lost from one of its neighbor because of no > synchronisation with it. Since access attempts are temporally random it is unlikely two nodes will start to send packets at the same time. Say a node starts to broadcast a packet, all nodes that are within range will then try to receive it. This involves synchronizing to the chip sequence. Say all nodes within range have now synchronized and are receiving a packet and then a second node starts to transmit that was not within range of the first source. THe probability any one of the original destinations receives the first packet will depend on its local SIR characteristics. If the interfering nodes chip sequence is out of sync with the first packet transmission then the first packet will have a 10 dB SIR advantage. THe final SIR will depend on a number of factors, e.g. path loss, antenna gains, etc, of each of the transmissions. > > On the other hand, if the receiver node is synchronised with the both > transmitter's then there is collision at the receiver because of two > transmissions. Data packets are lost in both the cases either > synchronisation exists are not. The fact that a node is within range of two transmissions does not mean that it is bound not to receive either. It is likely to be synchronized to the first it receives and the probability of reception of this first packet depends on the noise offered by the second transmission. A way of looking at the processing gain is that it reduces the interference noise that the second transmission causes and thus improves the odds that the first packet will be received. > > Could this be a potential problem for network disconnectivity. If the > broadcast fails to that node for more than the some threshold(RREQ_RETRIES) > in finding routes to destination? Possibly. It really depends on many factors not just the chance that two broadcast transmissions interfere at a destination. However, the performance of access protocols and in turn routing protocols will be very sensitive to congestion (more nodes within range of each other) as these hidden node transmissions will occur more frequently. > > -Sumeeth John _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 19:20:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12151 for ; Thu, 6 Jun 2002 19:20:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01446; Thu, 6 Jun 2002 18:53:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01403 for ; Thu, 6 Jun 2002 18:53:39 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04471 for ; Thu, 6 Jun 2002 18:53:07 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22843; Thu, 6 Jun 2002 11:38:25 -0700 (PDT) Message-Id: <200206061838.LAA22843@pit.erg.sri.com> To: syoshida cc: manet@ietf.org, tsato@net.ie.niigata-u.ac.jp, asuzuki@net.ie.niigata-u.ac.jp Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] About TBRPF In-reply-to: Your message of "Thu, 06 Jun 2002 08:41:24 +0900." <20020606084124.126a9667.syoshida@net.ie.niigata-u.ac.jp> Date: Thu, 06 Jun 2002 11:38:24 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Sota, > Hi, all. > > We have tried to install TBRPF in NS2.1b8 but we have not suceeded it so far. We recently discovered that the following change is necessary to get the ns-2 code to work on Linux. Remove the following line (number 435) from the file phop_ns2.cc: delete [] d; The code has always worked on SunOS/Solaris. I hope this fix works for you. If you still have problems running TBRPF, please send me email. Richard > Our install environment is Vine Linux 2.5 (kernel ver. 2.4.18) for i386. > We read "README" file in tbrpf directry and followed the procedure written > in that file. Our procedure and problems are summarized in the following. I > appreciate if anyone could give us some suggestions. > > 1. We unpacked the TBRPF tar ball in ns-2.1b8/ and did make in > ns2.1b8/tbrpf. but make returned error. So, we added the following function > to the file priqueue.cc under directory ns-2.1b8/ and added the change of > priqueue.h. > Packet *PriQueue::filter_for_dest(nsaddr_t dest) > After that we passed through make without error. > > 2. We added the exact code to ns-2.1b8/tcl/lib/ns-lib.tcl, > ns-2.1b8/lib/ns-mobilenode.tcl and ns-2.1b8/lib/ex/wireless.tcl. > > 3. We edited Makefile and did make.(no errors) > > 4. To run a tbrpf-based simulation, but we have failed. > > > After that, we edited the wireless.tcl file to use "dsr" and execute, > but error occured. > > And Does anyone use ns to simulate TBRPF? > Would you please give us some suggestions for us to solve these problems? > > > Best regards, > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > Japan, Niigata University > Sota Yoshida > syoshida@net.ie.niigata-u.ac.jp > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 19:20:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12162 for ; Thu, 6 Jun 2002 19:20:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04901 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 19:21:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01446; Thu, 6 Jun 2002 18:53:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01403 for ; Thu, 6 Jun 2002 18:53:39 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04471 for ; Thu, 6 Jun 2002 18:53:07 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22843; Thu, 6 Jun 2002 11:38:25 -0700 (PDT) Message-Id: <200206061838.LAA22843@pit.erg.sri.com> To: syoshida cc: manet@ietf.org, tsato@net.ie.niigata-u.ac.jp, asuzuki@net.ie.niigata-u.ac.jp Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] About TBRPF In-reply-to: Your message of "Thu, 06 Jun 2002 08:41:24 +0900." <20020606084124.126a9667.syoshida@net.ie.niigata-u.ac.jp> Date: Thu, 06 Jun 2002 11:38:24 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Sota, > Hi, all. > > We have tried to install TBRPF in NS2.1b8 but we have not suceeded it so far. We recently discovered that the following change is necessary to get the ns-2 code to work on Linux. Remove the following line (number 435) from the file phop_ns2.cc: delete [] d; The code has always worked on SunOS/Solaris. I hope this fix works for you. If you still have problems running TBRPF, please send me email. Richard > Our install environment is Vine Linux 2.5 (kernel ver. 2.4.18) for i386. > We read "README" file in tbrpf directry and followed the procedure written > in that file. Our procedure and problems are summarized in the following. I > appreciate if anyone could give us some suggestions. > > 1. We unpacked the TBRPF tar ball in ns-2.1b8/ and did make in > ns2.1b8/tbrpf. but make returned error. So, we added the following function > to the file priqueue.cc under directory ns-2.1b8/ and added the change of > priqueue.h. > Packet *PriQueue::filter_for_dest(nsaddr_t dest) > After that we passed through make without error. > > 2. We added the exact code to ns-2.1b8/tcl/lib/ns-lib.tcl, > ns-2.1b8/lib/ns-mobilenode.tcl and ns-2.1b8/lib/ex/wireless.tcl. > > 3. We edited Makefile and did make.(no errors) > > 4. To run a tbrpf-based simulation, but we have failed. > > > After that, we edited the wireless.tcl file to use "dsr" and execute, > but error occured. > > And Does anyone use ns to simulate TBRPF? > Would you please give us some suggestions for us to solve these problems? > > > Best regards, > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > Japan, Niigata University > Sota Yoshida > syoshida@net.ie.niigata-u.ac.jp > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 20:35:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20367 for ; Thu, 6 Jun 2002 20:35:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08537; Thu, 6 Jun 2002 20:03:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08508 for ; Thu, 6 Jun 2002 20:03:47 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18163 for ; Thu, 6 Jun 2002 20:03:14 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA23908; Thu, 6 Jun 2002 17:01:14 -0700 (PDT) Message-Id: <200206070001.RAA23908@pit.erg.sri.com> To: manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Date: Thu, 06 Jun 2002 17:01:14 -0700 Subject: [manet] Re: IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I would like to announce that our lawyer has submitted an updated IPR statement for TBRPF to the IETF, which is given below. This statement has two main changes: 1. If TBRPF becomes a standard, *all* portions of TBRPF that are explicitly specified (including optional portions indicated by MAY or SHOULD) can be used by anyone royalty-free (in addition to all required portions, whether explicity specified or not). This is even more generous than the W3C royalty-free patent policy: http://www.w3.org/TR/2002/WD-patent-policy-20020226/ which states that only *required* portions of a recommendation need to be royalty-free. 2. While it is being considered by the IETF, TBRPF can be used by anyone for research purposes. This second change was requested by Joe Macker at the last IETF meeting. ----------------------- 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 ------------------------ SRI IPR Statement for 'draft-ietf-manet-tbrpf-05.txt': ***************************************************** SRI International has filed one or more patents protecting the inventions described in this submission (the "Patents"). If SRI's submission, or material portions thereof, is accepted and becomes part of the IETF standard (the "Standard"), then SRI will grant any entity wishing to practice the Standard a non-exclusive, royalty-free license under the Patents to the extent, but only to the extent, that such license is required to implement (a) mandatory elements of the Standard; or (b) elements of SRI's submission that are explicitly specified (and not merely incorporated by reference) in the Standard. Use of any elements of SRI's submission that are neither required in order to implement the Standard nor explicitly specified in the Standard will require an additional license from SRI under terms to be negotiated between the parties. While the protocol disclosed in SRI's submission is being evaluated by the IETF, whether on the standards track or otherwise, SRI will and hereby does grant any party a license to utilize, test and evaluate such protocol solely for non-commercial, research purposes. Richard Abramson Vice President Legal and Business Affairs and General Counsel SRI International _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 20:35:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20377 for ; Thu, 6 Jun 2002 20:35:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA10769 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 20:36:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08537; Thu, 6 Jun 2002 20:03:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08508 for ; Thu, 6 Jun 2002 20:03:47 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18163 for ; Thu, 6 Jun 2002 20:03:14 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA23908; Thu, 6 Jun 2002 17:01:14 -0700 (PDT) Message-Id: <200206070001.RAA23908@pit.erg.sri.com> To: manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Date: Thu, 06 Jun 2002 17:01:14 -0700 Subject: [manet] Re: IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I would like to announce that our lawyer has submitted an updated IPR statement for TBRPF to the IETF, which is given below. This statement has two main changes: 1. If TBRPF becomes a standard, *all* portions of TBRPF that are explicitly specified (including optional portions indicated by MAY or SHOULD) can be used by anyone royalty-free (in addition to all required portions, whether explicity specified or not). This is even more generous than the W3C royalty-free patent policy: http://www.w3.org/TR/2002/WD-patent-policy-20020226/ which states that only *required* portions of a recommendation need to be royalty-free. 2. While it is being considered by the IETF, TBRPF can be used by anyone for research purposes. This second change was requested by Joe Macker at the last IETF meeting. ----------------------- 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 ------------------------ SRI IPR Statement for 'draft-ietf-manet-tbrpf-05.txt': ***************************************************** SRI International has filed one or more patents protecting the inventions described in this submission (the "Patents"). If SRI's submission, or material portions thereof, is accepted and becomes part of the IETF standard (the "Standard"), then SRI will grant any entity wishing to practice the Standard a non-exclusive, royalty-free license under the Patents to the extent, but only to the extent, that such license is required to implement (a) mandatory elements of the Standard; or (b) elements of SRI's submission that are explicitly specified (and not merely incorporated by reference) in the Standard. Use of any elements of SRI's submission that are neither required in order to implement the Standard nor explicitly specified in the Standard will require an additional license from SRI under terms to be negotiated between the parties. While the protocol disclosed in SRI's submission is being evaluated by the IETF, whether on the standards track or otherwise, SRI will and hereby does grant any party a license to utilize, test and evaluate such protocol solely for non-commercial, research purposes. Richard Abramson Vice President Legal and Business Affairs and General Counsel SRI International _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 6 20:53:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21435 for ; Thu, 6 Jun 2002 20:53:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09564; Thu, 6 Jun 2002 20:23:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09532 for ; Thu, 6 Jun 2002 20:23:38 -0400 (EDT) Received: from barney.usu.edu (barney.usu.edu [129.123.1.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19479 for ; Thu, 6 Jun 2002 20:23:08 -0400 (EDT) Received: from D7KQ4P01 ("port 2079"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39375) with SMTP id <01KILY8VSTUMA3CMPX@cc.usu.edu> for manet@ietf.org; Thu, 6 Jun 2002 11:51:47 MDT Date: Thu, 06 Jun 2002 11:55:10 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] IEEE 802.11 Broadcast? To: John Stine Cc: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Message-id: <010701c20d83$4d1cb8c0$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> <3CFF63ED.DC186E51@mitre.org> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello John, > Potential destinations synchronize to the transmission during the > training sequence at the beginning. Once the signal is captured there > is a potential advantage over other interfering signals. The DSSS > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > rates) which means the code is orthogonal to itself in all displaced > positions. So assuming the time of arrival of an interfering signal is > random, a good assumption since a chip with the 1 Mbs data rate > corresponds to a difference of ~28 meters propagation distance, there is > about a 10/11 chance that the codes will not align and the captured > signal will be received with a 10+ dB processing gain. When > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > processing gain is a nice feature. Potential does mean all neighbors should synchronise with the node that is transmitting right?(The chances being low) . Suppose a node synchronises itself to one of its neighbors and hears its other neighbor transmitting at the same time(Since no RTS-CTS-ACK exchange takes place in broadcast), as noise, packets are lost from one of its neighbor because of no synchronisation with it. On the other hand, if the receiver node is synchronised with the both transmitter's then there is collision at the receiver because of two transmissions. Data packets are lost in both the cases either synchronisation exists are not. Could this be a potential problem for network disconnectivity. If the broadcast fails to that node for more than the some threshold(RREQ_RETRIES) in finding routes to destination? -Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 6 20:53:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21445 for ; Thu, 6 Jun 2002 20:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11756 for manet-archive@odin.ietf.org; Thu, 6 Jun 2002 20:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09564; Thu, 6 Jun 2002 20:23:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09532 for ; Thu, 6 Jun 2002 20:23:38 -0400 (EDT) Received: from barney.usu.edu (barney.usu.edu [129.123.1.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19479 for ; Thu, 6 Jun 2002 20:23:08 -0400 (EDT) Received: from D7KQ4P01 ("port 2079"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39375) with SMTP id <01KILY8VSTUMA3CMPX@cc.usu.edu> for manet@ietf.org; Thu, 6 Jun 2002 11:51:47 MDT Date: Thu, 06 Jun 2002 11:55:10 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] IEEE 802.11 Broadcast? To: John Stine Cc: Miguel Sanchez , "Pei, Ke (Peak)" , manet@ietf.org Message-id: <010701c20d83$4d1cb8c0$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <31C0F08B0D18D511ACC800508BAE7B47019B8459@CI0026EXCH001U> <3CFF17F0.4020202@ieee.org> <00d701c20d3d$e7262c80$8d557b81@D7KQ4P01> <3CFF63ED.DC186E51@mitre.org> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello John, > Potential destinations synchronize to the transmission during the > training sequence at the beginning. Once the signal is captured there > is a potential advantage over other interfering signals. The DSSS > spreading code is a 11 bit Barker sequence (when using 1 Mbs and 2 Mbs > rates) which means the code is orthogonal to itself in all displaced > positions. So assuming the time of arrival of an interfering signal is > random, a good assumption since a chip with the 1 Mbs data rate > corresponds to a difference of ~28 meters propagation distance, there is > about a 10/11 chance that the codes will not align and the captured > signal will be received with a 10+ dB processing gain. When > broadcasting in 802.11, the RTS-CTS exchange is disabled so you have a > pure CSMA-CA protocol that does not prevent hidden nodes. Thus, this > processing gain is a nice feature. Potential does mean all neighbors should synchronise with the node that is transmitting right?(The chances being low) . Suppose a node synchronises itself to one of its neighbors and hears its other neighbor transmitting at the same time(Since no RTS-CTS-ACK exchange takes place in broadcast), as noise, packets are lost from one of its neighbor because of no synchronisation with it. On the other hand, if the receiver node is synchronised with the both transmitter's then there is collision at the receiver because of two transmissions. Data packets are lost in both the cases either synchronisation exists are not. Could this be a potential problem for network disconnectivity. If the broadcast fails to that node for more than the some threshold(RREQ_RETRIES) in finding routes to destination? -Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 7 13:44:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05373 for ; Fri, 7 Jun 2002 13:44:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19568; Fri, 7 Jun 2002 13:12:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19492 for ; Fri, 7 Jun 2002 13:11:57 -0400 (EDT) Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04363; Fri, 7 Jun 2002 13:11:21 -0400 (EDT) From: sunghyun.choi@philips.com Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA06719; Fri, 7 Jun 2002 12:11:03 -0500 (CDT) (envelope-from sunghyun.choi@philips.com) Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma006714; Fri, 7 Jun 02 12:11:04 -0500 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA25596; Fri, 7 Jun 2002 12:11:02 -0500 (CDT) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.79]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA22942; Fri, 7 Jun 2002 12:10:59 -0500 (CDT) To: Yu-Ching Hsu Cc: manet@ietf.org, manet-admin@ietf.org Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 7 Jun 2002 13:11:25 -0400 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 07/06/2002 12:11:29, Serialize complete at 07/06/2002 12:11:29 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EC66285256BD1_=" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multipart message in MIME format. --=_alternative 005EC66285256BD1_= Content-Type: text/plain; charset="us-ascii" HI Yu-Ching, You are right. Within infrastructure BSS, a station cannot send a frame to another station directly. As far as I understand, 802.11 Working Group decided not to support that mode in order to maximize the utility of the power saving capability. However, the emerging 802.11e MAC (for QoS) will allow such direct station-to-station transmission. Sunghyun ------------ Sunghyun Choi, Ph.D. Senior Member Research Staff WiCAN - Wireless Communications and Networking Department Philips Research USA, Briarcliff Manor, New York, USA Tel: (914) 945 6506 Fax: (914) 945 6580 E-mail: sunghyun.choi@philips.com URL 1: http://www.philabs.research.philips.com/~szc - Philips internal URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage ** My opinions do not necessarily reflect those of my employer ** Yu-Ching Hsu Sent by: manet-admin@ietf.org 06/06/2002 01:18 AM To: manet@ietf.org cc: (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS) Subject: [manet] 802.11: infrastructure mode and adhoc mode Classification: Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --=_alternative 005EC66285256BD1_= Content-Type: text/html; charset="us-ascii"
HI Yu-Ching,

You are right. Within infrastructure BSS,
a station cannot send a frame to another station directly.
As far as I understand, 802.11 Working Group decided not to support
that mode in order to maximize the utility of the power saving
capability.
However, the emerging 802.11e MAC (for QoS)
will allow such direct station-to-station transmission.

Sunghyun

------------
Sunghyun Choi, Ph.D.
Senior Member Research Staff
WiCAN - Wireless Communications and Networking Department
Philips Research USA, Briarcliff Manor, New York, USA
Tel: (914) 945 6506    Fax: (914) 945 6580
E-mail: sunghyun.choi@philips.com
URL 1: http://www.philabs.research.philips.com/~szc - Philips internal
URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage
** My opinions do not necessarily reflect those of my employer **


Yu-Ching Hsu <gis86806@cis.nctu.edu.tw>
Sent by: manet-admin@ietf.org

06/06/2002 01:18 AM

       
        To:        manet@ietf.org
        cc:        (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS)
        Subject:        [manet] 802.11: infrastructure mode and adhoc mode

        Classification:        




Dear all,
 I have an interesting question regarding the IEEE 802.11b products.
Does anyone know why stations cannot opperate in the hybrid mode, i.e.
infrastructure + ad-hoc. For example, in the following scenario, why
sta1 cannot send to sta2 directly?


                            AP1
                           /   \
                          /     \
                         /       \
                      sta1 ---- sta2



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

--=_alternative 005EC66285256BD1_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 7 14:43:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05383 for ; Fri, 7 Jun 2002 13:44:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18548 for manet-archive@odin.ietf.org; Fri, 7 Jun 2002 13:44:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19568; Fri, 7 Jun 2002 13:12:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19492 for ; Fri, 7 Jun 2002 13:11:57 -0400 (EDT) Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04363; Fri, 7 Jun 2002 13:11:21 -0400 (EDT) From: sunghyun.choi@philips.com Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA06719; Fri, 7 Jun 2002 12:11:03 -0500 (CDT) (envelope-from sunghyun.choi@philips.com) Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma006714; Fri, 7 Jun 02 12:11:04 -0500 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA25596; Fri, 7 Jun 2002 12:11:02 -0500 (CDT) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.79]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA22942; Fri, 7 Jun 2002 12:10:59 -0500 (CDT) To: Yu-Ching Hsu Cc: manet@ietf.org, manet-admin@ietf.org Subject: Re: [manet] 802.11: infrastructure mode and adhoc mode X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 7 Jun 2002 13:11:25 -0400 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 07/06/2002 12:11:29, Serialize complete at 07/06/2002 12:11:29 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EC66285256BD1_=" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multipart message in MIME format. --=_alternative 005EC66285256BD1_= Content-Type: text/plain; charset="us-ascii" HI Yu-Ching, You are right. Within infrastructure BSS, a station cannot send a frame to another station directly. As far as I understand, 802.11 Working Group decided not to support that mode in order to maximize the utility of the power saving capability. However, the emerging 802.11e MAC (for QoS) will allow such direct station-to-station transmission. Sunghyun ------------ Sunghyun Choi, Ph.D. Senior Member Research Staff WiCAN - Wireless Communications and Networking Department Philips Research USA, Briarcliff Manor, New York, USA Tel: (914) 945 6506 Fax: (914) 945 6580 E-mail: sunghyun.choi@philips.com URL 1: http://www.philabs.research.philips.com/~szc - Philips internal URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage ** My opinions do not necessarily reflect those of my employer ** Yu-Ching Hsu Sent by: manet-admin@ietf.org 06/06/2002 01:18 AM To: manet@ietf.org cc: (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS) Subject: [manet] 802.11: infrastructure mode and adhoc mode Classification: Dear all, I have an interesting question regarding the IEEE 802.11b products. Does anyone know why stations cannot opperate in the hybrid mode, i.e. infrastructure + ad-hoc. For example, in the following scenario, why sta1 cannot send to sta2 directly? AP1 / \ / \ / \ sta1 ---- sta2 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --=_alternative 005EC66285256BD1_= Content-Type: text/html; charset="us-ascii"
HI Yu-Ching,

You are right. Within infrastructure BSS,
a station cannot send a frame to another station directly.
As far as I understand, 802.11 Working Group decided not to support
that mode in order to maximize the utility of the power saving
capability.
However, the emerging 802.11e MAC (for QoS)
will allow such direct station-to-station transmission.

Sunghyun

------------
Sunghyun Choi, Ph.D.
Senior Member Research Staff
WiCAN - Wireless Communications and Networking Department
Philips Research USA, Briarcliff Manor, New York, USA
Tel: (914) 945 6506    Fax: (914) 945 6580
E-mail: sunghyun.choi@philips.com
URL 1: http://www.philabs.research.philips.com/~szc - Philips internal
URL 2: http://www.eecs.umich.edu/~shchoi - Personal Homepage
** My opinions do not necessarily reflect those of my employer **


Yu-Ching Hsu <gis86806@cis.nctu.edu.tw>
Sent by: manet-admin@ietf.org

06/06/2002 01:18 AM

       
        To:        manet@ietf.org
        cc:        (bcc: Sunghyun Choi/BRQ/RESEARCH/PHILIPS)
        Subject:        [manet] 802.11: infrastructure mode and adhoc mode

        Classification:        




Dear all,
 I have an interesting question regarding the IEEE 802.11b products.
Does anyone know why stations cannot opperate in the hybrid mode, i.e.
infrastructure + ad-hoc. For example, in the following scenario, why
sta1 cannot send to sta2 directly?


                            AP1
                           /   \
                          /     \
                         /       \
                      sta1 ---- sta2



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

--=_alternative 005EC66285256BD1_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 14 12:51:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06108 for ; Fri, 14 Jun 2002 12:51:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22736; Fri, 14 Jun 2002 12:34:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22707 for ; Fri, 14 Jun 2002 12:33:57 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05528 for ; Fri, 14 Jun 2002 12:33:21 -0400 (EDT) Received: (qmail 26422 invoked from network); 14 Jun 2002 16:33:56 -0000 Received: from pc-024.diku.dk (130.225.97.24) by hugin.diku.dk with QMQP; 14 Jun 2002 16:33:56 -0000 To: manet@ietf.org From: Jacob Hansen Date: 14 Jun 2002 18:33:55 +0200 Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] DSR implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I was wondering if anyone had gotten the DSR implementation for Linux called "Piconet II" (sourceforge.net/projects/piconet) working. It was done by Alex Song. ping between nodes works fine. FTP can connect, I can log in and list the direcotry contents - but the minute I try to transfer a 2KB file nothing happens!! Tcpdump reports a number of very strange looking packets. I am not able to reproduce these packets with the netfilter hooks (either pre route or post route). Anyone knows where in the netfilter chain, tcpdump views it's packets? Regards, Jacob -- Jacob Hansen. U of Copenhagen, Dept. of Computer Science e-mail : luffe@diku.dk _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 14 12:51:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06119 for ; Fri, 14 Jun 2002 12:51:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23858 for manet-archive@odin.ietf.org; Fri, 14 Jun 2002 12:52:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22736; Fri, 14 Jun 2002 12:34:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22707 for ; Fri, 14 Jun 2002 12:33:57 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05528 for ; Fri, 14 Jun 2002 12:33:21 -0400 (EDT) Received: (qmail 26422 invoked from network); 14 Jun 2002 16:33:56 -0000 Received: from pc-024.diku.dk (130.225.97.24) by hugin.diku.dk with QMQP; 14 Jun 2002 16:33:56 -0000 To: manet@ietf.org From: Jacob Hansen Date: 14 Jun 2002 18:33:55 +0200 Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] DSR implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I was wondering if anyone had gotten the DSR implementation for Linux called "Piconet II" (sourceforge.net/projects/piconet) working. It was done by Alex Song. ping between nodes works fine. FTP can connect, I can log in and list the direcotry contents - but the minute I try to transfer a 2KB file nothing happens!! Tcpdump reports a number of very strange looking packets. I am not able to reproduce these packets with the netfilter hooks (either pre route or post route). Anyone knows where in the netfilter chain, tcpdump views it's packets? Regards, Jacob -- Jacob Hansen. U of Copenhagen, Dept. of Computer Science e-mail : luffe@diku.dk _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 12:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09037 for ; Mon, 17 Jun 2002 12:04:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21601; Mon, 17 Jun 2002 11:26:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21575 for ; Mon, 17 Jun 2002 11:26:27 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07489 for ; Mon, 17 Jun 2002 11:25:45 -0400 (EDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g5HFQOj147129 for ; Mon, 17 Jun 2002 11:26:24 -0400 (EDT) Received: from ecpe15 ([208.17.194.151]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ADV44280; Mon, 17 Jun 2002 11:26:22 -0400 (EDT) Message-ID: <004c01c21613$55515b20$97c211d0@ecpe15> Reply-To: "Vikram Dham" From: "Vikram Dham" To: Date: Mon, 17 Jun 2002 11:26:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C215F1.CE1F88F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [manet] Asymmetric link Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C215F1.CE1F88F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, What is meant by asymmetric link in context of 802.11 mac protocol ? I = was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ? Tia , Vikram Dham ------=_NextPart_000_0049_01C215F1.CE1F88F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All,
 
What is meant by asymmetric link in context of 802.11 mac protocol = ? I was=20 thinking that all 802.11 packets require ack, so how is 802.11 supported = in=20 asymmetric links ?
 
Tia ,
 
Vikram Dham
 
 
------=_NextPart_000_0049_01C215F1.CE1F88F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 12:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09048 for ; Mon, 17 Jun 2002 12:04:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25744 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 12:05:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21601; Mon, 17 Jun 2002 11:26:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21575 for ; Mon, 17 Jun 2002 11:26:27 -0400 (EDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07489 for ; Mon, 17 Jun 2002 11:25:45 -0400 (EDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g5HFQOj147129 for ; Mon, 17 Jun 2002 11:26:24 -0400 (EDT) Received: from ecpe15 ([208.17.194.151]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ADV44280; Mon, 17 Jun 2002 11:26:22 -0400 (EDT) Message-ID: <004c01c21613$55515b20$97c211d0@ecpe15> Reply-To: "Vikram Dham" From: "Vikram Dham" To: Date: Mon, 17 Jun 2002 11:26:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C215F1.CE1F88F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [manet] Asymmetric link Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C215F1.CE1F88F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, What is meant by asymmetric link in context of 802.11 mac protocol ? I = was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ? Tia , Vikram Dham ------=_NextPart_000_0049_01C215F1.CE1F88F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All,
 
What is meant by asymmetric link in context of 802.11 mac protocol = ? I was=20 thinking that all 802.11 packets require ack, so how is 802.11 supported = in=20 asymmetric links ?
 
Tia ,
 
Vikram Dham
 
 
------=_NextPart_000_0049_01C215F1.CE1F88F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 12:32:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10314 for ; Mon, 17 Jun 2002 12:32:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26125; Mon, 17 Jun 2002 12:10:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26097 for ; Mon, 17 Jun 2002 12:10:30 -0400 (EDT) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09277 for ; Mon, 17 Jun 2002 12:09:52 -0400 (EDT) Received: from moment.cs.ucsb.edu ([128.111.40.94]) by mail.engr.ucsb.edu with esmtp (Exim 3.36 #1) id 17Jz5K-0005FT-00; Mon, 17 Jun 2002 09:10:30 -0700 Received: from mesa (moment [128.111.40.94]) by moment.cs.ucsb.edu (8.11.6/8.11.6) with ESMTP id g5HGBSn26577; Mon, 17 Jun 2002 09:11:29 -0700 From: "Ian Chakeres" To: "'Vikram Dham'" , Subject: RE: [manet] Asymmetric link Date: Mon, 17 Jun 2002 09:10:27 -0700 Message-ID: <000801c21619$7f422530$6401a8c0@cs.ucsb.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C215DE.D2E34D30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <004c01c21613$55515b20$97c211d0@ecpe15> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C215DE.D2E34D30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Broadcast packets do not require acks and therefore may be unidirectional. Ian Chakeres -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Vikram Dham Sent: Monday, June 17, 2002 8:26 AM To: manet@ietf.org Subject: [manet] Asymmetric link Dear All, What is meant by asymmetric link in context of 802.11 mac protocol ? I was thinking that all 802.11 packets require ack, so how is 802.11 supported in asymmetric links ? Tia , Vikram Dham ------=_NextPart_000_0009_01C215DE.D2E34D30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Broadcast packets do not require = acks and therefore may be unidirectional.

 

Ian Chakeres

 

-----Original Message-----
From: = manet-admin@ietf.org [mailto:manet-admin@ietf.org] On = Behalf Of Vikram Dham
Sent: Monday, June 17, = 2002 8:26 AM
To: manet@ietf.org
Subject: [manet] = Asymmetric link

 

Dear All,

 

What is meant by asymmetric link in context of 802.11 mac = protocol ? I was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ?

 

Tia ,

 

Vikram Dham

 

 

------=_NextPart_000_0009_01C215DE.D2E34D30-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 12:32:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10326 for ; Mon, 17 Jun 2002 12:32:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28417 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 12:33:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26125; Mon, 17 Jun 2002 12:10:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26097 for ; Mon, 17 Jun 2002 12:10:30 -0400 (EDT) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09277 for ; Mon, 17 Jun 2002 12:09:52 -0400 (EDT) Received: from moment.cs.ucsb.edu ([128.111.40.94]) by mail.engr.ucsb.edu with esmtp (Exim 3.36 #1) id 17Jz5K-0005FT-00; Mon, 17 Jun 2002 09:10:30 -0700 Received: from mesa (moment [128.111.40.94]) by moment.cs.ucsb.edu (8.11.6/8.11.6) with ESMTP id g5HGBSn26577; Mon, 17 Jun 2002 09:11:29 -0700 From: "Ian Chakeres" To: "'Vikram Dham'" , Subject: RE: [manet] Asymmetric link Date: Mon, 17 Jun 2002 09:10:27 -0700 Message-ID: <000801c21619$7f422530$6401a8c0@cs.ucsb.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C215DE.D2E34D30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <004c01c21613$55515b20$97c211d0@ecpe15> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C215DE.D2E34D30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Broadcast packets do not require acks and therefore may be unidirectional. Ian Chakeres -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Vikram Dham Sent: Monday, June 17, 2002 8:26 AM To: manet@ietf.org Subject: [manet] Asymmetric link Dear All, What is meant by asymmetric link in context of 802.11 mac protocol ? I was thinking that all 802.11 packets require ack, so how is 802.11 supported in asymmetric links ? Tia , Vikram Dham ------=_NextPart_000_0009_01C215DE.D2E34D30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Broadcast packets do not require = acks and therefore may be unidirectional.

 

Ian Chakeres

 

-----Original Message-----
From: = manet-admin@ietf.org [mailto:manet-admin@ietf.org] On = Behalf Of Vikram Dham
Sent: Monday, June 17, = 2002 8:26 AM
To: manet@ietf.org
Subject: [manet] = Asymmetric link

 

Dear All,

 

What is meant by asymmetric link in context of 802.11 mac = protocol ? I was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ?

 

Tia ,

 

Vikram Dham

 

 

------=_NextPart_000_0009_01C215DE.D2E34D30-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 13:41:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13125 for ; Mon, 17 Jun 2002 13:41:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29444; Mon, 17 Jun 2002 12:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29404 for ; Mon, 17 Jun 2002 12:49:34 -0400 (EDT) Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11025 for ; Mon, 17 Jun 2002 12:48:55 -0400 (EDT) Received: from D7KQ4P01 ("port 3520"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39089) with SMTP id <01KJ199E55CW927XEW@cc.usu.edu> for manet@ietf.org; Mon, 17 Jun 2002 10:49:26 MDT Date: Mon, 17 Jun 2002 10:52:52 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] Asymmetric link To: Vikram Dham , manet@ietf.org Message-id: <027b01c2161f$6bb92c10$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="----=_NextPart_000_0278_01C215ED.21065210" X-Priority: 3 X-MSMail-priority: Normal References: <004c01c21613$55515b20$97c211d0@ecpe15> Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0278_01C215ED.21065210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vikram,=20 Asymmetric links or uni-directional links are created in most cases by = the range of the transmitter or if a receiver is under heavy = interference from other sources nearing it. you can think of it being = created if you are using any transmitter power control algorithms that = could possibly create an uni directional link. I don't think even the CTS reaches the destination in case of Uni = directional links. If I am right, a node *A* could possibly Jam a = communication between nodes *B* and *C* if *A* has not heard RTS/ CTS = because of uni directional links. Let me know If I am missing something.=20 Regards, Sumeeth What is meant by asymmetric link in context of 802.11 mac protocol ? I = was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ? ------=_NextPart_000_0278_01C215ED.21065210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Vikram,
 
Asymmetric links or = uni-directional=20 links  are created in most cases by the range of the transmitter or = if a=20 receiver is under heavy interference from other sources nearing it. = you can=20 think of it being created if you are using any transmitter power control = algorithms that could possibly create an uni directional = link.
 
 I don't think even the CTS = reaches the=20 destination in case of Uni directional links. If I am right, a node *A* = could=20 possibly Jam a communication between nodes *B* and *C*  if *A* = has not=20 heard RTS/ CTS because of uni directional links.
 
Let me know If I am missing something.=20

Regards,
Sumeeth
 
What is meant by asymmetric link in context of 802.11 mac = protocol ? I=20 was thinking that all 802.11 packets require ack, so how is 802.11 = supported=20 in asymmetric links ?
 
------=_NextPart_000_0278_01C215ED.21065210-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 14:39:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13133 for ; Mon, 17 Jun 2002 13:41:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02528 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 13:41:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29444; Mon, 17 Jun 2002 12:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29404 for ; Mon, 17 Jun 2002 12:49:34 -0400 (EDT) Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11025 for ; Mon, 17 Jun 2002 12:48:55 -0400 (EDT) Received: from D7KQ4P01 ("port 3520"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39089) with SMTP id <01KJ199E55CW927XEW@cc.usu.edu> for manet@ietf.org; Mon, 17 Jun 2002 10:49:26 MDT Date: Mon, 17 Jun 2002 10:52:52 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] Asymmetric link To: Vikram Dham , manet@ietf.org Message-id: <027b01c2161f$6bb92c10$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="----=_NextPart_000_0278_01C215ED.21065210" X-Priority: 3 X-MSMail-priority: Normal References: <004c01c21613$55515b20$97c211d0@ecpe15> Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0278_01C215ED.21065210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vikram,=20 Asymmetric links or uni-directional links are created in most cases by = the range of the transmitter or if a receiver is under heavy = interference from other sources nearing it. you can think of it being = created if you are using any transmitter power control algorithms that = could possibly create an uni directional link. I don't think even the CTS reaches the destination in case of Uni = directional links. If I am right, a node *A* could possibly Jam a = communication between nodes *B* and *C* if *A* has not heard RTS/ CTS = because of uni directional links. Let me know If I am missing something.=20 Regards, Sumeeth What is meant by asymmetric link in context of 802.11 mac protocol ? I = was thinking that all 802.11 packets require ack, so how is 802.11 = supported in asymmetric links ? ------=_NextPart_000_0278_01C215ED.21065210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Vikram,
 
Asymmetric links or = uni-directional=20 links  are created in most cases by the range of the transmitter or = if a=20 receiver is under heavy interference from other sources nearing it. = you can=20 think of it being created if you are using any transmitter power control = algorithms that could possibly create an uni directional = link.
 
 I don't think even the CTS = reaches the=20 destination in case of Uni directional links. If I am right, a node *A* = could=20 possibly Jam a communication between nodes *B* and *C*  if *A* = has not=20 heard RTS/ CTS because of uni directional links.
 
Let me know If I am missing something.=20

Regards,
Sumeeth
 
What is meant by asymmetric link in context of 802.11 mac = protocol ? I=20 was thinking that all 802.11 packets require ack, so how is 802.11 = supported=20 in asymmetric links ?
 
------=_NextPart_000_0278_01C215ED.21065210-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 19:14:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23180 for ; Mon, 17 Jun 2002 19:14:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20002; Mon, 17 Jun 2002 18:34:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00060 for ; Thu, 23 May 2002 03:35:54 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29258 for ; Thu, 23 May 2002 03:35:33 -0400 (EDT) Received: (qmail 26136 invoked by uid 0); 23 May 2002 07:35:18 -0000 Received: from pd952471d.dip.t-dialin.net (HELO gmx.de) (217.82.71.29) by mail.gmx.net (mp016-rz3) with SMTP; 23 May 2002 07:35:18 -0000 Message-ID: <3CEC9C50.7000705@gmx.de> Date: Thu, 23 May 2002 09:37:52 +0200 From: Stefan Ribhegge User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: de-DE MIME-Version: 1.0 To: bluez-users@lists.sourceforge.net, bluetooth-dev@axis.com, manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] diploma thesis: Voice over Bluetooth based MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Last month I finished my diploma thesis. Topic was "Voice over Bluetooth base multihop Ad-Hoc Networks". It's written in german. If somebody is interested he can download it under http://ribhegge.gmxhome.de Some feedback would be nice. Stefan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 19:14:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23190 for ; Mon, 17 Jun 2002 19:14:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23480 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 19:15:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20002; Mon, 17 Jun 2002 18:34:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00060 for ; Thu, 23 May 2002 03:35:54 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29258 for ; Thu, 23 May 2002 03:35:33 -0400 (EDT) Received: (qmail 26136 invoked by uid 0); 23 May 2002 07:35:18 -0000 Received: from pd952471d.dip.t-dialin.net (HELO gmx.de) (217.82.71.29) by mail.gmx.net (mp016-rz3) with SMTP; 23 May 2002 07:35:18 -0000 Message-ID: <3CEC9C50.7000705@gmx.de> Date: Thu, 23 May 2002 09:37:52 +0200 From: Stefan Ribhegge User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: de-DE MIME-Version: 1.0 To: bluez-users@lists.sourceforge.net, bluetooth-dev@axis.com, manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] diploma thesis: Voice over Bluetooth based MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Last month I finished my diploma thesis. Topic was "Voice over Bluetooth base multihop Ad-Hoc Networks". It's written in german. If somebody is interested he can download it under http://ribhegge.gmxhome.de Some feedback would be nice. Stefan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 19:14:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23210 for ; Mon, 17 Jun 2002 19:14:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20515; Mon, 17 Jun 2002 18:43:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05903 for ; Fri, 24 May 2002 08:03:34 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24626 for ; Fri, 24 May 2002 08:03:12 -0400 (EDT) Received: from prokofiev.inria.fr (prokofiev.inria.fr [128.93.17.51]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g4OC2tf08888; Fri, 24 May 2002 14:02:55 +0200 (MET DST) Message-Id: <200205241202.g4OC2tf08888@nez-perce.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: zb Cc: Paul.Muhlethaler@inria.fr, manet@ietf.org Subject: Re: [manet] ad hoc network of HiPERLAN2? In-Reply-To: Your message of "Fri, 24 May 2002 08:59:17 +0900." <002001c202b5$d9aac9e0$5d2d024b@zbin> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 24 May 2002 14:02:21 +0200 From: Paul Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA05904 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit The architecture of HiPERLAN 2 is the architecture of an access network. The usual scenario is a mobile node accessing to a wired network through the air. The mobile node is attached to a master HiPERLAN 2 node called Central Controler (CC) the equivalent of the IEEE 802.11 access point. The CC acts like a bridge with the wired network, HiPERLAN 2 specifies connexion with various usual networks (Ethernet, Frame Relay, ATM, 1394 ...) HiPERLAN 2 uses a centralized access ruled by the CC. The CC defines a framing in which HiPERLAN 2 nodes are invited to send packets (actually they have previously send a request to the CC). In the normal mode a packet from an attached node is always sent to the CC which relays the packet (possibly through the air to another HiPERLAN 2 node). HiPERLAN 2 also defines an ad-hoc mode in which 2 HiPERLAN nodes attached to the same CC can directly exchanges packets (packets are not forwarded by the CC) but the CC is still controlling the transmission through the framing which is not the case in IEEE 802.11b in the DCF mode. Both usual mode and adhoc mode of HiPERLAN type 2 are much closer to the PCF mode of IEEE 802.11 than the DCF mode. I have the feeling that the HiPERLAN 2 adhoc mode is not suitable for multihop networks. Paul Muhlethaler zbin@samsung.com said: > hi,     Can anybody tell any paper on the ad hoc network of HyperLAN2? > Is there any difference between the ad hoc network of HyperLAN2 and > 802.11b?   regards   bin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 19:14:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23219 for ; Mon, 17 Jun 2002 19:14:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23494 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 19:15:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20515; Mon, 17 Jun 2002 18:43:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05903 for ; Fri, 24 May 2002 08:03:34 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24626 for ; Fri, 24 May 2002 08:03:12 -0400 (EDT) Received: from prokofiev.inria.fr (prokofiev.inria.fr [128.93.17.51]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g4OC2tf08888; Fri, 24 May 2002 14:02:55 +0200 (MET DST) Message-Id: <200205241202.g4OC2tf08888@nez-perce.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: zb Cc: Paul.Muhlethaler@inria.fr, manet@ietf.org Subject: Re: [manet] ad hoc network of HiPERLAN2? In-Reply-To: Your message of "Fri, 24 May 2002 08:59:17 +0900." <002001c202b5$d9aac9e0$5d2d024b@zbin> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 24 May 2002 14:02:21 +0200 From: Paul Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA05904 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit The architecture of HiPERLAN 2 is the architecture of an access network. The usual scenario is a mobile node accessing to a wired network through the air. The mobile node is attached to a master HiPERLAN 2 node called Central Controler (CC) the equivalent of the IEEE 802.11 access point. The CC acts like a bridge with the wired network, HiPERLAN 2 specifies connexion with various usual networks (Ethernet, Frame Relay, ATM, 1394 ...) HiPERLAN 2 uses a centralized access ruled by the CC. The CC defines a framing in which HiPERLAN 2 nodes are invited to send packets (actually they have previously send a request to the CC). In the normal mode a packet from an attached node is always sent to the CC which relays the packet (possibly through the air to another HiPERLAN 2 node). HiPERLAN 2 also defines an ad-hoc mode in which 2 HiPERLAN nodes attached to the same CC can directly exchanges packets (packets are not forwarded by the CC) but the CC is still controlling the transmission through the framing which is not the case in IEEE 802.11b in the DCF mode. Both usual mode and adhoc mode of HiPERLAN type 2 are much closer to the PCF mode of IEEE 802.11 than the DCF mode. I have the feeling that the HiPERLAN 2 adhoc mode is not suitable for multihop networks. Paul Muhlethaler zbin@samsung.com said: > hi,     Can anybody tell any paper on the ad hoc network of HyperLAN2? > Is there any difference between the ad hoc network of HyperLAN2 and > 802.11b?   regards   bin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 17 19:15:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23301 for ; Mon, 17 Jun 2002 19:15:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19617; Mon, 17 Jun 2002 18:31:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19586 for ; Mon, 17 Jun 2002 18:31:29 -0400 (EDT) Received: from ece.ufl.edu (dot.ece.ufl.edu [128.227.220.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21849 for ; Mon, 17 Jun 2002 18:30:51 -0400 (EDT) Received: (qmail 4006 invoked from network); 17 Jun 2002 22:28:45 -0000 Received: from fang.ece.ufl.edu (128.227.80.157) by dot.ece.ufl.edu with SMTP; 17 Jun 2002 22:28:45 -0000 Received: (from fang@localhost) by fang.ece.ufl.edu (8.9.3/8.9.3) id SAA21857; Mon, 17 Jun 2002 18:29:06 -0400 (EDT) X-Authentication-Warning: fang.ece.ufl.edu: Processed from queue /home/faculty/fang/mqueue X-Authentication-Warning: fang.ece.ufl.edu: Processed by fang with -C /home/faculty/fang/bin/sendmail.cf Date: Mon, 17 Jun 2002 18:29:06 -0400 From: Yuguang Fang To: manet@ietf.org Cc: Yuguang Fang Message-ID: <20020617182906.B21835@ece.ufl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Subject: [manet] ACM MobiCom Student Travel Awards Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear Colleagues We apologize if you have received multiple copies. Could you please pass the message to your students or students you know who may be interested in attending ACM MobiCom'2002 held in Atlanta, Georgia? Thank you for your help. Best Regards, Michael Fang and Violet R. Syrotiuk Student Travel Award Co-Chairs, ACM MobiCom'2002 %%%%Applications for Student Travel Support The 2002 ACM SIGMOBILE International Conference on on Mobile Computing and Networking (MobiCom 2002), will be held in Atlanta, Georgia, from September 23--26, 2002. This conference is the premier technical meeting dedicated to addressing new challenges in mobile computing and networking. Our goal is to assist United States-based graduate students to attend this meeting. We anticipate that we will be able to reimburse up to $750 to each award recipient, to cover travel, lodging and meals. The conference registration fees for award recipients will be generously covered by ACM SIGMOBILE. Participation in conferences such as MobiCom is an extremely important part of the graduate school experience, providing the opportunity to interact with more senior researchers and be exposed to leading edge work in the field. Our goal is to enable the participation of students who would otherwise be unable to attend MobiCom 2002. An application for a travel award will consist of the student's vita, a letter from the student, and a letter from the student's advisor. The letter from the student should include: 1.a brief summary of research interests and accomplishments to date; 2.a description of areas reflected in the MobiCom 2002 program that would impact the student's research; and 3.why the conference attendance is important to the student. In addition, the student's advisor should send a letter of recommendation to the committee, that includes: 1.confirmation that the student is a Ph.D. candidate in good standing; 2.the suitability of the MobiCom program material to the student's research area; 3.ways this particular student would benefit from attendance at the conference; and 4.the strengths and potential contributions of the student. Applications for the travel award should be sent electronically to Dr. Violet R. Syrotiuk (syrotiuk@utdallas.edu) to be received by midnight of Friday, July 19, 2002. The recipients of the travel awards will be decided by a committee co-chaired by Dr. Violet R. Syrotiuk (University of Texas at Dallas) and Dr. Yuguang (Michael) Fang (University of Florida at Gainesville), with Dr. Victor Bahl (Microsoft Research and Chair of SIGMOBILE) also serving. The awards will be announced by Friday, August 2, 2002. Recipients will be required to accept the award by Friday, August 9, 2002, so that alternates can be notified in the event that a recipient declines. -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Yuguang "Michael" Fang, Ph.D Assistant Professor Department of Electrical and Computer Engineering University of Florida 435 Engineering Building, P.O.Box 116130 Gainesville, FL 32611 Tel: (352) 846-3043, Fax: (352) 392-0044 Email: fang@ece.ufl.edu, http://www.fang.ece.ufl.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 17 19:15:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23311 for ; Mon, 17 Jun 2002 19:15:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23565 for manet-archive@odin.ietf.org; Mon, 17 Jun 2002 19:16:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19617; Mon, 17 Jun 2002 18:31:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19586 for ; Mon, 17 Jun 2002 18:31:29 -0400 (EDT) Received: from ece.ufl.edu (dot.ece.ufl.edu [128.227.220.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21849 for ; Mon, 17 Jun 2002 18:30:51 -0400 (EDT) Received: (qmail 4006 invoked from network); 17 Jun 2002 22:28:45 -0000 Received: from fang.ece.ufl.edu (128.227.80.157) by dot.ece.ufl.edu with SMTP; 17 Jun 2002 22:28:45 -0000 Received: (from fang@localhost) by fang.ece.ufl.edu (8.9.3/8.9.3) id SAA21857; Mon, 17 Jun 2002 18:29:06 -0400 (EDT) X-Authentication-Warning: fang.ece.ufl.edu: Processed from queue /home/faculty/fang/mqueue X-Authentication-Warning: fang.ece.ufl.edu: Processed by fang with -C /home/faculty/fang/bin/sendmail.cf Date: Mon, 17 Jun 2002 18:29:06 -0400 From: Yuguang Fang To: manet@ietf.org Cc: Yuguang Fang Message-ID: <20020617182906.B21835@ece.ufl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Subject: [manet] ACM MobiCom Student Travel Awards Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear Colleagues We apologize if you have received multiple copies. Could you please pass the message to your students or students you know who may be interested in attending ACM MobiCom'2002 held in Atlanta, Georgia? Thank you for your help. Best Regards, Michael Fang and Violet R. Syrotiuk Student Travel Award Co-Chairs, ACM MobiCom'2002 %%%%Applications for Student Travel Support The 2002 ACM SIGMOBILE International Conference on on Mobile Computing and Networking (MobiCom 2002), will be held in Atlanta, Georgia, from September 23--26, 2002. This conference is the premier technical meeting dedicated to addressing new challenges in mobile computing and networking. Our goal is to assist United States-based graduate students to attend this meeting. We anticipate that we will be able to reimburse up to $750 to each award recipient, to cover travel, lodging and meals. The conference registration fees for award recipients will be generously covered by ACM SIGMOBILE. Participation in conferences such as MobiCom is an extremely important part of the graduate school experience, providing the opportunity to interact with more senior researchers and be exposed to leading edge work in the field. Our goal is to enable the participation of students who would otherwise be unable to attend MobiCom 2002. An application for a travel award will consist of the student's vita, a letter from the student, and a letter from the student's advisor. The letter from the student should include: 1.a brief summary of research interests and accomplishments to date; 2.a description of areas reflected in the MobiCom 2002 program that would impact the student's research; and 3.why the conference attendance is important to the student. In addition, the student's advisor should send a letter of recommendation to the committee, that includes: 1.confirmation that the student is a Ph.D. candidate in good standing; 2.the suitability of the MobiCom program material to the student's research area; 3.ways this particular student would benefit from attendance at the conference; and 4.the strengths and potential contributions of the student. Applications for the travel award should be sent electronically to Dr. Violet R. Syrotiuk (syrotiuk@utdallas.edu) to be received by midnight of Friday, July 19, 2002. The recipients of the travel awards will be decided by a committee co-chaired by Dr. Violet R. Syrotiuk (University of Texas at Dallas) and Dr. Yuguang (Michael) Fang (University of Florida at Gainesville), with Dr. Victor Bahl (Microsoft Research and Chair of SIGMOBILE) also serving. The awards will be announced by Friday, August 2, 2002. Recipients will be required to accept the award by Friday, August 9, 2002, so that alternates can be notified in the event that a recipient declines. -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Yuguang "Michael" Fang, Ph.D Assistant Professor Department of Electrical and Computer Engineering University of Florida 435 Engineering Building, P.O.Box 116130 Gainesville, FL 32611 Tel: (352) 846-3043, Fax: (352) 392-0044 Email: fang@ece.ufl.edu, http://www.fang.ece.ufl.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 18 02:30:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08469 for ; Tue, 18 Jun 2002 02:30:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18798; Tue, 18 Jun 2002 02:03:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18770 for ; Tue, 18 Jun 2002 02:03:39 -0400 (EDT) Received: from oldmoon.mt.lv (root@[159.148.147.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03498 for ; Tue, 18 Jun 2002 02:02:58 -0400 (EDT) Received: from laptop.mt.lv ([10.5.15.61]) by oldmoon.mt.lv (8.9.3/8.9.3) with ESMTP id IAA30787; Tue, 18 Jun 2002 08:03:34 +0200 Message-Id: <5.1.1.6.0.20020618090244.0168eca0@mail.mt.lv> X-Sender: tully@mail.mt.lv X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 18 Jun 2002 09:03:32 +0300 To: manet@ietf.org From: John Tully Cc: ogier@erg.sri.com, Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] SRI patent issuce Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I have been following the patent issue on SRI's TBRPF. Speedcom Wireless has announced that it has an exclusive license to implement SRI's "Packet Hop" which I understand is the same as TBRPF. The license is for fixed wireless networks. This action makes it appear that it could be impossible for them to comply with the statements they have made in their draft RFC. Maybe someone from their side can clear this up. John From SEC filing: http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-006934.txt ============================ In January 2001, SPEEDCOM acquired worldwide rights for six years to PacketHop(TM), a wireless routing software developed by SRI International (SRI). Under the terms of the agreement, SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed wireless infrastructure market for the primary frequencies below 6 GHz. Per the agreement, SRI International received a total of 325,000 shares of common stock of SPEEDCOM that was issued in four traunches. Each traunch was measured on the specific date that the stock was issued on. As of March 31, 2002, the value of these shares at the date of grant is classified in Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 in cash, included in Intellectual property on the balance sheet, which is being amortized over six years. Per the terms of the agreement, SRI may terminate the exclusive period (18 months) by providing written notice of such termination unless by such time SPEEDCOM has successfully closed a liquid event where SRI had the opportunity to obtain net proceeds of at least $5,000,000. Due to the fact that such an event has not occurred, it is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) in July 2002, but will retain its perpetual license agreement. SPEEDCOM has evaluated this long-lived asset for impairment by comparing the discounted expected future cash flows to its carrying amount. The undiscounted expected future cash flows are more than the carrying value of the asset, so an impairment loss has not been recognized. --------------------------------------------------------- At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Jun 18 02:30:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08476 for ; Tue, 18 Jun 2002 02:30:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20480 for manet-archive@odin.ietf.org; Tue, 18 Jun 2002 02:31:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18798; Tue, 18 Jun 2002 02:03:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18770 for ; Tue, 18 Jun 2002 02:03:39 -0400 (EDT) Received: from oldmoon.mt.lv (root@[159.148.147.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03498 for ; Tue, 18 Jun 2002 02:02:58 -0400 (EDT) Received: from laptop.mt.lv ([10.5.15.61]) by oldmoon.mt.lv (8.9.3/8.9.3) with ESMTP id IAA30787; Tue, 18 Jun 2002 08:03:34 +0200 Message-Id: <5.1.1.6.0.20020618090244.0168eca0@mail.mt.lv> X-Sender: tully@mail.mt.lv X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 18 Jun 2002 09:03:32 +0300 To: manet@ietf.org From: John Tully Cc: ogier@erg.sri.com, Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] SRI patent issuce Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I have been following the patent issue on SRI's TBRPF. Speedcom Wireless has announced that it has an exclusive license to implement SRI's "Packet Hop" which I understand is the same as TBRPF. The license is for fixed wireless networks. This action makes it appear that it could be impossible for them to comply with the statements they have made in their draft RFC. Maybe someone from their side can clear this up. John From SEC filing: http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-006934.txt ============================ In January 2001, SPEEDCOM acquired worldwide rights for six years to PacketHop(TM), a wireless routing software developed by SRI International (SRI). Under the terms of the agreement, SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed wireless infrastructure market for the primary frequencies below 6 GHz. Per the agreement, SRI International received a total of 325,000 shares of common stock of SPEEDCOM that was issued in four traunches. Each traunch was measured on the specific date that the stock was issued on. As of March 31, 2002, the value of these shares at the date of grant is classified in Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 in cash, included in Intellectual property on the balance sheet, which is being amortized over six years. Per the terms of the agreement, SRI may terminate the exclusive period (18 months) by providing written notice of such termination unless by such time SPEEDCOM has successfully closed a liquid event where SRI had the opportunity to obtain net proceeds of at least $5,000,000. Due to the fact that such an event has not occurred, it is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) in July 2002, but will retain its perpetual license agreement. SPEEDCOM has evaluated this long-lived asset for impairment by comparing the discounted expected future cash flows to its carrying amount. The undiscounted expected future cash flows are more than the carrying value of the asset, so an impairment loss has not been recognized. --------------------------------------------------------- At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 18 13:49:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28270 for ; Tue, 18 Jun 2002 13:49:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01034; Tue, 18 Jun 2002 13:25:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00969 for ; Tue, 18 Jun 2002 13:25:15 -0400 (EDT) Received: from mailhost2.malibunetworks.com (malibunetworks.com [158.222.96.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27309 for ; Tue, 18 Jun 2002 13:24:35 -0400 (EDT) Received: by mailhost2.malibunetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 10:27:06 -0700 Message-ID: <337F6EC31C8FD3119A10009027D63D874AD83B@mailhost2.malibunetworks.com> From: Ken Peirce To: "'John Tully'" , manet@ietf.org Cc: ogier@erg.sri.com, Fred Baker Subject: RE: [manet] SRI patent issuce Date: Tue, 18 Jun 2002 10:27:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C216ED.5C6BE3F0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C216ED.5C6BE3F0 Content-Type: text/plain John, I do not speak for SRI, however I spoke with Richard Ogier on this release a while back. My understanding is that there are no issues. The Speedcom software is older stuff and the exclusive agreement does not cover the current protocol. Cheers, Ken -----Original Message----- From: John Tully [mailto:tully@mt.lv] Sent: Monday, June 17, 2002 11:04 PM To: manet@ietf.org Cc: ogier@erg.sri.com; Fred Baker Subject: [manet] SRI patent issuce Hello, I have been following the patent issue on SRI's TBRPF. Speedcom Wireless has announced that it has an exclusive license to implement SRI's "Packet Hop" which I understand is the same as TBRPF. The license is for fixed wireless networks. This action makes it appear that it could be impossible for them to comply with the statements they have made in their draft RFC. Maybe someone from their side can clear this up. John From SEC filing: http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-006934.txt ============================ In January 2001, SPEEDCOM acquired worldwide rights for six years to PacketHop(TM), a wireless routing software developed by SRI International (SRI). Under the terms of the agreement, SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed wireless infrastructure market for the primary frequencies below 6 GHz. Per the agreement, SRI International received a total of 325,000 shares of common stock of SPEEDCOM that was issued in four traunches. Each traunch was measured on the specific date that the stock was issued on. As of March 31, 2002, the value of these shares at the date of grant is classified in Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 in cash, included in Intellectual property on the balance sheet, which is being amortized over six years. Per the terms of the agreement, SRI may terminate the exclusive period (18 months) by providing written notice of such termination unless by such time SPEEDCOM has successfully closed a liquid event where SRI had the opportunity to obtain net proceeds of at least $5,000,000. Due to the fact that such an event has not occurred, it is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) in July 2002, but will retain its perpetual license agreement. SPEEDCOM has evaluated this long-lived asset for impairment by comparing the discounted expected future cash flows to its carrying amount. The undiscounted expected future cash flows are more than the carrying value of the asset, so an impairment loss has not been recognized. --------------------------------------------------------- At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C216ED.5C6BE3F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [manet] SRI patent issuce

John,
        I do not = speak for SRI, however I spoke with Richard Ogier on this release a = while back. My understanding is that there are no issues. The Speedcom = software is older stuff and the exclusive agreement does not cover the = current protocol.

Cheers,
Ken

-----Original Message-----
From: John Tully [mailto:tully@mt.lv]
Sent: Monday, June 17, 2002 11:04 PM
To: manet@ietf.org
Cc: ogier@erg.sri.com; Fred Baker
Subject: [manet] SRI patent issuce


Hello,

I have been following the patent issue on SRI's = TBRPF.

Speedcom Wireless has announced that it has an = exclusive license to
implement SRI's "Packet Hop" which I = understand is the same as TBRPF.  The
license is for fixed wireless networks.  This = action makes it appear that
it could be impossible for them to comply with the = statements they have
made in their draft RFC.

Maybe someone from their side can clear this = up.

John

 From SEC filing:
http://www.sec.gov/Archives/edgar/data/1014343/0001021= 40802006934/0001021408-02-006934.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D In January 2001, SPEEDCOM acquired worldwide =
rights for six years to PacketHop(TM), a wireless = routing software
developed by SRI International (SRI). Under the = terms of the agreement,
SPEEDCOM obtains rights to SRI's PacketHop(TM) = technology in the fixed
wireless infrastructure market for the primary = frequencies below 6 GHz. Per
the agreement, SRI International received a total of = 325,000 shares of
common stock of SPEEDCOM that was issued in four = traunches. Each traunch
was measured on the specific date that the stock was = issued on. As of March
31, 2002, the value of these shares at the date of = grant is classified in
Intellectual property on the balance sheet. SPEEDCOM = also has paid $360,000
in cash, included in Intellectual property on the = balance sheet, which is
being amortized over six years. Per the terms of the = agreement, SRI may
terminate the exclusive period (18 months) by = providing written notice of
such termination unless by such time SPEEDCOM has = successfully closed a
liquid event where SRI had the opportunity to obtain = net proceeds of at
least $5,000,000. Due to the fact that such an event = has not occurred, it
is expected that SPEEDCOM will lose its exclusive = rights to PacketHop(TM)
in July 2002, but will retain its perpetual license = agreement. SPEEDCOM has
evaluated this long-lived asset for impairment by = comparing the discounted
expected future cash flows to its carrying amount. = The undiscounted
expected future cash flows are more than the = carrying value of the asset,
so an impairment loss has not been = recognized.

---------------------------------------------------------
At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com = wrote:

Fred,

 > My observation is my own, nobody else's, = but it comes from someone
 > who has been watching the IETF for a = *long* time. If you want to
 > guarantee a > scramble, say the word = "patent", and if you want to
 > guarantee that the IETF > will proceed = in a direction only under
 > duress, apply for one.

Let me quote a sentence from "A Novice's Guide = to the IETF"
http://www.imc.org/novice-ietf.html

"Sometimes, the patent holder is generous and = promises to give all
implementors of a standard a royalty-free license to = the patent,
thereby making it almost as easy to implement as it = would have been
if no patent existed."

That is exactly what SRI is doing. Our IPR statement = contains the
following sentence: "If SRI's submission (or = portions thereof) is
accepted and becomes part of the IETF standard, then = SRI will grant
any party a royalty-free license under such patents = for both
commercial and non-commercial uses, to the extent = necessary for
compliance with the standard."

Also note that ISATAP (in the NGTRANS WG) has exactly = the same IPR
statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt

This issue has been discussed previously on this = list, e.g., see
Ken Peirce's message dated 12/13/01.  Also, in = a recent email from
Ken to you (Ken, you can chime in if you want), he = pointed out that
the patent (if awarded) is actually a *bonus* to = TBRPF implementors,
since SRI will give all implementors a royalty-free = license if
TBRPF becomes a standard.  As Ken noted (and = our lawyer agrees),
in addition to guaranteeing that TBRPF will be = unencumbered, it also
provides some protection to TBRPF implementors from = 3rd party
infringement lawsuits.

In your response to Ken, you stated that it is very = unlikely that our
lawyers will let us concede our rights to = TBPRF.  This is not true.
In fact our lawyers are the ones who wrote the IPR = statement.

Our lawyers are currently updating the IPR statement = to clarify that
anyone can implement TBRPF for non-commercial = research purposes while
TBRPF is being considered by the IETF, as requested = by Joe Macker.
(The updated statement will be submitted to the IETF = in a few days.)

Now, if OLSR and TBRPF turn out to be equally good = protocols for
proactive routing in MANETs, then it would make = sense to select the
one that has no IPRs.  But *so far*, TBRPF has = outperformed OLSR
significantly in our simulations (and has other = advantages that
I have previously discussed).  These = simulations are based
on the OLSR code that is available from the INRIA = web site, which
has been outdated for several months (according to = Clausen's
message dated 11/29/01), so I hope that newer OLSR = code will
be available soon.

Richard

P.S. For reference, here is the excerpt from
draft-baker-manet-review-01.txt that I think is = unfair:

   "SRI has aggressively marketed = TBRPF and
   its IPRs to the working group.  = The fact that a patent has been
   applied for on certain aspects is, = however, severely limiting
   politically.  If there is any way = in which the IETF is absolutely
   predictable, it is that when confronted = with a choice between a
   proposal encumbered with IPR issues and = an unencumbered proposal, it
   will choose the unencumbered = one."


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C216ED.5C6BE3F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 18 13:49:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28287 for ; Tue, 18 Jun 2002 13:49:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02775 for manet-archive@odin.ietf.org; Tue, 18 Jun 2002 13:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01034; Tue, 18 Jun 2002 13:25:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00969 for ; Tue, 18 Jun 2002 13:25:15 -0400 (EDT) Received: from mailhost2.malibunetworks.com (malibunetworks.com [158.222.96.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27309 for ; Tue, 18 Jun 2002 13:24:35 -0400 (EDT) Received: by mailhost2.malibunetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 10:27:06 -0700 Message-ID: <337F6EC31C8FD3119A10009027D63D874AD83B@mailhost2.malibunetworks.com> From: Ken Peirce To: "'John Tully'" , manet@ietf.org Cc: ogier@erg.sri.com, Fred Baker Subject: RE: [manet] SRI patent issuce Date: Tue, 18 Jun 2002 10:27:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C216ED.5C6BE3F0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C216ED.5C6BE3F0 Content-Type: text/plain John, I do not speak for SRI, however I spoke with Richard Ogier on this release a while back. My understanding is that there are no issues. The Speedcom software is older stuff and the exclusive agreement does not cover the current protocol. Cheers, Ken -----Original Message----- From: John Tully [mailto:tully@mt.lv] Sent: Monday, June 17, 2002 11:04 PM To: manet@ietf.org Cc: ogier@erg.sri.com; Fred Baker Subject: [manet] SRI patent issuce Hello, I have been following the patent issue on SRI's TBRPF. Speedcom Wireless has announced that it has an exclusive license to implement SRI's "Packet Hop" which I understand is the same as TBRPF. The license is for fixed wireless networks. This action makes it appear that it could be impossible for them to comply with the statements they have made in their draft RFC. Maybe someone from their side can clear this up. John From SEC filing: http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-006934.txt ============================ In January 2001, SPEEDCOM acquired worldwide rights for six years to PacketHop(TM), a wireless routing software developed by SRI International (SRI). Under the terms of the agreement, SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed wireless infrastructure market for the primary frequencies below 6 GHz. Per the agreement, SRI International received a total of 325,000 shares of common stock of SPEEDCOM that was issued in four traunches. Each traunch was measured on the specific date that the stock was issued on. As of March 31, 2002, the value of these shares at the date of grant is classified in Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 in cash, included in Intellectual property on the balance sheet, which is being amortized over six years. Per the terms of the agreement, SRI may terminate the exclusive period (18 months) by providing written notice of such termination unless by such time SPEEDCOM has successfully closed a liquid event where SRI had the opportunity to obtain net proceeds of at least $5,000,000. Due to the fact that such an event has not occurred, it is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) in July 2002, but will retain its perpetual license agreement. SPEEDCOM has evaluated this long-lived asset for impairment by comparing the discounted expected future cash flows to its carrying amount. The undiscounted expected future cash flows are more than the carrying value of the asset, so an impairment loss has not been recognized. --------------------------------------------------------- At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: Fred, > My observation is my own, nobody else's, but it comes from someone > who has been watching the IETF for a *long* time. If you want to > guarantee a > scramble, say the word "patent", and if you want to > guarantee that the IETF > will proceed in a direction only under > duress, apply for one. Let me quote a sentence from "A Novice's Guide to the IETF" http://www.imc.org/novice-ietf.html "Sometimes, the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed." That is exactly what SRI is doing. Our IPR statement contains the following sentence: "If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant any party a royalty-free license under such patents for both commercial and non-commercial uses, to the extent necessary for compliance with the standard." Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt This issue has been discussed previously on this list, e.g., see Ken Peirce's message dated 12/13/01. Also, in a recent email from Ken to you (Ken, you can chime in if you want), he pointed out that the patent (if awarded) is actually a *bonus* to TBRPF implementors, since SRI will give all implementors a royalty-free license if TBRPF becomes a standard. As Ken noted (and our lawyer agrees), in addition to guaranteeing that TBRPF will be unencumbered, it also provides some protection to TBRPF implementors from 3rd party infringement lawsuits. In your response to Ken, you stated that it is very unlikely that our lawyers will let us concede our rights to TBPRF. This is not true. In fact our lawyers are the ones who wrote the IPR statement. Our lawyers are currently updating the IPR statement to clarify that anyone can implement TBRPF for non-commercial research purposes while TBRPF is being considered by the IETF, as requested by Joe Macker. (The updated statement will be submitted to the IETF in a few days.) Now, if OLSR and TBRPF turn out to be equally good protocols for proactive routing in MANETs, then it would make sense to select the one that has no IPRs. But *so far*, TBRPF has outperformed OLSR significantly in our simulations (and has other advantages that I have previously discussed). These simulations are based on the OLSR code that is available from the INRIA web site, which has been outdated for several months (according to Clausen's message dated 11/29/01), so I hope that newer OLSR code will be available soon. Richard P.S. For reference, here is the excerpt from draft-baker-manet-review-01.txt that I think is unfair: "SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one." _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C216ED.5C6BE3F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [manet] SRI patent issuce

John,
        I do not = speak for SRI, however I spoke with Richard Ogier on this release a = while back. My understanding is that there are no issues. The Speedcom = software is older stuff and the exclusive agreement does not cover the = current protocol.

Cheers,
Ken

-----Original Message-----
From: John Tully [mailto:tully@mt.lv]
Sent: Monday, June 17, 2002 11:04 PM
To: manet@ietf.org
Cc: ogier@erg.sri.com; Fred Baker
Subject: [manet] SRI patent issuce


Hello,

I have been following the patent issue on SRI's = TBRPF.

Speedcom Wireless has announced that it has an = exclusive license to
implement SRI's "Packet Hop" which I = understand is the same as TBRPF.  The
license is for fixed wireless networks.  This = action makes it appear that
it could be impossible for them to comply with the = statements they have
made in their draft RFC.

Maybe someone from their side can clear this = up.

John

 From SEC filing:
http://www.sec.gov/Archives/edgar/data/1014343/0001021= 40802006934/0001021408-02-006934.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D In January 2001, SPEEDCOM acquired worldwide =
rights for six years to PacketHop(TM), a wireless = routing software
developed by SRI International (SRI). Under the = terms of the agreement,
SPEEDCOM obtains rights to SRI's PacketHop(TM) = technology in the fixed
wireless infrastructure market for the primary = frequencies below 6 GHz. Per
the agreement, SRI International received a total of = 325,000 shares of
common stock of SPEEDCOM that was issued in four = traunches. Each traunch
was measured on the specific date that the stock was = issued on. As of March
31, 2002, the value of these shares at the date of = grant is classified in
Intellectual property on the balance sheet. SPEEDCOM = also has paid $360,000
in cash, included in Intellectual property on the = balance sheet, which is
being amortized over six years. Per the terms of the = agreement, SRI may
terminate the exclusive period (18 months) by = providing written notice of
such termination unless by such time SPEEDCOM has = successfully closed a
liquid event where SRI had the opportunity to obtain = net proceeds of at
least $5,000,000. Due to the fact that such an event = has not occurred, it
is expected that SPEEDCOM will lose its exclusive = rights to PacketHop(TM)
in July 2002, but will retain its perpetual license = agreement. SPEEDCOM has
evaluated this long-lived asset for impairment by = comparing the discounted
expected future cash flows to its carrying amount. = The undiscounted
expected future cash flows are more than the = carrying value of the asset,
so an impairment loss has not been = recognized.

---------------------------------------------------------
At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com = wrote:

Fred,

 > My observation is my own, nobody else's, = but it comes from someone
 > who has been watching the IETF for a = *long* time. If you want to
 > guarantee a > scramble, say the word = "patent", and if you want to
 > guarantee that the IETF > will proceed = in a direction only under
 > duress, apply for one.

Let me quote a sentence from "A Novice's Guide = to the IETF"
http://www.imc.org/novice-ietf.html

"Sometimes, the patent holder is generous and = promises to give all
implementors of a standard a royalty-free license to = the patent,
thereby making it almost as easy to implement as it = would have been
if no patent existed."

That is exactly what SRI is doing. Our IPR statement = contains the
following sentence: "If SRI's submission (or = portions thereof) is
accepted and becomes part of the IETF standard, then = SRI will grant
any party a royalty-free license under such patents = for both
commercial and non-commercial uses, to the extent = necessary for
compliance with the standard."

Also note that ISATAP (in the NGTRANS WG) has exactly = the same IPR
statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt

This issue has been discussed previously on this = list, e.g., see
Ken Peirce's message dated 12/13/01.  Also, in = a recent email from
Ken to you (Ken, you can chime in if you want), he = pointed out that
the patent (if awarded) is actually a *bonus* to = TBRPF implementors,
since SRI will give all implementors a royalty-free = license if
TBRPF becomes a standard.  As Ken noted (and = our lawyer agrees),
in addition to guaranteeing that TBRPF will be = unencumbered, it also
provides some protection to TBRPF implementors from = 3rd party
infringement lawsuits.

In your response to Ken, you stated that it is very = unlikely that our
lawyers will let us concede our rights to = TBPRF.  This is not true.
In fact our lawyers are the ones who wrote the IPR = statement.

Our lawyers are currently updating the IPR statement = to clarify that
anyone can implement TBRPF for non-commercial = research purposes while
TBRPF is being considered by the IETF, as requested = by Joe Macker.
(The updated statement will be submitted to the IETF = in a few days.)

Now, if OLSR and TBRPF turn out to be equally good = protocols for
proactive routing in MANETs, then it would make = sense to select the
one that has no IPRs.  But *so far*, TBRPF has = outperformed OLSR
significantly in our simulations (and has other = advantages that
I have previously discussed).  These = simulations are based
on the OLSR code that is available from the INRIA = web site, which
has been outdated for several months (according to = Clausen's
message dated 11/29/01), so I hope that newer OLSR = code will
be available soon.

Richard

P.S. For reference, here is the excerpt from
draft-baker-manet-review-01.txt that I think is = unfair:

   "SRI has aggressively marketed = TBRPF and
   its IPRs to the working group.  = The fact that a patent has been
   applied for on certain aspects is, = however, severely limiting
   politically.  If there is any way = in which the IETF is absolutely
   predictable, it is that when confronted = with a choice between a
   proposal encumbered with IPR issues and = an unencumbered proposal, it
   will choose the unencumbered = one."


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C216ED.5C6BE3F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 03:32:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09977 for ; Wed, 19 Jun 2002 03:32:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05253; Wed, 19 Jun 2002 03:19:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05216 for ; Wed, 19 Jun 2002 03:19:38 -0400 (EDT) Received: from hotmail.com (f37.law12.hotmail.com [64.4.19.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09736 for ; Wed, 19 Jun 2002 03:18:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Jun 2002 00:19:06 -0700 Received: from 212.4.33.133 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 19 Jun 2002 07:19:06 GMT X-Originating-IP: [212.4.33.133] From: "Berner Vegge" To: manet@ietf.org Date: Wed, 19 Jun 2002 09:19:06 +0200 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 19 Jun 2002 07:19:06.0559 (UTC) FILETIME=[98FA1CF0:01C21761] Subject: [manet] Ad-Hoc compared to TETRA Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org



Hello!
I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI.

As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. TETRA uses a
GSM alike principle with switches and base stations, while Ad-Hoc uses
nodes that are combined routers and terminals (no base stations).
But although the technique is different the features seem to be very much the same with security, priority, group calls etc.
  • From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to TETRA are.
    Can anyone help me?

Thanks for your help!

Best Regards Berner

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 03:32:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09992 for ; Wed, 19 Jun 2002 03:32:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06271 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 03:33:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05253; Wed, 19 Jun 2002 03:19:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05216 for ; Wed, 19 Jun 2002 03:19:38 -0400 (EDT) Received: from hotmail.com (f37.law12.hotmail.com [64.4.19.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09736 for ; Wed, 19 Jun 2002 03:18:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Jun 2002 00:19:06 -0700 Received: from 212.4.33.133 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 19 Jun 2002 07:19:06 GMT X-Originating-IP: [212.4.33.133] From: "Berner Vegge" To: manet@ietf.org Date: Wed, 19 Jun 2002 09:19:06 +0200 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 19 Jun 2002 07:19:06.0559 (UTC) FILETIME=[98FA1CF0:01C21761] Subject: [manet] Ad-Hoc compared to TETRA Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org



Hello!
I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI.

As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. TETRA uses a
GSM alike principle with switches and base stations, while Ad-Hoc uses
nodes that are combined routers and terminals (no base stations).
But although the technique is different the features seem to be very much the same with security, priority, group calls etc.
  • From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to TETRA are.
    Can anyone help me?

Thanks for your help!

Best Regards Berner

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 04:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11237 for ; Wed, 19 Jun 2002 04:58:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09610; Wed, 19 Jun 2002 04:38:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09581 for ; Wed, 19 Jun 2002 04:38:37 -0400 (EDT) Received: from cvis153.mail.marconicomms.com (cvis153.marconicomms.com [128.87.251.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10941 for ; Wed, 19 Jun 2002 04:37:58 -0400 (EDT) Received: from cvis05.marconicomms.com (unverified) by cvis155.mail.marconicomms.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Wed, 19 Jun 2002 09:08:24 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-36) id g5J88MB07269; Wed, 19 Jun 2002 09:08:22 +0100 (BST) Subject: Re: [manet] Ad-Hoc compared to TETRA To: bernervegge@hotmail.com Cc: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Vincenzo Cipolla" Date: Wed, 19 Jun 2002 10:05:18 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 19/06/2002 09:08:18 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Berner, My personal feeling is that the Tetra Technology could be one the most suitable and real working technology to implement Ad-Hoc Networks, specially if we look the promising ETSI TETRA Release 2, currently under standardisation. If you want to explore the TETRA Technology I suggest to compare the TETRA Release 1 Direct Mode(DMO) operation against of the paradigms of the Ad-Hoc Network Technology. I'm sure that you will realise that this part of the TETRA standard could be a way to implement Ad-Hoc Networks. BR, Vincenzo Cipolla ************************************************************** Vincenzo Cipolla Marconi Mobile Private Mobile Networks SBU Software Development Director Wireless Software Competence Centre Galleria G.B. Gerace, 7 56124 Pisa - Italy Tel +39 (0) 50 3132421 (my office) Tel. +39 (0) 50 3132420(Secretary's Office) Fax. +39 (0) 50 3132431 (my office) Mobile Phone +39 (0) 335 7198283 http://www.marconi.com ************************************************************** "Berner Vegge" @ietf.org on 19/06/2002 09.19.06 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 04:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11246 for ; Wed, 19 Jun 2002 04:58:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA10529 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 04:59:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09610; Wed, 19 Jun 2002 04:38:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09581 for ; Wed, 19 Jun 2002 04:38:37 -0400 (EDT) Received: from cvis153.mail.marconicomms.com (cvis153.marconicomms.com [128.87.251.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10941 for ; Wed, 19 Jun 2002 04:37:58 -0400 (EDT) Received: from cvis05.marconicomms.com (unverified) by cvis155.mail.marconicomms.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Wed, 19 Jun 2002 09:08:24 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-36) id g5J88MB07269; Wed, 19 Jun 2002 09:08:22 +0100 (BST) Subject: Re: [manet] Ad-Hoc compared to TETRA To: bernervegge@hotmail.com Cc: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Vincenzo Cipolla" Date: Wed, 19 Jun 2002 10:05:18 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 19/06/2002 09:08:18 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Berner, My personal feeling is that the Tetra Technology could be one the most suitable and real working technology to implement Ad-Hoc Networks, specially if we look the promising ETSI TETRA Release 2, currently under standardisation. If you want to explore the TETRA Technology I suggest to compare the TETRA Release 1 Direct Mode(DMO) operation against of the paradigms of the Ad-Hoc Network Technology. I'm sure that you will realise that this part of the TETRA standard could be a way to implement Ad-Hoc Networks. BR, Vincenzo Cipolla ************************************************************** Vincenzo Cipolla Marconi Mobile Private Mobile Networks SBU Software Development Director Wireless Software Competence Centre Galleria G.B. Gerace, 7 56124 Pisa - Italy Tel +39 (0) 50 3132421 (my office) Tel. +39 (0) 50 3132420(Secretary's Office) Fax. +39 (0) 50 3132431 (my office) Mobile Phone +39 (0) 335 7198283 http://www.marconi.com ************************************************************** "Berner Vegge" @ietf.org on 19/06/2002 09.19.06 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 05:24:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11570 for ; Wed, 19 Jun 2002 05:24:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11350; Wed, 19 Jun 2002 05:12:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11318 for ; Wed, 19 Jun 2002 05:12:32 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11392 for ; Wed, 19 Jun 2002 05:11:52 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g5J9Bwj22736; Wed, 19 Jun 2002 11:11:58 +0200 (MET DST) Message-ID: <004301c21774$8011f1a0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Berner Vegge" , References: Subject: Re: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:34:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C21785.434FFD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C21785.434FFD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and = ambulance. It is based on a base station architecture like GSM and = provides similar low throughput. MANET is a mobile network based on = multihop routing but is not dedicated to specific applications. Since = the hop distance can be small, ad hoc architecture is suitable for high = speed data transfer such as in IEEE 802.11.=20 In WTC attack 15 base stations were knocked out and the remaining base = stations isolated from network were unable to route data between them. = This is probably a situation where an ad hoc technology could help (see = WERT recommendation). I don't know whether TETRA can do that either.=20 Philippe ----- Original Message -----=20 From: Berner Vegge=20 To: manet@ietf.org=20 Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello!=20 I have read a little about Ad-Hoc and also a little about TETRA = (Terrestrial Trunked Radio) which is defined by ETSI.=20 As I understand TETRA and AD-Hoc are very much adressing the same = users, where the main users are police, ambulance, firemen, but also = civil users and military users may be relevant.=20 The technology is very different for TETRA and Ad-Hoc. TETRA uses a=20 GSM alike principle with switches and base stations, while Ad-Hoc uses = nodes that are combined routers and terminals (no base stations).=20 But although the technique is different the features seem to be very = much the same with security, priority, group calls etc.=20 a.. From this I wonder if TETRA and Ad-Hoc are competing = technologies in the same market or complementary in some ways. Is it = e.g. relevant to use an Ad-Hoc network out in the field in a rescue = operation and then use TETRA for communication towards hospitals etc?=20 b.. I also wonder what the benefits of using Ad-Hoc compared to = TETRA are.=20 Can anyone help me?=20 Thanks for your help!=20 Best Regards Berner=20 -------------------------------------------------------------------------= ----- Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list = manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------=_NextPart_000_0040_01C21785.434FFD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Berner,
 
TETRA is a mobile networks specificaly = dedicated=20 for police, fireman and ambulance. It is based on a base station = architecture=20 like GSM and provides similar low throughput. MANET is a mobile network = based on=20 multihop routing but is not dedicated to specific applications. Since = the hop=20 distance can be small, ad hoc architecture is suitable for high speed = data=20 transfer such as in IEEE 802.11.
 
In WTC attack 15 base stations were = knocked out and=20 the remaining base stations isolated from network were unable to route = data=20 between them. This is probably a situation where an ad hoc technology = could help=20 (see WERT recommendation). I don't know whether TETRA can do that = either.=20
 
Philippe
----- Original Message -----
From:=20 Berner=20 Vegge
Sent: Wednesday, June 19, 2002 = 9:19=20 AM
Subject: [manet] Ad-Hoc = compared to=20 TETRA



Hello!
I have read a little about Ad-Hoc and also = a=20 little about TETRA (Terrestrial Trunked Radio) which is defined by = ETSI.=20

As I understand TETRA and AD-Hoc are very much adressing the same = users,=20 where the main users are police, ambulance, firemen, but also civil = users and=20 military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. = TETRA uses a=20
GSM alike principle with switches and base stations, while = Ad-Hoc=20 uses=20
nodes that are combined routers and terminals (no base = stations).=20
But although the technique is different the features seem = to be=20 very much the same with security, priority, group calls etc.=20
  • From this I wonder if TETRA and Ad-Hoc are competing = technologies in the=20 same market or complementary in some ways. Is it e.g. relevant to = use an=20 Ad-Hoc network out in the field in a rescue operation and then use = TETRA for=20 communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to = TETRA are.=20
    Can anyone help me?

Thanks for your help!

Best Regards Berner=20

Get your FREE download of MSN Explorer at http://explorer.msn.com.
__= _____________________________________________=20 manet mailing list manet@ietf.org=20 https://www1.ietf.org/mailman/listinfo/manet ------=_NextPart_000_0040_01C21785.434FFD00-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 05:24:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11579 for ; Wed, 19 Jun 2002 05:24:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12185 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 05:25:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11350; Wed, 19 Jun 2002 05:12:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11318 for ; Wed, 19 Jun 2002 05:12:32 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11392 for ; Wed, 19 Jun 2002 05:11:52 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g5J9Bwj22736; Wed, 19 Jun 2002 11:11:58 +0200 (MET DST) Message-ID: <004301c21774$8011f1a0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Berner Vegge" , References: Subject: Re: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:34:24 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C21785.434FFD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C21785.434FFD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and = ambulance. It is based on a base station architecture like GSM and = provides similar low throughput. MANET is a mobile network based on = multihop routing but is not dedicated to specific applications. Since = the hop distance can be small, ad hoc architecture is suitable for high = speed data transfer such as in IEEE 802.11.=20 In WTC attack 15 base stations were knocked out and the remaining base = stations isolated from network were unable to route data between them. = This is probably a situation where an ad hoc technology could help (see = WERT recommendation). I don't know whether TETRA can do that either.=20 Philippe ----- Original Message -----=20 From: Berner Vegge=20 To: manet@ietf.org=20 Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello!=20 I have read a little about Ad-Hoc and also a little about TETRA = (Terrestrial Trunked Radio) which is defined by ETSI.=20 As I understand TETRA and AD-Hoc are very much adressing the same = users, where the main users are police, ambulance, firemen, but also = civil users and military users may be relevant.=20 The technology is very different for TETRA and Ad-Hoc. TETRA uses a=20 GSM alike principle with switches and base stations, while Ad-Hoc uses = nodes that are combined routers and terminals (no base stations).=20 But although the technique is different the features seem to be very = much the same with security, priority, group calls etc.=20 a.. From this I wonder if TETRA and Ad-Hoc are competing = technologies in the same market or complementary in some ways. Is it = e.g. relevant to use an Ad-Hoc network out in the field in a rescue = operation and then use TETRA for communication towards hospitals etc?=20 b.. I also wonder what the benefits of using Ad-Hoc compared to = TETRA are.=20 Can anyone help me?=20 Thanks for your help!=20 Best Regards Berner=20 -------------------------------------------------------------------------= ----- Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list = manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------=_NextPart_000_0040_01C21785.434FFD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Berner,
 
TETRA is a mobile networks specificaly = dedicated=20 for police, fireman and ambulance. It is based on a base station = architecture=20 like GSM and provides similar low throughput. MANET is a mobile network = based on=20 multihop routing but is not dedicated to specific applications. Since = the hop=20 distance can be small, ad hoc architecture is suitable for high speed = data=20 transfer such as in IEEE 802.11.
 
In WTC attack 15 base stations were = knocked out and=20 the remaining base stations isolated from network were unable to route = data=20 between them. This is probably a situation where an ad hoc technology = could help=20 (see WERT recommendation). I don't know whether TETRA can do that = either.=20
 
Philippe
----- Original Message -----
From:=20 Berner=20 Vegge
Sent: Wednesday, June 19, 2002 = 9:19=20 AM
Subject: [manet] Ad-Hoc = compared to=20 TETRA



Hello!
I have read a little about Ad-Hoc and also = a=20 little about TETRA (Terrestrial Trunked Radio) which is defined by = ETSI.=20

As I understand TETRA and AD-Hoc are very much adressing the same = users,=20 where the main users are police, ambulance, firemen, but also civil = users and=20 military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. = TETRA uses a=20
GSM alike principle with switches and base stations, while = Ad-Hoc=20 uses=20
nodes that are combined routers and terminals (no base = stations).=20
But although the technique is different the features seem = to be=20 very much the same with security, priority, group calls etc.=20
  • From this I wonder if TETRA and Ad-Hoc are competing = technologies in the=20 same market or complementary in some ways. Is it e.g. relevant to = use an=20 Ad-Hoc network out in the field in a rescue operation and then use = TETRA for=20 communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to = TETRA are.=20
    Can anyone help me?

Thanks for your help!

Best Regards Berner=20

Get your FREE download of MSN Explorer at http://explorer.msn.com.
__= _____________________________________________=20 manet mailing list manet@ietf.org=20 https://www1.ietf.org/mailman/listinfo/manet ------=_NextPart_000_0040_01C21785.434FFD00-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 05:33:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11734 for ; Wed, 19 Jun 2002 05:33:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11945; Wed, 19 Jun 2002 05:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11845 for ; Wed, 19 Jun 2002 05:21:52 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11516; Wed, 19 Jun 2002 05:21:10 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 17:21:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 2002 17:21:48 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C74@MBXSRV26.stu.nus.edu.sg> Thread-Topic: Mobile agents in manets Thread-Index: AcHn4WP1039pLr99T7Oca3sXx9bkPQvjm30A From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 19 Jun 2002 09:21:48.0289 (UTC) FILETIME=[BCE8F710:01C21772] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA11846 Subject: [manet] Mobile agents in manets Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear All, Can somebody point me to suggestions, scope & papers on applications & use of mobile agents in MANETs. Is someone working on the use of mobile agents in MANETs. Thanks, Shivanajay Marwaha ********************************* M. Eng. Research Scholar ECE Dept., National University of Singapore. www.nus.edu.sg ********************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 05:33:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11745 for ; Wed, 19 Jun 2002 05:33:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13105 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 05:34:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11945; Wed, 19 Jun 2002 05:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11845 for ; Wed, 19 Jun 2002 05:21:52 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11516; Wed, 19 Jun 2002 05:21:10 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 17:21:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jun 2002 17:21:48 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C74@MBXSRV26.stu.nus.edu.sg> Thread-Topic: Mobile agents in manets Thread-Index: AcHn4WP1039pLr99T7Oca3sXx9bkPQvjm30A From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 19 Jun 2002 09:21:48.0289 (UTC) FILETIME=[BCE8F710:01C21772] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA11846 Subject: [manet] Mobile agents in manets Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear All, Can somebody point me to suggestions, scope & papers on applications & use of mobile agents in MANETs. Is someone working on the use of mobile agents in MANETs. Thanks, Shivanajay Marwaha ********************************* M. Eng. Research Scholar ECE Dept., National University of Singapore. www.nus.edu.sg ********************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 06:29:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12357 for ; Wed, 19 Jun 2002 06:29:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14795; Wed, 19 Jun 2002 06:14:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14667 for ; Wed, 19 Jun 2002 06:14:51 -0400 (EDT) Received: from p-voyageur.rd.francetelecom.fr (p-voyageur.rd.francetelecom.fr [139.100.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12177; Wed, 19 Jun 2002 06:14:10 -0400 (EDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Jun 2002 12:08:07 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A03C07F@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: "'Marwaha Shivanajay'" , manet@ietf.org Cc: rpsec@ietf.org Subject: RE: [manet] Mobile agents in manets Date: Wed, 19 Jun 2002 11:36:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21774.C07C36E0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21774.C07C36E0 Content-Type: text/plain hi you can see MAGNET (Mobile Agent For AdHoc Networking) www.inagaki.nuie.nagoya-u.ac.jp/~kawaguti/research/ regards -----Message d'origine----- De : Marwaha Shivanajay [mailto:engp1609@nus.edu.sg] Envoye : mercredi 19 juin 2002 11:22 A : manet@ietf.org Cc : rpsec@ietf.org Objet : [manet] Mobile agents in manets Dear All, Can somebody point me to suggestions, scope & papers on applications & use of mobile agents in MANETs. Is someone working on the use of mobile agents in MANETs. Thanks, Shivanajay Marwaha ********************************* M. Eng. Research Scholar ECE Dept., National University of Singapore. www.nus.edu.sg ********************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C21774.C07C36E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [manet] Mobile agents in manets

hi

you can see MAGNET (Mobile Agent For AdHoc = Networking)

www.inagaki.nuie.nagoya-u.ac.jp/~kawaguti/research/ =

regards

-----Message d'origine-----
De : Marwaha Shivanajay [mailto:engp1609@nus.edu.sg]
Envoye : mercredi 19 juin 2002 11:22
A : manet@ietf.org
Cc : rpsec@ietf.org
Objet : [manet] Mobile agents in manets


Dear All,
Can somebody point me to suggestions, scope & = papers on applications &
use of mobile agents in MANETs.
Is someone working on the use of mobile agents in = MANETs.

Thanks,
Shivanajay Marwaha
*********************************
M. Eng. Research Scholar
ECE Dept.,
National University of Singapore.
www.nus.edu.sg
*********************************




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C21774.C07C36E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 07:24:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12369 for ; Wed, 19 Jun 2002 06:29:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15400 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 06:30:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14795; Wed, 19 Jun 2002 06:14:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14667 for ; Wed, 19 Jun 2002 06:14:51 -0400 (EDT) Received: from p-voyageur.rd.francetelecom.fr (p-voyageur.rd.francetelecom.fr [139.100.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12177; Wed, 19 Jun 2002 06:14:10 -0400 (EDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Jun 2002 12:08:07 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A03C07F@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: "'Marwaha Shivanajay'" , manet@ietf.org Cc: rpsec@ietf.org Subject: RE: [manet] Mobile agents in manets Date: Wed, 19 Jun 2002 11:36:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21774.C07C36E0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21774.C07C36E0 Content-Type: text/plain hi you can see MAGNET (Mobile Agent For AdHoc Networking) www.inagaki.nuie.nagoya-u.ac.jp/~kawaguti/research/ regards -----Message d'origine----- De : Marwaha Shivanajay [mailto:engp1609@nus.edu.sg] Envoye : mercredi 19 juin 2002 11:22 A : manet@ietf.org Cc : rpsec@ietf.org Objet : [manet] Mobile agents in manets Dear All, Can somebody point me to suggestions, scope & papers on applications & use of mobile agents in MANETs. Is someone working on the use of mobile agents in MANETs. Thanks, Shivanajay Marwaha ********************************* M. Eng. Research Scholar ECE Dept., National University of Singapore. www.nus.edu.sg ********************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C21774.C07C36E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [manet] Mobile agents in manets

hi

you can see MAGNET (Mobile Agent For AdHoc = Networking)

www.inagaki.nuie.nagoya-u.ac.jp/~kawaguti/research/ =

regards

-----Message d'origine-----
De : Marwaha Shivanajay [mailto:engp1609@nus.edu.sg]
Envoye : mercredi 19 juin 2002 11:22
A : manet@ietf.org
Cc : rpsec@ietf.org
Objet : [manet] Mobile agents in manets


Dear All,
Can somebody point me to suggestions, scope & = papers on applications &
use of mobile agents in MANETs.
Is someone working on the use of mobile agents in = MANETs.

Thanks,
Shivanajay Marwaha
*********************************
M. Eng. Research Scholar
ECE Dept.,
National University of Singapore.
www.nus.edu.sg
*********************************




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C21774.C07C36E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 09:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17932 for ; Wed, 19 Jun 2002 09:31:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25666; Wed, 19 Jun 2002 09:14:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25637 for ; Wed, 19 Jun 2002 09:14:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17149 for ; Wed, 19 Jun 2002 09:13:59 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 19 Jun 2002 07:13:59 -0600 Message-Id: <02Jun19.071359mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 07:13:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21793.2A5378A0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21793.2A5378A0 Content-Type: text/plain; charset="iso-8859-1" Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation. TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different. In any event, I don't think it is possible to compare the two, since they are two different things. One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution. For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them. This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial. In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. * From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? * I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner _____ Get your FREE download of MSN Explorer at http://explorer.msn.com . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C21793.2A5378A0 Content-Type: text/html; charset="iso-8859-1"
Dear Berner,
 
I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem.
 
Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. 
 
While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET.  In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET).
 
John Mullen 
-----Original Message-----
From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]
Sent: Wednesday, June 19, 2002 3:34 AM
To: Berner Vegge; manet@ietf.org
Subject: Re: [manet] Ad-Hoc compared to TETRA

Dear Berner,
 
TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11.
 
In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either.
 
Philippe
----- Original Message -----
Sent: Wednesday, June 19, 2002 9:19 AM
Subject: [manet] Ad-Hoc compared to TETRA



Hello!
I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI.

As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. TETRA uses a
GSM alike principle with switches and base stations, while Ad-Hoc uses
nodes that are combined routers and terminals (no base stations).
But although the technique is different the features seem to be very much the same with security, priority, group calls etc.
  • From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to TETRA are.
    Can anyone help me?

Thanks for your help!

Best Regards Berner

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet
------_=_NextPart_001_01C21793.2A5378A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 09:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17942 for ; Wed, 19 Jun 2002 09:32:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27060 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 09:32:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25666; Wed, 19 Jun 2002 09:14:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25637 for ; Wed, 19 Jun 2002 09:14:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17149 for ; Wed, 19 Jun 2002 09:13:59 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 19 Jun 2002 07:13:59 -0600 Message-Id: <02Jun19.071359mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 07:13:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21793.2A5378A0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21793.2A5378A0 Content-Type: text/plain; charset="iso-8859-1" Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation. TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different. In any event, I don't think it is possible to compare the two, since they are two different things. One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution. For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them. This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial. In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. * From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? * I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner _____ Get your FREE download of MSN Explorer at http://explorer.msn.com . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C21793.2A5378A0 Content-Type: text/html; charset="iso-8859-1"
Dear Berner,
 
I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem.
 
Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. 
 
While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET.  In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET).
 
John Mullen 
-----Original Message-----
From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]
Sent: Wednesday, June 19, 2002 3:34 AM
To: Berner Vegge; manet@ietf.org
Subject: Re: [manet] Ad-Hoc compared to TETRA

Dear Berner,
 
TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11.
 
In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either.
 
Philippe
----- Original Message -----
Sent: Wednesday, June 19, 2002 9:19 AM
Subject: [manet] Ad-Hoc compared to TETRA



Hello!
I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI.

As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant.

The technology is very different for TETRA and Ad-Hoc. TETRA uses a
GSM alike principle with switches and base stations, while Ad-Hoc uses
nodes that are combined routers and terminals (no base stations).
But although the technique is different the features seem to be very much the same with security, priority, group calls etc.
  • From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc?
  • I also wonder what the benefits of using Ad-Hoc compared to TETRA are.
    Can anyone help me?

Thanks for your help!

Best Regards Berner

Get your FREE download of MSN Explorer at http://explorer.msn.com.
_______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet
------_=_NextPart_001_01C21793.2A5378A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 10:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20241 for ; Wed, 19 Jun 2002 10:24:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29586; Wed, 19 Jun 2002 10:13:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29559 for ; Wed, 19 Jun 2002 10:13:23 -0400 (EDT) Received: from cvis153.mail.marconicomms.com (cvis153.marconicomms.com [128.87.251.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19729 for ; Wed, 19 Jun 2002 10:12:44 -0400 (EDT) Received: from cvis05.marconicomms.com (unverified) by cvis154.mail.marconicomms.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Wed, 19 Jun 2002 14:50:48 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-36) id g5JDolB17860; Wed, 19 Jun 2002 14:50:47 +0100 (BST) Subject: RE: [manet] Ad-Hoc compared to TETRA To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Vincenzo Cipolla" Date: Wed, 19 Jun 2002 15:47:48 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 19/06/2002 14:50:42 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 optimus.ietf.org id KAA29560 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear John, just a short clarification. Implementing MANET systems using TETRA Direct Mode(DMO) operation doesn't require, by definition of the ETSI TETRA standards, any use of Tetra Base Station or Tetra Network capability. In other words the emergency services could operate in the scenarios that you are highlighting using only DMO TETRA Terminals implementing the MANET paradigms. BR, Vincenzo Cipolla "Mullen, John P. (Contractor)" @ietf.org on 19/06/2002 15.13.55 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: RE: [manet] Ad-Hoc compared to TETRA Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 11:09:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20249 for ; Wed, 19 Jun 2002 10:24:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00208 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 10:24:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29586; Wed, 19 Jun 2002 10:13:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29559 for ; Wed, 19 Jun 2002 10:13:23 -0400 (EDT) Received: from cvis153.mail.marconicomms.com (cvis153.marconicomms.com [128.87.251.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19729 for ; Wed, 19 Jun 2002 10:12:44 -0400 (EDT) Received: from cvis05.marconicomms.com (unverified) by cvis154.mail.marconicomms.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Wed, 19 Jun 2002 14:50:48 +0100 Received: from cvdgwy01.uk.marconicomms.com by cvis05.marconicomms.com with ESMTP (8.10.2+Sun/cvms-36) id g5JDolB17860; Wed, 19 Jun 2002 14:50:47 +0100 (BST) Subject: RE: [manet] Ad-Hoc compared to TETRA To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Vincenzo Cipolla" Date: Wed, 19 Jun 2002 15:47:48 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at 19/06/2002 14:50:42 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 optimus.ietf.org id KAA29560 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear John, just a short clarification. Implementing MANET systems using TETRA Direct Mode(DMO) operation doesn't require, by definition of the ETSI TETRA standards, any use of Tetra Base Station or Tetra Network capability. In other words the emergency services could operate in the scenarios that you are highlighting using only DMO TETRA Terminals implementing the MANET paradigms. BR, Vincenzo Cipolla "Mullen, John P. (Contractor)" @ietf.org on 19/06/2002 15.13.55 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: RE: [manet] Ad-Hoc compared to TETRA Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 11:42:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23987 for ; Wed, 19 Jun 2002 11:42:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04275; Wed, 19 Jun 2002 11:25:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04248 for ; Wed, 19 Jun 2002 11:25:11 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22929 for ; Wed, 19 Jun 2002 11:24:32 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 09:25:01 -0600 Message-Id: <02Jun19.092501mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Vincenzo Cipolla Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 09:24:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04249 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear Vincenzo, Thanks for the information. I was under the impression that direct mode was only capable of supporting local communications, rather than a full network (say 100 or more nodes) over a wide area (say several counties). Also, according to the press release below, those nodes using direct mode cannot communicate with nodes using normal TETRA operation. http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html But, it wouldn't be the first time that a press release was in error. :-) John Mullen -----Original Message----- From: Vincenzo Cipolla [mailto:Vincenzo.Cipolla@marconi.com] Sent: Wednesday, June 19, 2002 7:48 AM To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Dear John, just a short clarification. Implementing MANET systems using TETRA Direct Mode(DMO) operation doesn't require, by definition of the ETSI TETRA standards, any use of Tetra Base Station or Tetra Network capability. In other words the emergency services could operate in the scenarios that you are highlighting using only DMO TETRA Terminals implementing the MANET paradigms. BR, Vincenzo Cipolla "Mullen, John P. (Contractor)" @ietf.org on 19/06/2002 15.13.55 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: RE: [manet] Ad-Hoc compared to TETRA Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 11:42:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23996 for ; Wed, 19 Jun 2002 11:42:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05741 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 11:43:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04275; Wed, 19 Jun 2002 11:25:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04248 for ; Wed, 19 Jun 2002 11:25:11 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22929 for ; Wed, 19 Jun 2002 11:24:32 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 09:25:01 -0600 Message-Id: <02Jun19.092501mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Vincenzo Cipolla Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 09:24:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04249 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear Vincenzo, Thanks for the information. I was under the impression that direct mode was only capable of supporting local communications, rather than a full network (say 100 or more nodes) over a wide area (say several counties). Also, according to the press release below, those nodes using direct mode cannot communicate with nodes using normal TETRA operation. http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html But, it wouldn't be the first time that a press release was in error. :-) John Mullen -----Original Message----- From: Vincenzo Cipolla [mailto:Vincenzo.Cipolla@marconi.com] Sent: Wednesday, June 19, 2002 7:48 AM To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Dear John, just a short clarification. Implementing MANET systems using TETRA Direct Mode(DMO) operation doesn't require, by definition of the ETSI TETRA standards, any use of Tetra Base Station or Tetra Network capability. In other words the emergency services could operate in the scenarios that you are highlighting using only DMO TETRA Terminals implementing the MANET paradigms. BR, Vincenzo Cipolla "Mullen, John P. (Contractor)" @ietf.org on 19/06/2002 15.13.55 Sent by: manet-admin@ietf.org To: manet@ietf.org cc: Subject: RE: [manet] Ad-Hoc compared to TETRA Dear Berner, I would add to Philippe that the term "MANET" describes a type of communications situation in which all elements of the network are apt to be in motion, rather than a particular standard or implementation.  TETRA, on the other hand, is a specific solution to a problem, which as Philippe points out, is somewhat different.  In any event, I don't think it is possible to compare the two, since they are two different things.  One can only say whether or not TETRA is a reasonable solution to the MANET problem. Certainly, elements of TETRA may be helpful in dealing with the MANET problem, but the very fact that TETRA relies on base stations would rule out its entire adaptation as a general solution.  For example, if emergency services are extended into an area that has suffered an earthquake or hurricane, it is likely that any base stations, towers, etc. would be unusable and the system would have to depend solely on what the service agencies bring with them.  This would be a MANET problem. While, in my opinion, urban and suburban police and other emergency communications would be more resilient if they had at least a capability to function as a MANET, I recognize that in most situations, the added routing efficiency due to base stations is beneficial.  In addition, there needs to be a sufficient number of nodes in a area to support a MANET. In extreme rural areas, there would be too few mobile police and other emergency units, so both base and relay stations would be necessary (unless one relies on satellites or includes other, non-public service users in the MANET). John Mullen -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Wednesday, June 19, 2002 3:34 AM To: Berner Vegge; manet@ietf.org Subject: Re: [manet] Ad-Hoc compared to TETRA Dear Berner, TETRA is a mobile networks specificaly dedicated for police, fireman and ambulance. It is based on a base station architecture like GSM and provides similar low throughput. MANET is a mobile network based on multihop routing but is not dedicated to specific applications. Since the hop distance can be small, ad hoc architecture is suitable for high speed data transfer such as in IEEE 802.11. In WTC attack 15 base stations were knocked out and the remaining base stations isolated from network were unable to route data between them. This is probably a situation where an ad hoc technology could help (see WERT recommendation). I don't know whether TETRA can do that either. Philippe ----- Original Message ----- From: Berner Vegge To: manet@ietf.org Sent: Wednesday, June 19, 2002 9:19 AM Subject: [manet] Ad-Hoc compared to TETRA Hello! I have read a little about Ad-Hoc and also a little about TETRA (Terrestrial Trunked Radio) which is defined by ETSI. As I understand TETRA and AD-Hoc are very much adressing the same users, where the main users are police, ambulance, firemen, but also civil users and military users may be relevant. The technology is very different for TETRA and Ad-Hoc. TETRA uses a GSM alike principle with switches and base stations, while Ad-Hoc uses nodes that are combined routers and terminals (no base stations). But although the technique is different the features seem to be very much the same with security, priority, group calls etc. From this I wonder if TETRA and Ad-Hoc are competing technologies in the same market or complementary in some ways. Is it e.g. relevant to use an Ad-Hoc network out in the field in a rescue operation and then use TETRA for communication towards hospitals etc? I also wonder what the benefits of using Ad-Hoc compared to TETRA are. Can anyone help me? Thanks for your help! Best Regards Berner Get your FREE download of MSN Explorer at http://explorer.msn.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 12:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25477 for ; Wed, 19 Jun 2002 12:24:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06441; Wed, 19 Jun 2002 11:58:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06400 for ; Wed, 19 Jun 2002 11:58:07 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24471 for ; Wed, 19 Jun 2002 11:57:23 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA17848; Wed, 19 Jun 2002 08:57:59 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA27273; Wed, 19 Jun 2002 08:57:58 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5JFvvR14546; Wed, 19 Jun 2002 08:57:57 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 11:57:56 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3997@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:57:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Wednesday, June 19, 2002 11:25 AM > To: Vincenzo Cipolla > Cc: manet@ietf.org > Subject: RE: [manet] Ad-Hoc compared to TETRA > > > Dear Vincenzo, > > Thanks for the information. I was under the impression that > direct mode was > only capable of supporting local communications, rather than > a full network > (say 100 or more nodes) over a wide area (say several > counties). Also, > according to the press release below, those nodes using > direct mode cannot > communicate with nodes using normal TETRA operation. > > http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html > > But, it wouldn't be the first time that a press release was in error. > > :-) > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 12:24:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25487 for ; Wed, 19 Jun 2002 12:24:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09715 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 12:24:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06441; Wed, 19 Jun 2002 11:58:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06400 for ; Wed, 19 Jun 2002 11:58:07 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24471 for ; Wed, 19 Jun 2002 11:57:23 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA17848; Wed, 19 Jun 2002 08:57:59 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA27273; Wed, 19 Jun 2002 08:57:58 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5JFvvR14546; Wed, 19 Jun 2002 08:57:57 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 11:57:56 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3997@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:57:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Wednesday, June 19, 2002 11:25 AM > To: Vincenzo Cipolla > Cc: manet@ietf.org > Subject: RE: [manet] Ad-Hoc compared to TETRA > > > Dear Vincenzo, > > Thanks for the information. I was under the impression that > direct mode was > only capable of supporting local communications, rather than > a full network > (say 100 or more nodes) over a wide area (say several > counties). Also, > according to the press release below, those nodes using > direct mode cannot > communicate with nodes using normal TETRA operation. > > http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html > > But, it wouldn't be the first time that a press release was in error. > > :-) > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 12:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26871 for ; Wed, 19 Jun 2002 12:57:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10908; Wed, 19 Jun 2002 12:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10879 for ; Wed, 19 Jun 2002 12:41:29 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26096 for ; Wed, 19 Jun 2002 12:40:48 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 10:41:18 -0600 Message-Id: <02Jun19.104118mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 10:41:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I infer from your last sentence that you consider "MANET" to be some sort of commercial package. Just to make it clear, "MANET" describes a type of communications situation, not a product or particular implementation. The term simply means "Mobile Ad Hoc Network" and any network that fits that description could be termed a "MANET." The working characteristics of MANETs arise as logical consequences of that fundamental description. For example, most people agree that "mobile" implies "wireless." Any number of protocols and commercial products could be considered solutions to at least some MANET problems. Also, I want to make clear that there are degrees of "MANET"ness. In the MANET model, for example, all nodes could be mobile, while in practical situations, that may not be the case. As far as I can tell, the real juicy problems in MANETs are at the lowest two or three levels. This is where the MANETS differ most from conventional nets. For example, link capacity varies continuously and randomly, so one has to find a way to sort trivial changes from important ones to avoid congesting the net with too many update packets. If you can manage the problems at level three and below, then the upper levels can look pretty much that of like other networks. So, if you are saying that there are situations in which at least some nodes are mobile in which TETRA would perform well, I would say that most people would agree. However, whether or not those situations are sufficiently messy enough to be considered a MANET type of situation is debatable. I think each of us colors the MANET definition a bit by the nature of networks we work with. For example, I'm working in military tactical communications networks, which is probably as "MANET"ty as one can get. In fact, given that the enemy is expected to try to disrupt the network, maybe a little too "MANET"ty. :-) So, TETRA might be able to perform as a MANET under certain conditions. I really don't know enough technical details to say. However, to say that it is an alternative to a MANET is akin to saying a Chevrolet is an alternative to an automobile. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 9:58 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Wednesday, June 19, 2002 11:25 AM > To: Vincenzo Cipolla > Cc: manet@ietf.org > Subject: RE: [manet] Ad-Hoc compared to TETRA > > > Dear Vincenzo, > > Thanks for the information. I was under the impression that > direct mode was > only capable of supporting local communications, rather than > a full network > (say 100 or more nodes) over a wide area (say several > counties). Also, > according to the press release below, those nodes using > direct mode cannot > communicate with nodes using normal TETRA operation. > > http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html > > But, it wouldn't be the first time that a press release was in error. > > :-) > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 12:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26880 for ; Wed, 19 Jun 2002 12:57:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12163 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 12:58:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10908; Wed, 19 Jun 2002 12:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10879 for ; Wed, 19 Jun 2002 12:41:29 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26096 for ; Wed, 19 Jun 2002 12:40:48 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 10:41:18 -0600 Message-Id: <02Jun19.104118mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 10:41:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I infer from your last sentence that you consider "MANET" to be some sort of commercial package. Just to make it clear, "MANET" describes a type of communications situation, not a product or particular implementation. The term simply means "Mobile Ad Hoc Network" and any network that fits that description could be termed a "MANET." The working characteristics of MANETs arise as logical consequences of that fundamental description. For example, most people agree that "mobile" implies "wireless." Any number of protocols and commercial products could be considered solutions to at least some MANET problems. Also, I want to make clear that there are degrees of "MANET"ness. In the MANET model, for example, all nodes could be mobile, while in practical situations, that may not be the case. As far as I can tell, the real juicy problems in MANETs are at the lowest two or three levels. This is where the MANETS differ most from conventional nets. For example, link capacity varies continuously and randomly, so one has to find a way to sort trivial changes from important ones to avoid congesting the net with too many update packets. If you can manage the problems at level three and below, then the upper levels can look pretty much that of like other networks. So, if you are saying that there are situations in which at least some nodes are mobile in which TETRA would perform well, I would say that most people would agree. However, whether or not those situations are sufficiently messy enough to be considered a MANET type of situation is debatable. I think each of us colors the MANET definition a bit by the nature of networks we work with. For example, I'm working in military tactical communications networks, which is probably as "MANET"ty as one can get. In fact, given that the enemy is expected to try to disrupt the network, maybe a little too "MANET"ty. :-) So, TETRA might be able to perform as a MANET under certain conditions. I really don't know enough technical details to say. However, to say that it is an alternative to a MANET is akin to saying a Chevrolet is an alternative to an automobile. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 9:58 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Wednesday, June 19, 2002 11:25 AM > To: Vincenzo Cipolla > Cc: manet@ietf.org > Subject: RE: [manet] Ad-Hoc compared to TETRA > > > Dear Vincenzo, > > Thanks for the information. I was under the impression that > direct mode was > only capable of supporting local communications, rather than > a full network > (say 100 or more nodes) over a wide area (say several > counties). Also, > according to the press release below, those nodes using > direct mode cannot > communicate with nodes using normal TETRA operation. > > http://www.nokia.com/networks/pmr/tetra_terminals/models_tmr420.html > > But, it wouldn't be the first time that a press release was in error. > > :-) > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 13:15:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27553 for ; Wed, 19 Jun 2002 13:15:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11819; Wed, 19 Jun 2002 12:56:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11789 for ; Wed, 19 Jun 2002 12:55:57 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26727 for ; Wed, 19 Jun 2002 12:55:16 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 17Kijt-0000hL-00; Wed, 19 Jun 2002 18:55:25 +0200 Received: from localhost (hollos@localhost) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g5JGtOx31203; Wed, 19 Jun 2002 18:55:25 +0200 Date: Wed, 19 Jun 2002 18:55:24 +0200 (CEST) From: Daniel Hollos To: "Manfredi, Albert E" cc: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3997@xch-ne-02.ne.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org You are right, the TETRA DMO targets short distance kommunikations when it's needed, either when a base station is reachable or not. The max. distance in this mode is around 1km, I also tested it. Yours, Daniel > The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. > > Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 13:15:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27563 for ; Wed, 19 Jun 2002 13:15:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13922 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 13:16:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11819; Wed, 19 Jun 2002 12:56:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11789 for ; Wed, 19 Jun 2002 12:55:57 -0400 (EDT) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26727 for ; Wed, 19 Jun 2002 12:55:16 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 17Kijt-0000hL-00; Wed, 19 Jun 2002 18:55:25 +0200 Received: from localhost (hollos@localhost) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g5JGtOx31203; Wed, 19 Jun 2002 18:55:25 +0200 Date: Wed, 19 Jun 2002 18:55:24 +0200 (CEST) From: Daniel Hollos To: "Manfredi, Albert E" cc: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3997@xch-ne-02.ne.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org You are right, the TETRA DMO targets short distance kommunikations when it's needed, either when a base station is reachable or not. The max. distance in this mode is around 1km, I also tested it. Yours, Daniel > The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. > > Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 13:22:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27897 for ; Wed, 19 Jun 2002 13:22:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13104; Wed, 19 Jun 2002 13:06:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13078 for ; Wed, 19 Jun 2002 13:06:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27126 for ; Wed, 19 Jun 2002 13:05:29 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 11:06:05 -0600 Message-Id: <02Jun19.110605mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Daniel Hollos Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:06:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org -----Original Message----- From: Daniel Hollos [mailto:hollos@ftmail.ee.tu-berlin.de] Sent: Wednesday, June 19, 2002 10:55 AM To: Manfredi, Albert E Cc: 'Mullen, John P. (Contractor)'; manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA You are right, the TETRA DMO targets short distance kommunikations when it's needed, either when a base station is reachable or not. The max. distance in this mode is around 1km, I also tested it. Yours, Daniel > The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. > > Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 13:22:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27905 for ; Wed, 19 Jun 2002 13:22:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14871 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 13:23:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13104; Wed, 19 Jun 2002 13:06:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13078 for ; Wed, 19 Jun 2002 13:06:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27126 for ; Wed, 19 Jun 2002 13:05:29 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Wed, 19 Jun 2002 11:06:05 -0600 Message-Id: <02Jun19.110605mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Daniel Hollos Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:06:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org -----Original Message----- From: Daniel Hollos [mailto:hollos@ftmail.ee.tu-berlin.de] Sent: Wednesday, June 19, 2002 10:55 AM To: Manfredi, Albert E Cc: 'Mullen, John P. (Contractor)'; manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA You are right, the TETRA DMO targets short distance kommunikations when it's needed, either when a base station is reachable or not. The max. distance in this mode is around 1km, I also tested it. Yours, Daniel > The direct mode appears to be a short range option, for groups of terminals which are close together, but out of range of a base station. Is it like using walkie talkies? Just broadcast on a given frequency? Hard to say from the Nokia description, but that's the implication. > > Why isn't Tetra an option, similar to IEEE 802.11, to use as physical and link layers under MANET? It would seem to me that Tetra or 3G cellular would provide similar functionality at the lower 2 layers. And it seems to me that using Tetra with a base station, or IEEE 802.11b in so-called "infrastructure mode," allows one to layer IP over these schemes without any need for MANET. They just become extensions of the cabled Internet, used this way. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 13:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28175 for ; Wed, 19 Jun 2002 13:29:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13885; Wed, 19 Jun 2002 13:16:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13856 for ; Wed, 19 Jun 2002 13:16:04 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27541 for ; Wed, 19 Jun 2002 13:15:23 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA27097; Wed, 19 Jun 2002 10:15:56 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA27907; Wed, 19 Jun 2002 12:15:55 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5JHFrR27317; Wed, 19 Jun 2002 10:15:53 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 13:15:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3999@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 13:15:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > -----Original Message----- > From: Mullen, John P. (Contractor) > As far as I can tell, the real juicy problems in MANETs are > at the lowest > two or three levels. This is where the MANETS differ most > from conventional > nets. For example, link capacity varies continuously and > randomly, so one > has to find a way to sort trivial changes from important ones to avoid > congesting the net with too many update packets. If you can > manage the > problems at level three and below, then the upper levels can > look pretty > much that of like other networks. John, The way I see it, if you solve the routing problem at the link layer, such as using Tetra with base station, using IEEE 802.11 in infrastructure mode, or using 2.5G or 3G cellular, then the only problem left is potentially a problem with variable link capacity. But that is a standard IP problem, even in the wired Internet. Every problem needs to be bound. In this instance, a standard, fixed Internet structure, with a few wireless links to hosts which would otherwise appear fixed as well, should not be considered under the MANET umbrella. Or if it is, it would be a trivial case. > So, if you are saying that there are situations in which at > least some nodes > are mobile in which TETRA would perform well, I would say > that most people > would agree. However, whether or not those situations are > sufficiently > messy enough to be considered a MANET type of situation is > debatable. Let's assume that Tetra in its "direct mode" is functionally like a walkie talkie net except that each mobile acts as a repeater (I'm not positive it is). If one wants to implement unicast communications over such a broadcast net, then MANET would provide added value. In this case, I would consider Tetra to offer a physical and link layer to MANET, similar to what IEEE 802.11 provides when used in ad-hoc mode. But if one is happy to use the broadcast paradigm, then there is no reason to layer MANET over this, is there? Just broadcast the voice, or broadcast the data, over the link layer as provided, and perhaps use IP and UDP encapsulation if there's a reason to. I don't see anything MANET about this last approach? Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 13:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28186 for ; Wed, 19 Jun 2002 13:29:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15511 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 13:30:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13885; Wed, 19 Jun 2002 13:16:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13856 for ; Wed, 19 Jun 2002 13:16:04 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27541 for ; Wed, 19 Jun 2002 13:15:23 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA27097; Wed, 19 Jun 2002 10:15:56 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA27907; Wed, 19 Jun 2002 12:15:55 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5JHFrR27317; Wed, 19 Jun 2002 10:15:53 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 13:15:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3999@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 13:15:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > -----Original Message----- > From: Mullen, John P. (Contractor) > As far as I can tell, the real juicy problems in MANETs are > at the lowest > two or three levels. This is where the MANETS differ most > from conventional > nets. For example, link capacity varies continuously and > randomly, so one > has to find a way to sort trivial changes from important ones to avoid > congesting the net with too many update packets. If you can > manage the > problems at level three and below, then the upper levels can > look pretty > much that of like other networks. John, The way I see it, if you solve the routing problem at the link layer, such as using Tetra with base station, using IEEE 802.11 in infrastructure mode, or using 2.5G or 3G cellular, then the only problem left is potentially a problem with variable link capacity. But that is a standard IP problem, even in the wired Internet. Every problem needs to be bound. In this instance, a standard, fixed Internet structure, with a few wireless links to hosts which would otherwise appear fixed as well, should not be considered under the MANET umbrella. Or if it is, it would be a trivial case. > So, if you are saying that there are situations in which at > least some nodes > are mobile in which TETRA would perform well, I would say > that most people > would agree. However, whether or not those situations are > sufficiently > messy enough to be considered a MANET type of situation is > debatable. Let's assume that Tetra in its "direct mode" is functionally like a walkie talkie net except that each mobile acts as a repeater (I'm not positive it is). If one wants to implement unicast communications over such a broadcast net, then MANET would provide added value. In this case, I would consider Tetra to offer a physical and link layer to MANET, similar to what IEEE 802.11 provides when used in ad-hoc mode. But if one is happy to use the broadcast paradigm, then there is no reason to layer MANET over this, is there? Just broadcast the voice, or broadcast the data, over the link layer as provided, and perhaps use IP and UDP encapsulation if there's a reason to. I don't see anything MANET about this last approach? Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 13:30:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28230 for ; Wed, 19 Jun 2002 13:30:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14142; Wed, 19 Jun 2002 13:17:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14095 for ; Wed, 19 Jun 2002 13:17:12 -0400 (EDT) Received: from elanus.its.uu.se (Elanus.its.uu.se [130.238.4.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27653 for ; Wed, 19 Jun 2002 13:16:31 -0400 (EDT) Received: from elanus (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3CD2F4803; Wed, 19 Jun 2002 19:14:19 +0200 (DFT) Received: from elanus.its.uu.se(127.0.0.1) by elanus.its.uu.se via virus-scan id s21265; Wed, 19 Jun 02 19:14:07 +0200 Received: from nebulosa.it.uu.se (nebulosa.it.uu.se [130.238.8.24]) by elanus.its.uu.se (Postfix) with ESMTP id 48C284834; Wed, 19 Jun 2002 19:14:06 +0200 (DFT) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST , Aodvimpl-Public Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.7 Date: 19 Jun 2002 19:16:58 +0200 Message-Id: <1024507018.25626.40.camel@nebulosa.it.uu.se> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA14096 Subject: [manet] AODV-UU v0.5 with NS-2 support! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello. AODV-UU version 0.5 is now available for download on the AODV-UU webpage: http://www.docs.uu.se/~henrikl/aodv. AODV-UU runs in Linux on normal PC-computers and on PDAs like the Zaurus or the iPAQ. This release also makes it possible to run AODV-UU in NS-2, i.e. you can run the same AODV code in the real-world and in simulation!!! The NS-2 performance of AODV-UU using link layer feedback is similar to the existing AODV implementation in NS-2. AODV-UU also properly implements features like HELLO messages and expanding ring search, which seem to be broken in the NS-2 bundled AODV implementation. Also, AODV-UU is compliant with the AODV draft version 10. Bug reports and other feedback is always appreciated. Best Regards Erik Nordström IT-department Uppsala University _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 13:30:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28242 for ; Wed, 19 Jun 2002 13:30:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15776 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 13:30:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14142; Wed, 19 Jun 2002 13:17:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14095 for ; Wed, 19 Jun 2002 13:17:12 -0400 (EDT) Received: from elanus.its.uu.se (Elanus.its.uu.se [130.238.4.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27653 for ; Wed, 19 Jun 2002 13:16:31 -0400 (EDT) Received: from elanus (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3CD2F4803; Wed, 19 Jun 2002 19:14:19 +0200 (DFT) Received: from elanus.its.uu.se(127.0.0.1) by elanus.its.uu.se via virus-scan id s21265; Wed, 19 Jun 02 19:14:07 +0200 Received: from nebulosa.it.uu.se (nebulosa.it.uu.se [130.238.8.24]) by elanus.its.uu.se (Postfix) with ESMTP id 48C284834; Wed, 19 Jun 2002 19:14:06 +0200 (DFT) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST , Aodvimpl-Public Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.7 Date: 19 Jun 2002 19:16:58 +0200 Message-Id: <1024507018.25626.40.camel@nebulosa.it.uu.se> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA14096 Subject: [manet] AODV-UU v0.5 with NS-2 support! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello. AODV-UU version 0.5 is now available for download on the AODV-UU webpage: http://www.docs.uu.se/~henrikl/aodv. AODV-UU runs in Linux on normal PC-computers and on PDAs like the Zaurus or the iPAQ. This release also makes it possible to run AODV-UU in NS-2, i.e. you can run the same AODV code in the real-world and in simulation!!! The NS-2 performance of AODV-UU using link layer feedback is similar to the existing AODV implementation in NS-2. AODV-UU also properly implements features like HELLO messages and expanding ring search, which seem to be broken in the NS-2 bundled AODV implementation. Also, AODV-UU is compliant with the AODV draft version 10. Bug reports and other feedback is always appreciated. Best Regards Erik Nordström IT-department Uppsala University _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 13:56:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29185 for ; Wed, 19 Jun 2002 13:56:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16480; Wed, 19 Jun 2002 13:40:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16448 for ; Wed, 19 Jun 2002 13:40:48 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28548 for ; Wed, 19 Jun 2002 13:40:07 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117135>; Wed, 19 Jun 2002 11:40:38 -0600 Message-Id: <02Jun19.114038mdt.117135@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:40:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I think we pretty much agree. Whether or not a situation would classify as a MANET situation could be a matter of kind or degree. For example, I don't think a cellular network is a MANET because the backbone is fixed. Now, of course, a lightning strike would knock out a tower and the system might be able to recover from this. So, in a sense, the backbone is not absolutely fixed. However, I think most people would agree that even if the cellular net is self-healing, such a rare event would not qualify the situation to be a MANET. To me, an emergency services deployment would qualify if it involved a few base stations, such as at command centers, together with a moderately large number of nodes, some of which are out of range of the base stations, but within range of each other. If, without user intervention, the nodes can function as routers to enable those nodes that are out of the range of the base station to behave as if they are just as much part of the net as those in direct contact, the result would probably be a MANET. I would further expect that a large fraction of the nodes (80 or 90 percent) would be highly mobile, frequently changing their ability to communicate with base stations or each other. One final thing would be that these nodes are capable of communicating any voice, data, etc. that would be necessary in order to manage the emergency services under these conditions. Now, if you have a product that is affordable and performs these necessary functions, then you have something useful. I would also call it a MANET. I'm not sure what to say about the last couple of sentences. I get the impression that you are treating "MANET" as a specific protocol or product. I'm not aware of any use of the term in this way. As far as I know, "MANET" is a classification of network type, much like "leafy vegetable" is a classification of food. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 11:16 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA > -----Original Message----- > From: Mullen, John P. (Contractor) > As far as I can tell, the real juicy problems in MANETs are > at the lowest > two or three levels. This is where the MANETS differ most > from conventional > nets. For example, link capacity varies continuously and > randomly, so one > has to find a way to sort trivial changes from important ones to avoid > congesting the net with too many update packets. If you can > manage the > problems at level three and below, then the upper levels can > look pretty > much that of like other networks. John, The way I see it, if you solve the routing problem at the link layer, such as using Tetra with base station, using IEEE 802.11 in infrastructure mode, or using 2.5G or 3G cellular, then the only problem left is potentially a problem with variable link capacity. But that is a standard IP problem, even in the wired Internet. Every problem needs to be bound. In this instance, a standard, fixed Internet structure, with a few wireless links to hosts which would otherwise appear fixed as well, should not be considered under the MANET umbrella. Or if it is, it would be a trivial case. > So, if you are saying that there are situations in which at > least some nodes > are mobile in which TETRA would perform well, I would say > that most people > would agree. However, whether or not those situations are > sufficiently > messy enough to be considered a MANET type of situation is > debatable. Let's assume that Tetra in its "direct mode" is functionally like a walkie talkie net except that each mobile acts as a repeater (I'm not positive it is). If one wants to implement unicast communications over such a broadcast net, then MANET would provide added value. In this case, I would consider Tetra to offer a physical and link layer to MANET, similar to what IEEE 802.11 provides when used in ad-hoc mode. But if one is happy to use the broadcast paradigm, then there is no reason to layer MANET over this, is there? Just broadcast the voice, or broadcast the data, over the link layer as provided, and perhaps use IP and UDP encapsulation if there's a reason to. I don't see anything MANET about this last approach? Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 13:56:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29194 for ; Wed, 19 Jun 2002 13:56:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17759 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 13:56:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16480; Wed, 19 Jun 2002 13:40:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16448 for ; Wed, 19 Jun 2002 13:40:48 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28548 for ; Wed, 19 Jun 2002 13:40:07 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117135>; Wed, 19 Jun 2002 11:40:38 -0600 Message-Id: <02Jun19.114038mdt.117135@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 11:40:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I think we pretty much agree. Whether or not a situation would classify as a MANET situation could be a matter of kind or degree. For example, I don't think a cellular network is a MANET because the backbone is fixed. Now, of course, a lightning strike would knock out a tower and the system might be able to recover from this. So, in a sense, the backbone is not absolutely fixed. However, I think most people would agree that even if the cellular net is self-healing, such a rare event would not qualify the situation to be a MANET. To me, an emergency services deployment would qualify if it involved a few base stations, such as at command centers, together with a moderately large number of nodes, some of which are out of range of the base stations, but within range of each other. If, without user intervention, the nodes can function as routers to enable those nodes that are out of the range of the base station to behave as if they are just as much part of the net as those in direct contact, the result would probably be a MANET. I would further expect that a large fraction of the nodes (80 or 90 percent) would be highly mobile, frequently changing their ability to communicate with base stations or each other. One final thing would be that these nodes are capable of communicating any voice, data, etc. that would be necessary in order to manage the emergency services under these conditions. Now, if you have a product that is affordable and performs these necessary functions, then you have something useful. I would also call it a MANET. I'm not sure what to say about the last couple of sentences. I get the impression that you are treating "MANET" as a specific protocol or product. I'm not aware of any use of the term in this way. As far as I know, "MANET" is a classification of network type, much like "leafy vegetable" is a classification of food. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 11:16 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA > -----Original Message----- > From: Mullen, John P. (Contractor) > As far as I can tell, the real juicy problems in MANETs are > at the lowest > two or three levels. This is where the MANETS differ most > from conventional > nets. For example, link capacity varies continuously and > randomly, so one > has to find a way to sort trivial changes from important ones to avoid > congesting the net with too many update packets. If you can > manage the > problems at level three and below, then the upper levels can > look pretty > much that of like other networks. John, The way I see it, if you solve the routing problem at the link layer, such as using Tetra with base station, using IEEE 802.11 in infrastructure mode, or using 2.5G or 3G cellular, then the only problem left is potentially a problem with variable link capacity. But that is a standard IP problem, even in the wired Internet. Every problem needs to be bound. In this instance, a standard, fixed Internet structure, with a few wireless links to hosts which would otherwise appear fixed as well, should not be considered under the MANET umbrella. Or if it is, it would be a trivial case. > So, if you are saying that there are situations in which at > least some nodes > are mobile in which TETRA would perform well, I would say > that most people > would agree. However, whether or not those situations are > sufficiently > messy enough to be considered a MANET type of situation is > debatable. Let's assume that Tetra in its "direct mode" is functionally like a walkie talkie net except that each mobile acts as a repeater (I'm not positive it is). If one wants to implement unicast communications over such a broadcast net, then MANET would provide added value. In this case, I would consider Tetra to offer a physical and link layer to MANET, similar to what IEEE 802.11 provides when used in ad-hoc mode. But if one is happy to use the broadcast paradigm, then there is no reason to layer MANET over this, is there? Just broadcast the voice, or broadcast the data, over the link layer as provided, and perhaps use IP and UDP encapsulation if there's a reason to. I don't see anything MANET about this last approach? Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 15:14:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01324 for ; Wed, 19 Jun 2002 15:14:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21519; Wed, 19 Jun 2002 14:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21494 for ; Wed, 19 Jun 2002 14:56:59 -0400 (EDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00812 for ; Wed, 19 Jun 2002 14:56:19 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:56:24 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46994B43@ftmail> From: Scott Corson To: manet@ietf.org Date: Wed, 19 Jun 2002 14:56:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Agenda Request Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Folks, I'll be chairing the upcoming Yokohama mtg. Please send me a note if you wish to get on the agenda. The mtg is currently scheduled for: WEDNESDAY, July 17, 2002 0900-1130 Morning Sessions RTG manet Mobile Ad-hoc Networks WG -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jun 19 15:14:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01336 for ; Wed, 19 Jun 2002 15:14:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22860 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 15:14:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21519; Wed, 19 Jun 2002 14:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21494 for ; Wed, 19 Jun 2002 14:56:59 -0400 (EDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00812 for ; Wed, 19 Jun 2002 14:56:19 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:56:24 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46994B43@ftmail> From: Scott Corson To: manet@ietf.org Date: Wed, 19 Jun 2002 14:56:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Agenda Request Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Folks, I'll be chairing the upcoming Yokohama mtg. Please send me a note if you wish to get on the agenda. The mtg is currently scheduled for: WEDNESDAY, July 17, 2002 0900-1130 Morning Sessions RTG manet Mobile Ad-hoc Networks WG -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 16:32:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02836 for ; Wed, 19 Jun 2002 16:32:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25687; Wed, 19 Jun 2002 16:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25660 for ; Wed, 19 Jun 2002 16:16:35 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02513 for ; Wed, 19 Jun 2002 16:15:55 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id PAA01865 for manet@ietf.org; Wed, 19 Jun 2002 15:16:03 -0500 Date: Wed, 19 Jun 2002 15:16:03 -0500 From: David Young To: MANET LIST Message-ID: <20020619151603.A31659@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , MANET LIST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [manet] on-demand routing for BSD? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Does any AODV implementation exist for *BSD? It seems like a purely "userland" implementation of AODV, DSR, and other varieties of on-demand ad hoc routing are impossible because they require the kernel queue packets without nexthops for long enough that route discovery can be attempted. BSD kernels, however, discard packets immediately when they do not know a nexthop. It seems like an ioctl for BSD routing sockets which would be useful to on-demand routing implementors would command the kernel to briefly hold onto a small number of packets whose nexthops are unknown. This way a routing daemon has some time, after it reads an RTM_MISS message from the routing socket, to produce routes for the queued packets on demand. Would such an ioctl be useful to the MANET experimenter? Has anyone patched any existing *BSD with such an ioctl? Dave -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 19 16:32:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02848 for ; Wed, 19 Jun 2002 16:32:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27094 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 16:33:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25687; Wed, 19 Jun 2002 16:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25660 for ; Wed, 19 Jun 2002 16:16:35 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02513 for ; Wed, 19 Jun 2002 16:15:55 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id PAA01865 for manet@ietf.org; Wed, 19 Jun 2002 15:16:03 -0500 Date: Wed, 19 Jun 2002 15:16:03 -0500 From: David Young To: MANET LIST Message-ID: <20020619151603.A31659@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , MANET LIST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [manet] on-demand routing for BSD? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Does any AODV implementation exist for *BSD? It seems like a purely "userland" implementation of AODV, DSR, and other varieties of on-demand ad hoc routing are impossible because they require the kernel queue packets without nexthops for long enough that route discovery can be attempted. BSD kernels, however, discard packets immediately when they do not know a nexthop. It seems like an ioctl for BSD routing sockets which would be useful to on-demand routing implementors would command the kernel to briefly hold onto a small number of packets whose nexthops are unknown. This way a routing daemon has some time, after it reads an RTM_MISS message from the routing socket, to produce routes for the queued packets on demand. Would such an ioctl be useful to the MANET experimenter? Has anyone patched any existing *BSD with such an ioctl? Dave -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 16:55:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03303 for ; Wed, 19 Jun 2002 16:55:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27461; Wed, 19 Jun 2002 16:38:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27431 for ; Wed, 19 Jun 2002 16:38:31 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02933 for ; Wed, 19 Jun 2002 16:37:50 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 19 Jun 2002 14:37:59 -0600 Message-Id: <02Jun19.143759mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 14:37:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, We seem to be in agreement, so I'm cutting most stuff for the sake of bandwidth. I use the area emergency response as an example of a situation in which there are sufficient nodes to provide networking, but little or no supporting infrastructure. This is a rather unusual situation. Usually, if there is an opportunity to provide a fixed backbone, people will take it. If a stub network will do it, that is usually a more reliable, less expensive choice. On the other hand, if there are too few nodes in an area to support networking, then a MANET approach will not work and some sort of infrastructure must be provided. The area emergency response would be an example of a situation with enough nodes to support networking would be in an area that does not have a great deal of infrastructure. Of course, other examples are possible. The bottom line is that no one with sense would implement a MANET unless it was needed. With varying link capacity and mobile nodes, the situation is very difficult to manage. A big problem is the unstable backbone. In very dynamic cases, the best we can hope for is the avoidance of chaos. In all likelihood, MANET performance will always lag that of stable nets. The varying topology of the MANET is a complication that fixed nets do not have to deal with. If someone does come up with something that works under those conditions, in all likelihood, it work as well or better in a fixed net. For example, one key feature of MANETs is their "ad hoc" nature. The ability to join (or leave) a net without being computer gurus or having to call network services to hook us in is definitely a plus. If a reliable way to manage this is developed, it will probably become very popular in fixed nets and, maybe in the near future, ad hoc nets would become the norm. Thus, what could be, in the short run, an advantage of MANETS would quickly become a common feature of most nets. I don't think of "MANET" as a set of protocols, but a classification of the communications problem. MANETS differ in the frequency and degree at which the topology changes, as well as node density, size, etc. A protocol that works well in one MANET may not work well in another. One purpose of the MANET working group is to attempt to come up with a single protocol that works for all MANETs, but that protocol does not exist yet. For now, there are still MANET situations for which there are no good answers. But, that makes life more interesting. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 12:42 PM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] Ad-Hoc compared to TETRA I think of MANET as a family of protocols, yes of course. I don't see anything I said that implies I think MANET is a product, however. I think it pointless to give anything a label if it isn't to set boundaries around what this label describes. I would feel silly to call a couple of walkie talkies a "MANET." Years ago, when I was involved in the ATMF's wireless ATM working group, someone gave an example of emergency crews on the scene using wireless ATM among one another, for voice communications. But the example he described was far more efficiently served by broadcast radios with frequency division. Sorry, that didn't qualify in my book. Same situation here, and I think we agree. It might make MANET sound more impressive if one uses emergency crews as an example, but the risk is that you'll be looking hard for an answer to a question no one asked. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 19 16:55:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03314 for ; Wed, 19 Jun 2002 16:55:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28274 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 16:55:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27461; Wed, 19 Jun 2002 16:38:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27431 for ; Wed, 19 Jun 2002 16:38:31 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02933 for ; Wed, 19 Jun 2002 16:37:50 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 19 Jun 2002 14:37:59 -0600 Message-Id: <02Jun19.143759mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Wed, 19 Jun 2002 14:37:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, We seem to be in agreement, so I'm cutting most stuff for the sake of bandwidth. I use the area emergency response as an example of a situation in which there are sufficient nodes to provide networking, but little or no supporting infrastructure. This is a rather unusual situation. Usually, if there is an opportunity to provide a fixed backbone, people will take it. If a stub network will do it, that is usually a more reliable, less expensive choice. On the other hand, if there are too few nodes in an area to support networking, then a MANET approach will not work and some sort of infrastructure must be provided. The area emergency response would be an example of a situation with enough nodes to support networking would be in an area that does not have a great deal of infrastructure. Of course, other examples are possible. The bottom line is that no one with sense would implement a MANET unless it was needed. With varying link capacity and mobile nodes, the situation is very difficult to manage. A big problem is the unstable backbone. In very dynamic cases, the best we can hope for is the avoidance of chaos. In all likelihood, MANET performance will always lag that of stable nets. The varying topology of the MANET is a complication that fixed nets do not have to deal with. If someone does come up with something that works under those conditions, in all likelihood, it work as well or better in a fixed net. For example, one key feature of MANETs is their "ad hoc" nature. The ability to join (or leave) a net without being computer gurus or having to call network services to hook us in is definitely a plus. If a reliable way to manage this is developed, it will probably become very popular in fixed nets and, maybe in the near future, ad hoc nets would become the norm. Thus, what could be, in the short run, an advantage of MANETS would quickly become a common feature of most nets. I don't think of "MANET" as a set of protocols, but a classification of the communications problem. MANETS differ in the frequency and degree at which the topology changes, as well as node density, size, etc. A protocol that works well in one MANET may not work well in another. One purpose of the MANET working group is to attempt to come up with a single protocol that works for all MANETs, but that protocol does not exist yet. For now, there are still MANET situations for which there are no good answers. But, that makes life more interesting. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, June 19, 2002 12:42 PM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] Ad-Hoc compared to TETRA I think of MANET as a family of protocols, yes of course. I don't see anything I said that implies I think MANET is a product, however. I think it pointless to give anything a label if it isn't to set boundaries around what this label describes. I would feel silly to call a couple of walkie talkies a "MANET." Years ago, when I was involved in the ATMF's wireless ATM working group, someone gave an example of emergency crews on the scene using wireless ATM among one another, for voice communications. But the example he described was far more efficiently served by broadcast radios with frequency division. Sorry, that didn't qualify in my book. Same situation here, and I think we agree. It might make MANET sound more impressive if one uses emergency crews as an example, but the risk is that you'll be looking hard for an answer to a question no one asked. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jun 19 23:17:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09917 for ; Wed, 19 Jun 2002 23:17:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14717; Wed, 19 Jun 2002 23:05:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14690 for ; Wed, 19 Jun 2002 23:05:13 -0400 (EDT) Received: from pisces.katto.comm.waseda.ac.jp (IDENT:root@katto.comm.waseda.ac.jp [133.9.196.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09677 for ; Wed, 19 Jun 2002 23:04:32 -0400 (EDT) Received: from NISHIBA (pc045085.tokyo.ppp.waseda.ac.jp [133.9.45.85]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id MAA28906 for ; Thu, 20 Jun 2002 12:05:07 +0900 Message-ID: <003601c21807$47b7f0f0$552d0985@NISHIBA> From: "Yasuyuki Nishibayashi" To: Subject: [manet] About MANET CBR simmulation Date: Thu, 20 Jun 2002 12:05:02 +0900 Organization: Waseda Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear, MANET mailinglist users. I'm a graduate student of Waseda university (Japan), and researching about MANET routing protocols. My name is Yasuyuki Nishibayashi. I simulated the AODV protocol with the use of ns-2.1b9. (Number of nodes is 50, 10 traffic sources. 1500*300 topology, and pause time is 60 seconds.) But I found the strange result from the simulation. I wrote the two traffic patterns like below. (pattern1) using Application/Traffic/CBR Agent $cbr set PacketSize_ 500 $cbr set interval_ 0.25 This means transmission rate is 16Kbps. (pattern2) using Application/Traffic/CBR Agent $cbr set PacketSize_ 512 $cbr set rate_ 16Kb This also means transmission rate is 16Kbps. (The agent send a packet every 0.256 seconds.) There is an indiscencible difference between two patterns. But the simulation results are eye-opening differences. Please look at the link below. (4 hop away pairs.) The Green is pattern1,and the Red is pattern2. http://www.katto.comm.waseda.ac.jp/~nishiba/test.jpg In pattern1,the packet loss ratio is more than 30%, although pattern2's loss ratio is only 2%. It seems like no-route establishment for about 100 seconds in pattern1 (from the ns-trace file). Many packets were dropped and burst traffic was caused. I've already read the several articles about MANET simulation. ("Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks", "A Performance Comparison of Multihop Wireless AdHoc Networks"..etc) The simulation manner was clarified like "send 4packets per second ". Could it be better using "sending X packets per seconds" than "setting rates"? Setting rate (pattern2) is a wrong description? Shall I ask your advices about this problem? Thanks and Regards. //Yasuyuki Nishibayashi //Waseda Univ, Department of Communication and Information Engineering. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jun 19 23:17:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09928 for ; Wed, 19 Jun 2002 23:17:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA15314 for manet-archive@odin.ietf.org; Wed, 19 Jun 2002 23:18:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14717; Wed, 19 Jun 2002 23:05:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14690 for ; Wed, 19 Jun 2002 23:05:13 -0400 (EDT) Received: from pisces.katto.comm.waseda.ac.jp (IDENT:root@katto.comm.waseda.ac.jp [133.9.196.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09677 for ; Wed, 19 Jun 2002 23:04:32 -0400 (EDT) Received: from NISHIBA (pc045085.tokyo.ppp.waseda.ac.jp [133.9.45.85]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id MAA28906 for ; Thu, 20 Jun 2002 12:05:07 +0900 Message-ID: <003601c21807$47b7f0f0$552d0985@NISHIBA> From: "Yasuyuki Nishibayashi" To: Subject: [manet] About MANET CBR simmulation Date: Thu, 20 Jun 2002 12:05:02 +0900 Organization: Waseda Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear, MANET mailinglist users. I'm a graduate student of Waseda university (Japan), and researching about MANET routing protocols. My name is Yasuyuki Nishibayashi. I simulated the AODV protocol with the use of ns-2.1b9. (Number of nodes is 50, 10 traffic sources. 1500*300 topology, and pause time is 60 seconds.) But I found the strange result from the simulation. I wrote the two traffic patterns like below. (pattern1) using Application/Traffic/CBR Agent $cbr set PacketSize_ 500 $cbr set interval_ 0.25 This means transmission rate is 16Kbps. (pattern2) using Application/Traffic/CBR Agent $cbr set PacketSize_ 512 $cbr set rate_ 16Kb This also means transmission rate is 16Kbps. (The agent send a packet every 0.256 seconds.) There is an indiscencible difference between two patterns. But the simulation results are eye-opening differences. Please look at the link below. (4 hop away pairs.) The Green is pattern1,and the Red is pattern2. http://www.katto.comm.waseda.ac.jp/~nishiba/test.jpg In pattern1,the packet loss ratio is more than 30%, although pattern2's loss ratio is only 2%. It seems like no-route establishment for about 100 seconds in pattern1 (from the ns-trace file). Many packets were dropped and burst traffic was caused. I've already read the several articles about MANET simulation. ("Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks", "A Performance Comparison of Multihop Wireless AdHoc Networks"..etc) The simulation manner was clarified like "send 4packets per second ". Could it be better using "sending X packets per seconds" than "setting rates"? Setting rate (pattern2) is a wrong description? Shall I ask your advices about this problem? Thanks and Regards. //Yasuyuki Nishibayashi //Waseda Univ, Department of Communication and Information Engineering. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 06:02:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23197 for ; Thu, 20 Jun 2002 06:02:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08826; Thu, 20 Jun 2002 05:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08795 for ; Thu, 20 Jun 2002 05:47:14 -0400 (EDT) Received: from news.comp.lancs.ac.uk (news.comp.lancs.ac.uk [148.88.152.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22951 for ; Thu, 20 Jun 2002 05:46:33 -0400 (EDT) Received: from egcsky000004 (egcsky000004.lancs.ac.uk [148.88.155.217]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with ESMTP id g5K9lBq10842 for ; Thu, 20 Jun 2002 10:47:12 +0100 (BST) From: "Daniel Prince" To: Date: Thu, 20 Jun 2002 10:47:11 +0100 Message-ID: <45EA1063C2F8D211915800204808343B02F8B8C7@exchange1.lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <45EA1063C2F8D211915800204808343B038021F9@exchange1.lancs.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] Device Driver APIs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Everyone, I was wondering if anybody out there knows where to get hold of the APIs for the windows drivers for 802.11 cards for Cisco, Lucent etc, as I want to be able to register for media events such as other interfaces leaving or joining. Many Thanks, Daniel Daniel Prince M.Eng. Computing Department, Lancaster University, Lancaster, LA1 4YR, UK Tel: 01524 594143, Fax: 01524 593608 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 06:02:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23207 for ; Thu, 20 Jun 2002 06:02:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10118 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 06:03:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08826; Thu, 20 Jun 2002 05:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08795 for ; Thu, 20 Jun 2002 05:47:14 -0400 (EDT) Received: from news.comp.lancs.ac.uk (news.comp.lancs.ac.uk [148.88.152.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22951 for ; Thu, 20 Jun 2002 05:46:33 -0400 (EDT) Received: from egcsky000004 (egcsky000004.lancs.ac.uk [148.88.155.217]) by news.comp.lancs.ac.uk (8.11.0/8.11.0) with ESMTP id g5K9lBq10842 for ; Thu, 20 Jun 2002 10:47:12 +0100 (BST) From: "Daniel Prince" To: Date: Thu, 20 Jun 2002 10:47:11 +0100 Message-ID: <45EA1063C2F8D211915800204808343B02F8B8C7@exchange1.lancs.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <45EA1063C2F8D211915800204808343B038021F9@exchange1.lancs.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] Device Driver APIs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Everyone, I was wondering if anybody out there knows where to get hold of the APIs for the windows drivers for 802.11 cards for Cisco, Lucent etc, as I want to be able to register for media events such as other interfaces leaving or joining. Many Thanks, Daniel Daniel Prince M.Eng. Computing Department, Lancaster University, Lancaster, LA1 4YR, UK Tel: 01524 594143, Fax: 01524 593608 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 10:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01206 for ; Thu, 20 Jun 2002 10:25:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23457; Thu, 20 Jun 2002 10:01:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23433 for ; Thu, 20 Jun 2002 10:01:51 -0400 (EDT) Received: from amsterdam.lcs.mit.edu (amsterdam.lcs.mit.edu [18.26.4.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00358 for ; Thu, 20 Jun 2002 10:01:10 -0400 (EDT) Received: from lcs.mit.edu (bermuda.lcs.mit.edu [18.26.4.25]) by amsterdam.lcs.mit.edu (8.11.6/8.11.6) with ESMTP id g5KE1lR65216; Thu, 20 Jun 2002 10:01:47 -0400 (EDT) (envelope-from decouto@lcs.mit.edu) Message-ID: <3D11E04B.8090601@lcs.mit.edu> Date: Thu, 20 Jun 2002 10:01:47 -0400 From: "Douglas S. J. De Couto" Reply-To: decouto@lcs.mit.edu Organization: MIT LCS User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dyoung@pobox.com, manet@ietf.org Subject: Re: [manet] on-demand routing for BSD? References: <20020619151603.A31659@che.onthejob.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit David Young wrote: > Does any AODV implementation exist for *BSD? > > It seems like a purely "userland" implementation of AODV, DSR, and > other varieties of on-demand ad hoc routing are impossible because they > require the kernel queue packets without nexthops for long enough that > route discovery can be attempted. BSD kernels, however, discard packets > immediately when they do not know a nexthop. or you could handle the queuing and route lookup in userland, using e.g. the click modular router (http://pdos.lcs.mit.edu/click). we have a protocol that combines DSDV and geographic forwarding implemented in userlevel click (http://pdos.lcs.mit.edu/grid). others have implemented DSR, AODV, and TORA using click (http://systems.cs.colorado.edu/Networking/modular-adhoc.html) d -- Douglas S. J. De Couto decouto@lcs.mit.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 10:25:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01216 for ; Thu, 20 Jun 2002 10:25:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24915 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 10:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23457; Thu, 20 Jun 2002 10:01:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23433 for ; Thu, 20 Jun 2002 10:01:51 -0400 (EDT) Received: from amsterdam.lcs.mit.edu (amsterdam.lcs.mit.edu [18.26.4.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00358 for ; Thu, 20 Jun 2002 10:01:10 -0400 (EDT) Received: from lcs.mit.edu (bermuda.lcs.mit.edu [18.26.4.25]) by amsterdam.lcs.mit.edu (8.11.6/8.11.6) with ESMTP id g5KE1lR65216; Thu, 20 Jun 2002 10:01:47 -0400 (EDT) (envelope-from decouto@lcs.mit.edu) Message-ID: <3D11E04B.8090601@lcs.mit.edu> Date: Thu, 20 Jun 2002 10:01:47 -0400 From: "Douglas S. J. De Couto" Reply-To: decouto@lcs.mit.edu Organization: MIT LCS User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dyoung@pobox.com, manet@ietf.org Subject: Re: [manet] on-demand routing for BSD? References: <20020619151603.A31659@che.onthejob.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit David Young wrote: > Does any AODV implementation exist for *BSD? > > It seems like a purely "userland" implementation of AODV, DSR, and > other varieties of on-demand ad hoc routing are impossible because they > require the kernel queue packets without nexthops for long enough that > route discovery can be attempted. BSD kernels, however, discard packets > immediately when they do not know a nexthop. or you could handle the queuing and route lookup in userland, using e.g. the click modular router (http://pdos.lcs.mit.edu/click). we have a protocol that combines DSDV and geographic forwarding implemented in userlevel click (http://pdos.lcs.mit.edu/grid). others have implemented DSR, AODV, and TORA using click (http://systems.cs.colorado.edu/Networking/modular-adhoc.html) d -- Douglas S. J. De Couto decouto@lcs.mit.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 11:03:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02617 for ; Thu, 20 Jun 2002 11:03:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26344; Thu, 20 Jun 2002 10:49:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26311 for ; Thu, 20 Jun 2002 10:49:02 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02074 for ; Thu, 20 Jun 2002 10:48:20 -0400 (EDT) Received: from gatekeeper.ececs.uc.edu (gatekeeper.ececs.uc.edu [10.63.3.227]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5KEmTVN013659 for ; Thu, 20 Jun 2002 10:48:29 -0400 (EDT) Received: from localhost (jains@localhost) by gatekeeper.ececs.uc.edu (8.10.2+Sun/8.9.1) with ESMTP id g5KEmTo00939 for ; Thu, 20 Jun 2002 10:48:29 -0400 (EDT) X-Authentication-Warning: gatekeeper.ececs.uc.edu: jains owned process doing -bs Date: Thu, 20 Jun 2002 10:48:28 -0400 (EDT) From: Saurabh Jain To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] TBRPF source code Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello. Would anyone know where I can get the source code of TBRPF? I applied online at http://www.erg.sri.com/projects/tbrpf/sourcecode.html but have not received a response. I wish to simulate a rural network where the backbone is wireless. Thanks Saurabh Jain -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ saurabh@ee.iitm.ernet.in Home: +1-513-556-7447, Lab: 556-3437 #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219 SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42 Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 11:03:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02627 for ; Thu, 20 Jun 2002 11:03:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27799 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 11:04:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26344; Thu, 20 Jun 2002 10:49:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26311 for ; Thu, 20 Jun 2002 10:49:02 -0400 (EDT) Received: from mail.ececs.uc.edu (mail.ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02074 for ; Thu, 20 Jun 2002 10:48:20 -0400 (EDT) Received: from gatekeeper.ececs.uc.edu (gatekeeper.ececs.uc.edu [10.63.3.227]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5KEmTVN013659 for ; Thu, 20 Jun 2002 10:48:29 -0400 (EDT) Received: from localhost (jains@localhost) by gatekeeper.ececs.uc.edu (8.10.2+Sun/8.9.1) with ESMTP id g5KEmTo00939 for ; Thu, 20 Jun 2002 10:48:29 -0400 (EDT) X-Authentication-Warning: gatekeeper.ececs.uc.edu: jains owned process doing -bs Date: Thu, 20 Jun 2002 10:48:28 -0400 (EDT) From: Saurabh Jain To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] TBRPF source code Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello. Would anyone know where I can get the source code of TBRPF? I applied online at http://www.erg.sri.com/projects/tbrpf/sourcecode.html but have not received a response. I wish to simulate a rural network where the backbone is wireless. Thanks Saurabh Jain -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ saurabh@ee.iitm.ernet.in Home: +1-513-556-7447, Lab: 556-3437 #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219 SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42 Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 12:39:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05673 for ; Thu, 20 Jun 2002 12:39:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03368; Thu, 20 Jun 2002 12:24:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03339 for ; Thu, 20 Jun 2002 12:24:34 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05238 for ; Thu, 20 Jun 2002 12:23:52 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 20 Jun 2002 10:24:28 -0600 Message-Id: <02Jun20.102428mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Josephson, William" , "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Thu, 20 Jun 2002 10:24:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi William, Well, sorta... In many civilian situations, the satellite is a good resource. The UAVs might be a bit much at this time, but their price will eventually come down. For example, see http://www.personal.psu.edu/faculty/l/n/lnl/rc/ In the military arena, a number of developers have hyped the satellite and UAVs up, but they always do that with every project. :-) Both UAVs and satellites are vulnerable to a number of threats. In the first attempt to get an Army satellite up (late 70s), there was a delay in establishing terrestrial stations. By the time the Army got them working, they discovered someone had pirated their satellite. (Nothing sinister, just some guy who saw an opportunity to make a few quick bucks and took it). They had to modify their terrestrial stations to operate at higher power in order to get the satellite back. As far as UAVs go, the current philosophy seems to be that they are best used where human pilots would be most at risk, so their current attrition rate is pretty high. It is hard to say how long they would stay up if simply performing a relay function. However, their primary LOS advantage for communications also makes them an obvious target. Beyond that, neither are physically connected to each other, other nodes, or any wired infrastructure. Because they must rely on radio links to remain connected, they can be jammed. (Of course, the link from a mobile node to a base station can be jammed, too, but not the wire link from the base station to the backbone). If we use geostationary satellites, we must have sophisticated antennas to communicate with the satellite because of the range (36,000 km). If we use lower orbits we can use antennas with less focused beams, but now the satellite is a moving target that must be tracked by the node to remain in contact. The UAV is a moving target, but omnidirectional antennas would probably work. Staying in its LOS footprint might be a bigger problem. Neither are exceptionally good alternatives in certain locations. For example, in mountainous territory, there may be large regions in which neither the satellite nor the UAV can cover. In urban areas, there is a similar problem. For satellites in equatorial orbits, coverage is spotty in extreme northern or southern locations. Also, if you have cable TV, you are aware of the problems caused by sunspot activity. If you've seen satellite reports on TV, you are also aware of the nearly two second round-trip delay, which leads to an immense bandwidth product and associated difficulties with network communications. Because they do not necessarily have a reliable connection to each other or the rest of the world, I would think of them more as relay nodes than base stations. I think their primary function is to provide sufficient node density in an area to maintain connectivity in the MANET, but not as base stations per se. Developer hype notwithstanding :-) John Mullen -----Original Message----- From: Josephson, William [mailto:William.Josephson@GDC4S.Com] Sent: Thursday, June 20, 2002 9:31 AM To: 'Mullen, John P. (Contractor)'; Manfredi, Albert E Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA One shouldn't forget that UAVs and satellites can play a part in a MANET. So these can be the base stations. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 12:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05685 for ; Thu, 20 Jun 2002 12:39:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04664 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 12:40:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03368; Thu, 20 Jun 2002 12:24:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03339 for ; Thu, 20 Jun 2002 12:24:34 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05238 for ; Thu, 20 Jun 2002 12:23:52 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 20 Jun 2002 10:24:28 -0600 Message-Id: <02Jun20.102428mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Josephson, William" , "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Thu, 20 Jun 2002 10:24:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi William, Well, sorta... In many civilian situations, the satellite is a good resource. The UAVs might be a bit much at this time, but their price will eventually come down. For example, see http://www.personal.psu.edu/faculty/l/n/lnl/rc/ In the military arena, a number of developers have hyped the satellite and UAVs up, but they always do that with every project. :-) Both UAVs and satellites are vulnerable to a number of threats. In the first attempt to get an Army satellite up (late 70s), there was a delay in establishing terrestrial stations. By the time the Army got them working, they discovered someone had pirated their satellite. (Nothing sinister, just some guy who saw an opportunity to make a few quick bucks and took it). They had to modify their terrestrial stations to operate at higher power in order to get the satellite back. As far as UAVs go, the current philosophy seems to be that they are best used where human pilots would be most at risk, so their current attrition rate is pretty high. It is hard to say how long they would stay up if simply performing a relay function. However, their primary LOS advantage for communications also makes them an obvious target. Beyond that, neither are physically connected to each other, other nodes, or any wired infrastructure. Because they must rely on radio links to remain connected, they can be jammed. (Of course, the link from a mobile node to a base station can be jammed, too, but not the wire link from the base station to the backbone). If we use geostationary satellites, we must have sophisticated antennas to communicate with the satellite because of the range (36,000 km). If we use lower orbits we can use antennas with less focused beams, but now the satellite is a moving target that must be tracked by the node to remain in contact. The UAV is a moving target, but omnidirectional antennas would probably work. Staying in its LOS footprint might be a bigger problem. Neither are exceptionally good alternatives in certain locations. For example, in mountainous territory, there may be large regions in which neither the satellite nor the UAV can cover. In urban areas, there is a similar problem. For satellites in equatorial orbits, coverage is spotty in extreme northern or southern locations. Also, if you have cable TV, you are aware of the problems caused by sunspot activity. If you've seen satellite reports on TV, you are also aware of the nearly two second round-trip delay, which leads to an immense bandwidth product and associated difficulties with network communications. Because they do not necessarily have a reliable connection to each other or the rest of the world, I would think of them more as relay nodes than base stations. I think their primary function is to provide sufficient node density in an area to maintain connectivity in the MANET, but not as base stations per se. Developer hype notwithstanding :-) John Mullen -----Original Message----- From: Josephson, William [mailto:William.Josephson@GDC4S.Com] Sent: Thursday, June 20, 2002 9:31 AM To: 'Mullen, John P. (Contractor)'; Manfredi, Albert E Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA One shouldn't forget that UAVs and satellites can play a part in a MANET. So these can be the base stations. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 12:59:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06665 for ; Thu, 20 Jun 2002 12:59:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04784; Thu, 20 Jun 2002 12:43:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04752 for ; Thu, 20 Jun 2002 12:43:23 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05792 for ; Thu, 20 Jun 2002 12:42:42 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA27012; Thu, 20 Jun 2002 09:43:20 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA27207; Thu, 20 Jun 2002 11:43:19 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5KGhHR17046; Thu, 20 Jun 2002 09:43:17 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jun 2002 12:43:17 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Josephson, William'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Thu, 20 Jun 2002 12:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > -----Original Message----- > From: Josephson, William [mailto:William.Josephson@GDC4S.Com] > > One shouldn't forget that UAVs and satellites can play a part > in a MANET. > > So these can be the base stations. Agreed. I'd break that down into different categories, to decide whether the system qualifies as a MANET or not. 1. If these satellite base stations are stationary with respect to the earth's surface, for example satellites in geosynchronous orbit that also provide routing services, then this would not qualify as MANET. The satellites are merely an extension of the fixed Internet. 2. If the satellites are providing "bent pipes" only, and the routers are stationary on the earth's surface, again, I don't see where the resulting IP structure would be a MANET. It would be an extension of the fixed Internet. 3. If the satellites (or manned aircraft or UAVs) are not geosynchronous, and are providing routing services for devices not located on those moving platforms, or are providing a link to the fixed Internet by continuously handing over to new links to the fixed Internet as the vehicle moves, then we have the difficult problem MANET addresses. The qualifications in #3 are important, IMO. You can postulate a case where aircraft are connected to the fixed Internet via a satellite link, routing services are only provided for hosts on that aircraft, and the satellite link always ties the aircraft to a single location on the earth's surface, where a router connects to the fixed Internet. In this scenario, there again is nothing MANET about the network, IMO. The routing problem sees all the hosts on the aircraft as being in a fixed location with respect to the earth's surface. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 12:59:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06674 for ; Thu, 20 Jun 2002 12:59:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06455 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 13:00:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04784; Thu, 20 Jun 2002 12:43:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04752 for ; Thu, 20 Jun 2002 12:43:23 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05792 for ; Thu, 20 Jun 2002 12:42:42 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA27012; Thu, 20 Jun 2002 09:43:20 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA27207; Thu, 20 Jun 2002 11:43:19 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5KGhHR17046; Thu, 20 Jun 2002 09:43:17 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jun 2002 12:43:17 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Josephson, William'" Cc: manet@ietf.org Subject: RE: [manet] Ad-Hoc compared to TETRA Date: Thu, 20 Jun 2002 12:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > -----Original Message----- > From: Josephson, William [mailto:William.Josephson@GDC4S.Com] > > One shouldn't forget that UAVs and satellites can play a part > in a MANET. > > So these can be the base stations. Agreed. I'd break that down into different categories, to decide whether the system qualifies as a MANET or not. 1. If these satellite base stations are stationary with respect to the earth's surface, for example satellites in geosynchronous orbit that also provide routing services, then this would not qualify as MANET. The satellites are merely an extension of the fixed Internet. 2. If the satellites are providing "bent pipes" only, and the routers are stationary on the earth's surface, again, I don't see where the resulting IP structure would be a MANET. It would be an extension of the fixed Internet. 3. If the satellites (or manned aircraft or UAVs) are not geosynchronous, and are providing routing services for devices not located on those moving platforms, or are providing a link to the fixed Internet by continuously handing over to new links to the fixed Internet as the vehicle moves, then we have the difficult problem MANET addresses. The qualifications in #3 are important, IMO. You can postulate a case where aircraft are connected to the fixed Internet via a satellite link, routing services are only provided for hosts on that aircraft, and the satellite link always ties the aircraft to a single location on the earth's surface, where a router connects to the fixed Internet. In this scenario, there again is nothing MANET about the network, IMO. The routing problem sees all the hosts on the aircraft as being in a fixed location with respect to the earth's surface. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 15:10:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10858 for ; Thu, 20 Jun 2002 15:10:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12322; Thu, 20 Jun 2002 14:45:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12293 for ; Thu, 20 Jun 2002 14:45:33 -0400 (EDT) Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10074 for ; Thu, 20 Jun 2002 14:44:51 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A39C26416E for ; Thu, 20 Jun 2002 14:45:01 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with SMTP id g5KIj0ra022358; Thu, 20 Jun 2002 14:45:00 -0400 (EDT) From: Daniel Oldham Date: Thu, 20 Jun 2002 18:45:01 GMT Message-ID: <20020620.18450100@doldham.lerc.nasa.gov> Subject: RE: [manet] Ad-Hoc compared to TETRA To: "Manfredi, Albert E" Cc: "'Josephson, William'" , manet@ietf.org, oldham@grc.nasa.gov In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id OAA12294 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Bert: I would like to add my two cents to the satellite discussion about MANET. Satellites are normally classified based on their orbital regimes as low earth orbit (LEO), medium earth orbit (MEO), geosynchronous orbit (GEO) or deep space escape. The altitude of LEO is generally above the atmosphere and below the first Van Allen radiation belt or below 1000 km. MEO lies between the first and second Van Allen radiation belts or above 1,000 km and below 10,000 km. GEO is uniquely at 35,786 km, in order to synchronize the orbit of the satellite with the spin of the Earth. GEO satellites then appear stationary in the sky. Besides altitude, there are five orbital parameters, including inclination and eccentricity. Inclination is the tilt relative to the equatorial plane and eccentricity is the shape of the orbit. Deep space escape has an eccentricity of a parabola or hyperbola and the satellite, in effect leaves Earth orbit and goes around the Sun. Most GEO satellites are as you say, bent-pipes in the sky that receive, translate and retransmit the information. Most of the non-GEO satellite systems have highly optimized communication systems that store and dump information to a ground station when it passes over head or transfers the information to a data relay satellite in GEO. These space to ground systems are one to one and therefore not of interest for MANET. Of the LEO and MEO satellite systems to consider for MANET are the distributed satellite system that consist of multiple satellites that interact and cooperate to achieve mission goals. These systems can be broken into two types of crosslink communication systems, constellation and formation flying missions. Iridium is an example of a constellation system with crosslink communications. They use a fixed infrastructure to simplify the communication issues. In this case the satellites communication with the satellites in the same or adjacent orbital planes so that it appears the neighboring satellites are not moving. A constellation system is a good application for MANET if you can address all the communication issues. I well be happy to expand of these issues if you are interested. The formation flying systems can be broken down into crosslink communication systems with a centralized or distributed topology. The centralized systems have a "mothership" as the primary spacecraft and "daughter" spacecraft as secondary spacecraft. Again this system is not of interest for MANET because of the centralized topology. The distributed systems do not have a single point of control within the formation and therefore a good application for MANET. In formation flying the satellites do not move very much in relationship to each other but the topology requires this type of communication system. I hope that helps... -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 6/20/02, 12:43:16 PM, "Manfredi, Albert E" wrote regarding RE: [manet] Ad-Hoc compared to TETRA: > > -----Original Message----- > > From: Josephson, William [mailto:William.Josephson@GDC4S.Com] > > > > One shouldn't forget that UAVs and satellites can play a part > > in a MANET. > > > > So these can be the base stations. > Agreed. > I'd break that down into different categories, to decide whether the system qualifies as a MANET or not. > 1. If these satellite base stations are stationary with respect to the earth's surface, for example satellites in geosynchronous orbit that also provide routing services, then this would not qualify as MANET. The satellites are merely an extension of the fixed Internet. > 2. If the satellites are providing "bent pipes" only, and the routers are stationary on the earth's surface, again, I don't see where the resulting IP structure would be a MANET. It would be an extension of the fixed Internet. > 3. If the satellites (or manned aircraft or UAVs) are not geosynchronous, and are providing routing services for devices not located on those moving platforms, or are providing a link to the fixed Internet by continuously handing over to new links to the fixed Internet as the vehicle moves, then we have the difficult problem MANET addresses. > The qualifications in #3 are important, IMO. You can postulate a case where aircraft are connected to the fixed Internet via a satellite link, routing services are only provided for hosts on that aircraft, and the satellite link always ties the aircraft to a single location on the earth's surface, where a router connects to the fixed Internet. In this scenario, there again is nothing MANET about the network, IMO. The routing problem sees all the hosts on the aircraft as being in a fixed location with respect to the earth's surface. > Bert > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 15:10:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10866 for ; Thu, 20 Jun 2002 15:10:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13998 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 15:11:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12322; Thu, 20 Jun 2002 14:45:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12293 for ; Thu, 20 Jun 2002 14:45:33 -0400 (EDT) Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10074 for ; Thu, 20 Jun 2002 14:44:51 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A39C26416E for ; Thu, 20 Jun 2002 14:45:01 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with SMTP id g5KIj0ra022358; Thu, 20 Jun 2002 14:45:00 -0400 (EDT) From: Daniel Oldham Date: Thu, 20 Jun 2002 18:45:01 GMT Message-ID: <20020620.18450100@doldham.lerc.nasa.gov> Subject: RE: [manet] Ad-Hoc compared to TETRA To: "Manfredi, Albert E" Cc: "'Josephson, William'" , manet@ietf.org, oldham@grc.nasa.gov In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A399D@xch-ne-02.ne.nos.boeing.com> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) 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 optimus.ietf.org id OAA12294 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Bert: I would like to add my two cents to the satellite discussion about MANET. Satellites are normally classified based on their orbital regimes as low earth orbit (LEO), medium earth orbit (MEO), geosynchronous orbit (GEO) or deep space escape. The altitude of LEO is generally above the atmosphere and below the first Van Allen radiation belt or below 1000 km. MEO lies between the first and second Van Allen radiation belts or above 1,000 km and below 10,000 km. GEO is uniquely at 35,786 km, in order to synchronize the orbit of the satellite with the spin of the Earth. GEO satellites then appear stationary in the sky. Besides altitude, there are five orbital parameters, including inclination and eccentricity. Inclination is the tilt relative to the equatorial plane and eccentricity is the shape of the orbit. Deep space escape has an eccentricity of a parabola or hyperbola and the satellite, in effect leaves Earth orbit and goes around the Sun. Most GEO satellites are as you say, bent-pipes in the sky that receive, translate and retransmit the information. Most of the non-GEO satellite systems have highly optimized communication systems that store and dump information to a ground station when it passes over head or transfers the information to a data relay satellite in GEO. These space to ground systems are one to one and therefore not of interest for MANET. Of the LEO and MEO satellite systems to consider for MANET are the distributed satellite system that consist of multiple satellites that interact and cooperate to achieve mission goals. These systems can be broken into two types of crosslink communication systems, constellation and formation flying missions. Iridium is an example of a constellation system with crosslink communications. They use a fixed infrastructure to simplify the communication issues. In this case the satellites communication with the satellites in the same or adjacent orbital planes so that it appears the neighboring satellites are not moving. A constellation system is a good application for MANET if you can address all the communication issues. I well be happy to expand of these issues if you are interested. The formation flying systems can be broken down into crosslink communication systems with a centralized or distributed topology. The centralized systems have a "mothership" as the primary spacecraft and "daughter" spacecraft as secondary spacecraft. Again this system is not of interest for MANET because of the centralized topology. The distributed systems do not have a single point of control within the formation and therefore a good application for MANET. In formation flying the satellites do not move very much in relationship to each other but the topology requires this type of communication system. I hope that helps... -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 6/20/02, 12:43:16 PM, "Manfredi, Albert E" wrote regarding RE: [manet] Ad-Hoc compared to TETRA: > > -----Original Message----- > > From: Josephson, William [mailto:William.Josephson@GDC4S.Com] > > > > One shouldn't forget that UAVs and satellites can play a part > > in a MANET. > > > > So these can be the base stations. > Agreed. > I'd break that down into different categories, to decide whether the system qualifies as a MANET or not. > 1. If these satellite base stations are stationary with respect to the earth's surface, for example satellites in geosynchronous orbit that also provide routing services, then this would not qualify as MANET. The satellites are merely an extension of the fixed Internet. > 2. If the satellites are providing "bent pipes" only, and the routers are stationary on the earth's surface, again, I don't see where the resulting IP structure would be a MANET. It would be an extension of the fixed Internet. > 3. If the satellites (or manned aircraft or UAVs) are not geosynchronous, and are providing routing services for devices not located on those moving platforms, or are providing a link to the fixed Internet by continuously handing over to new links to the fixed Internet as the vehicle moves, then we have the difficult problem MANET addresses. > The qualifications in #3 are important, IMO. You can postulate a case where aircraft are connected to the fixed Internet via a satellite link, routing services are only provided for hosts on that aircraft, and the satellite link always ties the aircraft to a single location on the earth's surface, where a router connects to the fixed Internet. In this scenario, there again is nothing MANET about the network, IMO. The routing problem sees all the hosts on the aircraft as being in a fixed location with respect to the earth's surface. > Bert > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 17:46:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13637 for ; Thu, 20 Jun 2002 17:46:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20241; Thu, 20 Jun 2002 17:20:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20210 for ; Thu, 20 Jun 2002 17:19:53 -0400 (EDT) Received: from bos-gate4.raytheon.com (bos-gate4.raytheon.com [199.46.198.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12849 for ; Thu, 20 Jun 2002 17:19:12 -0400 (EDT) Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate4.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5KLJpL09315; Thu, 20 Jun 2002 17:19:51 -0400 (EDT) Received: from ds02e00.directory.ray.com (root@localhost) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5KLJlSp005298; Thu, 20 Jun 2002 17:19:49 -0400 (EDT) Received: from mailhub.fcd.esys.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5KLJj79005266; Thu, 20 Jun 2002 17:19:46 -0400 (EDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fcd.esys.com (8.9.3/8.9.3) with ESMTP id RAA11625; Thu, 20 Jun 2002 17:17:50 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 17:17:51 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002AAB673@fcexchange.fal.us.ray.com> From: "Su, William" To: nishiba@katto.comm.waseda.ac.jp Cc: manet@ietf.org Subject: RE: [manet] About MANET CBR simmulation Date: Thu, 20 Jun 2002 17:17:50 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yasuyuki, Just curious, what kind of MAC layer protocol did you configure the simulation? Is it 802.11 or CSMA? One thing you can check to see is why the packets are being dropped in pattern1 (could it be collisions, queue overflows, ...etc) Not too sure about why no route established for 100 seconds in pattern1, were there any trace of any Route-REQ messages or Route-Reply messages coming back? William > -----Original Message----- > From: "Yasuyuki Nishibayashi" > To: > Subject: [manet] About MANET CBR simmulation > Date: Thu, 20 Jun 2002 12:05:02 +0900 > Organization: Waseda Univ. > charset="iso-2022-jp" > Dear, MANET mailinglist users. > I'm a graduate student of Waseda university (Japan), > and researching about MANET routing protocols. > My name is Yasuyuki Nishibayashi. > I simulated the AODV protocol with the use of ns-2.1b9. > (Number of nodes is 50, 10 traffic sources. > 1500*300 topology, and pause time is 60 seconds.) > But I found the strange result from the simulation. > I wrote the two traffic patterns like below. > (pattern1) > using Application/Traffic/CBR Agent > $cbr set PacketSize_ 500 > $cbr set interval_ 0.25 > This means transmission rate is 16Kbps. > (pattern2) > using Application/Traffic/CBR Agent > $cbr set PacketSize_ 512 > $cbr set rate_ 16Kb > This also means transmission rate is 16Kbps. > (The agent send a packet every 0.256 seconds.) > There is an indiscencible difference between two patterns. > But the simulation results are eye-opening differences. > Please look at the link below. > (4 hop away pairs.) > The Green is pattern1,and the Red is pattern2. > http://www.katto.comm.waseda.ac.jp/~nishiba/test.jpg > In pattern1,the packet loss ratio is more than 30%, > although pattern2's loss ratio is only 2%. > It seems like no-route establishment for about 100 seconds > in pattern1 (from the ns-trace file). > Many packets were dropped and burst traffic was caused. > I've already read the several articles about MANET simulation. > ("Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc > Networks", > "A Performance Comparison of Multihop Wireless AdHoc Networks"..etc) > The simulation manner was clarified like "send 4packets per second ". > Could it be better using "sending X packets per seconds" > than "setting rates"? > Setting rate (pattern2) is a wrong description? > Shall I ask your advices about this problem? > Thanks and Regards. > //Yasuyuki Nishibayashi > //Waseda Univ, Department of Communication and Information Engineering. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 17:46:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13647 for ; Thu, 20 Jun 2002 17:46:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23408 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 17:46:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20241; Thu, 20 Jun 2002 17:20:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20210 for ; Thu, 20 Jun 2002 17:19:53 -0400 (EDT) Received: from bos-gate4.raytheon.com (bos-gate4.raytheon.com [199.46.198.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12849 for ; Thu, 20 Jun 2002 17:19:12 -0400 (EDT) Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate4.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5KLJpL09315; Thu, 20 Jun 2002 17:19:51 -0400 (EDT) Received: from ds02e00.directory.ray.com (root@localhost) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5KLJlSp005298; Thu, 20 Jun 2002 17:19:49 -0400 (EDT) Received: from mailhub.fcd.esys.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5KLJj79005266; Thu, 20 Jun 2002 17:19:46 -0400 (EDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fcd.esys.com (8.9.3/8.9.3) with ESMTP id RAA11625; Thu, 20 Jun 2002 17:17:50 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 17:17:51 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002AAB673@fcexchange.fal.us.ray.com> From: "Su, William" To: nishiba@katto.comm.waseda.ac.jp Cc: manet@ietf.org Subject: RE: [manet] About MANET CBR simmulation Date: Thu, 20 Jun 2002 17:17:50 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yasuyuki, Just curious, what kind of MAC layer protocol did you configure the simulation? Is it 802.11 or CSMA? One thing you can check to see is why the packets are being dropped in pattern1 (could it be collisions, queue overflows, ...etc) Not too sure about why no route established for 100 seconds in pattern1, were there any trace of any Route-REQ messages or Route-Reply messages coming back? William > -----Original Message----- > From: "Yasuyuki Nishibayashi" > To: > Subject: [manet] About MANET CBR simmulation > Date: Thu, 20 Jun 2002 12:05:02 +0900 > Organization: Waseda Univ. > charset="iso-2022-jp" > Dear, MANET mailinglist users. > I'm a graduate student of Waseda university (Japan), > and researching about MANET routing protocols. > My name is Yasuyuki Nishibayashi. > I simulated the AODV protocol with the use of ns-2.1b9. > (Number of nodes is 50, 10 traffic sources. > 1500*300 topology, and pause time is 60 seconds.) > But I found the strange result from the simulation. > I wrote the two traffic patterns like below. > (pattern1) > using Application/Traffic/CBR Agent > $cbr set PacketSize_ 500 > $cbr set interval_ 0.25 > This means transmission rate is 16Kbps. > (pattern2) > using Application/Traffic/CBR Agent > $cbr set PacketSize_ 512 > $cbr set rate_ 16Kb > This also means transmission rate is 16Kbps. > (The agent send a packet every 0.256 seconds.) > There is an indiscencible difference between two patterns. > But the simulation results are eye-opening differences. > Please look at the link below. > (4 hop away pairs.) > The Green is pattern1,and the Red is pattern2. > http://www.katto.comm.waseda.ac.jp/~nishiba/test.jpg > In pattern1,the packet loss ratio is more than 30%, > although pattern2's loss ratio is only 2%. > It seems like no-route establishment for about 100 seconds > in pattern1 (from the ns-trace file). > Many packets were dropped and burst traffic was caused. > I've already read the several articles about MANET simulation. > ("Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc > Networks", > "A Performance Comparison of Multihop Wireless AdHoc Networks"..etc) > The simulation manner was clarified like "send 4packets per second ". > Could it be better using "sending X packets per seconds" > than "setting rates"? > Setting rate (pattern2) is a wrong description? > Shall I ask your advices about this problem? > Thanks and Regards. > //Yasuyuki Nishibayashi > //Waseda Univ, Department of Communication and Information Engineering. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 20 23:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20225 for ; Thu, 20 Jun 2002 23:13:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07543; Thu, 20 Jun 2002 23:00:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07507 for ; Thu, 20 Jun 2002 23:00:26 -0400 (EDT) Received: from pisces.katto.comm.waseda.ac.jp (IDENT:root@katto.comm.waseda.ac.jp [133.9.196.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20015 for ; Thu, 20 Jun 2002 22:59:44 -0400 (EDT) Received: from NISHIBA (pc045051.tokyo.ppp.waseda.ac.jp [133.9.45.51]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id MAA00858; Fri, 21 Jun 2002 12:00:03 +0900 Message-ID: <003801c218cf$bb26bc10$332d0985@NISHIBA> From: "Yasuyuki Nishibayashi" To: "Christian de Waal" , "Su, William" Cc: References: <72F06A8F0165D611AD2A00508BCFF60002AAB673@fcexchange.fal.us.ray.com> Subject: Re: [manet] About MANET CBR simmulation Date: Fri, 21 Jun 2002 11:59:51 +0900 Organization: Waseda Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear William and Christian de Waal. I appreciate your kindness.Thank you very much. I used 802.11 protocol for MAC layer. In the 100 seconds,source node (ID is 10) received several REPLY packets. r -t 116.444208224 -Hs 10 -Hd 10 -Ni 10 -Nx 857.29 -Ny 214.74 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 7 -Mt 800 -Is 7.255 -Id 0.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 4 -Pd 17 -Pds 18 -Pl 9.000000 -Pc REPLY r -t 118.857176831 -Hs 10 -Hd 10 -Ni 10 -Nx 854.10 -Ny 216.95 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2e -Mt 800 -Is 27.255 -Id 24.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 3 -Pd 17 -Pds 20 -Pl 8.000000 -Pc REPLY r -t 118.859067709 -Hs 10 -Hd 10 -Ni 10 -Nx 854.10 -Ny 216.96 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2e -Mt 800 -Is 17.255 -Id 24.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 2 -Pd 17 -Pds 22 -Pl 10.000000 -Pc REPLY r -t 140.910003640 -Hs 10 -Hd 10 -Ni 10 -Nx 824.91 -Ny 237.17 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2 -Mt 800 -Is 2.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 4 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.938572072 -Hs 10 -Hd 10 -Ni 10 -Nx 824.88 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms b -Mt 800 -Is 38.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 28 -P aodv -Pt 0x4 -Ph 8 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.940791675 -Hs 10 -Hd 10 -Ni 10 -Nx 824.87 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 23 -Mt 800 -Is 46.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 3 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.942812145 -Hs 10 -Hd 10 -Ni 10 -Nx 824.87 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms b -Mt 800 -Is 44.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 6 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY And the reason why packets were dropped is mainly "NRTE" event. In about 100 seconds, 322 packets were dropped by no-route available, although 85 packets were dropped by queue overflows. No MAC layer collisions. The source node sended the packet every 0.25 seconds correctly. After all, difference between pattern1 and pattern2 cause a huge performance gap? Or is it a problem from ns (CBR agent)? Thanks and Regards. //Yasuyuki Nishibayashi //Waseda Univ, Department of Communication and Information Engineering. //Katto Lab. > Yasuyuki, > > Just curious, what kind of MAC layer protocol did you configure the > simulation? Is it 802.11 or CSMA? > > One thing you can check to see is why the packets are being dropped in > pattern1 (could it be collisions, queue overflows, ...etc) Not too sure > about why no route established for 100 seconds in pattern1, were there any > trace of any Route-REQ messages or Route-Reply messages coming back? > > William >Hello, > >I myself have had same problems setting interval_ with CBR agents and >therefore completely switched to setting rate_. You should check your >trace file if the time between to packets really equals 0.25 for pattern1. >Regards, >Christian de Waal _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 20 23:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20237 for ; Thu, 20 Jun 2002 23:13:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08469 for manet-archive@odin.ietf.org; Thu, 20 Jun 2002 23:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07543; Thu, 20 Jun 2002 23:00:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07507 for ; Thu, 20 Jun 2002 23:00:26 -0400 (EDT) Received: from pisces.katto.comm.waseda.ac.jp (IDENT:root@katto.comm.waseda.ac.jp [133.9.196.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20015 for ; Thu, 20 Jun 2002 22:59:44 -0400 (EDT) Received: from NISHIBA (pc045051.tokyo.ppp.waseda.ac.jp [133.9.45.51]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id MAA00858; Fri, 21 Jun 2002 12:00:03 +0900 Message-ID: <003801c218cf$bb26bc10$332d0985@NISHIBA> From: "Yasuyuki Nishibayashi" To: "Christian de Waal" , "Su, William" Cc: References: <72F06A8F0165D611AD2A00508BCFF60002AAB673@fcexchange.fal.us.ray.com> Subject: Re: [manet] About MANET CBR simmulation Date: Fri, 21 Jun 2002 11:59:51 +0900 Organization: Waseda Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear William and Christian de Waal. I appreciate your kindness.Thank you very much. I used 802.11 protocol for MAC layer. In the 100 seconds,source node (ID is 10) received several REPLY packets. r -t 116.444208224 -Hs 10 -Hd 10 -Ni 10 -Nx 857.29 -Ny 214.74 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 7 -Mt 800 -Is 7.255 -Id 0.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 4 -Pd 17 -Pds 18 -Pl 9.000000 -Pc REPLY r -t 118.857176831 -Hs 10 -Hd 10 -Ni 10 -Nx 854.10 -Ny 216.95 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2e -Mt 800 -Is 27.255 -Id 24.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 3 -Pd 17 -Pds 20 -Pl 8.000000 -Pc REPLY r -t 118.859067709 -Hs 10 -Hd 10 -Ni 10 -Nx 854.10 -Ny 216.96 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2e -Mt 800 -Is 17.255 -Id 24.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 2 -Pd 17 -Pds 22 -Pl 10.000000 -Pc REPLY r -t 140.910003640 -Hs 10 -Hd 10 -Ni 10 -Nx 824.91 -Ny 237.17 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 2 -Mt 800 -Is 2.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 4 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.938572072 -Hs 10 -Hd 10 -Ni 10 -Nx 824.88 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms b -Mt 800 -Is 38.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 28 -P aodv -Pt 0x4 -Ph 8 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.940791675 -Hs 10 -Hd 10 -Ni 10 -Nx 824.87 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms 23 -Mt 800 -Is 46.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 3 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY r -t 140.942812145 -Hs 10 -Hd 10 -Ni 10 -Nx 824.87 -Ny 237.20 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw --- -Ma 13a -Md a -Ms b -Mt 800 -Is 44.255 -Id 10.255 -It AODV -Il 44 -If 0 -Ii 0 -Iv 29 -P aodv -Pt 0x4 -Ph 6 -Pd 17 -Pds 22 -Pl 9.000000 -Pc REPLY And the reason why packets were dropped is mainly "NRTE" event. In about 100 seconds, 322 packets were dropped by no-route available, although 85 packets were dropped by queue overflows. No MAC layer collisions. The source node sended the packet every 0.25 seconds correctly. After all, difference between pattern1 and pattern2 cause a huge performance gap? Or is it a problem from ns (CBR agent)? Thanks and Regards. //Yasuyuki Nishibayashi //Waseda Univ, Department of Communication and Information Engineering. //Katto Lab. > Yasuyuki, > > Just curious, what kind of MAC layer protocol did you configure the > simulation? Is it 802.11 or CSMA? > > One thing you can check to see is why the packets are being dropped in > pattern1 (could it be collisions, queue overflows, ...etc) Not too sure > about why no route established for 100 seconds in pattern1, were there any > trace of any Route-REQ messages or Route-Reply messages coming back? > > William >Hello, > >I myself have had same problems setting interval_ with CBR agents and >therefore completely switched to setting rate_. You should check your >trace file if the time between to packets really equals 0.25 for pattern1. >Regards, >Christian de Waal _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 21 13:12:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22717 for ; Fri, 21 Jun 2002 13:12:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24332; Fri, 21 Jun 2002 12:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24304 for ; Fri, 21 Jun 2002 12:57:40 -0400 (EDT) Received: from mailcity.com (fes4.mail.lycos.com [209.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22082 for ; Fri, 21 Jun 2002 12:56:58 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 21 09:57:02 2002 To: manet@ietf.org Date: Fri, 21 Jun 2002 22:27:02 +0530 From: "PARAG AGARWAL" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: paragr@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 129.110.94.72 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] POMC 2002 - Call for Papers Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: http://www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ ============================================================================= Mobile computing and communications devices are proliferating in recent years. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in mobile computing (especially, but not exclusively, ad hoc networks) and distributed algorithms (especially, but not exclusively, dynamic networks). To facilitate such interaction, the workshop is scheduled to begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour tutorials. Significant time for discussion will be allocated. It is intended to be a lively and informal meeting, and to foster cooperation among mobile computing systems researchers and distributed algorithms theoreticians. ============================================================================= Topics ------ Papers are solicited in all research and applied areas that touch on the application of, or need for, distributed algorithms in the context of mobile computing systems. Papers covering work in progress are especially welcome. Papers should describe original, previously unpublished work that is not currently under review by another conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms - routing - dynamic networks - dynamic graph algorithms - location tracking - middleware - security - scheduling - media access techniques - quality-of-service issues - sensor networks - complexity analysis of algorithms for mobile environments Please consult any member of the technical program committee if you are uncertain whether your paper falls within the scope of the workshop. Submission Instructions ----------------------- Submission should be up to 10 pages in length with reasonable margins and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi Prakash (ravip@utdallas.edu) Organsing Committee =================== General Chair - Andre Schiper, EPFL andre.schiper@epfl.ch Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu - David B. Johnson, Rice University dbj@cs.rice.edu - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr - Amy Murphy, University of Rochester murphy@cs.rochester.edu - Michel Raynal, IRISA michel.raynal@irisa.fr - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu Registration and Finance Chair - Xavier Defago, JAIST defago@jaist.ac.jp Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT lynch@theory.lcs.mit.edu - Andre Schiper, EPFL andre.schiper@epfl.ch - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu - Jennifer Welch, Texas A&M University welch@cs.tamu.edu _________________________________________ Communicate with others using Lycos Mail for FREE! http://mail.lycos.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Jun 21 13:12:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22727 for ; Fri, 21 Jun 2002 13:12:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25711 for manet-archive@odin.ietf.org; Fri, 21 Jun 2002 13:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24332; Fri, 21 Jun 2002 12:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24304 for ; Fri, 21 Jun 2002 12:57:40 -0400 (EDT) Received: from mailcity.com (fes4.mail.lycos.com [209.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22082 for ; Fri, 21 Jun 2002 12:56:58 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 21 09:57:02 2002 To: manet@ietf.org Date: Fri, 21 Jun 2002 22:27:02 +0530 From: "PARAG AGARWAL" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: paragr@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 129.110.94.72 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] POMC 2002 - Call for Papers Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: http://www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ ============================================================================= Mobile computing and communications devices are proliferating in recent years. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in mobile computing (especially, but not exclusively, ad hoc networks) and distributed algorithms (especially, but not exclusively, dynamic networks). To facilitate such interaction, the workshop is scheduled to begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour tutorials. Significant time for discussion will be allocated. It is intended to be a lively and informal meeting, and to foster cooperation among mobile computing systems researchers and distributed algorithms theoreticians. ============================================================================= Topics ------ Papers are solicited in all research and applied areas that touch on the application of, or need for, distributed algorithms in the context of mobile computing systems. Papers covering work in progress are especially welcome. Papers should describe original, previously unpublished work that is not currently under review by another conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms - routing - dynamic networks - dynamic graph algorithms - location tracking - middleware - security - scheduling - media access techniques - quality-of-service issues - sensor networks - complexity analysis of algorithms for mobile environments Please consult any member of the technical program committee if you are uncertain whether your paper falls within the scope of the workshop. Submission Instructions ----------------------- Submission should be up to 10 pages in length with reasonable margins and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi Prakash (ravip@utdallas.edu) Organsing Committee =================== General Chair - Andre Schiper, EPFL andre.schiper@epfl.ch Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu - David B. Johnson, Rice University dbj@cs.rice.edu - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr - Amy Murphy, University of Rochester murphy@cs.rochester.edu - Michel Raynal, IRISA michel.raynal@irisa.fr - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu Registration and Finance Chair - Xavier Defago, JAIST defago@jaist.ac.jp Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT lynch@theory.lcs.mit.edu - Andre Schiper, EPFL andre.schiper@epfl.ch - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu - Jennifer Welch, Texas A&M University welch@cs.tamu.edu _________________________________________ Communicate with others using Lycos Mail for FREE! http://mail.lycos.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jun 22 10:39:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27835 for ; Sat, 22 Jun 2002 10:39:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19190; Sat, 22 Jun 2002 10:19:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19166 for ; Sat, 22 Jun 2002 10:19:22 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27190 for ; Sat, 22 Jun 2002 10:18:41 -0400 (EDT) Received: (qmail 22379 invoked from network); 22 Jun 2002 14:19:20 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 22 Jun 2002 14:19:20 -0000 To: manet@ietf.org From: Jonas Nielsen Date: 22 Jun 2002 16:19:20 +0200 Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Data flow in nam for wireless scenarios Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm using ns for simulation of dsr and nam as a visualizer. For different reasons I have reinstalled ns-allinone from scratch. I now try to see data flow in nam. It shows the nodes moving but it shows no communication (normally visualized as rippling circles and small rectangles), though you can see that the nodes communicate in the .tr file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 and a11. I know there were problems with nam in b8, but I've earlier bypassed this problem by replacing the binary with another version. Any suggestions ? I really can't remmember if I dead anything else to get nam working, so any suggestions would be appreciated. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jun 22 10:52:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28143 for ; Sat, 22 Jun 2002 10:52:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19573; Sat, 22 Jun 2002 10:28:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19521 for ; Sat, 22 Jun 2002 10:28:25 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27407 for ; Sat, 22 Jun 2002 10:27:44 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Sat, 22 Jun 2002 22:28:23 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [manet] Data flow in nam for wireless scenarios Date: Sat, 22 Jun 2002 22:28:23 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> Thread-Topic: [manet] Data flow in nam for wireless scenarios Thread-Index: AcIZ+CVzESldm+rASJaBWHfGYcRhHwAAD38Q From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 22 Jun 2002 14:28:23.0857 (UTC) FILETIME=[10C32210:01C219F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19522 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, As far as I know NAM can't show packets flying in wireless simulations. I use ns-2.1b8a and in that also it does not show packets flying in the air. It just shows node movement. But for wired simulations it does show packet transfer. Regards, Shivanajay -----Original Message----- From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, 2002 10:19 PM To: manet@ietf.org Subject: [manet] Data flow in nam for wireless scenarios I'm using ns for simulation of dsr and nam as a visualizer. For different reasons I have reinstalled ns-allinone from scratch. I now try to see data flow in nam. It shows the nodes moving but it shows no communication (normally visualized as rippling circles and small rectangles), though you can see that the nodes communicate in the .tr file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 and a11. I know there were problems with nam in b8, but I've earlier bypassed this problem by replacing the binary with another version. Any suggestions ? I really can't remmember if I dead anything else to get nam working, so any suggestions would be appreciated. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sat Jun 22 11:38:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27841 for ; Sat, 22 Jun 2002 10:39:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20691 for manet-archive@odin.ietf.org; Sat, 22 Jun 2002 10:40:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19190; Sat, 22 Jun 2002 10:19:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19166 for ; Sat, 22 Jun 2002 10:19:22 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27190 for ; Sat, 22 Jun 2002 10:18:41 -0400 (EDT) Received: (qmail 22379 invoked from network); 22 Jun 2002 14:19:20 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 22 Jun 2002 14:19:20 -0000 To: manet@ietf.org From: Jonas Nielsen Date: 22 Jun 2002 16:19:20 +0200 Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Data flow in nam for wireless scenarios Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm using ns for simulation of dsr and nam as a visualizer. For different reasons I have reinstalled ns-allinone from scratch. I now try to see data flow in nam. It shows the nodes moving but it shows no communication (normally visualized as rippling circles and small rectangles), though you can see that the nodes communicate in the .tr file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 and a11. I know there were problems with nam in b8, but I've earlier bypassed this problem by replacing the binary with another version. Any suggestions ? I really can't remmember if I dead anything else to get nam working, so any suggestions would be appreciated. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sat Jun 22 11:38:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28148 for ; Sat, 22 Jun 2002 10:52:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21134 for manet-archive@odin.ietf.org; Sat, 22 Jun 2002 10:53:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19573; Sat, 22 Jun 2002 10:28:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19521 for ; Sat, 22 Jun 2002 10:28:25 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (ims21.stu.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27407 for ; Sat, 22 Jun 2002 10:27:44 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Sat, 22 Jun 2002 22:28:23 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [manet] Data flow in nam for wireless scenarios Date: Sat, 22 Jun 2002 22:28:23 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> Thread-Topic: [manet] Data flow in nam for wireless scenarios Thread-Index: AcIZ+CVzESldm+rASJaBWHfGYcRhHwAAD38Q From: "Marwaha Shivanajay" To: Cc: X-OriginalArrivalTime: 22 Jun 2002 14:28:23.0857 (UTC) FILETIME=[10C32210:01C219F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19522 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, As far as I know NAM can't show packets flying in wireless simulations. I use ns-2.1b8a and in that also it does not show packets flying in the air. It just shows node movement. But for wired simulations it does show packet transfer. Regards, Shivanajay -----Original Message----- From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, 2002 10:19 PM To: manet@ietf.org Subject: [manet] Data flow in nam for wireless scenarios I'm using ns for simulation of dsr and nam as a visualizer. For different reasons I have reinstalled ns-allinone from scratch. I now try to see data flow in nam. It shows the nodes moving but it shows no communication (normally visualized as rippling circles and small rectangles), though you can see that the nodes communicate in the .tr file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 and a11. I know there were problems with nam in b8, but I've earlier bypassed this problem by replacing the binary with another version. Any suggestions ? I really can't remmember if I dead anything else to get nam working, so any suggestions would be appreciated. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jun 22 17:48:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04429 for ; Sat, 22 Jun 2002 17:48:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04277; Sat, 22 Jun 2002 17:20:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04233 for ; Sat, 22 Jun 2002 17:20:48 -0400 (EDT) Received: from smtp4.yaonline.es (smtp4.yaonline.es [62.151.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03979 for ; Sat, 22 Jun 2002 17:20:06 -0400 (EDT) Received: from [217.125.50.240] (helo=ieee.org) by smtp4.yaonline.es with esmtp id 17LsEz-0001Vb-00; Sat, 22 Jun 2002 23:16:17 +0200 Message-ID: <3D14EA9B.2010203@ieee.org> Date: Sat, 22 Jun 2002 23:22:35 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marwaha Shivanajay CC: jonasn@diku.dk, manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Nam *does* show packets flying from node to node in a wireless simulation. It depends on your scenario setup, but it can be done and it works in both 2.1b8a and 2.1b9. You may want to check the ns2 userlist archives for extra information. Good luck, Miguel Sanchez Universidad Politecnica de Valencia, Spain Marwaha Shivanajay wrote: >Hi, >As far as I know NAM can't show packets flying in wireless simulations. >I use ns-2.1b8a and in that also it does not show packets flying in the >air. >It just shows node movement. But for wired simulations it does show >packet transfer. > >Regards, >Shivanajay > > > >-----Original Message----- >From: Jonas Nielsen [mailto:jonasn@diku.dk] >Sent: Saturday, June 22, 2002 10:19 PM >To: manet@ietf.org >Subject: [manet] Data flow in nam for wireless scenarios > > > >I'm using ns for simulation of dsr and nam as a visualizer. For >different reasons I have reinstalled ns-allinone from scratch. I now try >to see data flow in nam. It shows the nodes moving but it shows no >communication (normally visualized as rippling circles and small >rectangles), though you can see that the nodes communicate in the .tr >file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For >ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 >and a11. I know there were problems with nam in b8, but I've earlier >bypassed this problem by replacing the binary with another version. > >Any suggestions ? I really can't remmember if I dead anything else to >get nam working, so any suggestions would be appreciated. > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sat Jun 22 18:35:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04437 for ; Sat, 22 Jun 2002 17:48:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05519 for manet-archive@odin.ietf.org; Sat, 22 Jun 2002 17:48:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04277; Sat, 22 Jun 2002 17:20:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04233 for ; Sat, 22 Jun 2002 17:20:48 -0400 (EDT) Received: from smtp4.yaonline.es (smtp4.yaonline.es [62.151.4.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03979 for ; Sat, 22 Jun 2002 17:20:06 -0400 (EDT) Received: from [217.125.50.240] (helo=ieee.org) by smtp4.yaonline.es with esmtp id 17LsEz-0001Vb-00; Sat, 22 Jun 2002 23:16:17 +0200 Message-ID: <3D14EA9B.2010203@ieee.org> Date: Sat, 22 Jun 2002 23:22:35 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marwaha Shivanajay CC: jonasn@diku.dk, manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Nam *does* show packets flying from node to node in a wireless simulation. It depends on your scenario setup, but it can be done and it works in both 2.1b8a and 2.1b9. You may want to check the ns2 userlist archives for extra information. Good luck, Miguel Sanchez Universidad Politecnica de Valencia, Spain Marwaha Shivanajay wrote: >Hi, >As far as I know NAM can't show packets flying in wireless simulations. >I use ns-2.1b8a and in that also it does not show packets flying in the >air. >It just shows node movement. But for wired simulations it does show >packet transfer. > >Regards, >Shivanajay > > > >-----Original Message----- >From: Jonas Nielsen [mailto:jonasn@diku.dk] >Sent: Saturday, June 22, 2002 10:19 PM >To: manet@ietf.org >Subject: [manet] Data flow in nam for wireless scenarios > > > >I'm using ns for simulation of dsr and nam as a visualizer. For >different reasons I have reinstalled ns-allinone from scratch. I now try >to see data flow in nam. It shows the nodes moving but it shows no >communication (normally visualized as rippling circles and small >rectangles), though you can see that the nodes communicate in the .tr >file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For >ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 >and a11. I know there were problems with nam in b8, but I've earlier >bypassed this problem by replacing the binary with another version. > >Any suggestions ? I really can't remmember if I dead anything else to >get nam working, so any suggestions would be appreciated. > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Jun 23 12:42:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00664 for ; Sun, 23 Jun 2002 12:42:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15078; Sun, 23 Jun 2002 12:21:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15049 for ; Sun, 23 Jun 2002 12:21:34 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00193 for ; Sun, 23 Jun 2002 12:20:52 -0400 (EDT) Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id SAA01280; Sun, 23 Jun 2002 18:21:20 +0200 (MET DST) Message-ID: <3D15F470.4020207@telecom.lth.se> Date: Sun, 23 Jun 2002 18:16:48 +0200 From: Alex Hamidian User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: jonasn@diku.dk, manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> <3D14EA9B.2010203@ieee.org> Content-Type: multipart/alternative; boundary="------------070304090900060406010906" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------070304090900060406010906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! To see the packet flow between wireless nodes in a wireless simulation you have to * use namtrace-all-wireless * set -routerTrace ON If you want to see the packet flow between wireless nodes in nam-1.0a10 you have to use several setdest commands in a row: For example something like this... $ns at 2.0 "$mobile1 setdest 100.0 150.0 15.0" $ns at 2.3 "$mobile1 setdest 100.0 150.0 15.0" $ns at 2.7 "$mobile1 setdest 100.0 150.0 15.0" ... ...or this: set startTime 2.0 set endTime 50.0 (u can compute this value) set posx 100.0 set posy 150.0 set velocity 15.0 for {set i $startTime} {$i < $endTime } {incr i} { $ns at $i.0 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" $ns at $i.3 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" $ns at $i.7 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" } I hope this helps! Ali Hamidian Miguel Sanchez wrote: > Hi, > > Nam *does* show packets flying from node to node in a wireless > simulation. It depends on your scenario setup, but it can be done and > it works in both 2.1b8a and 2.1b9. > > You may want to check the ns2 userlist archives for extra information. > > Good luck, > > Miguel Sanchez > Universidad Politecnica de Valencia, Spain > > > Marwaha Shivanajay wrote: > >> Hi, >> As far as I know NAM can't show packets flying in wireless >> simulations. I use ns-2.1b8a and in that also it does not show >> packets flying in the >> air. >> It just shows node movement. But for wired simulations it does show >> packet transfer. >> >> Regards, >> Shivanajay >> >> >> >> -----Original Message----- >> From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, >> 2002 10:19 PM >> To: manet@ietf.org >> Subject: [manet] Data flow in nam for wireless scenarios >> >> >> >> I'm using ns for simulation of dsr and nam as a visualizer. For >> different reasons I have reinstalled ns-allinone from scratch. I now try >> to see data flow in nam. It shows the nodes moving but it shows no >> communication (normally visualized as rippling circles and small >> rectangles), though you can see that the nodes communicate in the .tr >> file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For >> ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 >> and a11. I know there were problems with nam in b8, but I've earlier >> bypassed this problem by replacing the binary with another version. >> >> Any suggestions ? I really can't remmember if I dead anything else to >> get nam working, so any suggestions would be appreciated. >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> >> >> > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --------------070304090900060406010906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!

To see the packet flow between wireless nodes in a wireless simulation you have to
* use namtrace-all-wireless
* set -routerTrace ON

If you want to see the packet flow between wireless nodes in nam-1.0a10 you have to use several setdest commands in a row:
For example something like this...

$ns at 2.0 "$mobile1 setdest  100.0 150.0 15.0"
$ns at 2.3 "$mobile1 setdest  100.0 150.0 15.0"
$ns at 2.7 "$mobile1 setdest  100.0 150.0 15.0"
...
...or this:

set startTime 2.0
set endTime 50.0 (u can compute this value)
set posx 100.0
set posy 150.0
set velocity 15.0

for {set i $startTime} {$i < $endTime } {incr i} {
            $ns at $i.0 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
            $ns at $i.3 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
            $ns at $i.7 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
}

I hope this helps!
Ali Hamidian


Miguel Sanchez wrote:
Hi,

Nam *does* show packets flying from node to node in a wireless simulation. It depends on your scenario setup, but it can be done and it works in both 2.1b8a and 2.1b9.

You may want to  check the ns2 userlist archives for extra information.

Good luck,

Miguel Sanchez
Universidad Politecnica de Valencia, Spain


Marwaha Shivanajay wrote:

Hi,
As far as I know NAM can't show packets flying in wireless simulations. I use ns-2.1b8a and in that also it does not show packets flying in the
air.
It just shows node movement. But for wired simulations it does show
packet transfer.

Regards,
Shivanajay



-----Original Message-----
From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, 2002 10:19 PM
To: manet@ietf.org
Subject: [manet] Data flow in nam for wireless scenarios



I'm using ns for simulation of dsr and nam as a visualizer.  For
different reasons I have reinstalled ns-allinone from scratch. I now try
to see data flow in nam. It shows the nodes moving but it shows no
communication (normally visualized as rippling circles and small
rectangles), though you can see that the nodes communicate in the .tr
file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For
ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10
and a11. I know there were problems with nam in b8, but I've earlier
bypassed this problem by replacing the binary with another version.

Any suggestions ? I really can't remmember if I dead anything else to
get nam working, so any suggestions would be appreciated.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


 





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--------------070304090900060406010906-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sun Jun 23 13:40:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00672 for ; Sun, 23 Jun 2002 12:42:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16241 for manet-archive@odin.ietf.org; Sun, 23 Jun 2002 12:42:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15078; Sun, 23 Jun 2002 12:21:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15049 for ; Sun, 23 Jun 2002 12:21:34 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00193 for ; Sun, 23 Jun 2002 12:20:52 -0400 (EDT) Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id SAA01280; Sun, 23 Jun 2002 18:21:20 +0200 (MET DST) Message-ID: <3D15F470.4020207@telecom.lth.se> Date: Sun, 23 Jun 2002 18:16:48 +0200 From: Alex Hamidian User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: jonasn@diku.dk, manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> <3D14EA9B.2010203@ieee.org> Content-Type: multipart/alternative; boundary="------------070304090900060406010906" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------070304090900060406010906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! To see the packet flow between wireless nodes in a wireless simulation you have to * use namtrace-all-wireless * set -routerTrace ON If you want to see the packet flow between wireless nodes in nam-1.0a10 you have to use several setdest commands in a row: For example something like this... $ns at 2.0 "$mobile1 setdest 100.0 150.0 15.0" $ns at 2.3 "$mobile1 setdest 100.0 150.0 15.0" $ns at 2.7 "$mobile1 setdest 100.0 150.0 15.0" ... ...or this: set startTime 2.0 set endTime 50.0 (u can compute this value) set posx 100.0 set posy 150.0 set velocity 15.0 for {set i $startTime} {$i < $endTime } {incr i} { $ns at $i.0 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" $ns at $i.3 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" $ns at $i.7 "$mobile1 setdest $posx.0 $posy.0 $velocity.0" } I hope this helps! Ali Hamidian Miguel Sanchez wrote: > Hi, > > Nam *does* show packets flying from node to node in a wireless > simulation. It depends on your scenario setup, but it can be done and > it works in both 2.1b8a and 2.1b9. > > You may want to check the ns2 userlist archives for extra information. > > Good luck, > > Miguel Sanchez > Universidad Politecnica de Valencia, Spain > > > Marwaha Shivanajay wrote: > >> Hi, >> As far as I know NAM can't show packets flying in wireless >> simulations. I use ns-2.1b8a and in that also it does not show >> packets flying in the >> air. >> It just shows node movement. But for wired simulations it does show >> packet transfer. >> >> Regards, >> Shivanajay >> >> >> >> -----Original Message----- >> From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, >> 2002 10:19 PM >> To: manet@ietf.org >> Subject: [manet] Data flow in nam for wireless scenarios >> >> >> >> I'm using ns for simulation of dsr and nam as a visualizer. For >> different reasons I have reinstalled ns-allinone from scratch. I now try >> to see data flow in nam. It shows the nodes moving but it shows no >> communication (normally visualized as rippling circles and small >> rectangles), though you can see that the nodes communicate in the .tr >> file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For >> ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10 >> and a11. I know there were problems with nam in b8, but I've earlier >> bypassed this problem by replacing the binary with another version. >> >> Any suggestions ? I really can't remmember if I dead anything else to >> get nam working, so any suggestions would be appreciated. >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> >> >> > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --------------070304090900060406010906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!

To see the packet flow between wireless nodes in a wireless simulation you have to
* use namtrace-all-wireless
* set -routerTrace ON

If you want to see the packet flow between wireless nodes in nam-1.0a10 you have to use several setdest commands in a row:
For example something like this...

$ns at 2.0 "$mobile1 setdest  100.0 150.0 15.0"
$ns at 2.3 "$mobile1 setdest  100.0 150.0 15.0"
$ns at 2.7 "$mobile1 setdest  100.0 150.0 15.0"
...
...or this:

set startTime 2.0
set endTime 50.0 (u can compute this value)
set posx 100.0
set posy 150.0
set velocity 15.0

for {set i $startTime} {$i < $endTime } {incr i} {
            $ns at $i.0 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
            $ns at $i.3 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
            $ns at $i.7 "$mobile1 setdest $posx.0 $posy.0 $velocity.0"
}

I hope this helps!
Ali Hamidian


Miguel Sanchez wrote:
Hi,

Nam *does* show packets flying from node to node in a wireless simulation. It depends on your scenario setup, but it can be done and it works in both 2.1b8a and 2.1b9.

You may want to  check the ns2 userlist archives for extra information.

Good luck,

Miguel Sanchez
Universidad Politecnica de Valencia, Spain


Marwaha Shivanajay wrote:

Hi,
As far as I know NAM can't show packets flying in wireless simulations. I use ns-2.1b8a and in that also it does not show packets flying in the
air.
It just shows node movement. But for wired simulations it does show
packet transfer.

Regards,
Shivanajay



-----Original Message-----
From: Jonas Nielsen [mailto:jonasn@diku.dk] Sent: Saturday, June 22, 2002 10:19 PM
To: manet@ietf.org
Subject: [manet] Data flow in nam for wireless scenarios



I'm using ns for simulation of dsr and nam as a visualizer.  For
different reasons I have reinstalled ns-allinone from scratch. I now try
to see data flow in nam. It shows the nodes moving but it shows no
communication (normally visualized as rippling circles and small
rectangles), though you can see that the nodes communicate in the .tr
file. I've tried to install ns-allinone-b9 and ns-allinone-b8. For
ns-allinone-b8 I've tried to use the binary version of nam v1.0a9 a10
and a11. I know there were problems with nam in b8, but I've earlier
bypassed this problem by replacing the binary with another version.

Any suggestions ? I really can't remmember if I dead anything else to
get nam working, so any suggestions would be appreciated.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


 





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--------------070304090900060406010906-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 04:36:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25984 for ; Mon, 24 Jun 2002 04:36:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28004; Mon, 24 Jun 2002 04:22:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27973 for ; Mon, 24 Jun 2002 04:22:04 -0400 (EDT) Received: from mx2.iat.cnr.it (mx2.iat.cnr.it [146.48.65.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25537 for ; Mon, 24 Jun 2002 04:21:20 -0400 (EDT) Received: from CONVERSION.MAIL.IAT.CNR.IT by mail.iat.cnr.it (PMDF V6.1-1 #40166) id <01KJB0BLNSXC90NHS2@mail.iat.cnr.it> for manet@ietf.org; Mon, 24 Jun 2002 10:21:03 +0200 (MET DST) Received: from [146.48.82.112] (e-dcp.cnuce.cnr.it [146.48.82.112]) by mail.iat.cnr.it (PMDF V6.1-1 #40166) with ESMTP id <01KJB0BLDPDC90NLPB@mail.iat.cnr.it> for manet@ietf.org; Mon, 24 Jun 2002 10:21:02 +0200 (MET DST) Date: Mon, 24 Jun 2002 10:17:33 +0200 From: Marco Conti X-Sender: man@pop.cnuce.cnr.it To: manet@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [manet] CFP final reminder: ACM WoWMoM2002 -- submission deadline is June 25 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on WIRELESS MOBILE MULTIMEDIA September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002 WoWMoM is the premier international forum, sponsored by ACM SIGMOBILE, for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile Web Access - Mobile and Wireless Multimedia Applications - Pervasive computing - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media - Delay and Jitter Management for Multimedia Services - Real-time voice/video over mobile and wireless networks - Multicasting in Wireless Services - Performance evaluation of wireless and mobile multimedia systems - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Energy-efficient Protocols and Power Management PAPER SUBMISSION AND PUBLICATION ================================= Papers should neither have been published elsewhere nor currently under review by another conference or journal. For paper submission, please follow the submission instructions at: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES ============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: Arup Acharya, IBM TJ Watson Research, USA Sudhir Aggarwal, Lucent Technologies, USA Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, Northeastern University, USA Chatschik Bisdikian, IBM T.J. Watson Research Center, USA Andrew T. Campbell, Columbia University, USA Erdal Cayirci, Georgia Institute of Technology, USA Subir Das, Telcordia Technologies, USA Silvia Giordano, EPFL, Lausanne, Switzerland Philippe Jacquet, INRIA, France Mohan Kumar, University of Texas at Arlington, USA Giridhar Mandyam, Nokia Research, USA Archan Misra IBM T.J. Watson Research Center, USA Hiroyuki Morikawa, University of Tokyo, Japan Sumit Roy, University of Washington, USA Elizabeth M. Belding-Royer, UC Santa Barbara, USA Paul Sanjoy, Bell Laboratories, USA Satish K. Tripathi, University of California at Riverside, USA Andras Valko, Ericsson, Hungary Adam Wolisz, Technical University Berlin, Germany Hee Yong Youn, Sungkyunkwan University, Korea _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Jun 24 04:36:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25991 for ; Mon, 24 Jun 2002 04:36:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00016 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 04:37:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28004; Mon, 24 Jun 2002 04:22:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27973 for ; Mon, 24 Jun 2002 04:22:04 -0400 (EDT) Received: from mx2.iat.cnr.it (mx2.iat.cnr.it [146.48.65.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25537 for ; Mon, 24 Jun 2002 04:21:20 -0400 (EDT) Received: from CONVERSION.MAIL.IAT.CNR.IT by mail.iat.cnr.it (PMDF V6.1-1 #40166) id <01KJB0BLNSXC90NHS2@mail.iat.cnr.it> for manet@ietf.org; Mon, 24 Jun 2002 10:21:03 +0200 (MET DST) Received: from [146.48.82.112] (e-dcp.cnuce.cnr.it [146.48.82.112]) by mail.iat.cnr.it (PMDF V6.1-1 #40166) with ESMTP id <01KJB0BLDPDC90NLPB@mail.iat.cnr.it> for manet@ietf.org; Mon, 24 Jun 2002 10:21:02 +0200 (MET DST) Date: Mon, 24 Jun 2002 10:17:33 +0200 From: Marco Conti X-Sender: man@pop.cnuce.cnr.it To: manet@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [manet] CFP final reminder: ACM WoWMoM2002 -- submission deadline is June 25 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on WIRELESS MOBILE MULTIMEDIA September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002 WoWMoM is the premier international forum, sponsored by ACM SIGMOBILE, for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile Web Access - Mobile and Wireless Multimedia Applications - Pervasive computing - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media - Delay and Jitter Management for Multimedia Services - Real-time voice/video over mobile and wireless networks - Multicasting in Wireless Services - Performance evaluation of wireless and mobile multimedia systems - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Energy-efficient Protocols and Power Management PAPER SUBMISSION AND PUBLICATION ================================= Papers should neither have been published elsewhere nor currently under review by another conference or journal. For paper submission, please follow the submission instructions at: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES ============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: Arup Acharya, IBM TJ Watson Research, USA Sudhir Aggarwal, Lucent Technologies, USA Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, Northeastern University, USA Chatschik Bisdikian, IBM T.J. Watson Research Center, USA Andrew T. Campbell, Columbia University, USA Erdal Cayirci, Georgia Institute of Technology, USA Subir Das, Telcordia Technologies, USA Silvia Giordano, EPFL, Lausanne, Switzerland Philippe Jacquet, INRIA, France Mohan Kumar, University of Texas at Arlington, USA Giridhar Mandyam, Nokia Research, USA Archan Misra IBM T.J. Watson Research Center, USA Hiroyuki Morikawa, University of Tokyo, Japan Sumit Roy, University of Washington, USA Elizabeth M. Belding-Royer, UC Santa Barbara, USA Paul Sanjoy, Bell Laboratories, USA Satish K. Tripathi, University of California at Riverside, USA Andras Valko, Ericsson, Hungary Adam Wolisz, Technical University Berlin, Germany Hee Yong Youn, Sungkyunkwan University, Korea _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 05:10:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26659 for ; Mon, 24 Jun 2002 05:10:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00714; Mon, 24 Jun 2002 04:54:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00683 for ; Mon, 24 Jun 2002 04:54:29 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26335 for ; Mon, 24 Jun 2002 04:53:44 -0400 (EDT) Received: (qmail 11879 invoked from network); 24 Jun 2002 08:54:26 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 24 Jun 2002 08:54:26 -0000 To: Alex Hamidian Cc: manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> <3D14EA9B.2010203@ieee.org> <3D15F470.4020207@telecom.lth.se> From: Jonas Nielsen Date: 24 Jun 2002 10:54:26 +0200 In-Reply-To: <3D15F470.4020207@telecom.lth.se> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Alex Hamidian writes: > Hi! > To see the packet flow between wireless nodes in a wireless simulation you have to > * use namtrace-all-wireless > * set -routerTrace ON > I hope this helps! It did, thanks. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Jun 24 05:10:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26667 for ; Mon, 24 Jun 2002 05:10:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA02174 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 05:11:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00714; Mon, 24 Jun 2002 04:54:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00683 for ; Mon, 24 Jun 2002 04:54:29 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26335 for ; Mon, 24 Jun 2002 04:53:44 -0400 (EDT) Received: (qmail 11879 invoked from network); 24 Jun 2002 08:54:26 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 24 Jun 2002 08:54:26 -0000 To: Alex Hamidian Cc: manet@ietf.org Subject: Re: [manet] Data flow in nam for wireless scenarios References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg> <3D14EA9B.2010203@ieee.org> <3D15F470.4020207@telecom.lth.se> From: Jonas Nielsen Date: 24 Jun 2002 10:54:26 +0200 In-Reply-To: <3D15F470.4020207@telecom.lth.se> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Alex Hamidian writes: > Hi! > To see the packet flow between wireless nodes in a wireless simulation you have to > * use namtrace-all-wireless > * set -routerTrace ON > I hope this helps! It did, thanks. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 05:42:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27341 for ; Mon, 24 Jun 2002 05:42:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02650; Mon, 24 Jun 2002 05:23:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02618 for ; Mon, 24 Jun 2002 05:23:20 -0400 (EDT) Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26852 for ; Mon, 24 Jun 2002 05:22:37 -0400 (EDT) Received: from [134.102.101.207] (helo=manet) by smtp.web.de with smtp (WEB.DE(Exim) 4.60 #1) id 17MQ3W-000467-00 for manet@ietf.org; Mon, 24 Jun 2002 11:22:42 +0200 Message-ID: <000b01c21b60$fc948f40$cf656686@vorstrasse.unibremen.de> From: "Michael Sessinghaus" To: References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg><3D14EA9B.2010203@ieee.org> <3D15F470.4020207@telecom.lth.se> Subject: Re: [manet] Data flow in nam or ad-hcokey? for wireless scenarios Date: Mon, 24 Jun 2002 11:24:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, What you think about ad-hockey to use for wireless visualization? Is it better than Nam. In Nam, i think, the packet flow is very small from one node to the other. I prefer the new ad-hockey version from CMU. But the problem is that the packet flow and the connections (lines) are build out from the left corner in the main window. This view is wrong or not? Is there a bug in ad-hockey or i must change some parameter? Regards, Michael. ----- Original Message ----- From: "Jonas Nielsen" To: "Alex Hamidian" Cc: Sent: Monday, June 24, 2002 10:54 AM Subject: Re: [manet] Data flow in nam for wireless scenarios > Alex Hamidian writes: > > > Hi! > > To see the packet flow between wireless nodes in a wireless simulation you have to > > * use namtrace-all-wireless > > * set -routerTrace ON > > I hope this helps! > > It did, thanks. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Jun 24 05:42:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27348 for ; Mon, 24 Jun 2002 05:42:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04152 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 05:42:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02650; Mon, 24 Jun 2002 05:23:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02618 for ; Mon, 24 Jun 2002 05:23:20 -0400 (EDT) Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26852 for ; Mon, 24 Jun 2002 05:22:37 -0400 (EDT) Received: from [134.102.101.207] (helo=manet) by smtp.web.de with smtp (WEB.DE(Exim) 4.60 #1) id 17MQ3W-000467-00 for manet@ietf.org; Mon, 24 Jun 2002 11:22:42 +0200 Message-ID: <000b01c21b60$fc948f40$cf656686@vorstrasse.unibremen.de> From: "Michael Sessinghaus" To: References: <6330DC96389A924A804F52FA3848930E703C7C@MBXSRV26.stu.nus.edu.sg><3D14EA9B.2010203@ieee.org> <3D15F470.4020207@telecom.lth.se> Subject: Re: [manet] Data flow in nam or ad-hcokey? for wireless scenarios Date: Mon, 24 Jun 2002 11:24:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, What you think about ad-hockey to use for wireless visualization? Is it better than Nam. In Nam, i think, the packet flow is very small from one node to the other. I prefer the new ad-hockey version from CMU. But the problem is that the packet flow and the connections (lines) are build out from the left corner in the main window. This view is wrong or not? Is there a bug in ad-hockey or i must change some parameter? Regards, Michael. ----- Original Message ----- From: "Jonas Nielsen" To: "Alex Hamidian" Cc: Sent: Monday, June 24, 2002 10:54 AM Subject: Re: [manet] Data flow in nam for wireless scenarios > Alex Hamidian writes: > > > Hi! > > To see the packet flow between wireless nodes in a wireless simulation you have to > > * use namtrace-all-wireless > > * set -routerTrace ON > > I hope this helps! > > It did, thanks. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 16:01:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27414 for ; Mon, 24 Jun 2002 16:01:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06601; Mon, 24 Jun 2002 15:42:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06569 for ; Mon, 24 Jun 2002 15:42:10 -0400 (EDT) Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26736 for ; Mon, 24 Jun 2002 15:41:25 -0400 (EDT) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id PAA14956 for ; Mon, 24 Jun 2002 15:42:08 -0400 (EDT) Message-id: <41022175@dancer.Dartmouth.EDU> Date: 24 Jun 2002 15:42:07 EDT From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Subject: [manet] DSR and Dijkstra's algorithm To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I am porting the DSR protocol to Dartmouth College's wireless ad-hoc network simulation (SWAN). I would like to write the Route Cache using Dijkstra's shortest-path algorithm (per Link-MaxLife specification in Appendix A of the draft). Does anyone know of open source code out there using this algorithm that I could use as reference? Either code for a DSR simulation or another similar routing protocol. Thank you, Noah Miller _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 24 16:01:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27420 for ; Mon, 24 Jun 2002 16:01:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07961 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 16:01:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06601; Mon, 24 Jun 2002 15:42:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06569 for ; Mon, 24 Jun 2002 15:42:10 -0400 (EDT) Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26736 for ; Mon, 24 Jun 2002 15:41:25 -0400 (EDT) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id PAA14956 for ; Mon, 24 Jun 2002 15:42:08 -0400 (EDT) Message-id: <41022175@dancer.Dartmouth.EDU> Date: 24 Jun 2002 15:42:07 EDT From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Subject: [manet] DSR and Dijkstra's algorithm To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I am porting the DSR protocol to Dartmouth College's wireless ad-hoc network simulation (SWAN). I would like to write the Route Cache using Dijkstra's shortest-path algorithm (per Link-MaxLife specification in Appendix A of the draft). Does anyone know of open source code out there using this algorithm that I could use as reference? Either code for a DSR simulation or another similar routing protocol. Thank you, Noah Miller _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 16:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29664 for ; Mon, 24 Jun 2002 16:48:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08663; Mon, 24 Jun 2002 16:18:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08636 for ; Mon, 24 Jun 2002 16:18:40 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28148 for ; Mon, 24 Jun 2002 16:17:55 -0400 (EDT) Received: (qmail 15447 invoked from network); 24 Jun 2002 20:18:37 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 24 Jun 2002 20:18:37 -0000 To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Cc: manet@ietf.org Subject: Re: [manet] DSR and Dijkstra's algorithm References: <41022175@dancer.Dartmouth.EDU> From: Jonas Nielsen Date: 24 Jun 2002 22:18:37 +0200 In-Reply-To: <41022175@dancer.Dartmouth.EDU> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) writes: > Hello, > > I am porting the DSR protocol to Dartmouth College's wireless ad-hoc network simulation (SWAN). I would like to write the Route Cache using Dijkstra's shortest-path algorithm (per Link-MaxLife specification in Appendix A of the draft). Does anyone know > of open source code out there using this algorithm that I could use as reference? Either code for a DSR simulation or another similar routing protocol. > > Thank you, > Noah Miller It's implemented in the file linkcache.cc in ns2.1b9. (but please note that the rest of dsr code in this version has a bug that make it unusable for performance tests). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 24 16:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29672 for ; Mon, 24 Jun 2002 16:48:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11269 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 16:49:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08663; Mon, 24 Jun 2002 16:18:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08636 for ; Mon, 24 Jun 2002 16:18:40 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28148 for ; Mon, 24 Jun 2002 16:17:55 -0400 (EDT) Received: (qmail 15447 invoked from network); 24 Jun 2002 20:18:37 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 24 Jun 2002 20:18:37 -0000 To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Cc: manet@ietf.org Subject: Re: [manet] DSR and Dijkstra's algorithm References: <41022175@dancer.Dartmouth.EDU> From: Jonas Nielsen Date: 24 Jun 2002 22:18:37 +0200 In-Reply-To: <41022175@dancer.Dartmouth.EDU> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) writes: > Hello, > > I am porting the DSR protocol to Dartmouth College's wireless ad-hoc network simulation (SWAN). I would like to write the Route Cache using Dijkstra's shortest-path algorithm (per Link-MaxLife specification in Appendix A of the draft). Does anyone know > of open source code out there using this algorithm that I could use as reference? Either code for a DSR simulation or another similar routing protocol. > > Thank you, > Noah Miller It's implemented in the file linkcache.cc in ns2.1b9. (but please note that the rest of dsr code in this version has a bug that make it unusable for performance tests). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 17:15:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01370 for ; Mon, 24 Jun 2002 17:15:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11659; Mon, 24 Jun 2002 16:53:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11621 for ; Mon, 24 Jun 2002 16:53:54 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29936 for ; Mon, 24 Jun 2002 16:53:08 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA07617; Mon, 24 Jun 2002 13:35:48 -0700 (PDT) Message-Id: <200206242035.NAA07617@pit.erg.sri.com> To: John Tully cc: manet@ietf.org, ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] SRI patent issuce In-reply-to: Your message of "Tue, 18 Jun 2002 09:03:32 +0300." <5.1.1.6.0.20020618090244.0168eca0@mail.mt.lv> Date: Mon, 24 Jun 2002 13:35:48 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > Hello, > > I have been following the patent issue on SRI's TBRPF. > > Speedcom Wireless has announced that it has an exclusive license to > implement SRI's "Packet Hop" which I understand is the same as TBRPF. The > license is for fixed wireless networks. This action makes it appear that > it could be impossible for them to comply with the statements they have > made in their draft RFC. > > Maybe someone from their side can clear this up. > > John John, SRI's agreement with Speedcom is not in conflict with any SRI submissions to date nor is it in conflict with the following IPR statement for TBRPF, which our lawyer has submitted to the IETF Secretariat, and which I discussed in a previous post. Essentially, it says that anyone can use TBRPF for free if it becomes a standard. Richard SRI IPR Statement for 'draft-ietf-manet-tbrpf-05.txt': ***************************************************** SRI International has filed one or more patents protecting the inventions described in this submission (the "Patents"). If SRI's submission, or material portions thereof, is accepted and becomes part of the IETF standard (the "Standard"), then SRI will grant any entity wishing to practice the Standard a non-exclusive, royalty-free license under the Patents to the extent, but only to the extent, that such license is required to implement (a) mandatory elements of the Standard; or (b) elements of SRI's submission that are explicitly specified (and not merely incorporated by reference) in the Standard. Use of any elements of SRI's submission that are neither required in order to implement the Standard nor explicitly specified in the Standard will require an additional license from SRI under terms to be negotiated between the parties. While the protocol disclosed in SRI's submission is being evaluated by the IETF, whether on the standards track or otherwise, SRI will and hereby does grant any party a license to utilize, test and evaluate such protocol solely for non-commercial, research purposes. > From SEC filing: > http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-00693 4.txt > ============================ In January 2001, SPEEDCOM acquired worldwide > rights for six years to PacketHop(TM), a wireless routing software > developed by SRI International (SRI). Under the terms of the agreement, > SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed > wireless infrastructure market for the primary frequencies below 6 GHz. Per > the agreement, SRI International received a total of 325,000 shares of > common stock of SPEEDCOM that was issued in four traunches. Each traunch > was measured on the specific date that the stock was issued on. As of March > 31, 2002, the value of these shares at the date of grant is classified in > Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 > in cash, included in Intellectual property on the balance sheet, which is > being amortized over six years. Per the terms of the agreement, SRI may > terminate the exclusive period (18 months) by providing written notice of > such termination unless by such time SPEEDCOM has successfully closed a > liquid event where SRI had the opportunity to obtain net proceeds of at > least $5,000,000. Due to the fact that such an event has not occurred, it > is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) > in July 2002, but will retain its perpetual license agreement. SPEEDCOM has > evaluated this long-lived asset for impairment by comparing the discounted > expected future cash flows to its carrying amount. The undiscounted > expected future cash flows are more than the carrying value of the asset, > so an impairment loss has not been recognized. > > --------------------------------------------------------- > At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: > > Fred, > > > My observation is my own, nobody else's, but it comes from someone > > who has been watching the IETF for a *long* time. If you want to > > guarantee a > scramble, say the word "patent", and if you want to > > guarantee that the IETF > will proceed in a direction only under > > duress, apply for one. > > Let me quote a sentence from "A Novice's Guide to the IETF" > http://www.imc.org/novice-ietf.html > > "Sometimes, the patent holder is generous and promises to give all > implementors of a standard a royalty-free license to the patent, > thereby making it almost as easy to implement as it would have been > if no patent existed." > > That is exactly what SRI is doing. Our IPR statement contains the > following sentence: "If SRI's submission (or portions thereof) is > accepted and becomes part of the IETF standard, then SRI will grant > any party a royalty-free license under such patents for both > commercial and non-commercial uses, to the extent necessary for > compliance with the standard." > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt > > This issue has been discussed previously on this list, e.g., see > Ken Peirce's message dated 12/13/01. Also, in a recent email from > Ken to you (Ken, you can chime in if you want), he pointed out that > the patent (if awarded) is actually a *bonus* to TBRPF implementors, > since SRI will give all implementors a royalty-free license if > TBRPF becomes a standard. As Ken noted (and our lawyer agrees), > in addition to guaranteeing that TBRPF will be unencumbered, it also > provides some protection to TBRPF implementors from 3rd party > infringement lawsuits. > > In your response to Ken, you stated that it is very unlikely that our > lawyers will let us concede our rights to TBPRF. This is not true. > In fact our lawyers are the ones who wrote the IPR statement. > > Our lawyers are currently updating the IPR statement to clarify that > anyone can implement TBRPF for non-commercial research purposes while > TBRPF is being considered by the IETF, as requested by Joe Macker. > (The updated statement will be submitted to the IETF in a few days.) > > Now, if OLSR and TBRPF turn out to be equally good protocols for > proactive routing in MANETs, then it would make sense to select the > one that has no IPRs. But *so far*, TBRPF has outperformed OLSR > significantly in our simulations (and has other advantages that > I have previously discussed). These simulations are based > on the OLSR code that is available from the INRIA web site, which > has been outdated for several months (according to Clausen's > message dated 11/29/01), so I hope that newer OLSR code will > be available soon. > > Richard > > P.S. For reference, here is the excerpt from > draft-baker-manet-review-01.txt that I think is unfair: > > "SRI has aggressively marketed TBRPF and > its IPRs to the working group. The fact that a patent has been > applied for on certain aspects is, however, severely limiting > politically. If there is any way in which the IETF is absolutely > predictable, it is that when confronted with a choice between a > proposal encumbered with IPR issues and an unencumbered proposal, it > will choose the unencumbered one." > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 24 17:15:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01376 for ; Mon, 24 Jun 2002 17:15:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15483 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 17:15:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11659; Mon, 24 Jun 2002 16:53:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11621 for ; Mon, 24 Jun 2002 16:53:54 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29936 for ; Mon, 24 Jun 2002 16:53:08 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA07617; Mon, 24 Jun 2002 13:35:48 -0700 (PDT) Message-Id: <200206242035.NAA07617@pit.erg.sri.com> To: John Tully cc: manet@ietf.org, ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] SRI patent issuce In-reply-to: Your message of "Tue, 18 Jun 2002 09:03:32 +0300." <5.1.1.6.0.20020618090244.0168eca0@mail.mt.lv> Date: Mon, 24 Jun 2002 13:35:48 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > Hello, > > I have been following the patent issue on SRI's TBRPF. > > Speedcom Wireless has announced that it has an exclusive license to > implement SRI's "Packet Hop" which I understand is the same as TBRPF. The > license is for fixed wireless networks. This action makes it appear that > it could be impossible for them to comply with the statements they have > made in their draft RFC. > > Maybe someone from their side can clear this up. > > John John, SRI's agreement with Speedcom is not in conflict with any SRI submissions to date nor is it in conflict with the following IPR statement for TBRPF, which our lawyer has submitted to the IETF Secretariat, and which I discussed in a previous post. Essentially, it says that anyone can use TBRPF for free if it becomes a standard. Richard SRI IPR Statement for 'draft-ietf-manet-tbrpf-05.txt': ***************************************************** SRI International has filed one or more patents protecting the inventions described in this submission (the "Patents"). If SRI's submission, or material portions thereof, is accepted and becomes part of the IETF standard (the "Standard"), then SRI will grant any entity wishing to practice the Standard a non-exclusive, royalty-free license under the Patents to the extent, but only to the extent, that such license is required to implement (a) mandatory elements of the Standard; or (b) elements of SRI's submission that are explicitly specified (and not merely incorporated by reference) in the Standard. Use of any elements of SRI's submission that are neither required in order to implement the Standard nor explicitly specified in the Standard will require an additional license from SRI under terms to be negotiated between the parties. While the protocol disclosed in SRI's submission is being evaluated by the IETF, whether on the standards track or otherwise, SRI will and hereby does grant any party a license to utilize, test and evaluate such protocol solely for non-commercial, research purposes. > From SEC filing: > http://www.sec.gov/Archives/edgar/data/1014343/000102140802006934/0001021408-02-00693 4.txt > ============================ In January 2001, SPEEDCOM acquired worldwide > rights for six years to PacketHop(TM), a wireless routing software > developed by SRI International (SRI). Under the terms of the agreement, > SPEEDCOM obtains rights to SRI's PacketHop(TM) technology in the fixed > wireless infrastructure market for the primary frequencies below 6 GHz. Per > the agreement, SRI International received a total of 325,000 shares of > common stock of SPEEDCOM that was issued in four traunches. Each traunch > was measured on the specific date that the stock was issued on. As of March > 31, 2002, the value of these shares at the date of grant is classified in > Intellectual property on the balance sheet. SPEEDCOM also has paid $360,000 > in cash, included in Intellectual property on the balance sheet, which is > being amortized over six years. Per the terms of the agreement, SRI may > terminate the exclusive period (18 months) by providing written notice of > such termination unless by such time SPEEDCOM has successfully closed a > liquid event where SRI had the opportunity to obtain net proceeds of at > least $5,000,000. Due to the fact that such an event has not occurred, it > is expected that SPEEDCOM will lose its exclusive rights to PacketHop(TM) > in July 2002, but will retain its perpetual license agreement. SPEEDCOM has > evaluated this long-lived asset for impairment by comparing the discounted > expected future cash flows to its carrying amount. The undiscounted > expected future cash flows are more than the carrying value of the asset, > so an impairment loss has not been recognized. > > --------------------------------------------------------- > At 10:42 AM 5/2/2002 -0700, ogier@erg.sri.com wrote: > > Fred, > > > My observation is my own, nobody else's, but it comes from someone > > who has been watching the IETF for a *long* time. If you want to > > guarantee a > scramble, say the word "patent", and if you want to > > guarantee that the IETF > will proceed in a direction only under > > duress, apply for one. > > Let me quote a sentence from "A Novice's Guide to the IETF" > http://www.imc.org/novice-ietf.html > > "Sometimes, the patent holder is generous and promises to give all > implementors of a standard a royalty-free license to the patent, > thereby making it almost as easy to implement as it would have been > if no patent existed." > > That is exactly what SRI is doing. Our IPR statement contains the > following sentence: "If SRI's submission (or portions thereof) is > accepted and becomes part of the IETF standard, then SRI will grant > any party a royalty-free license under such patents for both > commercial and non-commercial uses, to the extent necessary for > compliance with the standard." > > Also note that ISATAP (in the NGTRANS WG) has exactly the same IPR > statement as TBRPF: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt > > This issue has been discussed previously on this list, e.g., see > Ken Peirce's message dated 12/13/01. Also, in a recent email from > Ken to you (Ken, you can chime in if you want), he pointed out that > the patent (if awarded) is actually a *bonus* to TBRPF implementors, > since SRI will give all implementors a royalty-free license if > TBRPF becomes a standard. As Ken noted (and our lawyer agrees), > in addition to guaranteeing that TBRPF will be unencumbered, it also > provides some protection to TBRPF implementors from 3rd party > infringement lawsuits. > > In your response to Ken, you stated that it is very unlikely that our > lawyers will let us concede our rights to TBPRF. This is not true. > In fact our lawyers are the ones who wrote the IPR statement. > > Our lawyers are currently updating the IPR statement to clarify that > anyone can implement TBRPF for non-commercial research purposes while > TBRPF is being considered by the IETF, as requested by Joe Macker. > (The updated statement will be submitted to the IETF in a few days.) > > Now, if OLSR and TBRPF turn out to be equally good protocols for > proactive routing in MANETs, then it would make sense to select the > one that has no IPRs. But *so far*, TBRPF has outperformed OLSR > significantly in our simulations (and has other advantages that > I have previously discussed). These simulations are based > on the OLSR code that is available from the INRIA web site, which > has been outdated for several months (according to Clausen's > message dated 11/29/01), so I hope that newer OLSR code will > be available soon. > > Richard > > P.S. For reference, here is the excerpt from > draft-baker-manet-review-01.txt that I think is unfair: > > "SRI has aggressively marketed TBRPF and > its IPRs to the working group. The fact that a patent has been > applied for on certain aspects is, however, severely limiting > politically. If there is any way in which the IETF is absolutely > predictable, it is that when confronted with a choice between a > proposal encumbered with IPR issues and an unencumbered proposal, it > will choose the unencumbered one." > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jun 24 18:57:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06228 for ; Mon, 24 Jun 2002 18:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23307; Mon, 24 Jun 2002 18:36:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23268 for ; Mon, 24 Jun 2002 18:36:44 -0400 (EDT) Received: from web13503.mail.yahoo.com (web13503.mail.yahoo.com [216.136.175.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05563 for ; Mon, 24 Jun 2002 18:36:01 -0400 (EDT) Message-ID: <20020624223643.45520.qmail@web13503.mail.yahoo.com> Received: from [66.24.238.2] by web13503.mail.yahoo.com via HTTP; Mon, 24 Jun 2002 15:36:43 PDT Date: Mon, 24 Jun 2002 15:36:43 -0700 (PDT) From: sameer tilak Subject: Re: [manet] DSR and Dijkstra's algorithm To: TrustMeImTellingYouStories , manet@ietf.org In-Reply-To: <41022175@dancer.Dartmouth.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi All, I have another doubt regarding DSR. I read from the latest draft that for retransmission of route request it uses binary backoff algorithm. However is there any limit on the numbre of retries ? I am not sure even whether Network layer should handle max retries or applicaiton layer should handle this ? Thanks and Regards, --Sameer Tilak. --- "Noah H. Miller" wrote: > Hello, > > I am porting the DSR protocol to Dartmouth College's > wireless ad-hoc network simulation (SWAN). I would > like to write the Route Cache using Dijkstra's > shortest-path algorithm (per Link-MaxLife > specification in Appendix A of the draft). Does > anyone know > of open source code out there using this algorithm > that I could use as reference? Either code for a > DSR simulation or another similar routing protocol. > > Thank you, > Noah Miller > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jun 24 18:57:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06236 for ; Mon, 24 Jun 2002 18:57:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24314 for manet-archive@odin.ietf.org; Mon, 24 Jun 2002 18:58:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23307; Mon, 24 Jun 2002 18:36:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23268 for ; Mon, 24 Jun 2002 18:36:44 -0400 (EDT) Received: from web13503.mail.yahoo.com (web13503.mail.yahoo.com [216.136.175.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05563 for ; Mon, 24 Jun 2002 18:36:01 -0400 (EDT) Message-ID: <20020624223643.45520.qmail@web13503.mail.yahoo.com> Received: from [66.24.238.2] by web13503.mail.yahoo.com via HTTP; Mon, 24 Jun 2002 15:36:43 PDT Date: Mon, 24 Jun 2002 15:36:43 -0700 (PDT) From: sameer tilak Subject: Re: [manet] DSR and Dijkstra's algorithm To: TrustMeImTellingYouStories , manet@ietf.org In-Reply-To: <41022175@dancer.Dartmouth.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi All, I have another doubt regarding DSR. I read from the latest draft that for retransmission of route request it uses binary backoff algorithm. However is there any limit on the numbre of retries ? I am not sure even whether Network layer should handle max retries or applicaiton layer should handle this ? Thanks and Regards, --Sameer Tilak. --- "Noah H. Miller" wrote: > Hello, > > I am porting the DSR protocol to Dartmouth College's > wireless ad-hoc network simulation (SWAN). I would > like to write the Route Cache using Dijkstra's > shortest-path algorithm (per Link-MaxLife > specification in Appendix A of the draft). Does > anyone know > of open source code out there using this algorithm > that I could use as reference? Either code for a > DSR simulation or another similar routing protocol. > > Thank you, > Noah Miller > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 09:07:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04012 for ; Tue, 25 Jun 2002 09:07:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08006; Tue, 25 Jun 2002 08:42:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07975 for ; Tue, 25 Jun 2002 08:42:18 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03065 for ; Tue, 25 Jun 2002 08:41:32 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id OAA09821 for ; Tue, 25 Jun 2002 14:40:15 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 14:44:54 +0200 X-Mailer: KMail [version 1.2] References: <41022175@dancer.Dartmouth.EDU> In-Reply-To: Organization: deis MIME-Version: 1.0 Message-Id: <02062514445400.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Has anybody investigated the opportunity to use Virtual IP addresses for MANETs? regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 09:07:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04020 for ; Tue, 25 Jun 2002 09:07:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09962 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 09:08:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08006; Tue, 25 Jun 2002 08:42:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07975 for ; Tue, 25 Jun 2002 08:42:18 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03065 for ; Tue, 25 Jun 2002 08:41:32 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id OAA09821 for ; Tue, 25 Jun 2002 14:40:15 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 14:44:54 +0200 X-Mailer: KMail [version 1.2] References: <41022175@dancer.Dartmouth.EDU> In-Reply-To: Organization: deis MIME-Version: 1.0 Message-Id: <02062514445400.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Has anybody investigated the opportunity to use Virtual IP addresses for MANETs? regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 10:16:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06859 for ; Tue, 25 Jun 2002 10:16:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12124; Tue, 25 Jun 2002 09:57:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12095 for ; Tue, 25 Jun 2002 09:57:49 -0400 (EDT) Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05909 for ; Tue, 25 Jun 2002 09:57:02 -0400 (EDT) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id JAA06852; Tue, 25 Jun 2002 09:57:45 -0400 (EDT) Message-id: <41040032@dancer.Dartmouth.EDU> Date: 25 Jun 2002 09:57:45 EDT From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Subject: Re: [manet] DSR and Dijkstra's algorithm To: tilaksameer@yahoo.com (sameer tilak), manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=fnord52314 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org MIME! --fnord52314 Content-Type: text/plain Hello, According to DSR Internet Draft 7, there is a maximum number of retransmissions of a Request (suggested: 16) and a maximum period for those retransmissions (10 seconds) (see pages 47 and 67). DSR has similar variables for source routed packets. A similar problem to the one you raised is the lack of a blacklist for Requests to destinations that cannot be reached (for instance, destinations on the other side of a partition). A node is allowed to restart Route Discovery as soon as the maximum peri od for a Request is up, with the time between Requests reset to the initial, small period. Noah Miller --- sameer tilak wrote: --- Hi All,I have another doubt regarding DSR. I read from thelatest draft that for retransmission of route requestit uses binary backoff algorithm. However is there anylimit on the numbre of retries ? I am not sure evenwhether Network layer should handle max retries orapplicaiton layer should handle this ?Thanks and Regards,--Sameer Tilak. --- end of quote --- --fnord52314 Content-Type: text/html Hello,

According to DSR Internet Draft 7, there is a maximum number of retransmissions of a Request (suggested: 16) and a maximum period for those retransmissions (10 seconds) (see pages 47 and 67). DSR has similar variables for source routed pack ets.

A similar problem to the one you raised is the lack of a blacklist for Requests to destinations that cannot be reached (for instance, destinations on the other side of a partition). A node is allowed to restart Route Discovery as soon as the maximum period for a Request is up, with the time between Requests reset to the initial, small period.

Noah Miller

--- sameer tilak wrote: ---
Hi All,I have another doubt regarding DSR. I read from thelatest
dr aft that for retransmission of route requestit uses binary backoff
algorithm. However is there anylimit on the numbre of retries ? I am
not sure evenwhether Network layer should handle max retries
orapplicaiton layer should handle this ?Thanks and Regards,--Sameer
Tilak.
--- end of quote ---
--fnord52314-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 10:16:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06867 for ; Tue, 25 Jun 2002 10:16:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13804 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 10:17:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12124; Tue, 25 Jun 2002 09:57:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12095 for ; Tue, 25 Jun 2002 09:57:49 -0400 (EDT) Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05909 for ; Tue, 25 Jun 2002 09:57:02 -0400 (EDT) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id JAA06852; Tue, 25 Jun 2002 09:57:45 -0400 (EDT) Message-id: <41040032@dancer.Dartmouth.EDU> Date: 25 Jun 2002 09:57:45 EDT From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller) Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories) Subject: Re: [manet] DSR and Dijkstra's algorithm To: tilaksameer@yahoo.com (sameer tilak), manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=fnord52314 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org MIME! --fnord52314 Content-Type: text/plain Hello, According to DSR Internet Draft 7, there is a maximum number of retransmissions of a Request (suggested: 16) and a maximum period for those retransmissions (10 seconds) (see pages 47 and 67). DSR has similar variables for source routed packets. A similar problem to the one you raised is the lack of a blacklist for Requests to destinations that cannot be reached (for instance, destinations on the other side of a partition). A node is allowed to restart Route Discovery as soon as the maximum peri od for a Request is up, with the time between Requests reset to the initial, small period. Noah Miller --- sameer tilak wrote: --- Hi All,I have another doubt regarding DSR. I read from thelatest draft that for retransmission of route requestit uses binary backoff algorithm. However is there anylimit on the numbre of retries ? I am not sure evenwhether Network layer should handle max retries orapplicaiton layer should handle this ?Thanks and Regards,--Sameer Tilak. --- end of quote --- --fnord52314 Content-Type: text/html Hello,

According to DSR Internet Draft 7, there is a maximum number of retransmissions of a Request (suggested: 16) and a maximum period for those retransmissions (10 seconds) (see pages 47 and 67). DSR has similar variables for source routed pack ets.

A similar problem to the one you raised is the lack of a blacklist for Requests to destinations that cannot be reached (for instance, destinations on the other side of a partition). A node is allowed to restart Route Discovery as soon as the maximum period for a Request is up, with the time between Requests reset to the initial, small period.

Noah Miller

--- sameer tilak wrote: ---
Hi All,I have another doubt regarding DSR. I read from thelatest
dr aft that for retransmission of route requestit uses binary backoff
algorithm. However is there anylimit on the numbre of retries ? I am
not sure evenwhether Network layer should handle max retries
orapplicaiton layer should handle this ?Thanks and Regards,--Sameer
Tilak.
--- end of quote ---
--fnord52314-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 12:49:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15113 for ; Tue, 25 Jun 2002 12:49:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23731; Tue, 25 Jun 2002 12:25:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23688 for ; Tue, 25 Jun 2002 12:25:04 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13535 for ; Tue, 25 Jun 2002 12:24:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id SAA26581 for ; Tue, 25 Jun 2002 18:19:39 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 18:24:20 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062518122301.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit In my opinion some addressing scheme inspired from Virtual IP would be really useful in MANET framework: we might think to bind real IP addresses to the locality (or to a cluster) and this could reduce most of the network traffic related to routing management. (Routing tables would change with a lower frequency) If the Virtual IP (the name of the node) doesn't change even iin the case of a migration it is possible for the others to track its movement and to use the services it shows as soon as it reconnects somewhere into the MANET. Is it meaningfull? I'd like to have your opinion... regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 12:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15119 for ; Tue, 25 Jun 2002 12:49:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26066 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 12:49:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23731; Tue, 25 Jun 2002 12:25:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23688 for ; Tue, 25 Jun 2002 12:25:04 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13535 for ; Tue, 25 Jun 2002 12:24:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id SAA26581 for ; Tue, 25 Jun 2002 18:19:39 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 18:24:20 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062518122301.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit In my opinion some addressing scheme inspired from Virtual IP would be really useful in MANET framework: we might think to bind real IP addresses to the locality (or to a cluster) and this could reduce most of the network traffic related to routing management. (Routing tables would change with a lower frequency) If the Virtual IP (the name of the node) doesn't change even iin the case of a migration it is possible for the others to track its movement and to use the services it shows as soon as it reconnects somewhere into the MANET. Is it meaningfull? I'd like to have your opinion... regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 13:35:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17689 for ; Tue, 25 Jun 2002 13:35:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27625; Tue, 25 Jun 2002 13:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27595 for ; Tue, 25 Jun 2002 13:04:50 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15989 for ; Tue, 25 Jun 2002 13:04:07 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NCLXAAZT; Tue, 25 Jun 2002 13:04:37 -0400 Message-ID: <001c01c21c6a$639c1640$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Dario Bottazzi" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> <02062518122301.00483@manson> Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 13:04:38 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes, and another virtual space could be mapped to GIS coordinates to allow location routing through the address space. ----- Original Message ----- From: "Dario Bottazzi" To: Sent: Tuesday, June 25, 2002 12:24 PM Subject: [manet] IP addresses in MANET > In my opinion some addressing scheme inspired from Virtual IP would be really > useful in MANET framework: we might think to bind real IP addresses to the > locality (or to a cluster) and this could reduce most of the network traffic > related to routing management. (Routing tables would change with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even iin the case of > a migration it is possible for the others to track its movement and to use > the services it shows as soon as it reconnects somewhere into the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 13:35:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17697 for ; Tue, 25 Jun 2002 13:35:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00357 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 13:36:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27625; Tue, 25 Jun 2002 13:04:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27595 for ; Tue, 25 Jun 2002 13:04:50 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15989 for ; Tue, 25 Jun 2002 13:04:07 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NCLXAAZT; Tue, 25 Jun 2002 13:04:37 -0400 Message-ID: <001c01c21c6a$639c1640$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Dario Bottazzi" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A0550365C@XCH-NW-01.nw.nos.boeing.com> <02062518122301.00483@manson> Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 13:04:38 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes, and another virtual space could be mapped to GIS coordinates to allow location routing through the address space. ----- Original Message ----- From: "Dario Bottazzi" To: Sent: Tuesday, June 25, 2002 12:24 PM Subject: [manet] IP addresses in MANET > In my opinion some addressing scheme inspired from Virtual IP would be really > useful in MANET framework: we might think to bind real IP addresses to the > locality (or to a cluster) and this could reduce most of the network traffic > related to routing management. (Routing tables would change with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even iin the case of > a migration it is possible for the others to track its movement and to use > the services it shows as soon as it reconnects somewhere into the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 13:52:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18470 for ; Tue, 25 Jun 2002 13:52:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29041; Tue, 25 Jun 2002 13:25:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29016 for ; Tue, 25 Jun 2002 13:25:10 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16982 for ; Tue, 25 Jun 2002 13:24:26 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id TAA00802 for ; Tue, 25 Jun 2002 19:23:11 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 19:27:54 +0200 X-Mailer: KMail [version 1.2] References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02062519220703.00483@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > 1. If the MANET becomes connected to the Internet, how will that work? In my opinion we might use a gateway with a fixed address. I think it would be accetable because we need an infrastructure in order to see the network outside the manet.... > 2. This appears to be a flat address space in effect, just like creating a > Layer 2 catenet. Not sure how this differs from IEEE 802.11 in ad-hoc mode, > for example. I have little experience with 802.11 so I can't answer you now. The addressing schema in my mind is this : - When a node connects to a cluster it is assigned an IP. - The name of the host (the Virtual IP) never changes. PROS. Inter-cluster routing get simpler (tables change with low frequency) Intra-cluster routing can be simplified because addresses are assigned by the network (the cluster) itself. The addresses are valid only within the cluster. This would also solve a problem: you can't have two different nodes with the same IP address. Also, if node A is using a service shown by node B and B migrates it is simple to manage the reconnection between A and B. - A searches for a route to B using its "Virtual IP" - A reconnects B > > Bert > > > -----Original Message----- > > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > > Sent: Tuesday, June 25, 2002 12:24 PM > > To: manet@ietf.org > > Subject: [manet] IP addresses in MANET > > > > > > In my opinion some addressing scheme inspired from Virtual IP > > would be really > > useful in MANET framework: we might think to bind real IP > > addresses to the > > locality (or to a cluster) and this could reduce most of the > > network traffic > > related to routing management. (Routing tables would change > > with a lower > > frequency) > > If the Virtual IP (the name of the node) doesn't change even > > iin the case of > > a migration it is possible for the others to track its > > movement and to use > > the services it shows as soon as it reconnects somewhere into > > the MANET. > > Is it meaningfull? I'd like to have your opinion... > > regards > > Dario > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 13:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18477 for ; Tue, 25 Jun 2002 13:52:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01585 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 13:52:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29041; Tue, 25 Jun 2002 13:25:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29016 for ; Tue, 25 Jun 2002 13:25:10 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16982 for ; Tue, 25 Jun 2002 13:24:26 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id TAA00802 for ; Tue, 25 Jun 2002 19:23:11 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Date: Tue, 25 Jun 2002 19:27:54 +0200 X-Mailer: KMail [version 1.2] References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02062519220703.00483@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Subject: [manet] IP addresses in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > 1. If the MANET becomes connected to the Internet, how will that work? In my opinion we might use a gateway with a fixed address. I think it would be accetable because we need an infrastructure in order to see the network outside the manet.... > 2. This appears to be a flat address space in effect, just like creating a > Layer 2 catenet. Not sure how this differs from IEEE 802.11 in ad-hoc mode, > for example. I have little experience with 802.11 so I can't answer you now. The addressing schema in my mind is this : - When a node connects to a cluster it is assigned an IP. - The name of the host (the Virtual IP) never changes. PROS. Inter-cluster routing get simpler (tables change with low frequency) Intra-cluster routing can be simplified because addresses are assigned by the network (the cluster) itself. The addresses are valid only within the cluster. This would also solve a problem: you can't have two different nodes with the same IP address. Also, if node A is using a service shown by node B and B migrates it is simple to manage the reconnection between A and B. - A searches for a route to B using its "Virtual IP" - A reconnects B > > Bert > > > -----Original Message----- > > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > > Sent: Tuesday, June 25, 2002 12:24 PM > > To: manet@ietf.org > > Subject: [manet] IP addresses in MANET > > > > > > In my opinion some addressing scheme inspired from Virtual IP > > would be really > > useful in MANET framework: we might think to bind real IP > > addresses to the > > locality (or to a cluster) and this could reduce most of the > > network traffic > > related to routing management. (Routing tables would change > > with a lower > > frequency) > > If the Virtual IP (the name of the node) doesn't change even > > iin the case of > > a migration it is possible for the others to track its > > movement and to use > > the services it shows as soon as it reconnects somewhere into > > the MANET. > > Is it meaningfull? I'd like to have your opinion... > > regards > > Dario > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 14:08:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19360 for ; Tue, 25 Jun 2002 14:08:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25561; Tue, 25 Jun 2002 12:45:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25532 for ; Tue, 25 Jun 2002 12:45:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14731 for ; Tue, 25 Jun 2002 12:44:32 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA20263; Tue, 25 Jun 2002 09:43:32 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA26050; Tue, 25 Jun 2002 11:43:31 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5PGhU821066; Tue, 25 Jun 2002 09:43:30 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jun 2002 12:43:29 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Dario Bottazzi'" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 12:43:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I've heard this concept before, to use unrelated IP addresses in a MANET. Two problems come to mind, unless I'm missing something. 1. If the MANET becomes connected to the Internet, how will that work? 2. This appears to be a flat address space in effect, just like creating a Layer 2 catenet. Not sure how this differs from IEEE 802.11 in ad-hoc mode, for example. Bert > -----Original Message----- > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > Sent: Tuesday, June 25, 2002 12:24 PM > To: manet@ietf.org > Subject: [manet] IP addresses in MANET > > > In my opinion some addressing scheme inspired from Virtual IP > would be really > useful in MANET framework: we might think to bind real IP > addresses to the > locality (or to a cluster) and this could reduce most of the > network traffic > related to routing management. (Routing tables would change > with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even > iin the case of > a migration it is possible for the others to track its > movement and to use > the services it shows as soon as it reconnects somewhere into > the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 14:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19369 for ; Tue, 25 Jun 2002 14:08:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02979 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 14:09:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25561; Tue, 25 Jun 2002 12:45:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25532 for ; Tue, 25 Jun 2002 12:45:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14731 for ; Tue, 25 Jun 2002 12:44:32 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA20263; Tue, 25 Jun 2002 09:43:32 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA26050; Tue, 25 Jun 2002 11:43:31 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5PGhU821066; Tue, 25 Jun 2002 09:43:30 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jun 2002 12:43:29 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39B7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Dario Bottazzi'" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 12:43:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I've heard this concept before, to use unrelated IP addresses in a MANET. Two problems come to mind, unless I'm missing something. 1. If the MANET becomes connected to the Internet, how will that work? 2. This appears to be a flat address space in effect, just like creating a Layer 2 catenet. Not sure how this differs from IEEE 802.11 in ad-hoc mode, for example. Bert > -----Original Message----- > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > Sent: Tuesday, June 25, 2002 12:24 PM > To: manet@ietf.org > Subject: [manet] IP addresses in MANET > > > In my opinion some addressing scheme inspired from Virtual IP > would be really > useful in MANET framework: we might think to bind real IP > addresses to the > locality (or to a cluster) and this could reduce most of the > network traffic > related to routing management. (Routing tables would change > with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even > iin the case of > a migration it is possible for the others to track its > movement and to use > the services it shows as soon as it reconnects somewhere into > the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 14:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19988 for ; Tue, 25 Jun 2002 14:17:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00483; Tue, 25 Jun 2002 13:37:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00371 for ; Tue, 25 Jun 2002 13:37:05 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17733 for ; Tue, 25 Jun 2002 13:36:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id TAA01420 for ; Tue, 25 Jun 2002 19:34:14 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 19:38:58 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A05503663@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A05503663@XCH-NW-01.nw.nos.boeing.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062519385805.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit I haven't heard about SUO/SAP before... I can't be of any help.... In order to answer to Phil I think that the addresses might be assigned within the cluster with any addressing policy enforced by the cluster itself _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jun 25 14:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19996 for ; Tue, 25 Jun 2002 14:17:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03861 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 14:18:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00483; Tue, 25 Jun 2002 13:37:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00371 for ; Tue, 25 Jun 2002 13:37:05 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17733 for ; Tue, 25 Jun 2002 13:36:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id TAA01420 for ; Tue, 25 Jun 2002 19:34:14 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 19:38:58 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A05503663@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A05503663@XCH-NW-01.nw.nos.boeing.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062519385805.00483@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit I haven't heard about SUO/SAP before... I can't be of any help.... In order to answer to Phil I think that the addresses might be assigned within the cluster with any addressing policy enforced by the cluster itself _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jun 25 14:31:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21069 for ; Tue, 25 Jun 2002 14:31:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02971; Tue, 25 Jun 2002 14:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02942 for ; Tue, 25 Jun 2002 14:09:05 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19353 for ; Tue, 25 Jun 2002 14:08:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id UAA03254 for ; Tue, 25 Jun 2002 20:06:09 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 20:10:53 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A05503665@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A05503665@XCH-NW-01.nw.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02062520054106.00483@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > The way it works in SUO/SAS is that the cluster operates at the data link > layer, which itself has a two-level hierarch, and the cluster-head > communicates with other non-cluster entities, using IP. The advantage comes from combinating a fixed IP (the Virtual IP wich is tha name of the node) with a simple dynamic IP addressing schema. Isn't it meaningfull in a MANET? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Jun 25 14:31:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21074 for ; Tue, 25 Jun 2002 14:31:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05756 for manet-archive@odin.ietf.org; Tue, 25 Jun 2002 14:32:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02971; Tue, 25 Jun 2002 14:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02942 for ; Tue, 25 Jun 2002 14:09:05 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19353 for ; Tue, 25 Jun 2002 14:08:21 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id UAA03254 for ; Tue, 25 Jun 2002 20:06:09 +0200 (MEST) X-RAV-AntiVirus: This e-mail has been scanned for viruses Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Tue, 25 Jun 2002 20:10:53 +0200 X-Mailer: KMail [version 1.2] References: <8006AC6A777F3F4F8B2A6383C19C5B7A05503665@XCH-NW-01.nw.nos.boeing.com> In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A05503665@XCH-NW-01.nw.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02062520054106.00483@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > The way it works in SUO/SAS is that the cluster operates at the data link > layer, which itself has a two-level hierarch, and the cluster-head > communicates with other non-cluster entities, using IP. The advantage comes from combinating a fixed IP (the Virtual IP wich is tha name of the node) with a simple dynamic IP addressing schema. Isn't it meaningfull in a MANET? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 09:28:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17172 for ; Thu, 27 Jun 2002 09:28:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01963; Thu, 27 Jun 2002 08:53:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01932 for ; Thu, 27 Jun 2002 08:53:55 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15495 for ; Thu, 27 Jun 2002 08:53:11 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id NAA21634; Thu, 27 Jun 2002 13:53:55 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g5RCrrD02408; Thu, 27 Jun 2002 13:53:53 +0100 Date: Thu, 27 Jun 2002 13:53:53 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Cc: Hi@cs.man.ac.uk Message-ID: <18137_2404_1025182433_1@ug002> Content-ID: <18137_2404_1025182433_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] QoS over a wireless Ad Hoc network Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable I'm trying to find any information on whether I could get QoS over an Ad-Hoc network. I have been looking into the various routing protocols, but not sure which would be suitable for trying to get QoS vve= r. I have looked at RSVP, but as it stands, it doesn't support mobile = networks let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP,= but I need an Ad-Hoc network. Unfortunately most information about RSVP is at least 4-5 years old= - what happened? The mailing lists seem to just die over night. I would be looking for a linux implementation, or implementing it m= yself in ln ^H^HLinux Any comments at all are welcome, sorry if this is the wrong place. = Thanks, John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 09:28:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17181 for ; Thu, 27 Jun 2002 09:28:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05004 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 09:29:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01963; Thu, 27 Jun 2002 08:53:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01932 for ; Thu, 27 Jun 2002 08:53:55 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15495 for ; Thu, 27 Jun 2002 08:53:11 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id NAA21634; Thu, 27 Jun 2002 13:53:55 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g5RCrrD02408; Thu, 27 Jun 2002 13:53:53 +0100 Date: Thu, 27 Jun 2002 13:53:53 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Cc: Hi@cs.man.ac.uk Message-ID: <18137_2404_1025182433_1@ug002> Content-ID: <18137_2404_1025182433_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] QoS over a wireless Ad Hoc network Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable I'm trying to find any information on whether I could get QoS over an Ad-Hoc network. I have been looking into the various routing protocols, but not sure which would be suitable for trying to get QoS vve= r. I have looked at RSVP, but as it stands, it doesn't support mobile = networks let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP,= but I need an Ad-Hoc network. Unfortunately most information about RSVP is at least 4-5 years old= - what happened? The mailing lists seem to just die over night. I would be looking for a linux implementation, or implementing it m= yself in ln ^H^HLinux Any comments at all are welcome, sorry if this is the wrong place. = Thanks, John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 09:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18108 for ; Thu, 27 Jun 2002 09:43:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03716; Thu, 27 Jun 2002 09:13:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03687 for ; Thu, 27 Jun 2002 09:13:34 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16328 for ; Thu, 27 Jun 2002 09:12:50 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa19928; 27 Jun 2002 09:12 EDT Date: Thu, 27 Jun 2002 09:12:40 -0400 (EDT) From: Liangping Ma To: John Peter Tapsell cc: manet@ietf.org, Hi@cs.man.ac.uk MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [manet] QoS over a wireless Ad Hoc network In-Reply-To: <18137_2404_1025182433_1@ug002> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, John, There are some QoS schemes over Ad-Hoc networks. For example, INSIGNIA, and SWAN. They were developed by the comet group in Columbia University. You can go to the university's webpage and find them. Sincerely yours, Liangping Ma On Thu, 27 Jun 2002, John Peter Tapsell wrote: > > I'm trying to find any information on whether I could get QoS over an Ad-Hoc network. I have been looking into the various routing protocols, but not sure which would be suitable for trying to get QoS vver. > > > I have looked at RSVP, but as it stands, it doesn't support mobile networks let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP, but I need an Ad-Hoc network. > > > Unfortunately most information about RSVP is at least 4-5 years old - what happened? The mailing lists seem to just die over night. > > > I would be looking for a linux implementation, or implementing it myself in ln ^H^HLinux > > > Any comments at all are welcome, sorry if this is the wrong place. > > Thanks, John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 09:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18115 for ; Thu, 27 Jun 2002 09:43:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06795 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 09:43:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03716; Thu, 27 Jun 2002 09:13:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03687 for ; Thu, 27 Jun 2002 09:13:34 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16328 for ; Thu, 27 Jun 2002 09:12:50 -0400 (EDT) Received: from frink.ece.udel.edu by mail.eecis.udel.edu id aa19928; 27 Jun 2002 09:12 EDT Date: Thu, 27 Jun 2002 09:12:40 -0400 (EDT) From: Liangping Ma To: John Peter Tapsell cc: manet@ietf.org, Hi@cs.man.ac.uk MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: [manet] QoS over a wireless Ad Hoc network In-Reply-To: <18137_2404_1025182433_1@ug002> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, John, There are some QoS schemes over Ad-Hoc networks. For example, INSIGNIA, and SWAN. They were developed by the comet group in Columbia University. You can go to the university's webpage and find them. Sincerely yours, Liangping Ma On Thu, 27 Jun 2002, John Peter Tapsell wrote: > > I'm trying to find any information on whether I could get QoS over an Ad-Hoc network. I have been looking into the various routing protocols, but not sure which would be suitable for trying to get QoS vver. > > > I have looked at RSVP, but as it stands, it doesn't support mobile networks let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP, but I need an Ad-Hoc network. > > > Unfortunately most information about RSVP is at least 4-5 years old - what happened? The mailing lists seem to just die over night. > > > I would be looking for a linux implementation, or implementing it myself in ln ^H^HLinux > > > Any comments at all are welcome, sorry if this is the wrong place. > > Thanks, John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 09:50:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18361 for ; Thu, 27 Jun 2002 09:50:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04927; Thu, 27 Jun 2002 09:29:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04896 for ; Thu, 27 Jun 2002 09:29:08 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17119 for ; Thu, 27 Jun 2002 09:28:23 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117127>; Thu, 27 Jun 2002 07:29:03 -0600 Message-Id: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Dario Bottazzi , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 07:28:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Dario, I agree that using some form of hierarchal addressing scheme can improve routing efficiency in moderately large MANETs. The IP address in the Internet is hierarchal. Each node is given an address that reflects its position in the topology of the Internet, much as State and City reflects a person's location within the US. This allows for efficient routing, as you point out, by reducing the need for propagating local detail to other routers. Because Internet nodes do not typically move a lot, a node can be given a permanent address. The problem with the MANET is that because the nodes are in motion, any hierarchal clustering would have to be dynamic in order to aid routing. If MANET nodes have permanent addresses, it is simple to know which node to look for, but not where to look for it. On the other hand, if a node is given an address that reflects its location in the net, then the system has to resolve that address with a more permanent label. The analogy I use is that you are trying to find someone who is staying in a hotel. You may know the city and the hotel name, but at some point you end up talking to the front desk to find out which room Joe Smith is staying in. Joe's name (plus some other information) is a permanent label, but you need to know more information to find him. The desk clerk performs the final "address" resolution. Another way to look at this is the IP addresses perform two functions: 1) they uniquely identify a node, and 2) they allow efficient routing by encoding a clustering scheme. In a MANET, these two functions are distinct. In the general MANET, we are not able to bind a real IP address to a cluster. A cluster reflects a configuration of the dynamic topology. It has no permanent identity or even assurance of existence. As the nodes within the MANET move, clusters split and merge. The roles of a given node change. A node may be a cluster head one minute and a guest in a different cluster the next. If we assign a IP address to a location, then what happens if two clusters move into that location? What if no clusters are in a location? (If we have fixed locations we can reference, we do have a simpler problem, but this is not guaranteed in a MANET). Worse than that, a specific node will be given different IP addresses as it moves through the topology. This complicates the problem of identification. So far, one scheme I've seen involves giving each node a permanent IP address plus a MANET suffix. The suffix is used to find the node and the IP address to identify it. Alternatively, one can propagate throughout the net (either proactively or on demand) a cross-reference table that matches up IP and MANET addresses. This is not to say that binding IP addresses to a cluster or locality will not work in some situations. However, that would be a special situation and, some would say, not a MANET, but a stub network, instead. John Mullen -----Original Message----- From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] Sent: Tuesday, June 25, 2002 10:24 AM To: manet@ietf.org Subject: [manet] IP addresses in MANET In my opinion some addressing scheme inspired from Virtual IP would be really useful in MANET framework: we might think to bind real IP addresses to the locality (or to a cluster) and this could reduce most of the network traffic related to routing management. (Routing tables would change with a lower frequency) If the Virtual IP (the name of the node) doesn't change even iin the case of a migration it is possible for the others to track its movement and to use the services it shows as soon as it reconnects somewhere into the MANET. Is it meaningfull? I'd like to have your opinion... regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 09:50:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18369 for ; Thu, 27 Jun 2002 09:50:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07239 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 09:51:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04927; Thu, 27 Jun 2002 09:29:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04896 for ; Thu, 27 Jun 2002 09:29:08 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17119 for ; Thu, 27 Jun 2002 09:28:23 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117127>; Thu, 27 Jun 2002 07:29:03 -0600 Message-Id: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Dario Bottazzi , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 07:28:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Dario, I agree that using some form of hierarchal addressing scheme can improve routing efficiency in moderately large MANETs. The IP address in the Internet is hierarchal. Each node is given an address that reflects its position in the topology of the Internet, much as State and City reflects a person's location within the US. This allows for efficient routing, as you point out, by reducing the need for propagating local detail to other routers. Because Internet nodes do not typically move a lot, a node can be given a permanent address. The problem with the MANET is that because the nodes are in motion, any hierarchal clustering would have to be dynamic in order to aid routing. If MANET nodes have permanent addresses, it is simple to know which node to look for, but not where to look for it. On the other hand, if a node is given an address that reflects its location in the net, then the system has to resolve that address with a more permanent label. The analogy I use is that you are trying to find someone who is staying in a hotel. You may know the city and the hotel name, but at some point you end up talking to the front desk to find out which room Joe Smith is staying in. Joe's name (plus some other information) is a permanent label, but you need to know more information to find him. The desk clerk performs the final "address" resolution. Another way to look at this is the IP addresses perform two functions: 1) they uniquely identify a node, and 2) they allow efficient routing by encoding a clustering scheme. In a MANET, these two functions are distinct. In the general MANET, we are not able to bind a real IP address to a cluster. A cluster reflects a configuration of the dynamic topology. It has no permanent identity or even assurance of existence. As the nodes within the MANET move, clusters split and merge. The roles of a given node change. A node may be a cluster head one minute and a guest in a different cluster the next. If we assign a IP address to a location, then what happens if two clusters move into that location? What if no clusters are in a location? (If we have fixed locations we can reference, we do have a simpler problem, but this is not guaranteed in a MANET). Worse than that, a specific node will be given different IP addresses as it moves through the topology. This complicates the problem of identification. So far, one scheme I've seen involves giving each node a permanent IP address plus a MANET suffix. The suffix is used to find the node and the IP address to identify it. Alternatively, one can propagate throughout the net (either proactively or on demand) a cross-reference table that matches up IP and MANET addresses. This is not to say that binding IP addresses to a cluster or locality will not work in some situations. However, that would be a special situation and, some would say, not a MANET, but a stub network, instead. John Mullen -----Original Message----- From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] Sent: Tuesday, June 25, 2002 10:24 AM To: manet@ietf.org Subject: [manet] IP addresses in MANET In my opinion some addressing scheme inspired from Virtual IP would be really useful in MANET framework: we might think to bind real IP addresses to the locality (or to a cluster) and this could reduce most of the network traffic related to routing management. (Routing tables would change with a lower frequency) If the Virtual IP (the name of the node) doesn't change even iin the case of a migration it is possible for the others to track its movement and to use the services it shows as soon as it reconnects somewhere into the MANET. Is it meaningfull? I'd like to have your opinion... regards Dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 11:26:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23875 for ; Thu, 27 Jun 2002 11:26:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10851; Thu, 27 Jun 2002 10:36:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10824 for ; Thu, 27 Jun 2002 10:35:57 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20707 for ; Thu, 27 Jun 2002 10:35:11 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id QAA19742 for ; Thu, 27 Jun 2002 16:34:08 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:39:05 +0200 X-Mailer: KMail [version 1.2] References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> In-Reply-To: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> MIME-Version: 1.0 Message-Id: <02062716303703.00484@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dr. Mullen thank you for the clear and deep answer you have given me. I agree that my approach isn't general but I think that it maight fit many real life situations. I think that the approach I have expressed (it's only an idea...) shows two interesting points: - We have to think to cluster (o locality aware) solutions - It might be possible to bind the IP to the location (and assign it dynamically) and to keep "something" (a second address) fixed. If I search for Mario Rossi in any hotel in Bologna, I know that he can change hotel... but the person I am looking for is always Mario. Anyway I will read again the answer you gave me. many thanks dario > The analogy I use is that you are trying to find someone who is staying in > a hotel. You may know the city and the hotel name, but at some point you > end up talking to the front desk to find out which room Joe Smith is > staying in. Joe's name (plus some other information) is a permanent label, > but you need to know more information to find him. The desk clerk performs > the final "address" resolution. > > Another way to look at this is the IP addresses perform two functions: 1) > they uniquely identify a node, and 2) they allow efficient routing by > encoding a clustering scheme. In a MANET, these two functions are > distinct. > > In the general MANET, we are not able to bind a real IP address to a > cluster. A cluster reflects a configuration of the dynamic topology. It > has no permanent identity or even assurance of existence. As the nodes > within the MANET move, clusters split and merge. The roles of a given node > change. A node may be a cluster head one minute and a guest in a different > cluster the next. If we assign a IP address to a location, then what > happens if two clusters move into that location? What if no clusters are > in a location? (If we have fixed locations we can reference, we do have a > simpler problem, but this is not guaranteed in a MANET). Worse than that, > a specific node will be given different IP addresses as it moves through > the topology. This complicates the problem of identification. > > So far, one scheme I've seen involves giving each node a permanent IP > address plus a MANET suffix. The suffix is used to find the node and the > IP address to identify it. Alternatively, one can propagate throughout the > net (either proactively or on demand) a cross-reference table that matches > up IP and MANET addresses. > > This is not to say that binding IP addresses to a cluster or locality will > not work in some situations. However, that would be a special situation > and, some would say, not a MANET, but a stub network, instead. > > John Mullen > > -----Original Message----- > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > Sent: Tuesday, June 25, 2002 10:24 AM > To: manet@ietf.org > Subject: [manet] IP addresses in MANET > > > In my opinion some addressing scheme inspired from Virtual IP would be > really > useful in MANET framework: we might think to bind real IP addresses to the > locality (or to a cluster) and this could reduce most of the network > traffic > > related to routing management. (Routing tables would change with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even iin the case > of > > a migration it is possible for the others to track its movement and to use > the services it shows as soon as it reconnects somewhere into the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 11:26:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23881 for ; Thu, 27 Jun 2002 11:26:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16619 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 11:26:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10851; Thu, 27 Jun 2002 10:36:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10824 for ; Thu, 27 Jun 2002 10:35:57 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20707 for ; Thu, 27 Jun 2002 10:35:11 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id QAA19742 for ; Thu, 27 Jun 2002 16:34:08 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:39:05 +0200 X-Mailer: KMail [version 1.2] References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> In-Reply-To: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> MIME-Version: 1.0 Message-Id: <02062716303703.00484@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dr. Mullen thank you for the clear and deep answer you have given me. I agree that my approach isn't general but I think that it maight fit many real life situations. I think that the approach I have expressed (it's only an idea...) shows two interesting points: - We have to think to cluster (o locality aware) solutions - It might be possible to bind the IP to the location (and assign it dynamically) and to keep "something" (a second address) fixed. If I search for Mario Rossi in any hotel in Bologna, I know that he can change hotel... but the person I am looking for is always Mario. Anyway I will read again the answer you gave me. many thanks dario > The analogy I use is that you are trying to find someone who is staying in > a hotel. You may know the city and the hotel name, but at some point you > end up talking to the front desk to find out which room Joe Smith is > staying in. Joe's name (plus some other information) is a permanent label, > but you need to know more information to find him. The desk clerk performs > the final "address" resolution. > > Another way to look at this is the IP addresses perform two functions: 1) > they uniquely identify a node, and 2) they allow efficient routing by > encoding a clustering scheme. In a MANET, these two functions are > distinct. > > In the general MANET, we are not able to bind a real IP address to a > cluster. A cluster reflects a configuration of the dynamic topology. It > has no permanent identity or even assurance of existence. As the nodes > within the MANET move, clusters split and merge. The roles of a given node > change. A node may be a cluster head one minute and a guest in a different > cluster the next. If we assign a IP address to a location, then what > happens if two clusters move into that location? What if no clusters are > in a location? (If we have fixed locations we can reference, we do have a > simpler problem, but this is not guaranteed in a MANET). Worse than that, > a specific node will be given different IP addresses as it moves through > the topology. This complicates the problem of identification. > > So far, one scheme I've seen involves giving each node a permanent IP > address plus a MANET suffix. The suffix is used to find the node and the > IP address to identify it. Alternatively, one can propagate throughout the > net (either proactively or on demand) a cross-reference table that matches > up IP and MANET addresses. > > This is not to say that binding IP addresses to a cluster or locality will > not work in some situations. However, that would be a special situation > and, some would say, not a MANET, but a stub network, instead. > > John Mullen > > -----Original Message----- > From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] > Sent: Tuesday, June 25, 2002 10:24 AM > To: manet@ietf.org > Subject: [manet] IP addresses in MANET > > > In my opinion some addressing scheme inspired from Virtual IP would be > really > useful in MANET framework: we might think to bind real IP addresses to the > locality (or to a cluster) and this could reduce most of the network > traffic > > related to routing management. (Routing tables would change with a lower > frequency) > If the Virtual IP (the name of the node) doesn't change even iin the case > of > > a migration it is possible for the others to track its movement and to use > the services it shows as soon as it reconnects somewhere into the MANET. > Is it meaningfull? I'd like to have your opinion... > regards > Dario > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 11:41:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25091 for ; Thu, 27 Jun 2002 11:41:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14790; Thu, 27 Jun 2002 11:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14756 for ; Thu, 27 Jun 2002 11:12:22 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22803 for ; Thu, 27 Jun 2002 11:11:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 09:12:14 -0600 Message-Id: <02Jun27.091214mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Dario Bottazzi , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 09:12:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thanks Dario, But, I'm no expert. I'm just trying to figure this stuff out myself. John Mullen -----Original Message----- From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] Sent: Thursday, June 27, 2002 8:39 AM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Dr. Mullen thank you for the clear and deep answer you have given me. I agree that my approach isn't general but I think that it maight fit many real life situations. I think that the approach I have expressed (it's only an idea...) shows two interesting points: - We have to think to cluster (o locality aware) solutions - It might be possible to bind the IP to the location (and assign it dynamically) and to keep "something" (a second address) fixed. If I search for Mario Rossi in any hotel in Bologna, I know that he can change hotel... but the person I am looking for is always Mario. Anyway I will read again the answer you gave me. many thanks dario > The analogy I use is that you are trying to find someone who is staying in > a hotel. You may know the city and the hotel name, but at some point you > end up talking to the front desk to find out which room Joe Smith is > staying in. Joe's name (plus some other information) is a permanent label, > but you need to know more information to find him. The desk clerk performs > the final "address" resolution. > > Another way to look at this is the IP addresses perform two functions: 1) > they uniquely identify a node, and 2) they allow efficient routing by > encoding a clustering scheme. In a MANET, these two functions are > distinct. > > In the general MANET, we are not able to bind a real IP address to a > cluster. A cluster reflects a configuration of the dynamic topology. It > has no permanent identity or even assurance of existence. As the nodes > within the MANET move, clusters split and merge. The roles of a given node > change. A node may be a cluster head one minute and a guest in a different > cluster the next. If we assign a IP address to a location, then what > happens if two clusters move into that location? What if no clusters are > in a location? (If we have fixed locations we can reference, we do have a > simpler problem, but this is not guaranteed in a MANET). Worse than that, > a specific node will be given different IP addresses as it moves through > the topology. This complicates the problem of identification. > > So far, one scheme I've seen involves giving each node a permanent IP > address plus a MANET suffix. The suffix is used to find the node and the > IP address to identify it. Alternatively, one can propagate throughout the > net (either proactively or on demand) a cross-reference table that matches > up IP and MANET addresses. > > This is not to say that binding IP addresses to a cluster or locality will > not work in some situations. However, that would be a special situation > and, some would say, not a MANET, but a stub network, instead. > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 11:41:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25097 for ; Thu, 27 Jun 2002 11:41:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19042 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 11:42:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14790; Thu, 27 Jun 2002 11:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14756 for ; Thu, 27 Jun 2002 11:12:22 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22803 for ; Thu, 27 Jun 2002 11:11:35 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 09:12:14 -0600 Message-Id: <02Jun27.091214mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Dario Bottazzi , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 09:12:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thanks Dario, But, I'm no expert. I'm just trying to figure this stuff out myself. John Mullen -----Original Message----- From: Dario Bottazzi [mailto:dbottazzi@deis.unibo.it] Sent: Thursday, June 27, 2002 8:39 AM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Dr. Mullen thank you for the clear and deep answer you have given me. I agree that my approach isn't general but I think that it maight fit many real life situations. I think that the approach I have expressed (it's only an idea...) shows two interesting points: - We have to think to cluster (o locality aware) solutions - It might be possible to bind the IP to the location (and assign it dynamically) and to keep "something" (a second address) fixed. If I search for Mario Rossi in any hotel in Bologna, I know that he can change hotel... but the person I am looking for is always Mario. Anyway I will read again the answer you gave me. many thanks dario > The analogy I use is that you are trying to find someone who is staying in > a hotel. You may know the city and the hotel name, but at some point you > end up talking to the front desk to find out which room Joe Smith is > staying in. Joe's name (plus some other information) is a permanent label, > but you need to know more information to find him. The desk clerk performs > the final "address" resolution. > > Another way to look at this is the IP addresses perform two functions: 1) > they uniquely identify a node, and 2) they allow efficient routing by > encoding a clustering scheme. In a MANET, these two functions are > distinct. > > In the general MANET, we are not able to bind a real IP address to a > cluster. A cluster reflects a configuration of the dynamic topology. It > has no permanent identity or even assurance of existence. As the nodes > within the MANET move, clusters split and merge. The roles of a given node > change. A node may be a cluster head one minute and a guest in a different > cluster the next. If we assign a IP address to a location, then what > happens if two clusters move into that location? What if no clusters are > in a location? (If we have fixed locations we can reference, we do have a > simpler problem, but this is not guaranteed in a MANET). Worse than that, > a specific node will be given different IP addresses as it moves through > the topology. This complicates the problem of identification. > > So far, one scheme I've seen involves giving each node a permanent IP > address plus a MANET suffix. The suffix is used to find the node and the > IP address to identify it. Alternatively, one can propagate throughout the > net (either proactively or on demand) a cross-reference table that matches > up IP and MANET addresses. > > This is not to say that binding IP addresses to a cluster or locality will > not work in some situations. However, that would be a special situation > and, some would say, not a MANET, but a stub network, instead. > > John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 13:54:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04561 for ; Thu, 27 Jun 2002 13:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27104; Thu, 27 Jun 2002 13:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27075 for ; Thu, 27 Jun 2002 13:27:23 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02786 for ; Thu, 27 Jun 2002 13:26:38 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2002 17:31:50 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5RHJY4Y021263; Thu, 27 Jun 2002 10:19:37 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: <18137_2404_1025182433_1@ug002> References: <18137_2404_1025182433_1@ug002> Date: Thu, 27 Jun 2002 10:27:41 -0700 To: John Peter Tapsell From: Rex Buddenberg Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > I'm trying to find any information on whether I could get QoS >over an Ad-Hoc network. I have been looking into the various routing >protocols, but not sure which would be suitable for trying to get QoS vver. > do you want QoS or QoS control? > > I have looked at RSVP, but as it stands, it doesn't support >mobile networks >let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP, >but I need an Ad-Hoc network. > RSVP is per flow; diff-serv is per hop. What are your requirements? > > Unfortunately most information about RSVP is at least 4-5 years old - >what happened? The mailing lists seem to just die over night. > RSVP sets up reservations across a series of routers. It therefore freezes the topology ... or in language I prefer, it reintroduces state into the network layer where the genius of IP was to get it out. In marketing terms, 'RSVP doesn't scale'. Once this realization sank in, RSVP quickly lost popularity. In a MANET context, RSVP (aka integrated services) runs directly counter to the highly volatile topology expected in MANETs -- it requires a fixed path through the routing fabric for the duration of an RSVP-endowed connection. > > I would be looking for a linux implementation, or implementing >it myself in ln >^H^HLinux > Priority queueing, which is what diff-serv does, is much more scaleable. It doesn't reintroduce state in routers. There's no reason I can think of that diff-serv wouldn't work just as well in MANETs. Just don't expect determinism. The Linux diffserv list has this in the address block, help yourself: List-Help: List-Post: List-Subscribe: , List-Id: General discussion of Differentiated Services on Linux List-Unsubscribe: , List-Archive: > > Any comments at all are welcome, >sorry if this is the wrong place. > > >Thanks, >John Tapsell > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 13:54:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04568 for ; Thu, 27 Jun 2002 13:54:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29892 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 13:54:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27104; Thu, 27 Jun 2002 13:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27075 for ; Thu, 27 Jun 2002 13:27:23 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02786 for ; Thu, 27 Jun 2002 13:26:38 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2002 17:31:50 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5RHJY4Y021263; Thu, 27 Jun 2002 10:19:37 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: <18137_2404_1025182433_1@ug002> References: <18137_2404_1025182433_1@ug002> Date: Thu, 27 Jun 2002 10:27:41 -0700 To: John Peter Tapsell From: Rex Buddenberg Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > I'm trying to find any information on whether I could get QoS >over an Ad-Hoc network. I have been looking into the various routing >protocols, but not sure which would be suitable for trying to get QoS vver. > do you want QoS or QoS control? > > I have looked at RSVP, but as it stands, it doesn't support >mobile networks >let alone ad-hoc networks. There is MRSVP for using RSVP over Mobile IP, >but I need an Ad-Hoc network. > RSVP is per flow; diff-serv is per hop. What are your requirements? > > Unfortunately most information about RSVP is at least 4-5 years old - >what happened? The mailing lists seem to just die over night. > RSVP sets up reservations across a series of routers. It therefore freezes the topology ... or in language I prefer, it reintroduces state into the network layer where the genius of IP was to get it out. In marketing terms, 'RSVP doesn't scale'. Once this realization sank in, RSVP quickly lost popularity. In a MANET context, RSVP (aka integrated services) runs directly counter to the highly volatile topology expected in MANETs -- it requires a fixed path through the routing fabric for the duration of an RSVP-endowed connection. > > I would be looking for a linux implementation, or implementing >it myself in ln >^H^HLinux > Priority queueing, which is what diff-serv does, is much more scaleable. It doesn't reintroduce state in routers. There's no reason I can think of that diff-serv wouldn't work just as well in MANETs. Just don't expect determinism. The Linux diffserv list has this in the address block, help yourself: List-Help: List-Post: List-Subscribe: , List-Id: General discussion of Differentiated Services on Linux List-Unsubscribe: , List-Archive: > > Any comments at all are welcome, >sorry if this is the wrong place. > > >Thanks, >John Tapsell > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 14:11:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05868 for ; Thu, 27 Jun 2002 14:11:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28829; Thu, 27 Jun 2002 13:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28800 for ; Thu, 27 Jun 2002 13:44:06 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03837 for ; Thu, 27 Jun 2002 13:43:21 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2002 17:48:33 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5RHaI4Y021832; Thu, 27 Jun 2002 10:36:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> Date: Thu, 27 Jun 2002 10:33:02 -0700 To: "Mullen, John P. (Contractor)" , Dario Bottazzi , manet@ietf.org From: Rex Buddenberg Subject: RE: [manet] IP addresses in MANET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > >The IP address in the Internet is hierarchal. Each node is given an address >that reflects its position in the topology of the Internet, much as State >and City reflects a person's location within the US. This allows for >efficient routing, as you point out, by reducing the need for propagating >local detail to other routers. John, I find the database language appropriate for describing the problem. IP addresses are data structures that are not fully normalized. IP addresses tell you two things, not one (which would be fully normalized): - identity - location (your point about hierarchical) In the wired internet, you move to a new location, you get a new IP address. Even though your identity is unchanged. Mobile IP is one method for getting around that, but I think that Charlie would agree that that's not a thorough enough solution for MANETs of any scale. -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jun 27 14:11:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05876 for ; Thu, 27 Jun 2002 14:11:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01819 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 14:12:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28829; Thu, 27 Jun 2002 13:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28800 for ; Thu, 27 Jun 2002 13:44:06 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03837 for ; Thu, 27 Jun 2002 13:43:21 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2002 17:48:33 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5RHaI4Y021832; Thu, 27 Jun 2002 10:36:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> Date: Thu, 27 Jun 2002 10:33:02 -0700 To: "Mullen, John P. (Contractor)" , Dario Bottazzi , manet@ietf.org From: Rex Buddenberg Subject: RE: [manet] IP addresses in MANET Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > >The IP address in the Internet is hierarchal. Each node is given an address >that reflects its position in the topology of the Internet, much as State >and City reflects a person's location within the US. This allows for >efficient routing, as you point out, by reducing the need for propagating >local detail to other routers. John, I find the database language appropriate for describing the problem. IP addresses are data structures that are not fully normalized. IP addresses tell you two things, not one (which would be fully normalized): - identity - location (your point about hierarchical) In the wired internet, you move to a new location, you get a new IP address. Even though your identity is unchanged. Mobile IP is one method for getting around that, but I think that Charlie would agree that that's not a thorough enough solution for MANETs of any scale. -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 14:40:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07906 for ; Thu, 27 Jun 2002 14:40:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02229; Thu, 27 Jun 2002 14:17:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02199 for ; Thu, 27 Jun 2002 14:17:30 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06203 for ; Thu, 27 Jun 2002 14:16:40 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12380; Thu, 27 Jun 2002 11:16:54 -0700 (PDT) Received: from sun.com (dsl198-18.Eng.Sun.COM [129.146.198.18]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5RIGrC18394; Thu, 27 Jun 2002 11:16:53 -0700 (PDT) Message-ID: <3D1B56B4.AE2AE54D@sun.com> Date: Thu, 27 Jun 2002 11:17:24 -0700 From: Kuldip Singh Pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Forgive me for my limited knowledge of this working group. I have been following this discussion for the last few days and thought of expressing my views and have questions. IMO, adhocism is adhocism - its not planned or organized. For e.g. if I become a part of a small group/conf./gathering in a pure adhoc manner for a short while. Moreover, MANET is not trying to address Mobile IP. Am I right! o In this case, where would I get my permanent IP address from? o Moreover, Internet is already running out of IP addresses, so, how would each and every 802.11 enabled device get its unique IP address? o I agree with some of you that unlike a wired device, a MANET device is mobile. So, an IP address is only serving as an Identity of the device and not its location info. So, a virtual IP address or an ID could be more meaningful than an IP address. o Also, in a wired planet, its easier to detect address conflicts, in a wireless world, it would be tough to detect a conflict. MANET may already be addressing this issue, if so, I would be interested in pointers to this info. -Kuldip Rex Buddenberg wrote: > > > > >The IP address in the Internet is hierarchal. Each node is given an address > >that reflects its position in the topology of the Internet, much as State > >and City reflects a person's location within the US. This allows for > >efficient routing, as you point out, by reducing the need for propagating > >local detail to other routers. > > John, > > I find the database language appropriate for describing the problem. > IP addresses are data structures that are not fully normalized. IP > addresses tell you two things, not one (which would be fully > normalized): > - identity > - location (your point about hierarchical) > > In the wired internet, you move to a new location, you get a new IP > address. Even though your identity is unchanged. > > Mobile IP is one method for getting around that, but I think that > Charlie would agree that that's not a thorough enough solution for > MANETs of any scale. > > -- > b > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Kuldip Singh Pabla Peer-2-Peer Networking _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 14:40:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07913 for ; Thu, 27 Jun 2002 14:40:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04546 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 14:41:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02229; Thu, 27 Jun 2002 14:17:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02199 for ; Thu, 27 Jun 2002 14:17:30 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06203 for ; Thu, 27 Jun 2002 14:16:40 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12380; Thu, 27 Jun 2002 11:16:54 -0700 (PDT) Received: from sun.com (dsl198-18.Eng.Sun.COM [129.146.198.18]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5RIGrC18394; Thu, 27 Jun 2002 11:16:53 -0700 (PDT) Message-ID: <3D1B56B4.AE2AE54D@sun.com> Date: Thu, 27 Jun 2002 11:17:24 -0700 From: Kuldip Singh Pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rex Buddenberg , manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Forgive me for my limited knowledge of this working group. I have been following this discussion for the last few days and thought of expressing my views and have questions. IMO, adhocism is adhocism - its not planned or organized. For e.g. if I become a part of a small group/conf./gathering in a pure adhoc manner for a short while. Moreover, MANET is not trying to address Mobile IP. Am I right! o In this case, where would I get my permanent IP address from? o Moreover, Internet is already running out of IP addresses, so, how would each and every 802.11 enabled device get its unique IP address? o I agree with some of you that unlike a wired device, a MANET device is mobile. So, an IP address is only serving as an Identity of the device and not its location info. So, a virtual IP address or an ID could be more meaningful than an IP address. o Also, in a wired planet, its easier to detect address conflicts, in a wireless world, it would be tough to detect a conflict. MANET may already be addressing this issue, if so, I would be interested in pointers to this info. -Kuldip Rex Buddenberg wrote: > > > > >The IP address in the Internet is hierarchal. Each node is given an address > >that reflects its position in the topology of the Internet, much as State > >and City reflects a person's location within the US. This allows for > >efficient routing, as you point out, by reducing the need for propagating > >local detail to other routers. > > John, > > I find the database language appropriate for describing the problem. > IP addresses are data structures that are not fully normalized. IP > addresses tell you two things, not one (which would be fully > normalized): > - identity > - location (your point about hierarchical) > > In the wired internet, you move to a new location, you get a new IP > address. Even though your identity is unchanged. > > Mobile IP is one method for getting around that, but I think that > Charlie would agree that that's not a thorough enough solution for > MANETs of any scale. > > -- > b > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Kuldip Singh Pabla Peer-2-Peer Networking _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 14:55:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09047 for ; Thu, 27 Jun 2002 14:55:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03002; Thu, 27 Jun 2002 14:26:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02966 for ; Thu, 27 Jun 2002 14:26:33 -0400 (EDT) Received: from lax-gate6.raytheon.com (lax-gate6.raytheon.com [199.46.200.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06797 for ; Thu, 27 Jun 2002 14:25:47 -0400 (EDT) Received: from ds02w01.directory.ray.com (ds02w01.directory.ray.com [147.25.154.117]) by lax-gate6.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5RIQUt22960 for ; Thu, 27 Jun 2002 11:26:31 -0700 (PDT) Received: from ds02w01.directory.ray.com (root@localhost) by ds02w01.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RIQPZB024687 for ; Thu, 27 Jun 2002 13:26:28 -0500 (CDT) Received: from mailhub.fcd.esys.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02w01.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RIQKqT024612 for ; Thu, 27 Jun 2002 13:26:21 -0500 (CDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fcd.esys.com (8.9.3/8.9.3) with ESMTP id OAA16885 for ; Thu, 27 Jun 2002 14:23:31 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 14:23:33 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002C9CEE4@fcexchange.fal.us.ray.com> From: "Su, William" To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 14:23:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 14:55:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09053 for ; Thu, 27 Jun 2002 14:55:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05892 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 14:56:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03002; Thu, 27 Jun 2002 14:26:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02966 for ; Thu, 27 Jun 2002 14:26:33 -0400 (EDT) Received: from lax-gate6.raytheon.com (lax-gate6.raytheon.com [199.46.200.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06797 for ; Thu, 27 Jun 2002 14:25:47 -0400 (EDT) Received: from ds02w01.directory.ray.com (ds02w01.directory.ray.com [147.25.154.117]) by lax-gate6.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5RIQUt22960 for ; Thu, 27 Jun 2002 11:26:31 -0700 (PDT) Received: from ds02w01.directory.ray.com (root@localhost) by ds02w01.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RIQPZB024687 for ; Thu, 27 Jun 2002 13:26:28 -0500 (CDT) Received: from mailhub.fcd.esys.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02w01.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RIQKqT024612 for ; Thu, 27 Jun 2002 13:26:21 -0500 (CDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fcd.esys.com (8.9.3/8.9.3) with ESMTP id OAA16885 for ; Thu, 27 Jun 2002 14:23:31 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 14:23:33 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002C9CEE4@fcexchange.fal.us.ray.com> From: "Su, William" To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 14:23:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 15:16:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10252 for ; Thu, 27 Jun 2002 15:16:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04533; Thu, 27 Jun 2002 14:41:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04504 for ; Thu, 27 Jun 2002 14:41:14 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07899 for ; Thu, 27 Jun 2002 14:40:28 -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 LAA08030; Thu, 27 Jun 2002 11:40:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RIeaM04555; Thu, 27 Jun 2002 11:40:36 -0700 X-mProtect: <200206271840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7riznX; Thu, 27 Jun 2002 11:40:34 PDT Message-ID: <3D1B5C23.82EDFEA5@iprg.nokia.com> Date: Thu, 27 Jun 2002 11:40:35 -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: Rex Buddenberg , Kuldip Singh Pabla CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> <3D1B56B4.AE2AE54D@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello folks, So little time just now ... Kuldip Singh Pabla wrote: > IMO, adhocism is adhocism - its not planned or organized. For e.g. if I > become a part of a small group/conf./gathering in a pure adhoc manner > for a short while. Moreover, MANET is not trying to address Mobile IP. > Am I right! That would match my view. Mobile IP requires infrastructure, and manet does not. > o In this case, where would I get my permanent IP address from? Anywhere you like -- or, you may try to autoconfigure one according to the IPv4 and/or IPv6 draft(s) that have been submitted. > o Moreover, Internet is already running out of IP addresses, so, how > would each and every 802.11 enabled device get its unique IP address? The abovementioned drafts offer solutions, but of course I would suggest that the IPv6 version is better at offering enough addresses. > o I agree with some of you that unlike a wired device, a MANET device is > mobile. So, an IP address is only serving as an Identity of the device > and not its location info. So, a virtual IP address or an ID could be > more meaningful than an IP address. But protocols work on bits, not meanings. > o Also, in a wired planet, its easier to detect address conflicts, in a > wireless world, it would be tough to detect a conflict. MANET may > already be addressing this issue, if so, I would be interested in > pointers to this info. The conflict MAY be irrelevant for temporary addresses used in networks that are never connected to each other or the Internet. > Rex Buddenberg wrote: > > In the wired internet, you move to a new location, you get a new IP > > address. Even though your identity is unchanged. > > > > Mobile IP is one method for getting around that, but I think that > > Charlie would agree that that's not a thorough enough solution for > > MANETs of any scale. What I would rather say is that Mobile IP can be used when there is infrastructure, and mobile ad hoc networks need solutions for cases when there is no infrastructure. However, as it turns out, the latter solution is still useful with Mobile IP if the ad hoc network has connectivity to the Internet. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 15:16:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10259 for ; Thu, 27 Jun 2002 15:16:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14681 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 15:17:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04533; Thu, 27 Jun 2002 14:41:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04504 for ; Thu, 27 Jun 2002 14:41:14 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07899 for ; Thu, 27 Jun 2002 14:40:28 -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 LAA08030; Thu, 27 Jun 2002 11:40:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RIeaM04555; Thu, 27 Jun 2002 11:40:36 -0700 X-mProtect: <200206271840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7riznX; Thu, 27 Jun 2002 11:40:34 PDT Message-ID: <3D1B5C23.82EDFEA5@iprg.nokia.com> Date: Thu, 27 Jun 2002 11:40:35 -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: Rex Buddenberg , Kuldip Singh Pabla CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <02Jun27.072903mdt.117127@gw.trac.wsmr.army.mil> <3D1B56B4.AE2AE54D@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello folks, So little time just now ... Kuldip Singh Pabla wrote: > IMO, adhocism is adhocism - its not planned or organized. For e.g. if I > become a part of a small group/conf./gathering in a pure adhoc manner > for a short while. Moreover, MANET is not trying to address Mobile IP. > Am I right! That would match my view. Mobile IP requires infrastructure, and manet does not. > o In this case, where would I get my permanent IP address from? Anywhere you like -- or, you may try to autoconfigure one according to the IPv4 and/or IPv6 draft(s) that have been submitted. > o Moreover, Internet is already running out of IP addresses, so, how > would each and every 802.11 enabled device get its unique IP address? The abovementioned drafts offer solutions, but of course I would suggest that the IPv6 version is better at offering enough addresses. > o I agree with some of you that unlike a wired device, a MANET device is > mobile. So, an IP address is only serving as an Identity of the device > and not its location info. So, a virtual IP address or an ID could be > more meaningful than an IP address. But protocols work on bits, not meanings. > o Also, in a wired planet, its easier to detect address conflicts, in a > wireless world, it would be tough to detect a conflict. MANET may > already be addressing this issue, if so, I would be interested in > pointers to this info. The conflict MAY be irrelevant for temporary addresses used in networks that are never connected to each other or the Internet. > Rex Buddenberg wrote: > > In the wired internet, you move to a new location, you get a new IP > > address. Even though your identity is unchanged. > > > > Mobile IP is one method for getting around that, but I think that > > Charlie would agree that that's not a thorough enough solution for > > MANETs of any scale. What I would rather say is that Mobile IP can be used when there is infrastructure, and mobile ad hoc networks need solutions for cases when there is no infrastructure. However, as it turns out, the latter solution is still useful with Mobile IP if the ad hoc network has connectivity to the Internet. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 15:37:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11489 for ; Thu, 27 Jun 2002 15:37:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13096; Thu, 27 Jun 2002 15:09:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13066 for ; Thu, 27 Jun 2002 15:09:09 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09610 for ; Thu, 27 Jun 2002 15:08:22 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 13:09:00 -0600 Message-Id: <02Jun27.130900mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Su, William" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 13:08:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 15:37:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11499 for ; Thu, 27 Jun 2002 15:37:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16263 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 15:38:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13096; Thu, 27 Jun 2002 15:09:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13066 for ; Thu, 27 Jun 2002 15:09:09 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09610 for ; Thu, 27 Jun 2002 15:08:22 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 13:09:00 -0600 Message-Id: <02Jun27.130900mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Su, William" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 13:08:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 17:21:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16761 for ; Thu, 27 Jun 2002 17:21:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21816; Thu, 27 Jun 2002 16:55:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21784 for ; Thu, 27 Jun 2002 16:55:26 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15418 for ; Thu, 27 Jun 2002 16:54:39 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jun 27 13:54:38 2002 To: "Rex Buddenberg" , "Kuldip Singh Pabla" , "Charles E. Perkins" Date: Thu, 27 Jun 2002 16:54:38 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [manet] IP addresses in MANET X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day everybody, I've been following on the IP addressing proplem, and want to contribute some thoughts 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" which is global vs local IP 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. Hope I made my point clear, any input? Yasser Carleton U Ottawa Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 17:21:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16767 for ; Thu, 27 Jun 2002 17:21:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24819 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 17:22:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21816; Thu, 27 Jun 2002 16:55:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21784 for ; Thu, 27 Jun 2002 16:55:26 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15418 for ; Thu, 27 Jun 2002 16:54:39 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jun 27 13:54:38 2002 To: "Rex Buddenberg" , "Kuldip Singh Pabla" , "Charles E. Perkins" Date: Thu, 27 Jun 2002 16:54:38 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [manet] IP addresses in MANET X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day everybody, I've been following on the IP addressing proplem, and want to contribute some thoughts 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" which is global vs local IP 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. Hope I made my point clear, any input? Yasser Carleton U Ottawa Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 17:39:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17838 for ; Thu, 27 Jun 2002 17:39:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23655; Thu, 27 Jun 2002 17:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23630 for ; Thu, 27 Jun 2002 17:05:58 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15884 for ; Thu, 27 Jun 2002 17:05:11 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA07352; Thu, 27 Jun 2002 16:05:55 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA04814; Thu, 27 Jun 2002 16:05:52 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5RL5r001954; Thu, 27 Jun 2002 14:05:53 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jun 2002 17:05:52 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'yasser.lotfy@lycos.com'" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:06:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I agree with the thrust of what Yasser says below, which is why I initially offered that MANET addressing would in effect be a flat address space, at least as long as the packets remain within the MANET. IPv6 would be nice because it supports autoconfiguration. Perhaps, for example, an IP address prefix could be added to the IP addresses used in the MANET by whatever gateway(s) might connect the MANET to the Internet. Meanwhile, a unique MAC address embedded in the IPv6 address would guarantee address uniqueness within the MANET, and then in the Internet. But these are just words. Exactly how one keeps multiple gateways from sending duplicate packets to the Internet, for instance, is not clear to me. As well as a host of other issues. Bert > -----Original Message----- > From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] > Sent: Thursday, June 27, 2002 4:55 PM > To: Rex Buddenberg; Kuldip Singh Pabla; Charles E. Perkins > Cc: manet@ietf.org > Subject: Re: [manet] IP addresses in MANET > > > Good day everybody, > > I've been following on the IP addressing proplem, and want to > contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial > solution is available for ad-hoc, it makes absolute sense to > use IPv6 for addressing. This solve the problem of "Internet > running out of space" and introduce the problem of "Personal > IP" which is global vs local IP > > 2) Assigning "pool of addresses" for an ad-hoc network is so > difficult in the absense of central authority. This means > that nodes will have to announce an IP address when joining > the network, get authenticated (how the authentication could > be done is a different issue), then the nodes can move within > the same ad-hoc freely by keeping their IP. > > 3) Local traffic (within the same ad-hoc) can be routed > easly. Internet traffic will be subject to (gateway address > resolution). Since many gateways may work for the same > ad-hoc, we need to guarantee consistency between all gateways. > > This way no central authority is needed which is very > consistent with the MANET charter. Also, if an individual > nodes has a static IP it should be able to use it. The > authentication process can elementate the possibility of IP > address conflict. > > Hope I made my point clear, any input? > > Yasser > > Carleton U > Ottawa Canada _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 17:39:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17843 for ; Thu, 27 Jun 2002 17:39:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26220 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 17:39:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23655; Thu, 27 Jun 2002 17:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23630 for ; Thu, 27 Jun 2002 17:05:58 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15884 for ; Thu, 27 Jun 2002 17:05:11 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA07352; Thu, 27 Jun 2002 16:05:55 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA04814; Thu, 27 Jun 2002 16:05:52 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5RL5r001954; Thu, 27 Jun 2002 14:05:53 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jun 2002 17:05:52 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'yasser.lotfy@lycos.com'" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:06:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I agree with the thrust of what Yasser says below, which is why I initially offered that MANET addressing would in effect be a flat address space, at least as long as the packets remain within the MANET. IPv6 would be nice because it supports autoconfiguration. Perhaps, for example, an IP address prefix could be added to the IP addresses used in the MANET by whatever gateway(s) might connect the MANET to the Internet. Meanwhile, a unique MAC address embedded in the IPv6 address would guarantee address uniqueness within the MANET, and then in the Internet. But these are just words. Exactly how one keeps multiple gateways from sending duplicate packets to the Internet, for instance, is not clear to me. As well as a host of other issues. Bert > -----Original Message----- > From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] > Sent: Thursday, June 27, 2002 4:55 PM > To: Rex Buddenberg; Kuldip Singh Pabla; Charles E. Perkins > Cc: manet@ietf.org > Subject: Re: [manet] IP addresses in MANET > > > Good day everybody, > > I've been following on the IP addressing proplem, and want to > contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial > solution is available for ad-hoc, it makes absolute sense to > use IPv6 for addressing. This solve the problem of "Internet > running out of space" and introduce the problem of "Personal > IP" which is global vs local IP > > 2) Assigning "pool of addresses" for an ad-hoc network is so > difficult in the absense of central authority. This means > that nodes will have to announce an IP address when joining > the network, get authenticated (how the authentication could > be done is a different issue), then the nodes can move within > the same ad-hoc freely by keeping their IP. > > 3) Local traffic (within the same ad-hoc) can be routed > easly. Internet traffic will be subject to (gateway address > resolution). Since many gateways may work for the same > ad-hoc, we need to guarantee consistency between all gateways. > > This way no central authority is needed which is very > consistent with the MANET charter. Also, if an individual > nodes has a static IP it should be able to use it. The > authentication process can elementate the possibility of IP > address conflict. > > Hope I made my point clear, any input? > > Yasser > > Carleton U > Ottawa Canada _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 17:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18791 for ; Thu, 27 Jun 2002 17:58:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25091; Thu, 27 Jun 2002 17:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25062 for ; Thu, 27 Jun 2002 17:26:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17080 for ; Thu, 27 Jun 2002 17:25:56 -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 OAA19648; Thu, 27 Jun 2002 14:26:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RLQ9B15319; Thu, 27 Jun 2002 14:26:09 -0700 X-mProtect: <200206272126> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde47AHP; Thu, 27 Jun 2002 14:26:07 PDT Message-ID: <3D1B846A.1080009@iprg.nokia.com> Date: Thu, 27 Jun 2002 14:32:26 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C7@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Bert, Manfredi, Albert E wrote: > But these are just words. Exactly how one keeps multiple > gateways from sending duplicate packets to the Internet, I'm not sure I'm interpreting your concern correctly, but I don't think there should be any such issue when multiple IPv6 gateways within the MANET peer with the Internet. Nodes that send packets (and/or intermediate forwarding hops) will eventually pick one such gateway as the final next hop before the packet leaves the MANET. The unicast MAC address of the gateway is then placed as the destination MAC address in the forwarded packet, so only one border gateway will do the forwarding and duplicates should not arise. Did I miss your point? Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 17:58:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18797 for ; Thu, 27 Jun 2002 17:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27653 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 17:59:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25091; Thu, 27 Jun 2002 17:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25062 for ; Thu, 27 Jun 2002 17:26:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17080 for ; Thu, 27 Jun 2002 17:25:56 -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 OAA19648; Thu, 27 Jun 2002 14:26:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RLQ9B15319; Thu, 27 Jun 2002 14:26:09 -0700 X-mProtect: <200206272126> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpde47AHP; Thu, 27 Jun 2002 14:26:07 PDT Message-ID: <3D1B846A.1080009@iprg.nokia.com> Date: Thu, 27 Jun 2002 14:32:26 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C7@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Bert, Manfredi, Albert E wrote: > But these are just words. Exactly how one keeps multiple > gateways from sending duplicate packets to the Internet, I'm not sure I'm interpreting your concern correctly, but I don't think there should be any such issue when multiple IPv6 gateways within the MANET peer with the Internet. Nodes that send packets (and/or intermediate forwarding hops) will eventually pick one such gateway as the final next hop before the packet leaves the MANET. The unicast MAC address of the gateway is then placed as the destination MAC address in the forwarded packet, so only one border gateway will do the forwarding and duplicates should not arise. Did I miss your point? Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 18:20:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19859 for ; Thu, 27 Jun 2002 18:20:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26772; Thu, 27 Jun 2002 17:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26743 for ; Thu, 27 Jun 2002 17:49:12 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18337 for ; Thu, 27 Jun 2002 17:48:26 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA12768; Thu, 27 Jun 2002 14:49:04 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA13790; Thu, 27 Jun 2002 16:49:00 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5RLn1016550; Thu, 27 Jun 2002 14:49:01 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jun 2002 17:49:01 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C9@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Fred L. Templin'" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:49:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Fred L. Templin wrote: > > Hi Bert, > > Manfredi, Albert E wrote: > > But these are just words. Exactly how one keeps multiple > > gateways from sending duplicate packets to the Internet, > > I'm not sure I'm interpreting your concern correctly, but > I don't think there should be any such issue when multiple > IPv6 gateways within the MANET peer with the Internet. Nodes > that send packets (and/or intermediate forwarding hops) will > eventually pick one such gateway as the final next hop before > the packet leaves the MANET. The unicast MAC address of the > gateway is then placed as the destination MAC address in the > forwarded packet, so only one border gateway will do the > forwarding and duplicates should not arise. Hmmm. I was thinking that the IP DA of the packet destined to the Internet would be the IP DA of that host out there, in the Internet. And that there would be a good likelihood that several gateways to the Internet could see that packet, and add their own prefix to the IP SA, before sending it on. So the packets would seem different out there, within the wired Internet. Are you saying that the packet transmitted by the MANET host is encapsulated in another packet, with the gateway's MANET address on it? I suppose you could establish that sort of initial transaction, before transmitting to the outside world. As the MANET host moves, it would have to be aware of changes to the gateway to the Internet. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 18:20:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19864 for ; Thu, 27 Jun 2002 18:20:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29335 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 18:21:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26772; Thu, 27 Jun 2002 17:49:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26743 for ; Thu, 27 Jun 2002 17:49:12 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18337 for ; Thu, 27 Jun 2002 17:48:26 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA12768; Thu, 27 Jun 2002 14:49:04 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA13790; Thu, 27 Jun 2002 16:49:00 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5RLn1016550; Thu, 27 Jun 2002 14:49:01 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jun 2002 17:49:01 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C9@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Fred L. Templin'" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:49:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Fred L. Templin wrote: > > Hi Bert, > > Manfredi, Albert E wrote: > > But these are just words. Exactly how one keeps multiple > > gateways from sending duplicate packets to the Internet, > > I'm not sure I'm interpreting your concern correctly, but > I don't think there should be any such issue when multiple > IPv6 gateways within the MANET peer with the Internet. Nodes > that send packets (and/or intermediate forwarding hops) will > eventually pick one such gateway as the final next hop before > the packet leaves the MANET. The unicast MAC address of the > gateway is then placed as the destination MAC address in the > forwarded packet, so only one border gateway will do the > forwarding and duplicates should not arise. Hmmm. I was thinking that the IP DA of the packet destined to the Internet would be the IP DA of that host out there, in the Internet. And that there would be a good likelihood that several gateways to the Internet could see that packet, and add their own prefix to the IP SA, before sending it on. So the packets would seem different out there, within the wired Internet. Are you saying that the packet transmitted by the MANET host is encapsulated in another packet, with the gateway's MANET address on it? I suppose you could establish that sort of initial transaction, before transmitting to the outside world. As the MANET host moves, it would have to be aware of changes to the gateway to the Internet. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 18:22:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19957 for ; Thu, 27 Jun 2002 18:22:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27183; Thu, 27 Jun 2002 17:55:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27153 for ; Thu, 27 Jun 2002 17:55:14 -0400 (EDT) Received: from bos-gate1.raytheon.com (bos-gate1.raytheon.com [199.46.198.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18625 for ; Thu, 27 Jun 2002 17:54:29 -0400 (EDT) Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate1.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5RLtEb10525; Thu, 27 Jun 2002 17:55:14 -0400 (EDT) Received: from ds02e00.directory.ray.com (root@localhost) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RLtDmL018896; Thu, 27 Jun 2002 17:55:13 -0400 (EDT) Received: from mailhub.fal.us.ray.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RLtCA1018889; Thu, 27 Jun 2002 17:55:12 -0400 (EDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fal.us.ray.com (8.9.3/8.9.3) with ESMTP id RAA00357; Thu, 27 Jun 2002 17:55:11 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 17:55:14 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002C9D02D@fcexchange.fal.us.ray.com> From: "Su, William" To: "Mullen, John P. (Contractor)" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:55:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John, Very good point. I think I totally agree with you on the benefit of hierchical scheme :) The scenario I was thinking is the situation when all nodes in the field are moving very rapidly in different random directions. For this case, it would seem that a lot of clusters would have to be created/modified. Therefore the bulk of overhead actually becomes cluster maintainence (cluster head election, gateway nodes selection, .etc) rather than routing updates. Although the routing info probably also needed to be propagated more frequently to keep up with the fast changing clusters. I guess I may be thinking of an "extreme" case that the mobility speed is so high each cluster stays intact for only a very short amount of time, and all its members are constantly joining/dropping rapidly. Although I'm not so sure at what mobility threshold using cluster in this case will generate too much cluster maintainence overhead. Perhaps there are some MANET papers that have insights in this area? IMHO, I think cluster based approach would definitely work very well in a situation when the mobility pattern for a certain cluster or group is similar (i.e. a squad based cluster). If there are no group mobility behavior, there is a possibility that cluster maintaince might actually congest the network. I would also suspect that factors such as cluster size, radius, and the efficiency of cluster maintenance scheme are important. I think it would probably be an interesting study? :) -Bill -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Thursday, June 27, 2002 3:09 PM To: Su, William; manet@ietf.org Subject: RE: [manet] IP addresses in MANET Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 18:22:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19966 for ; Thu, 27 Jun 2002 18:22:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29432 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 18:23:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27183; Thu, 27 Jun 2002 17:55:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27153 for ; Thu, 27 Jun 2002 17:55:14 -0400 (EDT) Received: from bos-gate1.raytheon.com (bos-gate1.raytheon.com [199.46.198.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18625 for ; Thu, 27 Jun 2002 17:54:29 -0400 (EDT) Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate1.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id g5RLtEb10525; Thu, 27 Jun 2002 17:55:14 -0400 (EDT) Received: from ds02e00.directory.ray.com (root@localhost) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RLtDmL018896; Thu, 27 Jun 2002 17:55:13 -0400 (EDT) Received: from mailhub.fal.us.ray.com (mailhub.fcd.esys.com [147.18.176.59]) by ds02e00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g5RLtCA1018889; Thu, 27 Jun 2002 17:55:12 -0400 (EDT) Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31]) by mailhub.fal.us.ray.com (8.9.3/8.9.3) with ESMTP id RAA00357; Thu, 27 Jun 2002 17:55:11 -0400 (EDT) Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 17:55:14 -0400 Message-ID: <72F06A8F0165D611AD2A00508BCFF60002C9D02D@fcexchange.fal.us.ray.com> From: "Su, William" To: "Mullen, John P. (Contractor)" , manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 17:55:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John, Very good point. I think I totally agree with you on the benefit of hierchical scheme :) The scenario I was thinking is the situation when all nodes in the field are moving very rapidly in different random directions. For this case, it would seem that a lot of clusters would have to be created/modified. Therefore the bulk of overhead actually becomes cluster maintainence (cluster head election, gateway nodes selection, .etc) rather than routing updates. Although the routing info probably also needed to be propagated more frequently to keep up with the fast changing clusters. I guess I may be thinking of an "extreme" case that the mobility speed is so high each cluster stays intact for only a very short amount of time, and all its members are constantly joining/dropping rapidly. Although I'm not so sure at what mobility threshold using cluster in this case will generate too much cluster maintainence overhead. Perhaps there are some MANET papers that have insights in this area? IMHO, I think cluster based approach would definitely work very well in a situation when the mobility pattern for a certain cluster or group is similar (i.e. a squad based cluster). If there are no group mobility behavior, there is a possibility that cluster maintaince might actually congest the network. I would also suspect that factors such as cluster size, radius, and the efficiency of cluster maintenance scheme are important. I think it would probably be an interesting study? :) -Bill -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Thursday, June 27, 2002 3:09 PM To: Su, William; manet@ietf.org Subject: RE: [manet] IP addresses in MANET Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 18:36:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20544 for ; Thu, 27 Jun 2002 18:36:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28530; Thu, 27 Jun 2002 18:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28501 for ; Thu, 27 Jun 2002 18:07:00 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19196 for ; Thu, 27 Jun 2002 18:06: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 PAA21866; Thu, 27 Jun 2002 15:06:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RM6S007708; Thu, 27 Jun 2002 15:06:28 -0700 X-mProtect: <200206272206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwmircE; Thu, 27 Jun 2002 15:06:26 PDT Message-ID: <3D1B8DDE.6000209@iprg.nokia.com> Date: Thu, 27 Jun 2002 15:12:46 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C9@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > Hmmm. I was thinking that the IP DA of the packet destined to the Internet > would be the IP DA of that host out there, in the Internet. And that there > would be a good likelihood that several gateways to the Internet could see > that packet, and add their own prefix to the IP SA, before sending it on. > So the packets would seem different out there, within the wired Internet. Several gateways might "see" the packet in the RF sense, but only the one whose MAC address appears in the L2 header's destination address field will act on it. (Also, the gateways don't add their own prefix; hosts configure their own prefixes via stateless or statefull address autoconfiguration.) > Are you saying that the packet transmitted by the MANET host is > encapsulated in another packet, with the gateway's MANET address > on it? I suppose you could establish that sort of initial transaction, > before transmitting to the outside world. As the MANET host moves, it > would have to be aware of changes to the gateway to the Internet. I'm just talking about vanilla IPv6 forwarding and what happens with the addresses in the L2 and L3 headers during the process. How MANET hosts discover gateways to the Internet is a higher-level question and may/may not entail encapsulation. Perhaps I missed some of the earlier context for this discussion? Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 18:36:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20553 for ; Thu, 27 Jun 2002 18:36:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01171 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 18:37:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28530; Thu, 27 Jun 2002 18:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28501 for ; Thu, 27 Jun 2002 18:07:00 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19196 for ; Thu, 27 Jun 2002 18:06: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 PAA21866; Thu, 27 Jun 2002 15:06:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RM6S007708; Thu, 27 Jun 2002 15:06:28 -0700 X-mProtect: <200206272206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwmircE; Thu, 27 Jun 2002 15:06:26 PDT Message-ID: <3D1B8DDE.6000209@iprg.nokia.com> Date: Thu, 27 Jun 2002 15:12:46 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39C9@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > Hmmm. I was thinking that the IP DA of the packet destined to the Internet > would be the IP DA of that host out there, in the Internet. And that there > would be a good likelihood that several gateways to the Internet could see > that packet, and add their own prefix to the IP SA, before sending it on. > So the packets would seem different out there, within the wired Internet. Several gateways might "see" the packet in the RF sense, but only the one whose MAC address appears in the L2 header's destination address field will act on it. (Also, the gateways don't add their own prefix; hosts configure their own prefixes via stateless or statefull address autoconfiguration.) > Are you saying that the packet transmitted by the MANET host is > encapsulated in another packet, with the gateway's MANET address > on it? I suppose you could establish that sort of initial transaction, > before transmitting to the outside world. As the MANET host moves, it > would have to be aware of changes to the gateway to the Internet. I'm just talking about vanilla IPv6 forwarding and what happens with the addresses in the L2 and L3 headers during the process. How MANET hosts discover gateways to the Internet is a higher-level question and may/may not entail encapsulation. Perhaps I missed some of the earlier context for this discussion? Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 18:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21176 for ; Thu, 27 Jun 2002 18:51:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00501; Thu, 27 Jun 2002 18:32:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00385 for ; Thu, 27 Jun 2002 18:32:41 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20326 for ; Thu, 27 Jun 2002 18:31:55 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 16:32:33 -0600 Message-Id: <02Jun27.163233mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:32:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, this is something I'm not too familiar with, but I suspect the Originator will send out a request for information and then select one of the possible paths after getting replies (in ad-hoc routing). Details vary by protocol, but this is the usual situation within the MANET. For a MANET to work, you must have sufficient hosts in an area to have connectivity. To have a stable MANET, you need more hosts than absolutely necessary. Otherwise, your MANET will be frequently partitioned due to a lack of redundancy. As a result, it is a routine MANET problem to prevent multiple paths by selecting from among the available hosts, the hosts to use. I am assuming here that the gateway nodes would appear to be MANET nodes from the MANET side, so they would probably be treated as any other MANET node in this respect. The originator would see each reachable gateway as a candidate node and simply pick one. The others, being well-behaved MANET nodes, would simply discard packets not intended for them. I'm also assuming that, from the perspective of the MANET, every Internet gateway is about as good as every other Internet gateway on the Internet side. That is, the capacity of Internet links would be so much greater than those within the MANET, that the control scheme could consider the gateway as the next-to-last node. John Mullen P.S. I must sign off for now, but will be back tomorrow. -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Thursday, June 27, 2002 4:11 PM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] IP addresses in MANET John, I think that as long as everyone is in the MANET, what you describe probably works. But how are hosts told what the available gateways are? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Thursday, June 27, 2002 6:02 PM > To: Manfredi, Albert E > Subject: RE: [manet] IP addresses in MANET > > > Hi Bert, > > Well, I can help you with the last point. > > The trick in a MANET is that each node has the potential to > be a router, but > the protocol selects just certain nodes to act as routers. > As the topology > changes, different nodes become or cease being routers, as > needed. What > each protocol tries to do is maintain the minimum number of > active routers > necessary to provide the required level of service. > Otherwise, too many > nodes will transmit and channel utilization will go up. > > The same is true for messages to the Internet. Whatever > protocol is used, > its job will be to assure that just one Internet gateway, of those > available, is selected as the gateway to use. > > As for the mechanism, there are two basic ways: route > specification, as in > DSR, or routing tables, as in AODV. In the first case, the > packet contains > the complete path from source to destination. In the second, > each node > maintains a table of actions for each source and destination. > > Suppose the path A-B-C-F is to be used. (F can be the > gateway). Under DSR, > the path A-B-C-F is in the packet. When a node receives a > packet, there are > just three possible actions (ignoring the complication of > broken links). > 1. Process the information in the packet because it is > addressed to it > (Node F), > 2. Rebroadcast the packet, if both > a. The node is on the path, but not the > destination (Nodes B, C) > and > b. The packet has not been received before. > 3. Discard the packet, if either > a. The node is not on the list, or > b. The node is on the list, but previously > broadcast the packet. > As you can see, each node on the path will (assuming connectivity) > re-broadcast the packet once and only once. Furthermore, > only Node F will > accept the packet as intended for it. Any other gateway in > the area will > just discard the packet. > > Now, with routing tables, each node maintains an entry for > each possible > destination. So, at Node B is the entry "C" for Destination > F. When Node B > receives the packet, it places C's address in the next-hop > position and > re-broadcasts it. Any other node in the area will discard the packet > because it is not the next node. At Node C, the next node is > F, the process > is repeated with "F" as the next-node, and F gets the > message. In this > case, the rules are: > 1. Process the information in the packet if the node is > the destination > (Node F), > 2. Rebroadcast the packet with an appropriate next-node > entry, if both > a. The node is the "next-Node," but not the > destination (Nodes B, > C) and > b. There is an entry for that destination in the > Node's routing > table (if not, it is broken link time). > 3. Discard the packet, if the packet is not addressed to the node. > Again, only one gateway will get the packet and all is well > with the world. > > John Mullen > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, June 27, 2002 3:07 PM > To: 'yasser.lotfy@lycos.com' > Cc: manet@ietf.org > Subject: RE: [manet] IP addresses in MANET > > > I agree with the thrust of what Yasser says below, which is > why I initially > offered that MANET addressing would in effect be a flat > address space, at > least as long as the packets remain within the MANET. > > IPv6 would be nice because it supports autoconfiguration. Perhaps, for > example, an IP address prefix could be added to the IP > addresses used in the > MANET by whatever gateway(s) might connect the MANET to the Internet. > Meanwhile, a unique MAC address embedded in the IPv6 address > would guarantee > address uniqueness within the MANET, and then in the Internet. > > But these are just words. Exactly how one keeps multiple gateways from > sending duplicate packets to the Internet, for instance, is > not clear to me. > As well as a host of other issues. > > Bert > > > > -----Original Message----- > > From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] > > Sent: Thursday, June 27, 2002 4:55 PM > > To: Rex Buddenberg; Kuldip Singh Pabla; Charles E. Perkins > > Cc: manet@ietf.org > > Subject: Re: [manet] IP addresses in MANET > > > > > > Good day everybody, > > > > I've been following on the IP addressing proplem, and want to > > contribute some thoughts > > 1) I believe ad hoc will adopt IPv6. Since no comercial > > solution is available for ad-hoc, it makes absolute sense to > > use IPv6 for addressing. This solve the problem of "Internet > > running out of space" and introduce the problem of "Personal > > IP" which is global vs local IP > > > > 2) Assigning "pool of addresses" for an ad-hoc network is so > > difficult in the absense of central authority. This means > > that nodes will have to announce an IP address when joining > > the network, get authenticated (how the authentication could > > be done is a different issue), then the nodes can move within > > the same ad-hoc freely by keeping their IP. > > > > 3) Local traffic (within the same ad-hoc) can be routed > > easly. Internet traffic will be subject to (gateway address > > resolution). Since many gateways may work for the same > > ad-hoc, we need to guarantee consistency between all gateways. > > > > This way no central authority is needed which is very > > consistent with the MANET charter. Also, if an individual > > nodes has a static IP it should be able to use it. The > > authentication process can elementate the possibility of IP > > address conflict. > > > > Hope I made my point clear, any input? > > > > Yasser > > > > Carleton U > > Ottawa Canada > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 18:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21184 for ; Thu, 27 Jun 2002 18:51:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01783 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 18:52:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00501; Thu, 27 Jun 2002 18:32:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00385 for ; Thu, 27 Jun 2002 18:32:41 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20326 for ; Thu, 27 Jun 2002 18:31:55 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 16:32:33 -0600 Message-Id: <02Jun27.163233mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:32:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, this is something I'm not too familiar with, but I suspect the Originator will send out a request for information and then select one of the possible paths after getting replies (in ad-hoc routing). Details vary by protocol, but this is the usual situation within the MANET. For a MANET to work, you must have sufficient hosts in an area to have connectivity. To have a stable MANET, you need more hosts than absolutely necessary. Otherwise, your MANET will be frequently partitioned due to a lack of redundancy. As a result, it is a routine MANET problem to prevent multiple paths by selecting from among the available hosts, the hosts to use. I am assuming here that the gateway nodes would appear to be MANET nodes from the MANET side, so they would probably be treated as any other MANET node in this respect. The originator would see each reachable gateway as a candidate node and simply pick one. The others, being well-behaved MANET nodes, would simply discard packets not intended for them. I'm also assuming that, from the perspective of the MANET, every Internet gateway is about as good as every other Internet gateway on the Internet side. That is, the capacity of Internet links would be so much greater than those within the MANET, that the control scheme could consider the gateway as the next-to-last node. John Mullen P.S. I must sign off for now, but will be back tomorrow. -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Thursday, June 27, 2002 4:11 PM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] IP addresses in MANET John, I think that as long as everyone is in the MANET, what you describe probably works. But how are hosts told what the available gateways are? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Thursday, June 27, 2002 6:02 PM > To: Manfredi, Albert E > Subject: RE: [manet] IP addresses in MANET > > > Hi Bert, > > Well, I can help you with the last point. > > The trick in a MANET is that each node has the potential to > be a router, but > the protocol selects just certain nodes to act as routers. > As the topology > changes, different nodes become or cease being routers, as > needed. What > each protocol tries to do is maintain the minimum number of > active routers > necessary to provide the required level of service. > Otherwise, too many > nodes will transmit and channel utilization will go up. > > The same is true for messages to the Internet. Whatever > protocol is used, > its job will be to assure that just one Internet gateway, of those > available, is selected as the gateway to use. > > As for the mechanism, there are two basic ways: route > specification, as in > DSR, or routing tables, as in AODV. In the first case, the > packet contains > the complete path from source to destination. In the second, > each node > maintains a table of actions for each source and destination. > > Suppose the path A-B-C-F is to be used. (F can be the > gateway). Under DSR, > the path A-B-C-F is in the packet. When a node receives a > packet, there are > just three possible actions (ignoring the complication of > broken links). > 1. Process the information in the packet because it is > addressed to it > (Node F), > 2. Rebroadcast the packet, if both > a. The node is on the path, but not the > destination (Nodes B, C) > and > b. The packet has not been received before. > 3. Discard the packet, if either > a. The node is not on the list, or > b. The node is on the list, but previously > broadcast the packet. > As you can see, each node on the path will (assuming connectivity) > re-broadcast the packet once and only once. Furthermore, > only Node F will > accept the packet as intended for it. Any other gateway in > the area will > just discard the packet. > > Now, with routing tables, each node maintains an entry for > each possible > destination. So, at Node B is the entry "C" for Destination > F. When Node B > receives the packet, it places C's address in the next-hop > position and > re-broadcasts it. Any other node in the area will discard the packet > because it is not the next node. At Node C, the next node is > F, the process > is repeated with "F" as the next-node, and F gets the > message. In this > case, the rules are: > 1. Process the information in the packet if the node is > the destination > (Node F), > 2. Rebroadcast the packet with an appropriate next-node > entry, if both > a. The node is the "next-Node," but not the > destination (Nodes B, > C) and > b. There is an entry for that destination in the > Node's routing > table (if not, it is broken link time). > 3. Discard the packet, if the packet is not addressed to the node. > Again, only one gateway will get the packet and all is well > with the world. > > John Mullen > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, June 27, 2002 3:07 PM > To: 'yasser.lotfy@lycos.com' > Cc: manet@ietf.org > Subject: RE: [manet] IP addresses in MANET > > > I agree with the thrust of what Yasser says below, which is > why I initially > offered that MANET addressing would in effect be a flat > address space, at > least as long as the packets remain within the MANET. > > IPv6 would be nice because it supports autoconfiguration. Perhaps, for > example, an IP address prefix could be added to the IP > addresses used in the > MANET by whatever gateway(s) might connect the MANET to the Internet. > Meanwhile, a unique MAC address embedded in the IPv6 address > would guarantee > address uniqueness within the MANET, and then in the Internet. > > But these are just words. Exactly how one keeps multiple gateways from > sending duplicate packets to the Internet, for instance, is > not clear to me. > As well as a host of other issues. > > Bert > > > > -----Original Message----- > > From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] > > Sent: Thursday, June 27, 2002 4:55 PM > > To: Rex Buddenberg; Kuldip Singh Pabla; Charles E. Perkins > > Cc: manet@ietf.org > > Subject: Re: [manet] IP addresses in MANET > > > > > > Good day everybody, > > > > I've been following on the IP addressing proplem, and want to > > contribute some thoughts > > 1) I believe ad hoc will adopt IPv6. Since no comercial > > solution is available for ad-hoc, it makes absolute sense to > > use IPv6 for addressing. This solve the problem of "Internet > > running out of space" and introduce the problem of "Personal > > IP" which is global vs local IP > > > > 2) Assigning "pool of addresses" for an ad-hoc network is so > > difficult in the absense of central authority. This means > > that nodes will have to announce an IP address when joining > > the network, get authenticated (how the authentication could > > be done is a different issue), then the nodes can move within > > the same ad-hoc freely by keeping their IP. > > > > 3) Local traffic (within the same ad-hoc) can be routed > > easly. Internet traffic will be subject to (gateway address > > resolution). Since many gateways may work for the same > > ad-hoc, we need to guarantee consistency between all gateways. > > > > This way no central authority is needed which is very > > consistent with the MANET charter. Also, if an individual > > nodes has a static IP it should be able to use it. The > > authentication process can elementate the possibility of IP > > address conflict. > > > > Hope I made my point clear, any input? > > > > Yasser > > > > Carleton U > > Ottawa Canada > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jun 27 18:55:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21356 for ; Thu, 27 Jun 2002 18:55:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00793; Thu, 27 Jun 2002 18:34:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00766 for ; Thu, 27 Jun 2002 18:34:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20397 for ; Thu, 27 Jun 2002 18:33:24 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 16:34:01 -0600 Message-Id: <02Jun27.163401mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Su, William" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:33:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bill, I think it could go either way, depending on the nature of the MANET. The advantage of clustering is that you can keep some information local. Even in a very dynamic situation, not all changes need be propagated throughout the net. However, there is a certain amount of OH involved and it could be that under certain circumstances, the OH would cut into available BW. However, in checking this out, we would have to consider the total effect of clustering. It is not just that one keeps local changes more-or-less local, but also that the resulting hierarchal structure makes routing more efficient. There is also another factor. Some protocols (e.g. AODV) maintain only active routes. In a very dynamic network of n nodes in which only a few of the n-squared possible routes are used, clustering might have less value than in a network in which a large fraction of possible source-destination pairs are active. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 3:55 PM To: Mullen, John P. (Contractor); manet@ietf.org Subject: RE: [manet] IP addresses in MANET John, Very good point. I think I totally agree with you on the benefit of hierchical scheme :) The scenario I was thinking is the situation when all nodes in the field are moving very rapidly in different random directions. For this case, it would seem that a lot of clusters would have to be created/modified. Therefore the bulk of overhead actually becomes cluster maintainence (cluster head election, gateway nodes selection, .etc) rather than routing updates. Although the routing info probably also needed to be propagated more frequently to keep up with the fast changing clusters. I guess I may be thinking of an "extreme" case that the mobility speed is so high each cluster stays intact for only a very short amount of time, and all its members are constantly joining/dropping rapidly. Although I'm not so sure at what mobility threshold using cluster in this case will generate too much cluster maintainence overhead. Perhaps there are some MANET papers that have insights in this area? IMHO, I think cluster based approach would definitely work very well in a situation when the mobility pattern for a certain cluster or group is similar (i.e. a squad based cluster). If there are no group mobility behavior, there is a possibility that cluster maintaince might actually congest the network. I would also suspect that factors such as cluster size, radius, and the efficiency of cluster maintenance scheme are important. I think it would probably be an interesting study? :) -Bill -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Thursday, June 27, 2002 3:09 PM To: Su, William; manet@ietf.org Subject: RE: [manet] IP addresses in MANET Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Jun 27 18:56:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21365 for ; Thu, 27 Jun 2002 18:55:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01918 for manet-archive@odin.ietf.org; Thu, 27 Jun 2002 18:56:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00793; Thu, 27 Jun 2002 18:34:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00766 for ; Thu, 27 Jun 2002 18:34:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20397 for ; Thu, 27 Jun 2002 18:33:24 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Thu, 27 Jun 2002 16:34:01 -0600 Message-Id: <02Jun27.163401mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Su, William" Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Thu, 27 Jun 2002 16:33:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bill, I think it could go either way, depending on the nature of the MANET. The advantage of clustering is that you can keep some information local. Even in a very dynamic situation, not all changes need be propagated throughout the net. However, there is a certain amount of OH involved and it could be that under certain circumstances, the OH would cut into available BW. However, in checking this out, we would have to consider the total effect of clustering. It is not just that one keeps local changes more-or-less local, but also that the resulting hierarchal structure makes routing more efficient. There is also another factor. Some protocols (e.g. AODV) maintain only active routes. In a very dynamic network of n nodes in which only a few of the n-squared possible routes are used, clustering might have less value than in a network in which a large fraction of possible source-destination pairs are active. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 3:55 PM To: Mullen, John P. (Contractor); manet@ietf.org Subject: RE: [manet] IP addresses in MANET John, Very good point. I think I totally agree with you on the benefit of hierchical scheme :) The scenario I was thinking is the situation when all nodes in the field are moving very rapidly in different random directions. For this case, it would seem that a lot of clusters would have to be created/modified. Therefore the bulk of overhead actually becomes cluster maintainence (cluster head election, gateway nodes selection, .etc) rather than routing updates. Although the routing info probably also needed to be propagated more frequently to keep up with the fast changing clusters. I guess I may be thinking of an "extreme" case that the mobility speed is so high each cluster stays intact for only a very short amount of time, and all its members are constantly joining/dropping rapidly. Although I'm not so sure at what mobility threshold using cluster in this case will generate too much cluster maintainence overhead. Perhaps there are some MANET papers that have insights in this area? IMHO, I think cluster based approach would definitely work very well in a situation when the mobility pattern for a certain cluster or group is similar (i.e. a squad based cluster). If there are no group mobility behavior, there is a possibility that cluster maintaince might actually congest the network. I would also suspect that factors such as cluster size, radius, and the efficiency of cluster maintenance scheme are important. I think it would probably be an interesting study? :) -Bill -----Original Message----- From: Mullen, John P. (Contractor) [mailto:mullenjp.contractor@trac.wsmr.army.mil] Sent: Thursday, June 27, 2002 3:09 PM To: Su, William; manet@ietf.org Subject: RE: [manet] IP addresses in MANET Hi Bill, As I understand it, hierarchical clustering can help manage an unstable topology. The idea in clustering is that a cluster becomes a supernode. The details of what goes on within that supernode are hidden from the rest of the network as much as possible. Consequently, changes in topology of local interest remain within the cluster, reducing the OH associated with routing updates. For example, suppose Node A, along with four or five other nodes, is in Cluster 1. If I want to send a packet to Node A, all I need to know is it is in Cluster 1. Once it hits the cluster, the local mechanism gets the packet to A. So, A can move around within the cluster all it wants to and the only thing that is affected is local (one hop) routing. There is no need to advise the rest of the net of these changes. Of course, some changes are of general interest. Any time a node leaves or joins a cluster, for example. However, these changes are usually less frequent, and given the instability of connections in some wireless nets, this can greatly reduce the number of net wide updates. Furthermore, under next-hop routing, even some cluster changes need not be propagated network wide. For example, suppose I reach Node A via cluster 7, which goes to Cluster 4, then Cluster 1. If Node A moves to Cluster 2, which is also reachable from Cluster 4, then my next hop doesn't change and the update need not go beyond the controller for Cluster 4. John Mullen -----Original Message----- From: Su, William [mailto:wsu@raytheon.com] Sent: Thursday, June 27, 2002 12:24 PM To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET I would think that one possible factor that determines whether to use cluster or not is the mobility rate. Hierarchical cluster schemes would reduce network traffic if all the nodes within the locality are fairly stable, but if they tends to move around different clusters a lot then there could be significant routing overhead. Typical non-cluster routing schemes like AODV, DSR and such are good for small to medium size networks that are fast moving, although they are probably not as scaleable as the cluster or hierarchical approach. It would seem like as the network size becomes larger and larger, something like ZRP or Fisheye would have to be used. -Bill _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 00:31:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00575 for ; Fri, 28 Jun 2002 00:31:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14304; Fri, 28 Jun 2002 00:03:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14276 for ; Fri, 28 Jun 2002 00:03:39 -0400 (EDT) Received: from bjapp4.163.net ([202.108.255.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29274 for ; Fri, 28 Jun 2002 00:02:47 -0400 (EDT) Received: by bjapp4.163.net (Postfix, from userid 1005) id A40E81DD7A53A; Fri, 28 Jun 2002 12:02:38 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D1BDFDE.000018.21798@bjapp4> Date: Fri, 28 Jun 2002 12:02:38 +0800 (CST) From: "Íõº£" To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org, wsu@raytheon.com X-Priority: 3 X-Originating-IP: [218.2.150.198] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf" Subject: [manet] =?gb2312?B?UmU6IFJFOiBbbWFuZXRdIElQIGFkZHJlc3NlcyBpbiBNQU5FVA==?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John: I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol. However, I see no reasonable default parameter such as cluster size, cluster merge/split threshold can be fitted for all real networks. So a hierarchical MANET¡¯s performance is not promising. Am I right? Or is there any reference parameter for hierarchical MANET implementation? There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands of nodes or even tens of thousands of nodes? I heard that UBC has build a Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message to transfer on the net, OH is not a big problem. In a very big MANET, with its mobility nature, I doubt any scheme , neither flat nor hierarchical, would work. If there is a limit, do we have a value this society agreed on? With this in mind, I think it will be better for us to discuss the hierarchical or flat MANET. BR Hai Wang > Hi Bill, > > I think it could go either way, depending on the nature of the MANET. > > The advantage of clustering is that you can keep some information local. > Even in a very dynamic situation, not all changes need be propagated > throughout the net. However, there is a certain amount of OH involved and > it could be that under certain circumstances, the OH would cut into > available BW. > > However, in checking this out, we would have to consider the total effect of > clustering. It is not just that one keeps local changes more-or-less local, > but also that the resulting hierarchal structure makes routing more > efficient. > > There is also another factor. Some protocols (e.g. AODV) maintain only > active routes. In a very dynamic network of n nodes in which only a few of > the n-squared possible routes are used, clustering might have less value > than in a network in which a large fraction of possible source-destination > pairs are active. > > John Mullen > > --Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hi John:

I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol. However, I see no reasonable default parameter such as cluster size, cluster merge/split threshold can be fitted for all real networks. So a hierarchical MANET¡¯s performance is not promising. Am I right? Or is there any reference parameter for hierarchical MANET implementation?
There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands of nodes or even tens of thousands of nodes? I heard that UBC has build a Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message to transfer on the net, OH is not a big problem. In a very big MANET, with its mobility nature, I doubt any scheme , neithe! r flat nor hierarchical, would work. If there is a limit, do we have a value this society agreed on? With this in mind, I think it will be better for us to discuss the hierarchical or flat MANET.

BR
Hai Wang


> Hi Bill,
>
> I think it could go either way, depending on the nature of the MANET.
>
> The advantage of clustering is that you can keep some information local.
> Even in a very dynamic situation, not all changes need be propagated
> throughout the net. However, there is a certain amount of OH involved and
> it could be that under certain circumstances, the OH would cut into
> available BW.
>
> However, in checking this out, we would have to consider the total effect of
> clustering. It is not just that one keeps local changes more-or-less local,
> but also that the resulting hierarchal structure makes routing more
> efficient.
>
> There is also anot! her factor. Some protocols (e.g. AODV) maintain only
> active r outes. In a very dynamic network of n nodes in which only a few of
> the n-squared possible routes are used, clustering might have less value
> than in a network in which a large fraction of possible source-destination
> pairs are active.
>
> John Mullen
>
>

--Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Jun 28 00:31:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00584 for ; Fri, 28 Jun 2002 00:31:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA16322 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 00:32:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14304; Fri, 28 Jun 2002 00:03:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14276 for ; Fri, 28 Jun 2002 00:03:39 -0400 (EDT) Received: from bjapp4.163.net ([202.108.255.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29274 for ; Fri, 28 Jun 2002 00:02:47 -0400 (EDT) Received: by bjapp4.163.net (Postfix, from userid 1005) id A40E81DD7A53A; Fri, 28 Jun 2002 12:02:38 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D1BDFDE.000018.21798@bjapp4> Date: Fri, 28 Jun 2002 12:02:38 +0800 (CST) From: "Íõº£" To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org, wsu@raytheon.com X-Priority: 3 X-Originating-IP: [218.2.150.198] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf" Subject: [manet] =?gb2312?B?UmU6IFJFOiBbbWFuZXRdIElQIGFkZHJlc3NlcyBpbiBNQU5FVA==?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John: I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol. However, I see no reasonable default parameter such as cluster size, cluster merge/split threshold can be fitted for all real networks. So a hierarchical MANET¡¯s performance is not promising. Am I right? Or is there any reference parameter for hierarchical MANET implementation? There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands of nodes or even tens of thousands of nodes? I heard that UBC has build a Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message to transfer on the net, OH is not a big problem. In a very big MANET, with its mobility nature, I doubt any scheme , neither flat nor hierarchical, would work. If there is a limit, do we have a value this society agreed on? With this in mind, I think it will be better for us to discuss the hierarchical or flat MANET. BR Hai Wang > Hi Bill, > > I think it could go either way, depending on the nature of the MANET. > > The advantage of clustering is that you can keep some information local. > Even in a very dynamic situation, not all changes need be propagated > throughout the net. However, there is a certain amount of OH involved and > it could be that under certain circumstances, the OH would cut into > available BW. > > However, in checking this out, we would have to consider the total effect of > clustering. It is not just that one keeps local changes more-or-less local, > but also that the resulting hierarchal structure makes routing more > efficient. > > There is also another factor. Some protocols (e.g. AODV) maintain only > active routes. In a very dynamic network of n nodes in which only a few of > the n-squared possible routes are used, clustering might have less value > than in a network in which a large fraction of possible source-destination > pairs are active. > > John Mullen > > --Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hi John:

I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol. However, I see no reasonable default parameter such as cluster size, cluster merge/split threshold can be fitted for all real networks. So a hierarchical MANET¡¯s performance is not promising. Am I right? Or is there any reference parameter for hierarchical MANET implementation?
There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands of nodes or even tens of thousands of nodes? I heard that UBC has build a Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message to transfer on the net, OH is not a big problem. In a very big MANET, with its mobility nature, I doubt any scheme , neithe! r flat nor hierarchical, would work. If there is a limit, do we have a value this society agreed on? With this in mind, I think it will be better for us to discuss the hierarchical or flat MANET.

BR
Hai Wang


> Hi Bill,
>
> I think it could go either way, depending on the nature of the MANET.
>
> The advantage of clustering is that you can keep some information local.
> Even in a very dynamic situation, not all changes need be propagated
> throughout the net. However, there is a certain amount of OH involved and
> it could be that under certain circumstances, the OH would cut into
> available BW.
>
> However, in checking this out, we would have to consider the total effect of
> clustering. It is not just that one keeps local changes more-or-less local,
> but also that the resulting hierarchal structure makes routing more
> efficient.
>
> There is also anot! her factor. Some protocols (e.g. AODV) maintain only
> active r outes. In a very dynamic network of n nodes in which only a few of
> the n-squared possible routes are used, clustering might have less value
> than in a network in which a large fraction of possible source-destination
> pairs are active.
>
> John Mullen
>
>

--Boundary-=_JDvixurZqTbfnFSAefTAckDPULWf-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 01:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02267 for ; Fri, 28 Jun 2002 01:43:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17534; Fri, 28 Jun 2002 01:02:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17505 for ; Fri, 28 Jun 2002 01:02:54 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01279 for ; Fri, 28 Jun 2002 01:02:09 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14547 for ; Thu, 27 Jun 2002 23:02:52 -0600 (MDT) Received: from sun.com (dsl198-18.Eng.Sun.COM [129.146.198.18]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5S52pC13740 for ; Thu, 27 Jun 2002 22:02:51 -0700 (PDT) Message-ID: <3D1BEE1B.CC8EC110@sun.com> Date: Thu, 27 Jun 2002 22:03:23 -0700 From: Kuldip Singh Pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Yasser, "Yasser A. Lotfy" wrote: > > Good day everybody, > > I've been following on the IP addressing proplem, and want to contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" which is global vs local IP This pretty much matches with my view of ad-hoc network. It could be IPv6 or something close to it, like UUIDs. As I had mentioned, IPv6 or IP or any other ID will serve as an identity of a node and not its location in the hierarchy. And hence, it would be tough to have a unique identity in the adhoc network. > > 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. At the same time, the authentication will be very difficult. The adhoc network created by a bunch nodes may just be a private network not connected to the Internet - so, no question of authentication and authorization, unless there is a central authority - which is not consistent with MANET charter. > > 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. Exactly! > > This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. I am still not convinced on address conflict resolution. -Kuldip > > Hope I made my point clear, any input? > > Yasser > > Carleton U > Ottawa Canada > > ____________________________________________________________ > Win a first-class trip to New Orleans and vacation Elvis Style!. > Enter NOW! > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ -- Kuldip Singh Pabla Peer-2-Peer Networking _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Jun 28 01:43:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02279 for ; Fri, 28 Jun 2002 01:43:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27337 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 01:44:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17534; Fri, 28 Jun 2002 01:02:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17505 for ; Fri, 28 Jun 2002 01:02:54 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01279 for ; Fri, 28 Jun 2002 01:02:09 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14547 for ; Thu, 27 Jun 2002 23:02:52 -0600 (MDT) Received: from sun.com (dsl198-18.Eng.Sun.COM [129.146.198.18]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5S52pC13740 for ; Thu, 27 Jun 2002 22:02:51 -0700 (PDT) Message-ID: <3D1BEE1B.CC8EC110@sun.com> Date: Thu, 27 Jun 2002 22:03:23 -0700 From: Kuldip Singh Pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Yasser, "Yasser A. Lotfy" wrote: > > Good day everybody, > > I've been following on the IP addressing proplem, and want to contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" which is global vs local IP This pretty much matches with my view of ad-hoc network. It could be IPv6 or something close to it, like UUIDs. As I had mentioned, IPv6 or IP or any other ID will serve as an identity of a node and not its location in the hierarchy. And hence, it would be tough to have a unique identity in the adhoc network. > > 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. At the same time, the authentication will be very difficult. The adhoc network created by a bunch nodes may just be a private network not connected to the Internet - so, no question of authentication and authorization, unless there is a central authority - which is not consistent with MANET charter. > > 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. Exactly! > > This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. I am still not convinced on address conflict resolution. -Kuldip > > Hope I made my point clear, any input? > > Yasser > > Carleton U > Ottawa Canada > > ____________________________________________________________ > Win a first-class trip to New Orleans and vacation Elvis Style!. > Enter NOW! > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ -- Kuldip Singh Pabla Peer-2-Peer Networking _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 08:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22105 for ; Fri, 28 Jun 2002 08:11:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18301; Fri, 28 Jun 2002 07:46:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18274 for ; Fri, 28 Jun 2002 07:46:42 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20967 for ; Fri, 28 Jun 2002 07:45:56 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id NAA05561 for ; Fri, 28 Jun 2002 13:44:48 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Fri, 28 Jun 2002 13:49:52 +0200 X-Mailer: KMail [version 1.2] References: <3D1BEE1B.CC8EC110@sun.com> In-Reply-To: <3D1BEE1B.CC8EC110@sun.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062813495201.00484@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dr. Pabla I am not convinced at all that authentication should be solved at this level. I agree that security issues in manet involve any level of protocol stack expecially in wireless hightly dynamic networks as MANETs. The threat of a "false IP" exist even into the internet but it is solved at higher level throught certificates and cryptography. Many research effort have been spend over this field into the context of MANET i.e. threshold cryptography regards dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 08:11:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22115 for ; Fri, 28 Jun 2002 08:11:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20336 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 08:11:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18301; Fri, 28 Jun 2002 07:46:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18274 for ; Fri, 28 Jun 2002 07:46:42 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20967 for ; Fri, 28 Jun 2002 07:45:56 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id NAA05561 for ; Fri, 28 Jun 2002 13:44:48 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] IP addresses in MANET Date: Fri, 28 Jun 2002 13:49:52 +0200 X-Mailer: KMail [version 1.2] References: <3D1BEE1B.CC8EC110@sun.com> In-Reply-To: <3D1BEE1B.CC8EC110@sun.com> Organization: deis MIME-Version: 1.0 Message-Id: <02062813495201.00484@manson> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dr. Pabla I am not convinced at all that authentication should be solved at this level. I agree that security issues in manet involve any level of protocol stack expecially in wireless hightly dynamic networks as MANETs. The threat of a "false IP" exist even into the internet but it is solved at higher level throught certificates and cryptography. Many research effort have been spend over this field into the context of MANET i.e. threshold cryptography regards dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 08:32:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23059 for ; Fri, 28 Jun 2002 08:32:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19964; Fri, 28 Jun 2002 08:08:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19935 for ; Fri, 28 Jun 2002 08:08:26 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21911 for ; Fri, 28 Jun 2002 08:07:40 -0400 (EDT) Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id NAA22667; Fri, 28 Jun 2002 13:08:22 +0100 (BST) Received: (from tapselj0@localhost) by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g5SC8LE01472; Fri, 28 Jun 2002 13:08:21 +0100 Date: Fri, 28 Jun 2002 13:08:21 +0100 From: John Peter Tapsell Message-Id: <200206281208.g5SC8LE01472@ug003.cs.man.ac.uk> To: budden@nps.navy.mil, tapselj0@cs.man.ac.uk Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thank you all very much :) The trouble is, I have a network with many many nodes, all wanting to use up as much bandwidth as they can. I need a way to *) Prioritise certain nodes. *) Try hard to guarantee a certain bandwidth to nodes *) Try hard to guarantee a certain latency to nodes *) Minimise traffic on certain nodes so it's only used for priority packets that have no other sensible way. (For minimal bandwidth etc) *) Set up routes that take into consideration somehow the quality of the link e.g. two nodes that are far apart may drop a lot of packets, so a preferable route would be going through several nodes, etc. Basically I want the world :) I'm currently trying to just see what's out there. I've only looked at SWAN for a few hours, but so far I'm not sure how it would cope when the needed bandwidth far exceeds actual. :) I'm new to this field, so have patience with me :) Thanks. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 08:32:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23069 for ; Fri, 28 Jun 2002 08:32:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21995 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 08:33:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19964; Fri, 28 Jun 2002 08:08:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19935 for ; Fri, 28 Jun 2002 08:08:26 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21911 for ; Fri, 28 Jun 2002 08:07:40 -0400 (EDT) Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id NAA22667; Fri, 28 Jun 2002 13:08:22 +0100 (BST) Received: (from tapselj0@localhost) by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g5SC8LE01472; Fri, 28 Jun 2002 13:08:21 +0100 Date: Fri, 28 Jun 2002 13:08:21 +0100 From: John Peter Tapsell Message-Id: <200206281208.g5SC8LE01472@ug003.cs.man.ac.uk> To: budden@nps.navy.mil, tapselj0@cs.man.ac.uk Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thank you all very much :) The trouble is, I have a network with many many nodes, all wanting to use up as much bandwidth as they can. I need a way to *) Prioritise certain nodes. *) Try hard to guarantee a certain bandwidth to nodes *) Try hard to guarantee a certain latency to nodes *) Minimise traffic on certain nodes so it's only used for priority packets that have no other sensible way. (For minimal bandwidth etc) *) Set up routes that take into consideration somehow the quality of the link e.g. two nodes that are far apart may drop a lot of packets, so a preferable route would be going through several nodes, etc. Basically I want the world :) I'm currently trying to just see what's out there. I've only looked at SWAN for a few hours, but so far I'm not sure how it would cope when the needed bandwidth far exceeds actual. :) I'm new to this field, so have patience with me :) Thanks. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 08:43:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23592 for ; Fri, 28 Jun 2002 08:43:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21073; Fri, 28 Jun 2002 08:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21047 for ; Fri, 28 Jun 2002 08:28:51 -0400 (EDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22809 for ; Fri, 28 Jun 2002 08:28:05 -0400 (EDT) Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 14:28:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [manet] QoS over a wireless Ad Hoc network Date: Fri, 28 Jun 2002 14:28:48 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A21AD1A@LANMHS20.rd.francetelecom.fr> Thread-Topic: [manet] QoS over a wireless Ad Hoc network Thread-Index: AcIenfnM1r7IU6dUQ5SpwLl6sb2JXAAAR8iA From: "MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN" To: "John Peter Tapsell" , Cc: X-OriginalArrivalTime: 28 Jun 2002 12:28:49.0367 (UTC) FILETIME=[5AE95670:01C21E9F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21048 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit guarantee a correct QoS in manet is an NP-Complet problem. with the actuel configuration of materail I think that software solution like Swan and Insignia car treat all QoS pb in Manet in all situations. -----Message d'origine----- De : John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk] Envoye : vendredi 28 juin 2002 14:08 A : budden@nps.navy.mil; tapselj0@cs.man.ac.uk Cc : manet@ietf.org Objet : Re: [manet] QoS over a wireless Ad Hoc network Thank you all very much :) The trouble is, I have a network with many many nodes, all wanting to use up as much bandwidth as they can. I need a way to *) Prioritise certain nodes. *) Try hard to guarantee a certain bandwidth to nodes *) Try hard to guarantee a certain latency to nodes *) Minimise traffic on certain nodes so it's only used for priority packets that have no other sensible way. (For minimal bandwidth etc) *) Set up routes that take into consideration somehow the quality of the link e.g. two nodes that are far apart may drop a lot of packets, so a preferable route would be going through several nodes, etc. Basically I want the world :) I'm currently trying to just see what's out there. I've only looked at SWAN for a few hours, but so far I'm not sure how it would cope when the needed bandwidth far exceeds actual. :) I'm new to this field, so have patience with me :) Thanks. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 08:43:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23599 for ; Fri, 28 Jun 2002 08:43:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22676 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 08:44:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21073; Fri, 28 Jun 2002 08:28:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21047 for ; Fri, 28 Jun 2002 08:28:51 -0400 (EDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22809 for ; Fri, 28 Jun 2002 08:28:05 -0400 (EDT) Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 14:28:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [manet] QoS over a wireless Ad Hoc network Date: Fri, 28 Jun 2002 14:28:48 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A21AD1A@LANMHS20.rd.francetelecom.fr> Thread-Topic: [manet] QoS over a wireless Ad Hoc network Thread-Index: AcIenfnM1r7IU6dUQ5SpwLl6sb2JXAAAR8iA From: "MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN" To: "John Peter Tapsell" , Cc: X-OriginalArrivalTime: 28 Jun 2002 12:28:49.0367 (UTC) FILETIME=[5AE95670:01C21E9F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21048 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit guarantee a correct QoS in manet is an NP-Complet problem. with the actuel configuration of materail I think that software solution like Swan and Insignia car treat all QoS pb in Manet in all situations. -----Message d'origine----- De : John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk] Envoye : vendredi 28 juin 2002 14:08 A : budden@nps.navy.mil; tapselj0@cs.man.ac.uk Cc : manet@ietf.org Objet : Re: [manet] QoS over a wireless Ad Hoc network Thank you all very much :) The trouble is, I have a network with many many nodes, all wanting to use up as much bandwidth as they can. I need a way to *) Prioritise certain nodes. *) Try hard to guarantee a certain bandwidth to nodes *) Try hard to guarantee a certain latency to nodes *) Minimise traffic on certain nodes so it's only used for priority packets that have no other sensible way. (For minimal bandwidth etc) *) Set up routes that take into consideration somehow the quality of the link e.g. two nodes that are far apart may drop a lot of packets, so a preferable route would be going through several nodes, etc. Basically I want the world :) I'm currently trying to just see what's out there. I've only looked at SWAN for a few hours, but so far I'm not sure how it would cope when the needed bandwidth far exceeds actual. :) I'm new to this field, so have patience with me :) Thanks. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 10:33:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28529 for ; Fri, 28 Jun 2002 10:33:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27676; Fri, 28 Jun 2002 10:13:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27570 for ; Fri, 28 Jun 2002 10:13:05 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27374 for ; Fri, 28 Jun 2002 10:12:17 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 28 Jun 2002 08:12:53 -0600 Message-Id: <02Jun28.081253mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Fri, 28 Jun 2002 08:12:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21EAD.DCEE3790" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21EAD.DCEE3790 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Hai Wang, =20 You have a lot of statements here, so I'll comment on them one at a = time. =20 [Hai Wang] I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster = maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol.=20 [John M] Regardless of what protocol we pick, there will be a set of circumstances under which it will not perform well. In Computer = Science, people tend to look at the worst case and ask if that is tolerable. In Industrial Engineering (my field), we also look at average performance. This involves a bit more understanding of the situation in that we have = to figure out how likely the worst case (and other cases) are. So, if = there is a set of circumstances under which a protocol will do badly, but those circumstances are very very rare, we may still use the protocol. =20 =20 Any form of organization will work best when it coincides with the = situation and worst when it does not. Essentially, a set of instructions is = trying to guess which organization will be best, based on the observed network = state. Every once in a while, it will be wrong. However, if it is better than = the alternatives, including no clustering, we would still tend to use it. =20 [Hai Wang] However, I see no reasonable default parameter such as = cluster size, cluster merge/split threshold can be fitted for all real = networks. So a hierarchical MANET=A1=AFs performance is not promising. Am I right? = Or is there any reference parameter for hierarchical MANET implementation? =20 [John M] The term "MANET" describes a tremendous variety of rather = messy networks. Additionally, the equipment in use has some impact on = cluster size and design. In a large MANET, local conditions can vary, so in = some regions, a larger cluster size might be advisable. Finally, traffic patterns interact with clustering. It is unlikely that a single = default parameter would be acceptable for all MANETs. However, it is likely = that a single initial value will be good starting point and that heuristics = can be found to locally optimize cluster size. After all, we have to find something for hungry graduate students to do. :-) Also, there are a number of clustering schemes, so parameters for one = would differ from those of another. Martha Steenstrup discusses a number of = these in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, = Chapter 4]. Her discussion does a good job of describing the protocols and = showing how technology, traffic patterns, and geographical dispersion impact = and are impacted by different clustering methods. =20 [Hai Wang] There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands = of nodes or even tens of thousands of nodes? I heard that UBC has build a = Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message = to transfer on the net, OH is not a big problem.=20 [John M] I have heard of working MANETS up to 1000 nodes in size. This = is 1000 hosts, almost all of which are operated by people communicating = with each other. Conceptually, there is no limit, though practically = speaking there probably is one. Of course, special circumstances can reduce the complexity of the problem. For example, if a MANET consists of ten = teams of 100 hosts, each team of which is organized into five units, and if = these teams and units tend to travel together, say as in an emergency relief operation, then a clustering by organizational unit seems logical and = would probably work. Given a "nice" situation, there would be no practical = limit to the MANET, though purists would probably call it a very tame one. =20 [Hai Wang] In a very big MANET, with its mobility nature, I doubt any = scheme , neithe! r flat nor hierarchical, would work. If there is a limit, do = we have a value this society agreed on? With this in mind, I think it will = be better for us to discuss the hierarchical or flat MANET. [John M] There are probably circumstances under which a flat MANET is preferable to a hierarchical one, but I think you have the size factor backwards. Hierarchal clustering tends to localize the impact of state changes, so it tends to be more useful in larger nets than in smaller = ones. If each node is one or two hops away from every other node, probably clustering is not worth the OH. However, if the net diameter is ten or twenty hops, something is needed to reduce the size of the routing = problem and clustering seems to be one way to do it. If there is a limit to = MANET size, it will be a practical one, set by limitations of the media and technology. I think that is too much of a moving target to set a value = at this point. BR Hai Wang > Hi Bill, >=20 > I think it could go either way, depending on the nature of the MANET. >=20 > The advantage of clustering is that you can keep some information = local. > Even in a very dynamic situation, not all changes need be propagated > throughout the net. However, there is a certain amount of OH involved = and > it could be that under certain circumstances, the OH would cut into > available BW. >=20 > However, in checking this out, we would have to consider the total = effect of > clustering. It is not just that one keeps local changes more-or-less local, > but also that the resulting hierarchal structure makes routing more > efficient. >=20 > There is also anot! her factor. Some protocols (e.g. AODV) maintain = only > active r outes. In a very dynamic network of n nodes in which only a = few of > the n-squared possible routes are used, clustering might have less = value > than in a network in which a large fraction of possible = source-destination > pairs are active.=20 >=20 > John Mullen >=20 >=20 ------_=_NextPart_001_01C21EAD.DCEE3790 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 Hai Wang,
 
You have a=20 lot of statements here, so I'll comment on them one at a=20 time.
 
[Hai=20 Wang] I think what Bill referred is the clustering = problem of=20 hierarchical MANET. In some situation, bad parameterized cluster = maintenance=20 such as cluster-split, cluster-merge may induce more OH than routing = protocol.=20
[John M]  Regardless of what protocol we pick, there will = be a set=20 of circumstances under which it will not perform well.  In = Computer=20 Science, people tend to look at the worst case and ask if that is=20 tolerable.  In Industrial Engineering (my field), we also look at = average=20 performance.  This involves a bit more understanding of the = situation in=20 that we have to figure out how likely the worst case (and other cases)=20 are.  So, if there is a set of circumstances under which a = protocol will do=20 badly, but those circumstances are very very rare, we may still use the = protocol. 
 
Any=20 form of organization will work best when it coincides with the = situation and=20 worst when it does not.  Essentially, a set of instructions is = trying to=20 guess which organization will be best, based on the observed network=20 state.  Every once in a while, it will be wrong.  However, if = it is=20 better than the alternatives, including no clustering, we would still = tend to=20 use it.
 
[Hai=20 Wang] However, I see no reasonable default parameter such = as cluster=20 size, cluster merge/split threshold can be fitted for all real = networks. So a=20 hierarchical MANET=A1=AFs performance is not promising. Am I right? Or = is there any=20 reference parameter for hierarchical MANET implementation?
 
[John M]  The term "MANET" describes a = tremendous=20 variety of rather messy networks.  Additionally, the equipment in = use has=20 some impact on cluster size and design.  In a large MANET, local = conditions=20 can vary, so in some regions, a larger cluster size might be = advisable. =20 Finally, traffic patterns interact with clustering.  It is = unlikely that a=20 single default parameter would be acceptable for all MANETs.  = However,=20 it is likely that a single initial value will be good starting point = and that=20 heuristics can be found to locally optimize cluster size.  After = all, we=20 have to find something for hungry graduate students to=20 do.
:-)

Also, there are a number of clustering schemes, so parameters = for one=20 would differ from those of another. Martha Steenstrup discusses a = number of=20 these in "Cluster-Based Networks," [Ad Hoc Networking, by = Charles=20 Perkins, Chapter 4].  Her discussion does a good job=20 of describing the protocols and showing how technology, = traffic=20 patterns, and geographical dispersion impact and are impacted by=20 different clustering methods.
 
[Hai=20 Wang]  There is another = question=20 aroused in my brain: Is there a nodes-limit for MANET? That is: can = MANET=20 support more than thousands of nodes or even tens of thousands of = nodes? I heard=20 that UBC has build a Ad hoc sensor network of 800 nodes; however, I = think there=20 is difference between sensor network and MANET, for sensor network has = little=20 message to transfer on the net, OH is not a big = problem. 
[John M] I have heard of working MANETS up to 1000 nodes in = size. =20 This is 1000 hosts, almost all of which are operated by=20 people communicating with each other.  Conceptually, = there is no=20 limit, though practically speaking there probably is one.  Of = course,=20 special circumstances can reduce the complexity of the problem.  = For=20 example, if a MANET consists of ten teams of 100 hosts, each team of = which is=20 organized into five units, and if these teams and units tend to travel = together,=20 say as in an emergency relief operation, then a clustering by = organizational=20 unit seems logical and would probably work.  Given a "nice" = situation,=20 there would be no practical limit to the MANET, though purists would = probably=20 call it a very tame one.
 
[Hai Wang] In a very big MANET, with = its=20 mobility nature, I doubt any scheme , neithe! r flat nor hierarchical, = would=20 work. If there is a limit, do we have a value this society agreed on? = With this=20 in mind, I think it will be better for us to discuss the hierarchical = or flat=20 MANET.
[John M]  There are probably circumstances under = which a flat=20 MANET is preferable to a hierarchical one, but I think you have the = size factor=20 backwards.  Hierarchal clustering tends to localize the impact of = state=20 changes, so it tends to be more useful in larger nets than in smaller=20 ones.  If each node is one or two hops away from every other node, = probably=20 clustering is not worth the OH.  However, if the net diameter is = ten or=20 twenty hops, something is needed to reduce the size of the routing = problem and=20 clustering seems to be one way to do it.  If there is a limit to = MANET=20 size, it will be a practical one, set by limitations of the media and=20 technology.  I think that is too much of a moving target to set a = value at=20 this point.

BR
Hai Wang


> Hi Bill,
> =
> I=20 think it could go either way, depending on the nature of the = MANET.
>=20
> The advantage of clustering is that you can keep some = information=20 local.
> Even in a very dynamic situation, not all changes need = be=20 propagated
> throughout the net. However, there is a certain = amount of OH=20 involved and
> it could be that under certain circumstances, the = OH would=20 cut into
> available BW.
>
> However, in checking = this out,=20 we would have to consider the total effect of
> clustering. It is = not just=20 that one keeps local changes more-or-less local,
> but also that = the=20 resulting hierarchal structure makes routing more
> = efficient.
>=20
> There is also anot! her factor. Some protocols (e.g. AODV) = maintain=20 only
> active r outes. In a very dynamic network of n nodes in = which only=20 a few of
> the n-squared possible routes are used, clustering = might have=20 less value
> than in a network in which a large fraction of = possible=20 source-destination
> pairs are active.
>
> John=20 Mullen
>
>

------_=_NextPart_001_01C21EAD.DCEE3790-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 10:33:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28535 for ; Fri, 28 Jun 2002 10:33:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29650 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 10:34:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27676; Fri, 28 Jun 2002 10:13:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27570 for ; Fri, 28 Jun 2002 10:13:05 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27374 for ; Fri, 28 Jun 2002 10:12:17 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 28 Jun 2002 08:12:53 -0600 Message-Id: <02Jun28.081253mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Subject: RE: [manet] IP addresses in MANET Date: Fri, 28 Jun 2002 08:12:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21EAD.DCEE3790" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21EAD.DCEE3790 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Hai Wang, =20 You have a lot of statements here, so I'll comment on them one at a = time. =20 [Hai Wang] I think what Bill referred is the clustering problem of hierarchical MANET. In some situation, bad parameterized cluster = maintenance such as cluster-split, cluster-merge may induce more OH than routing protocol.=20 [John M] Regardless of what protocol we pick, there will be a set of circumstances under which it will not perform well. In Computer = Science, people tend to look at the worst case and ask if that is tolerable. In Industrial Engineering (my field), we also look at average performance. This involves a bit more understanding of the situation in that we have = to figure out how likely the worst case (and other cases) are. So, if = there is a set of circumstances under which a protocol will do badly, but those circumstances are very very rare, we may still use the protocol. =20 =20 Any form of organization will work best when it coincides with the = situation and worst when it does not. Essentially, a set of instructions is = trying to guess which organization will be best, based on the observed network = state. Every once in a while, it will be wrong. However, if it is better than = the alternatives, including no clustering, we would still tend to use it. =20 [Hai Wang] However, I see no reasonable default parameter such as = cluster size, cluster merge/split threshold can be fitted for all real = networks. So a hierarchical MANET=A1=AFs performance is not promising. Am I right? = Or is there any reference parameter for hierarchical MANET implementation? =20 [John M] The term "MANET" describes a tremendous variety of rather = messy networks. Additionally, the equipment in use has some impact on = cluster size and design. In a large MANET, local conditions can vary, so in = some regions, a larger cluster size might be advisable. Finally, traffic patterns interact with clustering. It is unlikely that a single = default parameter would be acceptable for all MANETs. However, it is likely = that a single initial value will be good starting point and that heuristics = can be found to locally optimize cluster size. After all, we have to find something for hungry graduate students to do. :-) Also, there are a number of clustering schemes, so parameters for one = would differ from those of another. Martha Steenstrup discusses a number of = these in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, = Chapter 4]. Her discussion does a good job of describing the protocols and = showing how technology, traffic patterns, and geographical dispersion impact = and are impacted by different clustering methods. =20 [Hai Wang] There is another question aroused in my brain: Is there a nodes-limit for MANET? That is: can MANET support more than thousands = of nodes or even tens of thousands of nodes? I heard that UBC has build a = Ad hoc sensor network of 800 nodes; however, I think there is difference between sensor network and MANET, for sensor network has little message = to transfer on the net, OH is not a big problem.=20 [John M] I have heard of working MANETS up to 1000 nodes in size. This = is 1000 hosts, almost all of which are operated by people communicating = with each other. Conceptually, there is no limit, though practically = speaking there probably is one. Of course, special circumstances can reduce the complexity of the problem. For example, if a MANET consists of ten = teams of 100 hosts, each team of which is organized into five units, and if = these teams and units tend to travel together, say as in an emergency relief operation, then a clustering by organizational unit seems logical and = would probably work. Given a "nice" situation, there would be no practical = limit to the MANET, though purists would probably call it a very tame one. =20 [Hai Wang] In a very big MANET, with its mobility nature, I doubt any = scheme , neithe! r flat nor hierarchical, would work. If there is a limit, do = we have a value this society agreed on? With this in mind, I think it will = be better for us to discuss the hierarchical or flat MANET. [John M] There are probably circumstances under which a flat MANET is preferable to a hierarchical one, but I think you have the size factor backwards. Hierarchal clustering tends to localize the impact of state changes, so it tends to be more useful in larger nets than in smaller = ones. If each node is one or two hops away from every other node, probably clustering is not worth the OH. However, if the net diameter is ten or twenty hops, something is needed to reduce the size of the routing = problem and clustering seems to be one way to do it. If there is a limit to = MANET size, it will be a practical one, set by limitations of the media and technology. I think that is too much of a moving target to set a value = at this point. BR Hai Wang > Hi Bill, >=20 > I think it could go either way, depending on the nature of the MANET. >=20 > The advantage of clustering is that you can keep some information = local. > Even in a very dynamic situation, not all changes need be propagated > throughout the net. However, there is a certain amount of OH involved = and > it could be that under certain circumstances, the OH would cut into > available BW. >=20 > However, in checking this out, we would have to consider the total = effect of > clustering. It is not just that one keeps local changes more-or-less local, > but also that the resulting hierarchal structure makes routing more > efficient. >=20 > There is also anot! her factor. Some protocols (e.g. AODV) maintain = only > active r outes. In a very dynamic network of n nodes in which only a = few of > the n-squared possible routes are used, clustering might have less = value > than in a network in which a large fraction of possible = source-destination > pairs are active.=20 >=20 > John Mullen >=20 >=20 ------_=_NextPart_001_01C21EAD.DCEE3790 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 Hai Wang,
 
You have a=20 lot of statements here, so I'll comment on them one at a=20 time.
 
[Hai=20 Wang] I think what Bill referred is the clustering = problem of=20 hierarchical MANET. In some situation, bad parameterized cluster = maintenance=20 such as cluster-split, cluster-merge may induce more OH than routing = protocol.=20
[John M]  Regardless of what protocol we pick, there will = be a set=20 of circumstances under which it will not perform well.  In = Computer=20 Science, people tend to look at the worst case and ask if that is=20 tolerable.  In Industrial Engineering (my field), we also look at = average=20 performance.  This involves a bit more understanding of the = situation in=20 that we have to figure out how likely the worst case (and other cases)=20 are.  So, if there is a set of circumstances under which a = protocol will do=20 badly, but those circumstances are very very rare, we may still use the = protocol. 
 
Any=20 form of organization will work best when it coincides with the = situation and=20 worst when it does not.  Essentially, a set of instructions is = trying to=20 guess which organization will be best, based on the observed network=20 state.  Every once in a while, it will be wrong.  However, if = it is=20 better than the alternatives, including no clustering, we would still = tend to=20 use it.
 
[Hai=20 Wang] However, I see no reasonable default parameter such = as cluster=20 size, cluster merge/split threshold can be fitted for all real = networks. So a=20 hierarchical MANET=A1=AFs performance is not promising. Am I right? Or = is there any=20 reference parameter for hierarchical MANET implementation?
 
[John M]  The term "MANET" describes a = tremendous=20 variety of rather messy networks.  Additionally, the equipment in = use has=20 some impact on cluster size and design.  In a large MANET, local = conditions=20 can vary, so in some regions, a larger cluster size might be = advisable. =20 Finally, traffic patterns interact with clustering.  It is = unlikely that a=20 single default parameter would be acceptable for all MANETs.  = However,=20 it is likely that a single initial value will be good starting point = and that=20 heuristics can be found to locally optimize cluster size.  After = all, we=20 have to find something for hungry graduate students to=20 do.
:-)

Also, there are a number of clustering schemes, so parameters = for one=20 would differ from those of another. Martha Steenstrup discusses a = number of=20 these in "Cluster-Based Networks," [Ad Hoc Networking, by = Charles=20 Perkins, Chapter 4].  Her discussion does a good job=20 of describing the protocols and showing how technology, = traffic=20 patterns, and geographical dispersion impact and are impacted by=20 different clustering methods.
 
[Hai=20 Wang]  There is another = question=20 aroused in my brain: Is there a nodes-limit for MANET? That is: can = MANET=20 support more than thousands of nodes or even tens of thousands of = nodes? I heard=20 that UBC has build a Ad hoc sensor network of 800 nodes; however, I = think there=20 is difference between sensor network and MANET, for sensor network has = little=20 message to transfer on the net, OH is not a big = problem. 
[John M] I have heard of working MANETS up to 1000 nodes in = size. =20 This is 1000 hosts, almost all of which are operated by=20 people communicating with each other.  Conceptually, = there is no=20 limit, though practically speaking there probably is one.  Of = course,=20 special circumstances can reduce the complexity of the problem.  = For=20 example, if a MANET consists of ten teams of 100 hosts, each team of = which is=20 organized into five units, and if these teams and units tend to travel = together,=20 say as in an emergency relief operation, then a clustering by = organizational=20 unit seems logical and would probably work.  Given a "nice" = situation,=20 there would be no practical limit to the MANET, though purists would = probably=20 call it a very tame one.
 
[Hai Wang] In a very big MANET, with = its=20 mobility nature, I doubt any scheme , neithe! r flat nor hierarchical, = would=20 work. If there is a limit, do we have a value this society agreed on? = With this=20 in mind, I think it will be better for us to discuss the hierarchical = or flat=20 MANET.
[John M]  There are probably circumstances under = which a flat=20 MANET is preferable to a hierarchical one, but I think you have the = size factor=20 backwards.  Hierarchal clustering tends to localize the impact of = state=20 changes, so it tends to be more useful in larger nets than in smaller=20 ones.  If each node is one or two hops away from every other node, = probably=20 clustering is not worth the OH.  However, if the net diameter is = ten or=20 twenty hops, something is needed to reduce the size of the routing = problem and=20 clustering seems to be one way to do it.  If there is a limit to = MANET=20 size, it will be a practical one, set by limitations of the media and=20 technology.  I think that is too much of a moving target to set a = value at=20 this point.

BR
Hai Wang


> Hi Bill,
> =
> I=20 think it could go either way, depending on the nature of the = MANET.
>=20
> The advantage of clustering is that you can keep some = information=20 local.
> Even in a very dynamic situation, not all changes need = be=20 propagated
> throughout the net. However, there is a certain = amount of OH=20 involved and
> it could be that under certain circumstances, the = OH would=20 cut into
> available BW.
>
> However, in checking = this out,=20 we would have to consider the total effect of
> clustering. It is = not just=20 that one keeps local changes more-or-less local,
> but also that = the=20 resulting hierarchal structure makes routing more
> = efficient.
>=20
> There is also anot! her factor. Some protocols (e.g. AODV) = maintain=20 only
> active r outes. In a very dynamic network of n nodes in = which only=20 a few of
> the n-squared possible routes are used, clustering = might have=20 less value
> than in a network in which a large fraction of = possible=20 source-destination
> pairs are active.
>
> John=20 Mullen
>
>

------_=_NextPart_001_01C21EAD.DCEE3790-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 12:11:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03945 for ; Fri, 28 Jun 2002 12:11:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03267; Fri, 28 Jun 2002 11:45:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03236 for ; Fri, 28 Jun 2002 11:45:15 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01861 for ; Fri, 28 Jun 2002 11:44:27 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Jun 2002 15:49:37 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5SFbR4a024413; Fri, 28 Jun 2002 08:37:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Fri, 28 Jun 2002 08:45:52 -0700 To: yasser.lotfy@lycos.com, "Kuldip Singh Pabla" , "Charles E. Perkins" From: Rex Buddenberg Subject: Re: [manet] IP addresses in MANET Cc: manet@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 4:54 PM -0400 6/27/02, Yasser A. Lotfy wrote: >Good day everybody, > >I've been following on the IP addressing proplem, and want to >contribute some thoughts >1) I believe ad hoc will adopt IPv6. Since no comercial solution is >available for ad-hoc, it makes absolute sense to use IPv6 for >addressing. This solve the problem of "Internet running out of >space" and introduce the problem of "Personal IP" which is global vs >local IP This strikes as sensible. > >2) Assigning "pool of addresses" for an ad-hoc network is so >difficult in the absense of central authority. This means that nodes >will have to announce an IP address when joining the network, get >authenticated (how the authentication could be done is a different >issue), then the nodes can move within the same ad-hoc freely by >keeping their IP. Litmus test: does this allow full normalization of the addressing field? (When I mentioned Mobile IP yesterday, I should have also mentioned multicast class D addresses which is also an approach to the problem and sounds like where you're thinking here.) > >3) Local traffic (within the same ad-hoc) can be routed easly. >Internet traffic will be subject to (gateway address resolution). >Since many gateways may work for the same ad-hoc, we need to >guarantee consistency between all gateways. Agreed. It's probably reasonable to conjecture that 'backside' comms between gateways, because their attached to the Internet, would be somewhat more stable than on the MANET side. This allows cheating -- the gateways could sync tables that way and probably maintain convergence faster than the rest of the nodes within the MANET. > >This way no central authority is needed which is very consistent >with the MANET charter. Also, if an individual nodes has a static IP >it should be able to use it. The authentication process can >elementate the possibility of IP address conflict. Military systems always need to be designed with distribution in mind because Bad Guys are in the business of putting craters in it. If the crater coincides with a single point of failure, we have a problem. -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 12:11:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03958 for ; Fri, 28 Jun 2002 12:11:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10145 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 12:12:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03267; Fri, 28 Jun 2002 11:45:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03236 for ; Fri, 28 Jun 2002 11:45:15 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01861 for ; Fri, 28 Jun 2002 11:44:27 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Jun 2002 15:49:37 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g5SFbR4a024413; Fri, 28 Jun 2002 08:37:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Fri, 28 Jun 2002 08:45:52 -0700 To: yasser.lotfy@lycos.com, "Kuldip Singh Pabla" , "Charles E. Perkins" From: Rex Buddenberg Subject: Re: [manet] IP addresses in MANET Cc: manet@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 4:54 PM -0400 6/27/02, Yasser A. Lotfy wrote: >Good day everybody, > >I've been following on the IP addressing proplem, and want to >contribute some thoughts >1) I believe ad hoc will adopt IPv6. Since no comercial solution is >available for ad-hoc, it makes absolute sense to use IPv6 for >addressing. This solve the problem of "Internet running out of >space" and introduce the problem of "Personal IP" which is global vs >local IP This strikes as sensible. > >2) Assigning "pool of addresses" for an ad-hoc network is so >difficult in the absense of central authority. This means that nodes >will have to announce an IP address when joining the network, get >authenticated (how the authentication could be done is a different >issue), then the nodes can move within the same ad-hoc freely by >keeping their IP. Litmus test: does this allow full normalization of the addressing field? (When I mentioned Mobile IP yesterday, I should have also mentioned multicast class D addresses which is also an approach to the problem and sounds like where you're thinking here.) > >3) Local traffic (within the same ad-hoc) can be routed easly. >Internet traffic will be subject to (gateway address resolution). >Since many gateways may work for the same ad-hoc, we need to >guarantee consistency between all gateways. Agreed. It's probably reasonable to conjecture that 'backside' comms between gateways, because their attached to the Internet, would be somewhat more stable than on the MANET side. This allows cheating -- the gateways could sync tables that way and probably maintain convergence faster than the rest of the nodes within the MANET. > >This way no central authority is needed which is very consistent >with the MANET charter. Also, if an individual nodes has a static IP >it should be able to use it. The authentication process can >elementate the possibility of IP address conflict. Military systems always need to be designed with distribution in mind because Bad Guys are in the business of putting craters in it. If the crater coincides with a single point of failure, we have a problem. -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 14:46:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13818 for ; Fri, 28 Jun 2002 14:46:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19320; Fri, 28 Jun 2002 14:29:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19284 for ; Fri, 28 Jun 2002 14:29:31 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12492 for ; Fri, 28 Jun 2002 14:28:45 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 28 Jun 2002 12:29:21 -0600 Message-Id: <02Jun28.122921mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Date: Fri, 28 Jun 2002 12:29:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21ED1.B2781ED0" Subject: [manet] RE: Maximum MANET size Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21ED1.B2781ED0 Content-Type: text/plain; charset="gb2312" Hi Hai Wang, I just came across this in Hass and Pearlman's description of Zone Routing Protocol (ZRP). "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad hoc networks by rapidly changing network topologies, influenced by network size and node mobility. Typically, such networks have a large span and contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my emphasis). I'd say "hundreds to thousands" qualifies as "large" in my book! As to what a RWN is, as far as I can tell, it is simply a very large, very dynamic MANET that has to be ready to go as soon as it is deployed. If a protocol works under those conditions, it will probably work anywhere and anytime. (Though it could be overkill in simpler cases). Incidentally, I think Zygmunt Hass is on this working group, so if you want to learn more about ZRP, this is the place to ask. (Also the place for other MANET protocols, too :-) All I know is what I'm reading in books and papers. John Mullen ------_=_NextPart_001_01C21ED1.B2781ED0 Content-Type: text/html; charset="gb2312"
Hi Hai Wang,
 
I just came across this in Hass and Pearlman's description of Zone Routing Protocol (ZRP).
 
"RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad hoc networks by rapidly changing network topologies, influenced by network size and node mobility.  Typically, such networks have a large span and contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my emphasis).
 
I'd say "hundreds to thousands" qualifies as "large" in my book!
 
As to what a RWN is, as far as I can tell, it is simply a very large, very dynamic MANET that has to be ready to go as soon as it is deployed.  If a protocol works under those conditions, it will probably work anywhere and anytime. (Though it could be overkill in simpler cases).
 
Incidentally, I think Zygmunt Hass is on this working group, so if you want to learn more about ZRP, this is the place to ask.  (Also the place for other MANET protocols, too :-) 
 
All I know is what I'm reading in books and papers.
 
John Mullen
------_=_NextPart_001_01C21ED1.B2781ED0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 14:46:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13825 for ; Fri, 28 Jun 2002 14:46:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21569 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 14:46:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19320; Fri, 28 Jun 2002 14:29:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19284 for ; Fri, 28 Jun 2002 14:29:31 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12492 for ; Fri, 28 Jun 2002 14:28:45 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 28 Jun 2002 12:29:21 -0600 Message-Id: <02Jun28.122921mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Date: Fri, 28 Jun 2002 12:29:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21ED1.B2781ED0" Subject: [manet] RE: Maximum MANET size Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21ED1.B2781ED0 Content-Type: text/plain; charset="gb2312" Hi Hai Wang, I just came across this in Hass and Pearlman's description of Zone Routing Protocol (ZRP). "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad hoc networks by rapidly changing network topologies, influenced by network size and node mobility. Typically, such networks have a large span and contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my emphasis). I'd say "hundreds to thousands" qualifies as "large" in my book! As to what a RWN is, as far as I can tell, it is simply a very large, very dynamic MANET that has to be ready to go as soon as it is deployed. If a protocol works under those conditions, it will probably work anywhere and anytime. (Though it could be overkill in simpler cases). Incidentally, I think Zygmunt Hass is on this working group, so if you want to learn more about ZRP, this is the place to ask. (Also the place for other MANET protocols, too :-) All I know is what I'm reading in books and papers. John Mullen ------_=_NextPart_001_01C21ED1.B2781ED0 Content-Type: text/html; charset="gb2312"
Hi Hai Wang,
 
I just came across this in Hass and Pearlman's description of Zone Routing Protocol (ZRP).
 
"RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad hoc networks by rapidly changing network topologies, influenced by network size and node mobility.  Typically, such networks have a large span and contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my emphasis).
 
I'd say "hundreds to thousands" qualifies as "large" in my book!
 
As to what a RWN is, as far as I can tell, it is simply a very large, very dynamic MANET that has to be ready to go as soon as it is deployed.  If a protocol works under those conditions, it will probably work anywhere and anytime. (Though it could be overkill in simpler cases).
 
Incidentally, I think Zygmunt Hass is on this working group, so if you want to learn more about ZRP, this is the place to ask.  (Also the place for other MANET protocols, too :-) 
 
All I know is what I'm reading in books and papers.
 
John Mullen
------_=_NextPart_001_01C21ED1.B2781ED0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 14:52:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14302 for ; Fri, 28 Jun 2002 14:52:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20715; Fri, 28 Jun 2002 14:37:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20688 for ; Fri, 28 Jun 2002 14:37:49 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13043 for ; Fri, 28 Jun 2002 14:37:04 -0400 (EDT) Received: from virgo.rhod.uc.edu (virgo.rhod.uc.edu [10.63.7.110]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5SIbBn9010845; Fri, 28 Jun 2002 14:37:11 -0400 (EDT) Received: from localhost (vkumar@localhost) by virgo.rhod.uc.edu (8.11.6/8.9.1) with ESMTP id g5SIb7Z07947; Fri, 28 Jun 2002 14:37:07 -0400 X-Authentication-Warning: virgo.rhod.uc.edu: vkumar owned process doing -bs Date: Fri, 28 Jun 2002 14:37:07 -0400 (EDT) From: Vijay Kumar To: "Mullen, John P. (Contractor)" cc: ?? , Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: <02Jun28.122921mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org hi! I am basicaly new to this list . Has any work been done on routing in Large Scale MANETS (RWNs as mentioned below? Whcih are the protocols which have been tested / developed for such routing and where can i find them? thanks, Vijay On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > Hi Hai Wang, > > I just came across this in Hass and Pearlman's description of Zone Routing > Protocol (ZRP). > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > hoc networks by rapidly changing network topologies, influenced by network > size and node mobility. Typically, such networks have a large span and > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > emphasis). > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > As to what a RWN is, as far as I can tell, it is simply a very large, very > dynamic MANET that has to be ready to go as soon as it is deployed. If a > protocol works under those conditions, it will probably work anywhere and > anytime. (Though it could be overkill in simpler cases). > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > to learn more about ZRP, this is the place to ask. (Also the place for > other MANET protocols, too :-) > > All I know is what I'm reading in books and papers. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 14:52:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14311 for ; Fri, 28 Jun 2002 14:52:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21890 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 14:53:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20715; Fri, 28 Jun 2002 14:37:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20688 for ; Fri, 28 Jun 2002 14:37:49 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13043 for ; Fri, 28 Jun 2002 14:37:04 -0400 (EDT) Received: from virgo.rhod.uc.edu (virgo.rhod.uc.edu [10.63.7.110]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g5SIbBn9010845; Fri, 28 Jun 2002 14:37:11 -0400 (EDT) Received: from localhost (vkumar@localhost) by virgo.rhod.uc.edu (8.11.6/8.9.1) with ESMTP id g5SIb7Z07947; Fri, 28 Jun 2002 14:37:07 -0400 X-Authentication-Warning: virgo.rhod.uc.edu: vkumar owned process doing -bs Date: Fri, 28 Jun 2002 14:37:07 -0400 (EDT) From: Vijay Kumar To: "Mullen, John P. (Contractor)" cc: ?? , Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: <02Jun28.122921mdt.117121@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org hi! I am basicaly new to this list . Has any work been done on routing in Large Scale MANETS (RWNs as mentioned below? Whcih are the protocols which have been tested / developed for such routing and where can i find them? thanks, Vijay On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > Hi Hai Wang, > > I just came across this in Hass and Pearlman's description of Zone Routing > Protocol (ZRP). > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > hoc networks by rapidly changing network topologies, influenced by network > size and node mobility. Typically, such networks have a large span and > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > emphasis). > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > As to what a RWN is, as far as I can tell, it is simply a very large, very > dynamic MANET that has to be ready to go as soon as it is deployed. If a > protocol works under those conditions, it will probably work anywhere and > anytime. (Though it could be overkill in simpler cases). > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > to learn more about ZRP, this is the place to ask. (Also the place for > other MANET protocols, too :-) > > All I know is what I'm reading in books and papers. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 15:18:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15874 for ; Fri, 28 Jun 2002 15:18:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22953; Fri, 28 Jun 2002 15:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22922 for ; Fri, 28 Jun 2002 15:03:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14846 for ; Fri, 28 Jun 2002 15:02:29 -0400 (EDT) Received: from slb-av-02.boeing.com ([129.172.13.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA15895 for ; Fri, 28 Jun 2002 12:03:13 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA15822 for ; Fri, 28 Jun 2002 12:03:13 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5SJ3B009641 for ; Fri, 28 Jun 2002 12:03:11 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jun 2002 15:03:11 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CE@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: manet@ietf.org Date: Fri, 28 Jun 2002 15:04:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Routing to and from the Internet Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hoping not to bore anyone with this recurring topic ... If MANET used something like RFC 1256, ICMP Router Discovery Messages, then in principle a MANET host wanting to access the Internet could keep a log of available gateways to include in its source routing list. These messages would have to be transmitted at some approriately high rate by the MANET-Internet gateways, in accordance with the mobility characteristics of that MANET (and not necessarily in accordance with RFC 1256), so each host will have a high probability of reaching the selected gateway at the right time. The problem remains, for me, how the packet from this MANET host, having reached its intended Internet destination, can find its way back from the Internet to the MANET host. If each MANET host is provided with an IP address applicable to that MANET, by some DHCP-like process, that would work. But if a MANET host is expected to be able to use its own IP address, as many think should be the case, then somehow the gateway would have to prepend its own IP address prefix to the MANET host's IP SA? One hopes that when the response from the Internet arrives, that MANET-Internet gateway can still reach the original MANET host. The again, that would be true regardless. Thanks. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 15:18:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15883 for ; Fri, 28 Jun 2002 15:18:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24306 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 15:18:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22953; Fri, 28 Jun 2002 15:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22922 for ; Fri, 28 Jun 2002 15:03:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14846 for ; Fri, 28 Jun 2002 15:02:29 -0400 (EDT) Received: from slb-av-02.boeing.com ([129.172.13.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA15895 for ; Fri, 28 Jun 2002 12:03:13 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA15822 for ; Fri, 28 Jun 2002 12:03:13 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5SJ3B009641 for ; Fri, 28 Jun 2002 12:03:11 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jun 2002 15:03:11 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CE@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: manet@ietf.org Date: Fri, 28 Jun 2002 15:04:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Routing to and from the Internet Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hoping not to bore anyone with this recurring topic ... If MANET used something like RFC 1256, ICMP Router Discovery Messages, then in principle a MANET host wanting to access the Internet could keep a log of available gateways to include in its source routing list. These messages would have to be transmitted at some approriately high rate by the MANET-Internet gateways, in accordance with the mobility characteristics of that MANET (and not necessarily in accordance with RFC 1256), so each host will have a high probability of reaching the selected gateway at the right time. The problem remains, for me, how the packet from this MANET host, having reached its intended Internet destination, can find its way back from the Internet to the MANET host. If each MANET host is provided with an IP address applicable to that MANET, by some DHCP-like process, that would work. But if a MANET host is expected to be able to use its own IP address, as many think should be the case, then somehow the gateway would have to prepend its own IP address prefix to the MANET host's IP SA? One hopes that when the response from the Internet arrives, that MANET-Internet gateway can still reach the original MANET host. The again, that would be true regardless. Thanks. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 15:42:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17325 for ; Fri, 28 Jun 2002 15:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24372; Fri, 28 Jun 2002 15:19:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24345 for ; Fri, 28 Jun 2002 15:19:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15962 for ; Fri, 28 Jun 2002 15:18:54 -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 MAA11235; Fri, 28 Jun 2002 12:19:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SJJ7g05157; Fri, 28 Jun 2002 12:19:07 -0700 X-mProtect: <200206281919> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9li8RX; Fri, 28 Jun 2002 12:19:03 PDT Message-ID: <3D1CB6A7.2E649260@iprg.nokia.com> Date: Fri, 28 Jun 2002 12:19:03 -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: Vijay Kumar CC: "Mullen, John P. (Contractor)" , ?? , manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Vijay, We did experiments with 10,000 nodes running AODV which indicated the need and beneficial directions for study. I think that recent advances in understanding for AODV would yield substantial performance improvements. I don't know of any other experiments of similar scale, and I don't know of any experiments at all with 100,000 nodes. That would be one of our next milestones with AODV, though... Regards, Charlie P. Vijay Kumar wrote: > > hi! > > I am basicaly new to this list . > Has any work been done on routing in Large Scale MANETS (RWNs as > mentioned below? Whcih are the protocols which have been tested / > developed for such routing and where can i find them? > > thanks, > Vijay > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > Hi Hai Wang, > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > Protocol (ZRP). > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > hoc networks by rapidly changing network topologies, influenced by network > > size and node mobility. Typically, such networks have a large span and > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > emphasis). > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > protocol works under those conditions, it will probably work anywhere and > > anytime. (Though it could be overkill in simpler cases). > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > to learn more about ZRP, this is the place to ask. (Also the place for > > other MANET protocols, too :-) > > > > All I know is what I'm reading in books and papers. > > > > John Mullen > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 15:42:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17333 for ; Fri, 28 Jun 2002 15:42:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26290 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 15:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24372; Fri, 28 Jun 2002 15:19:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24345 for ; Fri, 28 Jun 2002 15:19:41 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15962 for ; Fri, 28 Jun 2002 15:18:54 -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 MAA11235; Fri, 28 Jun 2002 12:19:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SJJ7g05157; Fri, 28 Jun 2002 12:19:07 -0700 X-mProtect: <200206281919> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9li8RX; Fri, 28 Jun 2002 12:19:03 PDT Message-ID: <3D1CB6A7.2E649260@iprg.nokia.com> Date: Fri, 28 Jun 2002 12:19:03 -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: Vijay Kumar CC: "Mullen, John P. (Contractor)" , ?? , manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Vijay, We did experiments with 10,000 nodes running AODV which indicated the need and beneficial directions for study. I think that recent advances in understanding for AODV would yield substantial performance improvements. I don't know of any other experiments of similar scale, and I don't know of any experiments at all with 100,000 nodes. That would be one of our next milestones with AODV, though... Regards, Charlie P. Vijay Kumar wrote: > > hi! > > I am basicaly new to this list . > Has any work been done on routing in Large Scale MANETS (RWNs as > mentioned below? Whcih are the protocols which have been tested / > developed for such routing and where can i find them? > > thanks, > Vijay > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > Hi Hai Wang, > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > Protocol (ZRP). > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > hoc networks by rapidly changing network topologies, influenced by network > > size and node mobility. Typically, such networks have a large span and > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > emphasis). > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > protocol works under those conditions, it will probably work anywhere and > > anytime. (Though it could be overkill in simpler cases). > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > to learn more about ZRP, this is the place to ask. (Also the place for > > other MANET protocols, too :-) > > > > All I know is what I'm reading in books and papers. > > > > John Mullen > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 16:20:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19579 for ; Fri, 28 Jun 2002 16:20:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27022; Fri, 28 Jun 2002 15:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26992 for ; Fri, 28 Jun 2002 15:57:38 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18188 for ; Fri, 28 Jun 2002 15:56:50 -0400 (EDT) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5SJubO15943; Fri, 28 Jun 2002 15:56:37 -0400 (EDT) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NF0ZW91A; Fri, 28 Jun 2002 15:56:37 -0400 Received: from americasm01.nt.com (wnc1h04q.us.nortel.com [47.142.211.72]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MF97G0YN; Fri, 28 Jun 2002 15:56:37 -0400 Message-ID: <3D1CBF75.8ABA8A57@americasm01.nt.com> Date: Fri, 28 Jun 2002 15:56:37 -0400 From: "He Huang" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (X11; I; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size References: <3D1CB6A7.2E649260@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Charles, which simulation tool was used in your experiements with 10,000 nodes? Thanks, He Huang "Charles E. Perkins" wrote: > Hello Vijay, > > We did experiments with 10,000 nodes running AODV which > indicated the need and beneficial directions for study. > I think that recent advances in understanding for AODV > would yield substantial performance improvements. > > I don't know of any other experiments of similar scale, > and I don't know of any experiments at all with 100,000 > nodes. That would be one of our next milestones with AODV, > though... > > Regards, > Charlie P. > > Vijay Kumar wrote: > > > > hi! > > > > I am basicaly new to this list . > > Has any work been done on routing in Large Scale MANETS (RWNs as > > mentioned below? Whcih are the protocols which have been tested / > > developed for such routing and where can i find them? > > > > thanks, > > Vijay > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > Hi Hai Wang, > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > Protocol (ZRP). > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > hoc networks by rapidly changing network topologies, influenced by network > > > size and node mobility. Typically, such networks have a large span and > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > emphasis). > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > protocol works under those conditions, it will probably work anywhere and > > > anytime. (Though it could be overkill in simpler cases). > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > other MANET protocols, too :-) > > > > > > All I know is what I'm reading in books and papers. > > > > > > John Mullen > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 16:20:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19585 for ; Fri, 28 Jun 2002 16:20:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28949 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 16:20:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27022; Fri, 28 Jun 2002 15:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26992 for ; Fri, 28 Jun 2002 15:57:38 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18188 for ; Fri, 28 Jun 2002 15:56:50 -0400 (EDT) Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5SJubO15943; Fri, 28 Jun 2002 15:56:37 -0400 (EDT) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NF0ZW91A; Fri, 28 Jun 2002 15:56:37 -0400 Received: from americasm01.nt.com (wnc1h04q.us.nortel.com [47.142.211.72]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MF97G0YN; Fri, 28 Jun 2002 15:56:37 -0400 Message-ID: <3D1CBF75.8ABA8A57@americasm01.nt.com> Date: Fri, 28 Jun 2002 15:56:37 -0400 From: "He Huang" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (X11; I; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size References: <3D1CB6A7.2E649260@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Charles, which simulation tool was used in your experiements with 10,000 nodes? Thanks, He Huang "Charles E. Perkins" wrote: > Hello Vijay, > > We did experiments with 10,000 nodes running AODV which > indicated the need and beneficial directions for study. > I think that recent advances in understanding for AODV > would yield substantial performance improvements. > > I don't know of any other experiments of similar scale, > and I don't know of any experiments at all with 100,000 > nodes. That would be one of our next milestones with AODV, > though... > > Regards, > Charlie P. > > Vijay Kumar wrote: > > > > hi! > > > > I am basicaly new to this list . > > Has any work been done on routing in Large Scale MANETS (RWNs as > > mentioned below? Whcih are the protocols which have been tested / > > developed for such routing and where can i find them? > > > > thanks, > > Vijay > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > Hi Hai Wang, > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > Protocol (ZRP). > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > hoc networks by rapidly changing network topologies, influenced by network > > > size and node mobility. Typically, such networks have a large span and > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > emphasis). > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > protocol works under those conditions, it will probably work anywhere and > > > anytime. (Though it could be overkill in simpler cases). > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > other MANET protocols, too :-) > > > > > > All I know is what I'm reading in books and papers. > > > > > > John Mullen > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 16:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19760 for ; Fri, 28 Jun 2002 16:24:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28176; Fri, 28 Jun 2002 16:08:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28151 for ; Fri, 28 Jun 2002 16:08:15 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18878 for ; Fri, 28 Jun 2002 16:07:28 -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 NAA13192; Fri, 28 Jun 2002 13:05:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SK5uf20702; Fri, 28 Jun 2002 13:05:56 -0700 X-mProtect: <200206282005> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPABeNe; Fri, 28 Jun 2002 13:05:54 PDT Message-ID: <3D1CC1A2.F603B629@iprg.nokia.com> Date: Fri, 28 Jun 2002 13:05:54 -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: He Huang CC: manet@ietf.org, "Lee, Sung Ju" Subject: Re: [manet] RE: Maximum MANET size References: <3D1CB6A7.2E649260@iprg.nokia.com> <3D1CBF75.8ABA8A57@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, Much of the work was carried out by S-J. Lee, and was done with Glomosim. Regards, Charlie P. He Huang wrote: > > Hi, Charles, > > which simulation tool was used in your experiements with 10,000 nodes? > Thanks, > > He Huang > > "Charles E. Perkins" wrote: > > > Hello Vijay, > > > > We did experiments with 10,000 nodes running AODV which > > indicated the need and beneficial directions for study. > > I think that recent advances in understanding for AODV > > would yield substantial performance improvements. > > > > I don't know of any other experiments of similar scale, > > and I don't know of any experiments at all with 100,000 > > nodes. That would be one of our next milestones with AODV, > > though... > > > > Regards, > > Charlie P. > > > > Vijay Kumar wrote: > > > > > > hi! > > > > > > I am basicaly new to this list . > > > Has any work been done on routing in Large Scale MANETS (RWNs as > > > mentioned below? Whcih are the protocols which have been tested / > > > developed for such routing and where can i find them? > > > > > > thanks, > > > Vijay > > > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > > > Hi Hai Wang, > > > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > > Protocol (ZRP). > > > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > > hoc networks by rapidly changing network topologies, influenced by network > > > > size and node mobility. Typically, such networks have a large span and > > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > > emphasis). > > > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > > protocol works under those conditions, it will probably work anywhere and > > > > anytime. (Though it could be overkill in simpler cases). > > > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > > other MANET protocols, too :-) > > > > > > > > All I know is what I'm reading in books and papers. > > > > > > > > John Mullen > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 16:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19768 for ; Fri, 28 Jun 2002 16:24:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29191 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 16:25:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28176; Fri, 28 Jun 2002 16:08:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28151 for ; Fri, 28 Jun 2002 16:08:15 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18878 for ; Fri, 28 Jun 2002 16:07:28 -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 NAA13192; Fri, 28 Jun 2002 13:05:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5SK5uf20702; Fri, 28 Jun 2002 13:05:56 -0700 X-mProtect: <200206282005> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPABeNe; Fri, 28 Jun 2002 13:05:54 PDT Message-ID: <3D1CC1A2.F603B629@iprg.nokia.com> Date: Fri, 28 Jun 2002 13:05:54 -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: He Huang CC: manet@ietf.org, "Lee, Sung Ju" Subject: Re: [manet] RE: Maximum MANET size References: <3D1CB6A7.2E649260@iprg.nokia.com> <3D1CBF75.8ABA8A57@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, Much of the work was carried out by S-J. Lee, and was done with Glomosim. Regards, Charlie P. He Huang wrote: > > Hi, Charles, > > which simulation tool was used in your experiements with 10,000 nodes? > Thanks, > > He Huang > > "Charles E. Perkins" wrote: > > > Hello Vijay, > > > > We did experiments with 10,000 nodes running AODV which > > indicated the need and beneficial directions for study. > > I think that recent advances in understanding for AODV > > would yield substantial performance improvements. > > > > I don't know of any other experiments of similar scale, > > and I don't know of any experiments at all with 100,000 > > nodes. That would be one of our next milestones with AODV, > > though... > > > > Regards, > > Charlie P. > > > > Vijay Kumar wrote: > > > > > > hi! > > > > > > I am basicaly new to this list . > > > Has any work been done on routing in Large Scale MANETS (RWNs as > > > mentioned below? Whcih are the protocols which have been tested / > > > developed for such routing and where can i find them? > > > > > > thanks, > > > Vijay > > > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > > > Hi Hai Wang, > > > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > > Protocol (ZRP). > > > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > > hoc networks by rapidly changing network topologies, influenced by network > > > > size and node mobility. Typically, such networks have a large span and > > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > > emphasis). > > > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > > protocol works under those conditions, it will probably work anywhere and > > > > anytime. (Though it could be overkill in simpler cases). > > > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > > other MANET protocols, too :-) > > > > > > > > All I know is what I'm reading in books and papers. > > > > > > > > John Mullen > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 17:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21967 for ; Fri, 28 Jun 2002 17:04:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00784; Fri, 28 Jun 2002 16:45:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00681 for ; Fri, 28 Jun 2002 16:45:17 -0400 (EDT) Received: from smtp.advancedgroup.com ([65.214.91.126]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20821 for ; Fri, 28 Jun 2002 16:44:29 -0400 (EDT) Received: by smtp.advancedgroup.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 86256BE6.00724520 ; Fri, 28 Jun 2002 15:48:07 -0500 X-Lotus-FromDomain: AGC From: "Adam J Schuhmacher" To: manet@ietf.org Message-ID: <86256BE6.007244E3.00@smtp.advancedgroup.com> Date: Fri, 28 Jun 2002 15:39:46 -0500 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw" Content-Disposition: inline Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw Content-type: text/plain; charset=us-ascii Content-Disposition: inline Members of IETF and MANET, My company has been tasked by a Department of Defense contractor to identify a Senior Systems Architect well versed in MANET technology to run the cradle to grave development of the Next Generation Hand-Held Radio for the U.S. Military. My hope is that many of the members of the IETF and MANET would be very enthusiastic about this project as it will be one the biggest concrete implementations of this technology. Please find the formal job description attached below. Thank you so much for you time and attention. Regards, Adam Schuhmacher Advanced Resources 847-466-7817 (See attached file: SYS Arch.doc) --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw Content-type: application/msword; name="SYS Arch.doc" Content-Disposition: attachment; filename="SYS Arch.doc" Content-Description: Mac Word 3.0 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAACgwAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAJRYAABZBAQAWQQEACggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAQwMAAO4AAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAACAMAAAIAAAAKAwAAAAAAAAoDAAAAAAAACgMAAAAAAAAKAwAAAAAAAAoDAAAAAAAACgMAACQA AAAxBAAA9AEAACUGAABaAQAALgMAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAC4DAAAAAAAA XgIAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAABe AgAAAAAAAF4CAAAAAAAAXgIAAAAAAADKAAAAQgEAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAACAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAIAwAAAAAAAF4CAACqAAAAXgIAAAAAAAAAAAAA AAAAAAgDAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAMAAAAAAADKAAAAAAAAAL4AAAAMAAAA8MG8vp8e wgGmAAAAAAAAAKYAAAAAAAAADAIAAFIAAAAIAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADVNy IGxldmVsIGNvbW0gc3lzdGVtcyBhcmNoIGZvciBsZWFkaW5nIGEgdGVhbSBpbiB0aGUgZGV2ZWxv cG1lbnQgb2YgYWR2YW5jZWQgdmhmIGFuZCB1aGYgcmFkaW8gYW5kIGNvbW11bmljYXRpb24gc3lz dGVtcy4gIHN0cm9uZyBzeXMgZW5nIGJhY2tncm91bmQgYXQgdGhlIGFwcGxpY2F0aW9uLCBuZXR3 b3JrLCBsaW5rIGFuZCBwaHlzaWNhbCBsYXllcnMgZm9yIG11bHRpLW1lZGlhIHdhdmVmb3JtcyAo dm9pY2UsIHZpZGVvLCBkYXRhKSBleHAgd2l0aCBhZHZhbmNlZCBkc3AgbW9kZW0gYW5kIHN3IGJh c2VkIHJhZGlvIGFyY2hpdGVjdHVyZXMgYW5kIGNvbW11bmljYXRpb24gaW5mcmFzdHJ1Y3R1cmVz LiBsZWFkIHJlYyBhbmFseXNpcywgY29uY2VwdCBmb3JtdWxhdGlvbiwgZnVuYyBhbmFseXNpcywg YW5kIHN5cyBhcmNoIGRlZmluaXRpb24uIG1vYmlsZSBzdWJzY3JpYmVyIGVxdWlwbWVudCBvciBm YWEgbmV4Y29tbSBleHAgYSBwbHVzLiAHB2lkZWFsIGNhbmRpZGF0ZSA6IHdvcmtlZCBvbiAyIGdp Z3MsIGtub3dzIHRoZSBmb2xsb3dpbmcgY29kZXM6IGNvbnZvbHVzaW9uLCB0dXJibywgbG9naWMs IHRkbWEsIGZyZXEgaG9wcGluZywgYWRsZXIsY29tY2F0LXVuZGVyc3RhbmRzIG5ldHdvcmtpbmcg dGVjaG5pcXVlcyAobGluayBsYXllciwgbmV0d29yayBsYXllciBwcm90b2NvbHMsIE1BQ0EvUFIs IEhBTUEvUFIsIGJsdWV0b290aCkgLSAzMSBwZW9wbGUgaW4gdGhlIGdyb3VwLW1vc3RseSBnZW5l cmFsIGVlJ3Mgd2hvIG5lZWQgdG8gYmUgbGVhZCBieSB0aGlzIHBlcnNvbiAtICJpbnNpZGUgdGhl IGJveCIgZW1iZWRkZWQgcHJvdG9jb2xzLSBzb21lb25lIHdobyBoYXMgd29ya2VkIG9uIGNvbXBs ZXggd2lyZWxlc3MgcHJvZHVjdHMgZnJvbSBjb25jZXB0IHRocnUgaW1wbGVtZW50YXRpb24HB3Nv bWVvbmUgd2hvIGhhcyBhIGJyb2FkIGtub3dsZWRnZSBvZiBzeXN0ZW1zOiBodywgc3csIHN5c3Rl bXMgYXJjaCwgc29tZW9uZSB3aG8gY2FuIGRldGVybWluZSB3aGF0knMgZ29ubmEgYmUgdXNlZCBp biB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhpcyBwcm9kdWN0LWZwZ2EncywgYXNpY3MsIGRzcCdzLCBv cGVyYXRpbmcgc3lzdGVtLXNvbWVvbmUgd2hvIGhhcyBhIGJhY2tncm91bmQgaW4gcGh5c2ljYWwg bGF5ZXJzIChzcGVjdHJhbGx5IGVmZmljaWVudCkgYW5kIG5ldHdvcmtpbmcgcHJvdG9jb2xzKG1v YmlsZSBhZGhvYyBuZXR3b3JraW5nLSBtZWFuaW5nIHRoZXJlIGlzIG5vdCBhIGZpeGVkIGNlbGwg c2l0ZSBvciBiYXNlIHN0YXRpb24taXRzIGNvbnRpbnVhbGx5IG1vdmluZy1oZSBrbm93cyBoZSBp cyBub3QgZ29pbmcgdG8gZmluZCBzb21lb25lIHdobyBpcyBhIGd1cnUgaW4gYm90aCBhcmVhcywg YnV0IHNvbWVvbmUgd2hvIGlzIHN0cm9uZyBpbiBvbmUgYW5kIGFsc28gdW5kZXJzdGFuZHMgdGhl IG90aGVyIGlzIGlkZWFsLXdhbnRzIGEgY29tbXVuaWNhdGlvbnMgZ3VydTogc29tZW9uZSB3aG8g a25vd3MgbW9kdWxhdGlvbiwgZXF1YWxpemF0aW9uLCBkc3Agc3R1ZmYsIGVuY3J5cHRpb24gDQ0N SW4gYSBudXQgc2hlbGwsIHRoZXkgYXJlIGxvb2tpbmcgZm9yIGEgTGVhZCBTeXN0ZW1zIEVuZ2lu ZWVyIHRvIHdvcmsgb24gV2lyZWxlc3MgTW9iaWxlIE5ldHdvcmtpbmcgUmFkaW9zLiBUaGlzIHBl cnNvbiB3aWxsIGJlIHJlc3BvbnNpYmxlIGZvciB0aGUgZW50aXJlIHN5c3RlbXMgZnJvbSBDb25j ZXB0IHRvIFByb2R1Y3Rpb24uIChkZWZpbmUgZnVuY3Rpb25hbGl0eS8gYXJjaGl0ZWN0dXJlIGFu ZCBhbGwgcHJvdG9jb2wgbGF5ZXJzKSBUaGlzIGlzIGFsbCBuZXcgc3R1ZmYuIE5ldyBIL1cgJiBT L1csIE5ldyBQcm90b2NvbHMuLi4uLg0NDUluIGFkZGl0aW9uLCB0aGlzIHBlcnNvbiBzaG91bGQg YmUgZmFtaWxpYXIgd2l0aCBtb2R1bGF0aW9uL2RlbW9kdWxhdGlvbiBjb2RpbmcsIEgvVyAmIFMv VyBBcmNoaXRlY3R1cmUgYW5kIEgvVyBpbXBsZW1lbnRhdGlvbi4gQWxsIGluIGFsbCwgYSBXaXJl bGVzcyBDb21tdW5pY2F0aW9ucyBTeXN0ZW1zIFN1cGVyIFN0YXIuLi4uLi4uLi4uLi4uLi4uLi4H Bw0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAAAJ DAAACgwAAPfsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABU1CIFCKgFPSgIAUUoCAGgIAG5ICQQPT0oDAFFKAwBoCABuSAkEAAMABAAAAQQAAOMF AADkBQAAkAcAAJEHAAAECgAABQoAAAYKAAA6CwAAOwsAADwLAAAHDAAACAwAAAkMAAAKDAAA+gAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADitAYAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOLcEQAAAAAA AAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOAAAAAA AAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAsAABYkARckAQKWKAAI 1gYAAQAA4SgNAAAFJAEGJAEOhCgAD4QoABJk8AAAABYkAQAEAAASZPAAAAAADwAEAAABBAAA4wUA AOQFAACQBwAAkQcAAAQKAAAFCgAABgoAADoLAAA7CwAAPAsAAAcMAAAIDAAACQwAAAoMAAAA/fv9 +/39/f39/f37AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAwEABAMBBQoPIwASMAAcUAEAH7DQ LyCw4D0hsKAFIrCfASOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwAC AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAKCAAABQAAFgAAAAD/////AAQAAAoMAAAIAAAAAAQAAAoM AAAJAAAAAAQAAAoMAAAKAAAAAAAAAAEAAAADAAAACgAAAA4AAACHAAAAigAAAPsAAAD+AAAADQEA ABABAAAbAQAAHQEAAEoBAABZAQAAYAEAAGMBAACDAQAAhwEAAMoBAADNAQAAzgEAANUBAADWAQAA 2QEAACMCAAAuAgAAPgIAAEICAABEAgAASAIAAFICAABeAgAAuQIAAMICAADsAgAA8AIAAHwDAACA AwAAvwMAAMEDAADDAwAAxQMAACcEAAAtBAAALwQAADQEAAA2BAAAOwQAALUEAAC6BAAA7QUAAPAF AAAMCAAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAA AAB8AAAAggAAAFsBAABfAQAAqwEAALEBAAALBgAAFAYAADQHAAA5BwAA9AcAAAYIAAAMCAAABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwD//wIAAAAQAEEAZABhAG0AIABTAGMAaAB1AGgAbQBhAGMA aABlAHIAQABDADoAXABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABBAFMAYwBoAHUAaABt AGEAYwBoAGUAcgBcAEQAZQBzAGsAdABvAHAAXABNAHkAIABCAHIAaQBlAGYAYwBhAHMAZQBcAFMA WQBTACAAQQByAGMAaAAuAGQAbwBjAP9ADYABAE4BAABOAQAA4KvpAAEAAQBOAQAAAAAAAE0BAAAA AAAAAhAAAAAAAAAACggAAFAAAAgAQAAABAAAAEcWkAEAAAICBgMFBAUCAwSHAgAAAAAAAAAAAAAA AAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAA3EpABAAAAAAAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAVABtAHMAIABSAG0AbgAAACIABABxCIgYAADQAgAAaAEAAAAAFqJm ht/hZqYAAAAAAgACAAAAKQEAAKEGAAABAAMAAAAEAAMQDgAAAAAAAAAAAAAAAQABAAAAAQAAAAAA AADhAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAAAAAAAAAAAAA AAAAACQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAHgAUwByACAAbABlAHYAZQBsACAAYwBvAG0A bQAgAHMAeQBzAHQAZQBtAHMAIABhAHIAYwBoACAAZgBvAHIAIABsAGUAYQBkAGkAbgBnACAAYQAg AHQAZQBhAG0AIABpAG4AIAB0AGgAZQAgAGQAZQB2AGUAbABvAHAAbQBlAG4AdAAgAG8AZgAgAGEA ZAB2AGEAbgBjAGUAZAAgAHYAaABmACAAYQBuAGQAIAB1AGgAZgAgAHIAYQBkAGkAbwAgAGEAbgBk ACAAYwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgAgAHMAeQBzAHQAZQBtAHMAAAAAAAAAEABBAGQA YQBtACAAUwBjAGgAdQBoAG0AYQBjAGgAZQByABAAQQBkAGEAbQAgAFMAYwBoAHUAaABtAGEAYwBo AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAA AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA9AEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAABwB AAAEAAAAKAEAAAUAAABEAQAABgAAAFABAAAHAAAAXAEAAAgAAABsAQAACQAAAIgBAAASAAAAlAEA AAoAAACwAQAADAAAALwBAAANAAAAyAEAAA4AAADUAQAADwAAANwBAAAQAAAA5AEAABMAAADsAQAA AgAAAOQEAAAeAAAAeQAAAFNyIGxldmVsIGNvbW0gc3lzdGVtcyBhcmNoIGZvciBsZWFkaW5nIGEg dGVhbSBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYWR2YW5jZWQgdmhmIGFuZCB1aGYgcmFkaW8gYW5k IGNvbW11bmljYXRpb24gc3lzdGVtcwAAbwAeAAAAAQAAAAByIGweAAAAEQAAAEFkYW0gU2NodWht YWNoZXIAdGVtHgAAAAEAAAAAZGFtHgAAAAEAAAAAZGFtHgAAAAcAAABOb3JtYWwAaB4AAAARAAAA QWRhbSBTY2h1aG1hY2hlcgB0ZW0eAAAAAgAAADIAYW0eAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDgu MABtQAAAAACMhkcAAAAAQAAAAABMX3VdGMIBQAAAAABaxqifHsIBAwAAAAEAAAADAAAAKQEAAAMA AAChBgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC 1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a6kAQAAYAEAAAwAAAABAAAAaAAAAA8A AABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAA AKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAEEBAAACAAAA5AQAAB4AAAAEAAAAQUdDAAMAAAAOAAAA AwAAAAMAAAADAAAAJAgAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAe EAAAAQAAAHkAAABTciBsZXZlbCBjb21tIHN5c3RlbXMgYXJjaCBmb3IgbGVhZGluZyBhIHRlYW0g aW4gdGhlIGRldmVsb3BtZW50IG9mIGFkdmFuY2VkIHZoZiBhbmQgdWhmIHJhZGlvIGFuZCBjb21t dW5pY2F0aW9uIHN5c3RlbXMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAA AAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAA AE4AAAB7ADAAMgAzADYANQAwADUAMAAtADgANAA1ADEALQAxADEARAA2AC0AOABEAEYANQAtADAA MAA1ADAAOABCAEEANQBDAEQAOQA3AH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAWWLEXRjCAXDcwr6fHsIBKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlFgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0 AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAABw3MK+nx7CAXDcwr6fHsIBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 17:33:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23569 for ; Fri, 28 Jun 2002 17:33:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03351; Fri, 28 Jun 2002 17:13:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03320 for ; Fri, 28 Jun 2002 17:13:28 -0400 (EDT) Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22436 for ; Fri, 28 Jun 2002 17:12:41 -0400 (EDT) Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19727; Fri, 28 Jun 2002 17:12:57 -0400 (EDT) Message-Id: <5.0.2.1.2.20020628170746.01c69890@pop3.norton.antivirus> X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 28 Jun 2002 17:11:34 -0400 To: "Charles E. Perkins" , Vijay Kumar From: Chip Elliott Subject: Re: [manet] RE: Maximum MANET size Cc: "Mullen, John P. (Contractor)" , ?? , manet@ietf.org In-Reply-To: <3D1CB6A7.2E649260@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org one more data point.... BBN and Dartmouth College ran some simulations last year of 10,000 node sensor webs, a rather different thing from fully mobile networks. We think we could hit 100 k nodes without too much trouble, and in fact, even too much elapsed time in the modeling, due to Dartmouth's excellent modeling tool (DaSSF). We were using a new routing protocol that we've been tinkering with, and our WiroKit software base. -- Chip At 03:19 PM 6/28/02, Charles E. Perkins wrote: >Hello Vijay, > >We did experiments with 10,000 nodes running AODV which >indicated the need and beneficial directions for study. >I think that recent advances in understanding for AODV >would yield substantial performance improvements. > >I don't know of any other experiments of similar scale, >and I don't know of any experiments at all with 100,000 >nodes. That would be one of our next milestones with AODV, >though... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 17:33:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23576 for ; Fri, 28 Jun 2002 17:33:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05014 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 17:33:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03351; Fri, 28 Jun 2002 17:13:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03320 for ; Fri, 28 Jun 2002 17:13:28 -0400 (EDT) Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22436 for ; Fri, 28 Jun 2002 17:12:41 -0400 (EDT) Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19727; Fri, 28 Jun 2002 17:12:57 -0400 (EDT) Message-Id: <5.0.2.1.2.20020628170746.01c69890@pop3.norton.antivirus> X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 28 Jun 2002 17:11:34 -0400 To: "Charles E. Perkins" , Vijay Kumar From: Chip Elliott Subject: Re: [manet] RE: Maximum MANET size Cc: "Mullen, John P. (Contractor)" , ?? , manet@ietf.org In-Reply-To: <3D1CB6A7.2E649260@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org one more data point.... BBN and Dartmouth College ran some simulations last year of 10,000 node sensor webs, a rather different thing from fully mobile networks. We think we could hit 100 k nodes without too much trouble, and in fact, even too much elapsed time in the modeling, due to Dartmouth's excellent modeling tool (DaSSF). We were using a new routing protocol that we've been tinkering with, and our WiroKit software base. -- Chip At 03:19 PM 6/28/02, Charles E. Perkins wrote: >Hello Vijay, > >We did experiments with 10,000 nodes running AODV which >indicated the need and beneficial directions for study. >I think that recent advances in understanding for AODV >would yield substantial performance improvements. > >I don't know of any other experiments of similar scale, >and I don't know of any experiments at all with 100,000 >nodes. That would be one of our next milestones with AODV, >though... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 17:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21975 for ; Fri, 28 Jun 2002 17:04:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02948 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 17:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00784; Fri, 28 Jun 2002 16:45:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00681 for ; Fri, 28 Jun 2002 16:45:17 -0400 (EDT) Received: from smtp.advancedgroup.com ([65.214.91.126]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20821 for ; Fri, 28 Jun 2002 16:44:29 -0400 (EDT) Received: by smtp.advancedgroup.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 86256BE6.00724520 ; Fri, 28 Jun 2002 15:48:07 -0500 X-Lotus-FromDomain: AGC From: "Adam J Schuhmacher" To: manet@ietf.org Message-ID: <86256BE6.007244E3.00@smtp.advancedgroup.com> Date: Fri, 28 Jun 2002 15:39:46 -0500 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw" Content-Disposition: inline Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw Content-type: text/plain; charset=us-ascii Content-Disposition: inline Members of IETF and MANET, My company has been tasked by a Department of Defense contractor to identify a Senior Systems Architect well versed in MANET technology to run the cradle to grave development of the Next Generation Hand-Held Radio for the U.S. Military. My hope is that many of the members of the IETF and MANET would be very enthusiastic about this project as it will be one the biggest concrete implementations of this technology. Please find the formal job description attached below. Thank you so much for you time and attention. Regards, Adam Schuhmacher Advanced Resources 847-466-7817 (See attached file: SYS Arch.doc) --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw Content-type: application/msword; name="SYS Arch.doc" Content-Disposition: attachment; filename="SYS Arch.doc" Content-Description: Mac Word 3.0 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAACgwAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAJRYAABZBAQAWQQEACggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAQwMAAO4AAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAACAMAAAIAAAAKAwAAAAAAAAoDAAAAAAAACgMAAAAAAAAKAwAAAAAAAAoDAAAAAAAACgMAACQA AAAxBAAA9AEAACUGAABaAQAALgMAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAC4DAAAAAAAA XgIAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAABe AgAAAAAAAF4CAAAAAAAAXgIAAAAAAADKAAAAQgEAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAACAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAIAwAAAAAAAF4CAACqAAAAXgIAAAAAAAAAAAAA AAAAAAgDAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAMAAAAAAADKAAAAAAAAAL4AAAAMAAAA8MG8vp8e wgGmAAAAAAAAAKYAAAAAAAAADAIAAFIAAAAIAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADVNy IGxldmVsIGNvbW0gc3lzdGVtcyBhcmNoIGZvciBsZWFkaW5nIGEgdGVhbSBpbiB0aGUgZGV2ZWxv cG1lbnQgb2YgYWR2YW5jZWQgdmhmIGFuZCB1aGYgcmFkaW8gYW5kIGNvbW11bmljYXRpb24gc3lz dGVtcy4gIHN0cm9uZyBzeXMgZW5nIGJhY2tncm91bmQgYXQgdGhlIGFwcGxpY2F0aW9uLCBuZXR3 b3JrLCBsaW5rIGFuZCBwaHlzaWNhbCBsYXllcnMgZm9yIG11bHRpLW1lZGlhIHdhdmVmb3JtcyAo dm9pY2UsIHZpZGVvLCBkYXRhKSBleHAgd2l0aCBhZHZhbmNlZCBkc3AgbW9kZW0gYW5kIHN3IGJh c2VkIHJhZGlvIGFyY2hpdGVjdHVyZXMgYW5kIGNvbW11bmljYXRpb24gaW5mcmFzdHJ1Y3R1cmVz LiBsZWFkIHJlYyBhbmFseXNpcywgY29uY2VwdCBmb3JtdWxhdGlvbiwgZnVuYyBhbmFseXNpcywg YW5kIHN5cyBhcmNoIGRlZmluaXRpb24uIG1vYmlsZSBzdWJzY3JpYmVyIGVxdWlwbWVudCBvciBm YWEgbmV4Y29tbSBleHAgYSBwbHVzLiAHB2lkZWFsIGNhbmRpZGF0ZSA6IHdvcmtlZCBvbiAyIGdp Z3MsIGtub3dzIHRoZSBmb2xsb3dpbmcgY29kZXM6IGNvbnZvbHVzaW9uLCB0dXJibywgbG9naWMs IHRkbWEsIGZyZXEgaG9wcGluZywgYWRsZXIsY29tY2F0LXVuZGVyc3RhbmRzIG5ldHdvcmtpbmcg dGVjaG5pcXVlcyAobGluayBsYXllciwgbmV0d29yayBsYXllciBwcm90b2NvbHMsIE1BQ0EvUFIs IEhBTUEvUFIsIGJsdWV0b290aCkgLSAzMSBwZW9wbGUgaW4gdGhlIGdyb3VwLW1vc3RseSBnZW5l cmFsIGVlJ3Mgd2hvIG5lZWQgdG8gYmUgbGVhZCBieSB0aGlzIHBlcnNvbiAtICJpbnNpZGUgdGhl IGJveCIgZW1iZWRkZWQgcHJvdG9jb2xzLSBzb21lb25lIHdobyBoYXMgd29ya2VkIG9uIGNvbXBs ZXggd2lyZWxlc3MgcHJvZHVjdHMgZnJvbSBjb25jZXB0IHRocnUgaW1wbGVtZW50YXRpb24HB3Nv bWVvbmUgd2hvIGhhcyBhIGJyb2FkIGtub3dsZWRnZSBvZiBzeXN0ZW1zOiBodywgc3csIHN5c3Rl bXMgYXJjaCwgc29tZW9uZSB3aG8gY2FuIGRldGVybWluZSB3aGF0knMgZ29ubmEgYmUgdXNlZCBp biB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhpcyBwcm9kdWN0LWZwZ2EncywgYXNpY3MsIGRzcCdzLCBv cGVyYXRpbmcgc3lzdGVtLXNvbWVvbmUgd2hvIGhhcyBhIGJhY2tncm91bmQgaW4gcGh5c2ljYWwg bGF5ZXJzIChzcGVjdHJhbGx5IGVmZmljaWVudCkgYW5kIG5ldHdvcmtpbmcgcHJvdG9jb2xzKG1v YmlsZSBhZGhvYyBuZXR3b3JraW5nLSBtZWFuaW5nIHRoZXJlIGlzIG5vdCBhIGZpeGVkIGNlbGwg c2l0ZSBvciBiYXNlIHN0YXRpb24taXRzIGNvbnRpbnVhbGx5IG1vdmluZy1oZSBrbm93cyBoZSBp cyBub3QgZ29pbmcgdG8gZmluZCBzb21lb25lIHdobyBpcyBhIGd1cnUgaW4gYm90aCBhcmVhcywg YnV0IHNvbWVvbmUgd2hvIGlzIHN0cm9uZyBpbiBvbmUgYW5kIGFsc28gdW5kZXJzdGFuZHMgdGhl IG90aGVyIGlzIGlkZWFsLXdhbnRzIGEgY29tbXVuaWNhdGlvbnMgZ3VydTogc29tZW9uZSB3aG8g a25vd3MgbW9kdWxhdGlvbiwgZXF1YWxpemF0aW9uLCBkc3Agc3R1ZmYsIGVuY3J5cHRpb24gDQ0N SW4gYSBudXQgc2hlbGwsIHRoZXkgYXJlIGxvb2tpbmcgZm9yIGEgTGVhZCBTeXN0ZW1zIEVuZ2lu ZWVyIHRvIHdvcmsgb24gV2lyZWxlc3MgTW9iaWxlIE5ldHdvcmtpbmcgUmFkaW9zLiBUaGlzIHBl cnNvbiB3aWxsIGJlIHJlc3BvbnNpYmxlIGZvciB0aGUgZW50aXJlIHN5c3RlbXMgZnJvbSBDb25j ZXB0IHRvIFByb2R1Y3Rpb24uIChkZWZpbmUgZnVuY3Rpb25hbGl0eS8gYXJjaGl0ZWN0dXJlIGFu ZCBhbGwgcHJvdG9jb2wgbGF5ZXJzKSBUaGlzIGlzIGFsbCBuZXcgc3R1ZmYuIE5ldyBIL1cgJiBT L1csIE5ldyBQcm90b2NvbHMuLi4uLg0NDUluIGFkZGl0aW9uLCB0aGlzIHBlcnNvbiBzaG91bGQg YmUgZmFtaWxpYXIgd2l0aCBtb2R1bGF0aW9uL2RlbW9kdWxhdGlvbiBjb2RpbmcsIEgvVyAmIFMv VyBBcmNoaXRlY3R1cmUgYW5kIEgvVyBpbXBsZW1lbnRhdGlvbi4gQWxsIGluIGFsbCwgYSBXaXJl bGVzcyBDb21tdW5pY2F0aW9ucyBTeXN0ZW1zIFN1cGVyIFN0YXIuLi4uLi4uLi4uLi4uLi4uLi4H Bw0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAAAJ DAAACgwAAPfsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABU1CIFCKgFPSgIAUUoCAGgIAG5ICQQPT0oDAFFKAwBoCABuSAkEAAMABAAAAQQAAOMF AADkBQAAkAcAAJEHAAAECgAABQoAAAYKAAA6CwAAOwsAADwLAAAHDAAACAwAAAkMAAAKDAAA+gAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADitAYAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOLcEQAAAAAA AAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOAAAAAA AAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAsAABYkARckAQKWKAAI 1gYAAQAA4SgNAAAFJAEGJAEOhCgAD4QoABJk8AAAABYkAQAEAAASZPAAAAAADwAEAAABBAAA4wUA AOQFAACQBwAAkQcAAAQKAAAFCgAABgoAADoLAAA7CwAAPAsAAAcMAAAIDAAACQwAAAoMAAAA/fv9 +/39/f39/f37AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAwEABAMBBQoPIwASMAAcUAEAH7DQ LyCw4D0hsKAFIrCfASOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwAC AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAKCAAABQAAFgAAAAD/////AAQAAAoMAAAIAAAAAAQAAAoM AAAJAAAAAAQAAAoMAAAKAAAAAAAAAAEAAAADAAAACgAAAA4AAACHAAAAigAAAPsAAAD+AAAADQEA ABABAAAbAQAAHQEAAEoBAABZAQAAYAEAAGMBAACDAQAAhwEAAMoBAADNAQAAzgEAANUBAADWAQAA 2QEAACMCAAAuAgAAPgIAAEICAABEAgAASAIAAFICAABeAgAAuQIAAMICAADsAgAA8AIAAHwDAACA AwAAvwMAAMEDAADDAwAAxQMAACcEAAAtBAAALwQAADQEAAA2BAAAOwQAALUEAAC6BAAA7QUAAPAF AAAMCAAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAA AAB8AAAAggAAAFsBAABfAQAAqwEAALEBAAALBgAAFAYAADQHAAA5BwAA9AcAAAYIAAAMCAAABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwD//wIAAAAQAEEAZABhAG0AIABTAGMAaAB1AGgAbQBhAGMA aABlAHIAQABDADoAXABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABBAFMAYwBoAHUAaABt AGEAYwBoAGUAcgBcAEQAZQBzAGsAdABvAHAAXABNAHkAIABCAHIAaQBlAGYAYwBhAHMAZQBcAFMA WQBTACAAQQByAGMAaAAuAGQAbwBjAP9ADYABAE4BAABOAQAA4KvpAAEAAQBOAQAAAAAAAE0BAAAA AAAAAhAAAAAAAAAACggAAFAAAAgAQAAABAAAAEcWkAEAAAICBgMFBAUCAwSHAgAAAAAAAAAAAAAA AAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAA3EpABAAAAAAAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAVABtAHMAIABSAG0AbgAAACIABABxCIgYAADQAgAAaAEAAAAAFqJm ht/hZqYAAAAAAgACAAAAKQEAAKEGAAABAAMAAAAEAAMQDgAAAAAAAAAAAAAAAQABAAAAAQAAAAAA AADhAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAAAAAAAAAAAAA AAAAACQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAHgAUwByACAAbABlAHYAZQBsACAAYwBvAG0A bQAgAHMAeQBzAHQAZQBtAHMAIABhAHIAYwBoACAAZgBvAHIAIABsAGUAYQBkAGkAbgBnACAAYQAg AHQAZQBhAG0AIABpAG4AIAB0AGgAZQAgAGQAZQB2AGUAbABvAHAAbQBlAG4AdAAgAG8AZgAgAGEA ZAB2AGEAbgBjAGUAZAAgAHYAaABmACAAYQBuAGQAIAB1AGgAZgAgAHIAYQBkAGkAbwAgAGEAbgBk ACAAYwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgAgAHMAeQBzAHQAZQBtAHMAAAAAAAAAEABBAGQA YQBtACAAUwBjAGgAdQBoAG0AYQBjAGgAZQByABAAQQBkAGEAbQAgAFMAYwBoAHUAaABtAGEAYwBo AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAA AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA9AEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAABwB AAAEAAAAKAEAAAUAAABEAQAABgAAAFABAAAHAAAAXAEAAAgAAABsAQAACQAAAIgBAAASAAAAlAEA AAoAAACwAQAADAAAALwBAAANAAAAyAEAAA4AAADUAQAADwAAANwBAAAQAAAA5AEAABMAAADsAQAA AgAAAOQEAAAeAAAAeQAAAFNyIGxldmVsIGNvbW0gc3lzdGVtcyBhcmNoIGZvciBsZWFkaW5nIGEg dGVhbSBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgYWR2YW5jZWQgdmhmIGFuZCB1aGYgcmFkaW8gYW5k IGNvbW11bmljYXRpb24gc3lzdGVtcwAAbwAeAAAAAQAAAAByIGweAAAAEQAAAEFkYW0gU2NodWht YWNoZXIAdGVtHgAAAAEAAAAAZGFtHgAAAAEAAAAAZGFtHgAAAAcAAABOb3JtYWwAaB4AAAARAAAA QWRhbSBTY2h1aG1hY2hlcgB0ZW0eAAAAAgAAADIAYW0eAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDgu MABtQAAAAACMhkcAAAAAQAAAAABMX3VdGMIBQAAAAABaxqifHsIBAwAAAAEAAAADAAAAKQEAAAMA AAChBgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC 1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a6kAQAAYAEAAAwAAAABAAAAaAAAAA8A AABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAA AKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAEEBAAACAAAA5AQAAB4AAAAEAAAAQUdDAAMAAAAOAAAA AwAAAAMAAAADAAAAJAgAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAe EAAAAQAAAHkAAABTciBsZXZlbCBjb21tIHN5c3RlbXMgYXJjaCBmb3IgbGVhZGluZyBhIHRlYW0g aW4gdGhlIGRldmVsb3BtZW50IG9mIGFkdmFuY2VkIHZoZiBhbmQgdWhmIHJhZGlvIGFuZCBjb21t dW5pY2F0aW9uIHN5c3RlbXMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAA AAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAA AE4AAAB7ADAAMgAzADYANQAwADUAMAAtADgANAA1ADEALQAxADEARAA2AC0AOABEAEYANQAtADAA MAA1ADAAOABCAEEANQBDAEQAOQA3AH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAWWLEXRjCAXDcwr6fHsIBKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlFgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0 AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAABw3MK+nx7CAXDcwr6fHsIBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA --0__=qPRKXZD49KKLklkeGwxXazy8CpfMZ519wbM94LXRPiDJY26a5ZlLJTqw-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 17:58:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24708 for ; Fri, 28 Jun 2002 17:58:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05222; Fri, 28 Jun 2002 17:40:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05191 for ; Fri, 28 Jun 2002 17:40:55 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23929 for ; Fri, 28 Jun 2002 17:40:07 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 28 14:40:04 2002 To: yasser.lotfy@lycos.com, "Kuldip Singh Pabla" , "Charles E. Perkins" , "Rex Buddenberg" Date: Fri, 28 Jun 2002 17:40:04 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 206.172.157.2 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Gateway address resolution Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: Gateway address resolution; Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? Yasser Carleton U Ottawa, Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 17:58:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24716 for ; Fri, 28 Jun 2002 17:58:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06559 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 17:59:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05222; Fri, 28 Jun 2002 17:40:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05191 for ; Fri, 28 Jun 2002 17:40:55 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23929 for ; Fri, 28 Jun 2002 17:40:07 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jun 28 14:40:04 2002 To: yasser.lotfy@lycos.com, "Kuldip Singh Pabla" , "Charles E. Perkins" , "Rex Buddenberg" Date: Fri, 28 Jun 2002 17:40:04 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 206.172.157.2 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Gateway address resolution Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: Gateway address resolution; Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? Yasser Carleton U Ottawa, Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 18:09:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25349 for ; Fri, 28 Jun 2002 18:09:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06021; Fri, 28 Jun 2002 17:51:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05994 for ; Fri, 28 Jun 2002 17:51:47 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24416 for ; Fri, 28 Jun 2002 17:50:58 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23454; Fri, 28 Jun 2002 14:50:26 -0700 (PDT) Received: from sun.com (obssa.red.iplanet.com [192.18.190.198]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5SLoPC24337; Fri, 28 Jun 2002 14:50:26 -0700 (PDT) Message-ID: <3D1CDA22.628904DE@sun.com> Date: Fri, 28 Jun 2002 14:50:26 -0700 From: kuldip Singh pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: yasser.lotfy@lycos.com, manet@ietf.org Subject: Re: [manet] Gateway address resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yasser, How about treating the ad-hoc network as a NATed community in this case! -Kuldip "Yasser A. Lotfy" wrote: > > Hi, > > Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: > > Gateway address resolution; > Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. > > For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? > > Yasser > Carleton U > Ottawa, Canada > > ____________________________________________________________ > Win a first-class trip to New Orleans and vacation Elvis Style!. > Enter NOW! > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Kuldip Singh Pabla Peer-2-Peer Networking External: 408.276.6118 Internal: x16118 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 18:09:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25358 for ; Fri, 28 Jun 2002 18:09:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07957 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 18:10:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06021; Fri, 28 Jun 2002 17:51:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05994 for ; Fri, 28 Jun 2002 17:51:47 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24416 for ; Fri, 28 Jun 2002 17:50:58 -0400 (EDT) Received: from ha1sca-mail1.SFBay.Sun.COM ([129.145.155.51]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23454; Fri, 28 Jun 2002 14:50:26 -0700 (PDT) Received: from sun.com (obssa.red.iplanet.com [192.18.190.198]) by ha1sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id g5SLoPC24337; Fri, 28 Jun 2002 14:50:26 -0700 (PDT) Message-ID: <3D1CDA22.628904DE@sun.com> Date: Fri, 28 Jun 2002 14:50:26 -0700 From: kuldip Singh pabla Reply-To: manet@ietf.org Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: yasser.lotfy@lycos.com, manet@ietf.org Subject: Re: [manet] Gateway address resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yasser, How about treating the ad-hoc network as a NATed community in this case! -Kuldip "Yasser A. Lotfy" wrote: > > Hi, > > Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: > > Gateway address resolution; > Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. > > For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? > > Yasser > Carleton U > Ottawa, Canada > > ____________________________________________________________ > Win a first-class trip to New Orleans and vacation Elvis Style!. > Enter NOW! > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Kuldip Singh Pabla Peer-2-Peer Networking External: 408.276.6118 Internal: x16118 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 18:30:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26068 for ; Fri, 28 Jun 2002 18:30:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07765; Fri, 28 Jun 2002 18:09:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07737 for ; Fri, 28 Jun 2002 18:08:57 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25176 for ; Fri, 28 Jun 2002 18:08:09 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA12705; Fri, 28 Jun 2002 15:06:09 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA16332; Fri, 28 Jun 2002 15:06:08 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5SM67013901; Fri, 28 Jun 2002 15:06:07 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jun 2002 18:06:06 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CF@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'yasser.lotfy@lycos.com'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Fri, 28 Jun 2002 18:06:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yasser A. Lotfy wrote: > Seems like many have agreed on the general ideas in my > original e-mail. However, one point yet need further discussion: > > Gateway address resolution; > Since ad-hoc IP addresses don't represent a pool of > addresses, the idea of subnet mask can not be used. Hince, > distinguishing intranet traffic from internet traaffic > becomes a critical challenge. > > For example ad-hoc gateways can read distination address and > check againest table of all ad-hoc IP addresses. This can > raise scalability issues. Can IPv6 provide a way to > distinguish local ad-hoc nodes from fixed structure nodes? > Any other ideas? There are many possible variations to how addressing inside the MANET is handled, which makes brief replies difficult or incomprehensible. But I'll give this suggestion. Assume that MANET hosts use their own IP address, as if it were a flat address. That seems to be the most general case. Have all these random IP addresses intercommunicating in the MANET. For that to work, with IPv4 addressing especially, I don't see any good solution except one in which the MANET-Internet gateways keep a table of all IP SAs they see arriving from the MANET. If they see packets with IP DAs that they have seen operating in that MANET, they do not forward the packets through to the Internet. To build up this exhaustive table, ICMP router discovery (RFC 1256), or a derivative, might be useful, and all MANET hosts must participate. In other words, all hosts must transmit router solicitations, in order to be seen by the gateway(s). If the gateways see an IP DA that they have not seen in the MANET, the gateways must assume these packets are meant for the fixed Internet. In this last instance, the gateway maps the IP SA of the incoming packet to a fixed-internet address from their fixed Internet subnet, then forwards the packet on to the wired Internet. Any packet returning with that IP DA is then mapped to the actual IP address of that MANET host, as they had been tabulated by the gateway previously. This table must be aged, of course. With IPv6, I would think one could use a simpler scheme, where each MANET host can use its MAC address embedded in the IPv6 address, with some bogus MANET prefix, and let the gateway take care of the prefix for stuff going outside the MANET. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 18:30:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26073 for ; Fri, 28 Jun 2002 18:30:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09615 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 18:31:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07765; Fri, 28 Jun 2002 18:09:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07737 for ; Fri, 28 Jun 2002 18:08:57 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25176 for ; Fri, 28 Jun 2002 18:08:09 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA12705; Fri, 28 Jun 2002 15:06:09 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA16332; Fri, 28 Jun 2002 15:06:08 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g5SM67013901; Fri, 28 Jun 2002 15:06:07 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jun 2002 18:06:06 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CF@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'yasser.lotfy@lycos.com'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Fri, 28 Jun 2002 18:06:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yasser A. Lotfy wrote: > Seems like many have agreed on the general ideas in my > original e-mail. However, one point yet need further discussion: > > Gateway address resolution; > Since ad-hoc IP addresses don't represent a pool of > addresses, the idea of subnet mask can not be used. Hince, > distinguishing intranet traffic from internet traaffic > becomes a critical challenge. > > For example ad-hoc gateways can read distination address and > check againest table of all ad-hoc IP addresses. This can > raise scalability issues. Can IPv6 provide a way to > distinguish local ad-hoc nodes from fixed structure nodes? > Any other ideas? There are many possible variations to how addressing inside the MANET is handled, which makes brief replies difficult or incomprehensible. But I'll give this suggestion. Assume that MANET hosts use their own IP address, as if it were a flat address. That seems to be the most general case. Have all these random IP addresses intercommunicating in the MANET. For that to work, with IPv4 addressing especially, I don't see any good solution except one in which the MANET-Internet gateways keep a table of all IP SAs they see arriving from the MANET. If they see packets with IP DAs that they have seen operating in that MANET, they do not forward the packets through to the Internet. To build up this exhaustive table, ICMP router discovery (RFC 1256), or a derivative, might be useful, and all MANET hosts must participate. In other words, all hosts must transmit router solicitations, in order to be seen by the gateway(s). If the gateways see an IP DA that they have not seen in the MANET, the gateways must assume these packets are meant for the fixed Internet. In this last instance, the gateway maps the IP SA of the incoming packet to a fixed-internet address from their fixed Internet subnet, then forwards the packet on to the wired Internet. Any packet returning with that IP DA is then mapped to the actual IP address of that MANET host, as they had been tabulated by the gateway previously. This table must be aged, of course. With IPv6, I would think one could use a simpler scheme, where each MANET host can use its MAC address embedded in the IPv6 address, with some bogus MANET prefix, and let the gateway take care of the prefix for stuff going outside the MANET. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 19:04:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27244 for ; Fri, 28 Jun 2002 19:04:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10357; Fri, 28 Jun 2002 18:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10328 for ; Fri, 28 Jun 2002 18:47:13 -0400 (EDT) Received: from barrichello.cs.ucr.edu (barrichello.cs.ucr.edu [138.23.169.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26587 for ; Fri, 28 Jun 2002 18:46:25 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id C323A8BCF7; Fri, 28 Jun 2002 15:47:10 -0700 (PDT) Received: from hill (hill.cs.ucr.edu [138.23.169.9]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 5CEDE8BCF5; Fri, 28 Jun 2002 15:47:06 -0700 (PDT) Date: Fri, 28 Jun 2002 15:47:06 -0700 (PDT) From: Zhenqiang Ye To: "Charles E. Perkins" Cc: Vijay Kumar , "Mullen, John P. (Contractor)" , ?? , Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: <3D1CB6A7.2E649260@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Charles: Did you publish your experiment results? Where can I find it? I am very interested in it. Regards, Zhenqiang(Frank) Ye On Fri, 28 Jun 2002, Charles E. Perkins wrote: > > Hello Vijay, > > We did experiments with 10,000 nodes running AODV which > indicated the need and beneficial directions for study. > I think that recent advances in understanding for AODV > would yield substantial performance improvements. > > I don't know of any other experiments of similar scale, > and I don't know of any experiments at all with 100,000 > nodes. That would be one of our next milestones with AODV, > though... > > Regards, > Charlie P. > > > > Vijay Kumar wrote: > > > > hi! > > > > I am basicaly new to this list . > > Has any work been done on routing in Large Scale MANETS (RWNs as > > mentioned below? Whcih are the protocols which have been tested / > > developed for such routing and where can i find them? > > > > thanks, > > Vijay > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > Hi Hai Wang, > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > Protocol (ZRP). > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > hoc networks by rapidly changing network topologies, influenced by network > > > size and node mobility. Typically, such networks have a large span and > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > emphasis). > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > protocol works under those conditions, it will probably work anywhere and > > > anytime. (Though it could be overkill in simpler cases). > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > other MANET protocols, too :-) > > > > > > All I know is what I'm reading in books and papers. > > > > > > John Mullen > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 19:04:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27253 for ; Fri, 28 Jun 2002 19:04:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11532 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 19:05:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10357; Fri, 28 Jun 2002 18:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10328 for ; Fri, 28 Jun 2002 18:47:13 -0400 (EDT) Received: from barrichello.cs.ucr.edu (barrichello.cs.ucr.edu [138.23.169.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26587 for ; Fri, 28 Jun 2002 18:46:25 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id C323A8BCF7; Fri, 28 Jun 2002 15:47:10 -0700 (PDT) Received: from hill (hill.cs.ucr.edu [138.23.169.9]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 5CEDE8BCF5; Fri, 28 Jun 2002 15:47:06 -0700 (PDT) Date: Fri, 28 Jun 2002 15:47:06 -0700 (PDT) From: Zhenqiang Ye To: "Charles E. Perkins" Cc: Vijay Kumar , "Mullen, John P. (Contractor)" , ?? , Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: <3D1CB6A7.2E649260@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Charles: Did you publish your experiment results? Where can I find it? I am very interested in it. Regards, Zhenqiang(Frank) Ye On Fri, 28 Jun 2002, Charles E. Perkins wrote: > > Hello Vijay, > > We did experiments with 10,000 nodes running AODV which > indicated the need and beneficial directions for study. > I think that recent advances in understanding for AODV > would yield substantial performance improvements. > > I don't know of any other experiments of similar scale, > and I don't know of any experiments at all with 100,000 > nodes. That would be one of our next milestones with AODV, > though... > > Regards, > Charlie P. > > > > Vijay Kumar wrote: > > > > hi! > > > > I am basicaly new to this list . > > Has any work been done on routing in Large Scale MANETS (RWNs as > > mentioned below? Whcih are the protocols which have been tested / > > developed for such routing and where can i find them? > > > > thanks, > > Vijay > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > Hi Hai Wang, > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > Protocol (ZRP). > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > hoc networks by rapidly changing network topologies, influenced by network > > > size and node mobility. Typically, such networks have a large span and > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > emphasis). > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > protocol works under those conditions, it will probably work anywhere and > > > anytime. (Though it could be overkill in simpler cases). > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > other MANET protocols, too :-) > > > > > > All I know is what I'm reading in books and papers. > > > > > > John Mullen > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 19:25:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28164 for ; Fri, 28 Jun 2002 19:25:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11765; Fri, 28 Jun 2002 19:10:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11736 for ; Fri, 28 Jun 2002 19:10:08 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27418 for ; Fri, 28 Jun 2002 19:09:18 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Fri, 28 Jun 2002 17:09:59 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 28 Jun 02 17:09:59 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 28 Jun 02 17:09:41 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 28 Jun 02 17:09:34 -0700 Message-ID: <013701c21ef9$1b26e8e0$390a640a@Transient> From: "Scott C. Lemon" To: References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CE@xch-ne-02.ne.nos.boeing.com> Subject: Re: [manet] Routing to and from the Internet Date: Fri, 28 Jun 2002 17:11:14 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, I really like your line of thinking here, and I too have been thinking down this line. My interest in MANETs is for groups of mobile users with wearable computers being able to have full data communications between them. I have also been creating some possible solution scenarios where the users would each have multiple radio technologies ... one dedicated for the "peer to peer" MANET (I am experimenting with some 900Mhz radios), and another for Internet Access such as 802.11b/a ... I would like for the entire MANET to have Internet access if any individual user came close to an 802.11b access point that was Internet connected. If multiple MANET users were in range of APs then there would even be multiple routes to the Internet. My initial thoughts on this was to have my MANET users all use addresses in the 10.x.x.x range, subnet mask 255.0.0.0 for their MANET interfaces, and then to configure the 802.11b for DHCP. Each user would be configured to be a routing node, and to have NAT (Network Address Translation). As a user established contact with a 802.11b AP, they would DHCP and get an address ... they would then begin to advertise to the MANET as a router ... and NAT all of the outbound traffic from the MANET to the Internet. Traffic coming back would be handled by the NAT and go back to the MANET node ... if it was still reachable. I know that some people will say there are issues with NAT and the ability to receive inbound connections, however I have been able to solve these issues for my applications by relaying through permanent Internet servers if necessary. In my scenario, every user would have the potential to become an Internet Gateway/Router ... although they would not have to. Also, I have thought about the process of "grabbing" an address in the 10.x.x.x range. Using the entire subnet space creates the potential to have a lot of addresses, and a user/node could just grab an address and attempt to use it ... pinging to see if that address replies. I am sure there is another way to do this also ... maybe SLP ... Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ----- Original Message ----- From: "Manfredi, Albert E" To: Sent: Friday, June 28, 2002 1:04 PM Subject: [manet] Routing to and from the Internet > Hoping not to bore anyone with this recurring topic ... > > If MANET used something like RFC 1256, ICMP Router Discovery Messages, then in principle a MANET host wanting to access the Internet could keep a log of available gateways to include in its source routing list. These messages would have to be transmitted at some approriately high rate by the MANET-Internet gateways, in accordance with the mobility characteristics of that MANET (and not necessarily in accordance with RFC 1256), so each host will have a high probability of reaching the selected gateway at the right time. > > The problem remains, for me, how the packet from this MANET host, having reached its intended Internet destination, can find its way back from the Internet to the MANET host. > > If each MANET host is provided with an IP address applicable to that MANET, by some DHCP-like process, that would work. But if a MANET host is expected to be able to use its own IP address, as many think should be the case, then somehow the gateway would have to prepend its own IP address prefix to the MANET host's IP SA? > > One hopes that when the response from the Internet arrives, that MANET-Internet gateway can still reach the original MANET host. The again, that would be true regardless. > > Thanks. > > Bert > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 19:25:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28172 for ; Fri, 28 Jun 2002 19:25:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13236 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 19:26:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11765; Fri, 28 Jun 2002 19:10:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11736 for ; Fri, 28 Jun 2002 19:10:08 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27418 for ; Fri, 28 Jun 2002 19:09:18 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Fri, 28 Jun 2002 17:09:59 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 28 Jun 02 17:09:59 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 28 Jun 02 17:09:41 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 28 Jun 02 17:09:34 -0700 Message-ID: <013701c21ef9$1b26e8e0$390a640a@Transient> From: "Scott C. Lemon" To: References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39CE@xch-ne-02.ne.nos.boeing.com> Subject: Re: [manet] Routing to and from the Internet Date: Fri, 28 Jun 2002 17:11:14 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, I really like your line of thinking here, and I too have been thinking down this line. My interest in MANETs is for groups of mobile users with wearable computers being able to have full data communications between them. I have also been creating some possible solution scenarios where the users would each have multiple radio technologies ... one dedicated for the "peer to peer" MANET (I am experimenting with some 900Mhz radios), and another for Internet Access such as 802.11b/a ... I would like for the entire MANET to have Internet access if any individual user came close to an 802.11b access point that was Internet connected. If multiple MANET users were in range of APs then there would even be multiple routes to the Internet. My initial thoughts on this was to have my MANET users all use addresses in the 10.x.x.x range, subnet mask 255.0.0.0 for their MANET interfaces, and then to configure the 802.11b for DHCP. Each user would be configured to be a routing node, and to have NAT (Network Address Translation). As a user established contact with a 802.11b AP, they would DHCP and get an address ... they would then begin to advertise to the MANET as a router ... and NAT all of the outbound traffic from the MANET to the Internet. Traffic coming back would be handled by the NAT and go back to the MANET node ... if it was still reachable. I know that some people will say there are issues with NAT and the ability to receive inbound connections, however I have been able to solve these issues for my applications by relaying through permanent Internet servers if necessary. In my scenario, every user would have the potential to become an Internet Gateway/Router ... although they would not have to. Also, I have thought about the process of "grabbing" an address in the 10.x.x.x range. Using the entire subnet space creates the potential to have a lot of addresses, and a user/node could just grab an address and attempt to use it ... pinging to see if that address replies. I am sure there is another way to do this also ... maybe SLP ... Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ----- Original Message ----- From: "Manfredi, Albert E" To: Sent: Friday, June 28, 2002 1:04 PM Subject: [manet] Routing to and from the Internet > Hoping not to bore anyone with this recurring topic ... > > If MANET used something like RFC 1256, ICMP Router Discovery Messages, then in principle a MANET host wanting to access the Internet could keep a log of available gateways to include in its source routing list. These messages would have to be transmitted at some approriately high rate by the MANET-Internet gateways, in accordance with the mobility characteristics of that MANET (and not necessarily in accordance with RFC 1256), so each host will have a high probability of reaching the selected gateway at the right time. > > The problem remains, for me, how the packet from this MANET host, having reached its intended Internet destination, can find its way back from the Internet to the MANET host. > > If each MANET host is provided with an IP address applicable to that MANET, by some DHCP-like process, that would work. But if a MANET host is expected to be able to use its own IP address, as many think should be the case, then somehow the gateway would have to prepend its own IP address prefix to the MANET host's IP SA? > > One hopes that when the response from the Internet arrives, that MANET-Internet gateway can still reach the original MANET host. The again, that would be true regardless. > > Thanks. > > Bert > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 19:33:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28455 for ; Fri, 28 Jun 2002 19:33:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12494; Fri, 28 Jun 2002 19:19:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12463 for ; Fri, 28 Jun 2002 19:19:31 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27853 for ; Fri, 28 Jun 2002 19:18:44 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Fri, 28 Jun 2002 17:19:28 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 28 Jun 02 17:19:28 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 28 Jun 02 17:19:00 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 28 Jun 02 17:18:57 -0700 Message-ID: <014101c21efa$6afb8140$390a640a@Transient> From: "Scott C. Lemon" To: References: <3D1CDA22.628904DE@sun.com> Subject: Re: [manet] Gateway address resolution Date: Fri, 28 Jun 2002 17:20:38 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes! I agree 100% ... think of the MANETs as roaming flat networks ... and each node becomes a possible router with NAT using a second interface - wireless *or* wired - to provide connectivity from the MANET to the Internet. This is the direction that we are working right now ... Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ----- Original Message ----- From: "kuldip Singh pabla" To: ; Sent: Friday, June 28, 2002 3:50 PM Subject: Re: [manet] Gateway address resolution > Yasser, > > How about treating the ad-hoc network as a NATed community in this case! > > -Kuldip > > "Yasser A. Lotfy" wrote: > > > > Hi, > > > > Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: > > > > Gateway address resolution; > > Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. > > > > For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? > > > > Yasser > > Carleton U > > Ottawa, Canada > > > > ____________________________________________________________ > > Win a first-class trip to New Orleans and vacation Elvis Style!. > > Enter NOW! > > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Kuldip Singh Pabla > Peer-2-Peer Networking > External: 408.276.6118 Internal: x16118 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 19:33:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28464 for ; Fri, 28 Jun 2002 19:33:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA14285 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 19:33:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12494; Fri, 28 Jun 2002 19:19:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12463 for ; Fri, 28 Jun 2002 19:19:31 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27853 for ; Fri, 28 Jun 2002 19:18:44 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Fri, 28 Jun 2002 17:19:28 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 28 Jun 02 17:19:28 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 28 Jun 02 17:19:00 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 28 Jun 02 17:18:57 -0700 Message-ID: <014101c21efa$6afb8140$390a640a@Transient> From: "Scott C. Lemon" To: References: <3D1CDA22.628904DE@sun.com> Subject: Re: [manet] Gateway address resolution Date: Fri, 28 Jun 2002 17:20:38 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes! I agree 100% ... think of the MANETs as roaming flat networks ... and each node becomes a possible router with NAT using a second interface - wireless *or* wired - to provide connectivity from the MANET to the Internet. This is the direction that we are working right now ... Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ----- Original Message ----- From: "kuldip Singh pabla" To: ; Sent: Friday, June 28, 2002 3:50 PM Subject: Re: [manet] Gateway address resolution > Yasser, > > How about treating the ad-hoc network as a NATed community in this case! > > -Kuldip > > "Yasser A. Lotfy" wrote: > > > > Hi, > > > > Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: > > > > Gateway address resolution; > > Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. > > > > For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? > > > > Yasser > > Carleton U > > Ottawa, Canada > > > > ____________________________________________________________ > > Win a first-class trip to New Orleans and vacation Elvis Style!. > > Enter NOW! > > http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Kuldip Singh Pabla > Peer-2-Peer Networking > External: 408.276.6118 Internal: x16118 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jun 28 19:46:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28975 for ; Fri, 28 Jun 2002 19:46:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12869; Fri, 28 Jun 2002 19:23:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12830 for ; Fri, 28 Jun 2002 19:23:23 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28023 for ; Fri, 28 Jun 2002 19:22:36 -0400 (EDT) Received: from mrwint.cisco.com (localhost [127.0.0.1]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA17296; Sat, 29 Jun 2002 00:22:40 +0100 (BST) Message-Id: <200206282322.AAA17296@cisco.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Charles E. Perkins" cc: He Huang , manet@ietf.org, "Lee, Sung Ju" Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: Message from "Charles E. Perkins" of "Fri, 28 Jun 2002 13:05:54 PDT." <3D1CC1A2.F603B629@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Jun 2002 00:22:40 +0100 From: Nikos Triantafillis Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org In message <3D1CC1A2.F603B629@iprg.nokia.com>, "Charles E. Perkins" writes: >Hello, > >Much of the work was carried out by S-J. Lee, and was >done with Glomosim. Hi Charlie, Can we have a bit more info on this if possible. Like results, scenarios, version of glomosim and possibly the glomosim AODV implementation because if my memory serves me right the current glomosim AODV implementation isn't close at all to the existing draft spec. Regards, Nikos.- >Regards, >Charlie P. > > >He Huang wrote: >> >> Hi, Charles, >> >> which simulation tool was used in your experiements with 10,000 nodes? >> Thanks, >> >> He Huang >> >> "Charles E. Perkins" wrote: >> >> > Hello Vijay, >> > >> > We did experiments with 10,000 nodes running AODV which >> > indicated the need and beneficial directions for study. >> > I think that recent advances in understanding for AODV >> > would yield substantial performance improvements. >> > >> > I don't know of any other experiments of similar scale, >> > and I don't know of any experiments at all with 100,000 >> > nodes. That would be one of our next milestones with AODV, >> > though... >> > >> > Regards, >> > Charlie P. >> > >> > Vijay Kumar wrote: >> > > >> > > hi! >> > > >> > > I am basicaly new to this list . >> > > Has any work been done on routing in Large Scale MANETS (RWNs as >> > > mentioned below? Whcih are the protocols which have been tested / >> > > developed for such routing and where can i find them? >> > > >> > > thanks, >> > > Vijay >> > > >> > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: >> > > >> > > > Hi Hai Wang, >> > > > >> > > > I just came across this in Hass and Pearlman's description of Zone Rou >ting >> > > > Protocol (ZRP). >> > > > >> > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from othe >r ad >> > > > hoc networks by rapidly changing network topologies, influenced by net >work >> > > > size and node mobility. Typically, such networks have a large span an >d >> > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. >(my >> > > > emphasis). >> > > > >> > > > I'd say "hundreds to thousands" qualifies as "large" in my book! >> > > > >> > > > As to what a RWN is, as far as I can tell, it is simply a very large, >very >> > > > dynamic MANET that has to be ready to go as soon as it is deployed. I >f a >> > > > protocol works under those conditions, it will probably work anywhere >and >> > > > anytime. (Though it could be overkill in simpler cases). >> > > > >> > > > Incidentally, I think Zygmunt Hass is on this working group, so if you > want >> > > > to learn more about ZRP, this is the place to ask. (Also the place fo >r >> > > > other MANET protocols, too :-) >> > > > >> > > > All I know is what I'm reading in books and papers. >> > > > >> > > > John Mullen >> > > > >> > > >> > > _______________________________________________ >> > > manet mailing list >> > > manet@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/manet >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www1.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jun 28 19:46:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28980 for ; Fri, 28 Jun 2002 19:46:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA14811 for manet-archive@odin.ietf.org; Fri, 28 Jun 2002 19:47:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12869; Fri, 28 Jun 2002 19:23:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12830 for ; Fri, 28 Jun 2002 19:23:23 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28023 for ; Fri, 28 Jun 2002 19:22:36 -0400 (EDT) Received: from mrwint.cisco.com (localhost [127.0.0.1]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA17296; Sat, 29 Jun 2002 00:22:40 +0100 (BST) Message-Id: <200206282322.AAA17296@cisco.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Charles E. Perkins" cc: He Huang , manet@ietf.org, "Lee, Sung Ju" Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: Message from "Charles E. Perkins" of "Fri, 28 Jun 2002 13:05:54 PDT." <3D1CC1A2.F603B629@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Jun 2002 00:22:40 +0100 From: Nikos Triantafillis Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org In message <3D1CC1A2.F603B629@iprg.nokia.com>, "Charles E. Perkins" writes: >Hello, > >Much of the work was carried out by S-J. Lee, and was >done with Glomosim. Hi Charlie, Can we have a bit more info on this if possible. Like results, scenarios, version of glomosim and possibly the glomosim AODV implementation because if my memory serves me right the current glomosim AODV implementation isn't close at all to the existing draft spec. Regards, Nikos.- >Regards, >Charlie P. > > >He Huang wrote: >> >> Hi, Charles, >> >> which simulation tool was used in your experiements with 10,000 nodes? >> Thanks, >> >> He Huang >> >> "Charles E. Perkins" wrote: >> >> > Hello Vijay, >> > >> > We did experiments with 10,000 nodes running AODV which >> > indicated the need and beneficial directions for study. >> > I think that recent advances in understanding for AODV >> > would yield substantial performance improvements. >> > >> > I don't know of any other experiments of similar scale, >> > and I don't know of any experiments at all with 100,000 >> > nodes. That would be one of our next milestones with AODV, >> > though... >> > >> > Regards, >> > Charlie P. >> > >> > Vijay Kumar wrote: >> > > >> > > hi! >> > > >> > > I am basicaly new to this list . >> > > Has any work been done on routing in Large Scale MANETS (RWNs as >> > > mentioned below? Whcih are the protocols which have been tested / >> > > developed for such routing and where can i find them? >> > > >> > > thanks, >> > > Vijay >> > > >> > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: >> > > >> > > > Hi Hai Wang, >> > > > >> > > > I just came across this in Hass and Pearlman's description of Zone Rou >ting >> > > > Protocol (ZRP). >> > > > >> > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from othe >r ad >> > > > hoc networks by rapidly changing network topologies, influenced by net >work >> > > > size and node mobility. Typically, such networks have a large span an >d >> > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. >(my >> > > > emphasis). >> > > > >> > > > I'd say "hundreds to thousands" qualifies as "large" in my book! >> > > > >> > > > As to what a RWN is, as far as I can tell, it is simply a very large, >very >> > > > dynamic MANET that has to be ready to go as soon as it is deployed. I >f a >> > > > protocol works under those conditions, it will probably work anywhere >and >> > > > anytime. (Though it could be overkill in simpler cases). >> > > > >> > > > Incidentally, I think Zygmunt Hass is on this working group, so if you > want >> > > > to learn more about ZRP, this is the place to ask. (Also the place fo >r >> > > > other MANET protocols, too :-) >> > > > >> > > > All I know is what I'm reading in books and papers. >> > > > >> > > > John Mullen >> > > > >> > > >> > > _______________________________________________ >> > > manet mailing list >> > > manet@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/manet >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www1.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jun 29 05:31:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21184 for ; Sat, 29 Jun 2002 05:31:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13835; Sat, 29 Jun 2002 04:48:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13728 for ; Sat, 29 Jun 2002 04:48:49 -0400 (EDT) Received: from bjapp1.163.net ([202.108.255.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20316 for ; Sat, 29 Jun 2002 04:48:02 -0400 (EDT) Received: by bjapp1.163.net (Postfix, from userid 1005) id 4ECC81DB6C9E1; Sat, 29 Jun 2002 16:48:46 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D1D746E.000001.02228@bjapp1> Date: Sat, 29 Jun 2002 16:48:46 +0800 (CST) From: "Íõº£" To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org X-Priority: 3 X-Originating-IP: [211.162.21.116] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw" Subject: [manet] =?gb2312?B?UmU6IFJFOiBbbWFuZXRdIElQIGFkZHJlc3NlcyBpbiBNQU5FVA==?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John: Thanks for your detailed explaining. I agree with you in most part, except: [John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,.... I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however, he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :) BR. Hai Wang > Hi Hai Wang, > > You have a lot of statements here, so I'll comment on them one at a time. > > [Hai Wang] I think what Bill referred is the clustering problem of > hierarchical MANET. In some situation, bad parameterized cluster maintenance > such as cluster-split, cluster-merge may induce more OH than routing > protocol. > > [John M] Regardless of what protocol we pick, there will be a set of > circumstances under which it will not perform well. In Computer Science, > people tend to look at the worst case and ask if that is tolerable. In > Industrial Engineering (my field), we also look at average performance. > This involves a bit more understanding of the situation in that we have to > figure out how likely the worst case (and other cases) are. So, if there is > a set of circumstances under which a protocol will do badly, but those > circumstances are very very rare, we may still use the protocol. > > Any form of organization will work best when it coincides with the situation > and worst when it does not. Essentially, a set of instructions is trying to > guess which organization will be best, based on the observed network state. > Every once in a while, it will be wrong. However, if it is better than the > alternatives, including no clustering, we would still tend to use it. > > [Hai Wang] However, I see no reasonable default parameter such as cluster > size, cluster merge/split threshold can be fitted for all real networks. So > a hierarchical MANET¡¯s performance is not promising. Am I right? Or is > there any reference parameter for hierarchical MANET implementation? > > [John M] The term "MANET" describes a tremendous variety of rather messy > networks. Additionally, the equipment in use has some impact on cluster > size and design. In a large MANET, local conditions can vary, so in some > regions, a larger cluster size might be advisable. Finally, traffic > patterns interact with clustering. It is unlikely that a single default > parameter would be acceptable for all MANETs. However, it is likely that a > single initial value will be good starting point and that heuristics can be > found to locally optimize cluster size. After all, we have to find > something for hungry graduate students to do. > :-) > > Also, there are a number of clustering schemes, so parameters for one would > differ from those of another. Martha Steenstrup discusses a number of these > in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, Chapter > 4]. Her discussion does a good job of describing the protocols and showing > how technology, traffic patterns, and geographical dispersion impact and are > impacted by different clustering methods. > > [Hai Wang] There is another question aroused in my brain: Is there a > nodes-limit for MANET? That is: can MANET support more than thousands of > nodes or even tens of thousands of nodes? I heard that UBC has build a Ad > hoc sensor network of 800 nodes; however, I think there is difference > between sensor network and MANET, for sensor network has little message to > transfer on the net, OH is not a big problem. > > [John M] I have heard of working MANETS up to 1000 nodes in size. This is > 1000 hosts, almost all of which are operated by people communicating with > each other. Conceptually, there is no limit, though practically speaking > there probably is one. Of course, special circumstances can reduce the > complexity of the problem. For example, if a MANET consists of ten teams of > 100 hosts, each team of which is organized into five units, and if these > teams and units tend to travel together, say as in an emergency relief > operation, then a clustering by organizational unit seems logical and would > probably work. Given a "nice" situation, there would be no practical limit > to the MANET, though purists would probably call it a very tame one. > > [Hai Wang] In a very big MANET, with its mobility nature, I doubt any scheme > , neithe! r flat nor hierarchical, would work. If there is a limit, do we > have a value this society agreed on? With this in mind, I think it will be > better for us to discuss the hierarchical or flat MANET. > > [John M] There are probably circumstances under which a flat MANET is > preferable to a hierarchical one, but I think you have the size factor > backwards. Hierarchal clustering tends to localize the impact of state > changes, so it tends to be more useful in larger nets than in smaller ones. > If each node is one or two hops away from every other node, probably > clustering is not worth the OH. However, if the net diameter is ten or > twenty hops, something is needed to reduce the size of the routing problem > and clustering seems to be one way to do it. If there is a limit to MANET > size, it will be a practical one, set by limitations of the media and > technology. I think that is too much of a moving target to set a value at > this point. > > BR > Hai Wang > > > > Hi Bill, > > > > I think it could go either way, depending on the nature of the MANET. > > > > The advantage of clustering is that you can keep some information local. > > Even in a very dynamic situation, not all changes need be propagated > > throughout the net. However, there is a certain amount of OH involved and > > it could be that under certain circumstances, the OH would cut into > > available BW. > > > > However, in checking this out, we would have to consider the total effect > of > > clustering. It is not just that one keeps local changes more-or-less > local, > > but also that the resulting hierarchal structure makes routing more > > efficient. > > > > There is also anot! her factor. Some protocols (e.g. AODV) maintain only > > active r outes. In a very dynamic network of n nodes in which only a few > of > > the n-squared possible routes are used, clustering might have less value > > than in a network in which a large fraction of possible source-destination > > pairs are active. > > > > John Mullen > > > > > > > --Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John:
Thanks for your detailed explaining. I agree with you in most part, except:
[John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,....

I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however,! he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :)

BR.
Hai Wang


> Hi Hai Wang,
>
> You have a lot of statements here, so I'll comment on them one at a time.
>
> [Hai Wang] I think what Bill referred is the clustering problem of
> hierarchical MANET. In some situation, bad parameterized cluster maintenance
> such as cluster-split, cluster-merge may induce more OH than routing
> protocol.
>
> [John M] Regardless of what protocol we pick, there will be a set of
> circumstances under which it will not perform well. In Computer Science,
> people tend to look at the worst case and ask if that is tolerable. In
> Industrial Engineering (my field), we also look at average performance.
> This involves a bit more understanding of the situation in that we have to
> figure out how likely the worst case (and other cases) are. So, if t! here is
> a set of circumstances under which a protocol will do badly, but those
> circumstances are very very rare, we may still use the protocol.
>
> Any form of organization will work best when it coincides with the situation
> and worst when it does not. Essentially, a set of instructions is trying to
> guess which organization will be best, based on the observed network state.
> Every once in a while, it will be wrong. However, if it is better than the
> alternatives, including no clustering, we would still tend to use it.
>
> [Hai Wang] However, I see no reasonable default parameter such as cluster
> size, cluster merge/split threshold can be fitted for all real networks. So
> a hierarchical MANET¡¯s performance is not promising. Am I right? Or is
> there any reference parameter for hierarchical MANET implementation?
>
> [John M] The term "MANET" describes a tremendous variety of rather messy
> networks. Additionally, the! equipment in use has some impact on cluster
> size and design. In a large MANET, local conditions can vary, so in some
> regions, a larger cluster size might be advisable. Finally, traffic
> patterns interact with clustering. It is unlikely that a single default
> parameter would be acceptable for all MANETs. However, it is likely that a
> single initial value will be good starting point and that heuristics can be
> found to locally optimize cluster size. After all, we have to find
> something for hungry graduate students to do.
> :-)
>
> Also, there are a number of clustering schemes, so parameters for one would
> differ from those of another. Martha Steenstrup discusses a number of these
> in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, Chapter
> 4]. Her discussion does a good job of describing the protocols and showing
> how technology, traffic patte! rns, and geographical dispersion impact and are
> impacted by di fferent clustering methods.
>
> [Hai Wang] There is another question aroused in my brain: Is there a
> nodes-limit for MANET? That is: can MANET support more than thousands of
> nodes or even tens of thousands of nodes? I heard that UBC has build a Ad
> hoc sensor network of 800 nodes; however, I think there is difference
> between sensor network and MANET, for sensor network has little message to
> transfer on the net, OH is not a big problem.
>
> [John M] I have heard of working MANETS up to 1000 nodes in size. This is
> 1000 hosts, almost all of which are operated by people communicating with
> each other. Conceptually, there is no limit, though practically speaking
> there probably is one. Of course, special circumstances can reduce the
> complexity of the problem. For example, if a MANET consists of ten teams of
> 100 hosts, each team of which is organized into five units, and i! f these
> teams and units tend to travel together, say as in an emergency relief
> operation, then a clustering by organizational unit seems logical and would
> probably work. Given a "nice" situation, there would be no practical limit
> to the MANET, though purists would probably call it a very tame one.
>
> [Hai Wang] In a very big MANET, with its mobility nature, I doubt any scheme
> , neithe! r flat nor hierarchical, would work. If there is a limit, do we
> have a value this society agreed on? With this in mind, I think it will be
> better for us to discuss the hierarchical or flat MANET.
>
> [John M] There are probably circumstances under which a flat MANET is
> preferable to a hierarchical one, but I think you have the size factor
> backwards. Hierarchal clustering tends to localize the impact of state
> changes, so it tends to be more useful in larger nets than in smal! ler ones.
> If each node is one or two hops away from every othe r node, probably
> clustering is not worth the OH. However, if the net diameter is ten or
> twenty hops, something is needed to reduce the size of the routing problem
> and clustering seems to be one way to do it. If there is a limit to MANET
> size, it will be a practical one, set by limitations of the media and
> technology. I think that is too much of a moving target to set a value at
> this point.
>
> BR
> Hai Wang
>
>
> > Hi Bill,
> >
> > I think it could go either way, depending on the nature of the MANET.
> >
> > The advantage of clustering is that you can keep some information local.
> > Even in a very dynamic situation, not all changes need be propagated
> > throughout the net. However, there is a certain amount of OH involved and
> > it could be that under certain circumstances, the OH would cut into
> > availabl! e BW.
> >
> > However, in checking this out, we would have to consider the total effect
> of
> > clustering. It is not just that one keeps local changes more-or-less
> local,
> > but also that the resulting hierarchal structure makes routing more
> > efficient.
> >
> > There is also anot! her factor. Some protocols (e.g. AODV) maintain only
> > active r outes. In a very dynamic network of n nodes in which only a few
> of
> > the n-squared possible routes are used, clustering might have less value
> > than in a network in which a large fraction of possible source-destination
> > pairs are active.
> >
> > John Mullen
> >
> >
>
>
>
--Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Jun 29 05:31:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21193 for ; Sat, 29 Jun 2002 05:31:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16470 for manet-archive@odin.ietf.org; Sat, 29 Jun 2002 05:32:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13835; Sat, 29 Jun 2002 04:48:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13728 for ; Sat, 29 Jun 2002 04:48:49 -0400 (EDT) Received: from bjapp1.163.net ([202.108.255.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20316 for ; Sat, 29 Jun 2002 04:48:02 -0400 (EDT) Received: by bjapp1.163.net (Postfix, from userid 1005) id 4ECC81DB6C9E1; Sat, 29 Jun 2002 16:48:46 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D1D746E.000001.02228@bjapp1> Date: Sat, 29 Jun 2002 16:48:46 +0800 (CST) From: "Íõº£" To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org X-Priority: 3 X-Originating-IP: [211.162.21.116] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw" Subject: [manet] =?gb2312?B?UmU6IFJFOiBbbWFuZXRdIElQIGFkZHJlc3NlcyBpbiBNQU5FVA==?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John: Thanks for your detailed explaining. I agree with you in most part, except: [John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,.... I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however, he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :) BR. Hai Wang > Hi Hai Wang, > > You have a lot of statements here, so I'll comment on them one at a time. > > [Hai Wang] I think what Bill referred is the clustering problem of > hierarchical MANET. In some situation, bad parameterized cluster maintenance > such as cluster-split, cluster-merge may induce more OH than routing > protocol. > > [John M] Regardless of what protocol we pick, there will be a set of > circumstances under which it will not perform well. In Computer Science, > people tend to look at the worst case and ask if that is tolerable. In > Industrial Engineering (my field), we also look at average performance. > This involves a bit more understanding of the situation in that we have to > figure out how likely the worst case (and other cases) are. So, if there is > a set of circumstances under which a protocol will do badly, but those > circumstances are very very rare, we may still use the protocol. > > Any form of organization will work best when it coincides with the situation > and worst when it does not. Essentially, a set of instructions is trying to > guess which organization will be best, based on the observed network state. > Every once in a while, it will be wrong. However, if it is better than the > alternatives, including no clustering, we would still tend to use it. > > [Hai Wang] However, I see no reasonable default parameter such as cluster > size, cluster merge/split threshold can be fitted for all real networks. So > a hierarchical MANET¡¯s performance is not promising. Am I right? Or is > there any reference parameter for hierarchical MANET implementation? > > [John M] The term "MANET" describes a tremendous variety of rather messy > networks. Additionally, the equipment in use has some impact on cluster > size and design. In a large MANET, local conditions can vary, so in some > regions, a larger cluster size might be advisable. Finally, traffic > patterns interact with clustering. It is unlikely that a single default > parameter would be acceptable for all MANETs. However, it is likely that a > single initial value will be good starting point and that heuristics can be > found to locally optimize cluster size. After all, we have to find > something for hungry graduate students to do. > :-) > > Also, there are a number of clustering schemes, so parameters for one would > differ from those of another. Martha Steenstrup discusses a number of these > in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, Chapter > 4]. Her discussion does a good job of describing the protocols and showing > how technology, traffic patterns, and geographical dispersion impact and are > impacted by different clustering methods. > > [Hai Wang] There is another question aroused in my brain: Is there a > nodes-limit for MANET? That is: can MANET support more than thousands of > nodes or even tens of thousands of nodes? I heard that UBC has build a Ad > hoc sensor network of 800 nodes; however, I think there is difference > between sensor network and MANET, for sensor network has little message to > transfer on the net, OH is not a big problem. > > [John M] I have heard of working MANETS up to 1000 nodes in size. This is > 1000 hosts, almost all of which are operated by people communicating with > each other. Conceptually, there is no limit, though practically speaking > there probably is one. Of course, special circumstances can reduce the > complexity of the problem. For example, if a MANET consists of ten teams of > 100 hosts, each team of which is organized into five units, and if these > teams and units tend to travel together, say as in an emergency relief > operation, then a clustering by organizational unit seems logical and would > probably work. Given a "nice" situation, there would be no practical limit > to the MANET, though purists would probably call it a very tame one. > > [Hai Wang] In a very big MANET, with its mobility nature, I doubt any scheme > , neithe! r flat nor hierarchical, would work. If there is a limit, do we > have a value this society agreed on? With this in mind, I think it will be > better for us to discuss the hierarchical or flat MANET. > > [John M] There are probably circumstances under which a flat MANET is > preferable to a hierarchical one, but I think you have the size factor > backwards. Hierarchal clustering tends to localize the impact of state > changes, so it tends to be more useful in larger nets than in smaller ones. > If each node is one or two hops away from every other node, probably > clustering is not worth the OH. However, if the net diameter is ten or > twenty hops, something is needed to reduce the size of the routing problem > and clustering seems to be one way to do it. If there is a limit to MANET > size, it will be a practical one, set by limitations of the media and > technology. I think that is too much of a moving target to set a value at > this point. > > BR > Hai Wang > > > > Hi Bill, > > > > I think it could go either way, depending on the nature of the MANET. > > > > The advantage of clustering is that you can keep some information local. > > Even in a very dynamic situation, not all changes need be propagated > > throughout the net. However, there is a certain amount of OH involved and > > it could be that under certain circumstances, the OH would cut into > > available BW. > > > > However, in checking this out, we would have to consider the total effect > of > > clustering. It is not just that one keeps local changes more-or-less > local, > > but also that the resulting hierarchal structure makes routing more > > efficient. > > > > There is also anot! her factor. Some protocols (e.g. AODV) maintain only > > active r outes. In a very dynamic network of n nodes in which only a few > of > > the n-squared possible routes are used, clustering might have less value > > than in a network in which a large fraction of possible source-destination > > pairs are active. > > > > John Mullen > > > > > > > --Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi John:
Thanks for your detailed explaining. I agree with you in most part, except:
[John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,....

I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however,! he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :)

BR.
Hai Wang


> Hi Hai Wang,
>
> You have a lot of statements here, so I'll comment on them one at a time.
>
> [Hai Wang] I think what Bill referred is the clustering problem of
> hierarchical MANET. In some situation, bad parameterized cluster maintenance
> such as cluster-split, cluster-merge may induce more OH than routing
> protocol.
>
> [John M] Regardless of what protocol we pick, there will be a set of
> circumstances under which it will not perform well. In Computer Science,
> people tend to look at the worst case and ask if that is tolerable. In
> Industrial Engineering (my field), we also look at average performance.
> This involves a bit more understanding of the situation in that we have to
> figure out how likely the worst case (and other cases) are. So, if t! here is
> a set of circumstances under which a protocol will do badly, but those
> circumstances are very very rare, we may still use the protocol.
>
> Any form of organization will work best when it coincides with the situation
> and worst when it does not. Essentially, a set of instructions is trying to
> guess which organization will be best, based on the observed network state.
> Every once in a while, it will be wrong. However, if it is better than the
> alternatives, including no clustering, we would still tend to use it.
>
> [Hai Wang] However, I see no reasonable default parameter such as cluster
> size, cluster merge/split threshold can be fitted for all real networks. So
> a hierarchical MANET¡¯s performance is not promising. Am I right? Or is
> there any reference parameter for hierarchical MANET implementation?
>
> [John M] The term "MANET" describes a tremendous variety of rather messy
> networks. Additionally, the! equipment in use has some impact on cluster
> size and design. In a large MANET, local conditions can vary, so in some
> regions, a larger cluster size might be advisable. Finally, traffic
> patterns interact with clustering. It is unlikely that a single default
> parameter would be acceptable for all MANETs. However, it is likely that a
> single initial value will be good starting point and that heuristics can be
> found to locally optimize cluster size. After all, we have to find
> something for hungry graduate students to do.
> :-)
>
> Also, there are a number of clustering schemes, so parameters for one would
> differ from those of another. Martha Steenstrup discusses a number of these
> in "Cluster-Based Networks," [Ad Hoc Networking, by Charles Perkins, Chapter
> 4]. Her discussion does a good job of describing the protocols and showing
> how technology, traffic patte! rns, and geographical dispersion impact and are
> impacted by di fferent clustering methods.
>
> [Hai Wang] There is another question aroused in my brain: Is there a
> nodes-limit for MANET? That is: can MANET support more than thousands of
> nodes or even tens of thousands of nodes? I heard that UBC has build a Ad
> hoc sensor network of 800 nodes; however, I think there is difference
> between sensor network and MANET, for sensor network has little message to
> transfer on the net, OH is not a big problem.
>
> [John M] I have heard of working MANETS up to 1000 nodes in size. This is
> 1000 hosts, almost all of which are operated by people communicating with
> each other. Conceptually, there is no limit, though practically speaking
> there probably is one. Of course, special circumstances can reduce the
> complexity of the problem. For example, if a MANET consists of ten teams of
> 100 hosts, each team of which is organized into five units, and i! f these
> teams and units tend to travel together, say as in an emergency relief
> operation, then a clustering by organizational unit seems logical and would
> probably work. Given a "nice" situation, there would be no practical limit
> to the MANET, though purists would probably call it a very tame one.
>
> [Hai Wang] In a very big MANET, with its mobility nature, I doubt any scheme
> , neithe! r flat nor hierarchical, would work. If there is a limit, do we
> have a value this society agreed on? With this in mind, I think it will be
> better for us to discuss the hierarchical or flat MANET.
>
> [John M] There are probably circumstances under which a flat MANET is
> preferable to a hierarchical one, but I think you have the size factor
> backwards. Hierarchal clustering tends to localize the impact of state
> changes, so it tends to be more useful in larger nets than in smal! ler ones.
> If each node is one or two hops away from every othe r node, probably
> clustering is not worth the OH. However, if the net diameter is ten or
> twenty hops, something is needed to reduce the size of the routing problem
> and clustering seems to be one way to do it. If there is a limit to MANET
> size, it will be a practical one, set by limitations of the media and
> technology. I think that is too much of a moving target to set a value at
> this point.
>
> BR
> Hai Wang
>
>
> > Hi Bill,
> >
> > I think it could go either way, depending on the nature of the MANET.
> >
> > The advantage of clustering is that you can keep some information local.
> > Even in a very dynamic situation, not all changes need be propagated
> > throughout the net. However, there is a certain amount of OH involved and
> > it could be that under certain circumstances, the OH would cut into
> > availabl! e BW.
> >
> > However, in checking this out, we would have to consider the total effect
> of
> > clustering. It is not just that one keeps local changes more-or-less
> local,
> > but also that the resulting hierarchal structure makes routing more
> > efficient.
> >
> > There is also anot! her factor. Some protocols (e.g. AODV) maintain only
> > active r outes. In a very dynamic network of n nodes in which only a few
> of
> > the n-squared possible routes are used, clustering might have less value
> > than in a network in which a large fraction of possible source-destination
> > pairs are active.
> >
> > John Mullen
> >
> >
>
>
>
--Boundary-=_SOkbTPnpIXteZlOAcMxqaACygvDw-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Jun 30 13:06:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06426 for ; Sun, 30 Jun 2002 13:06:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02150; Sun, 30 Jun 2002 12:35:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02121 for ; Sun, 30 Jun 2002 12:35:07 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05731 for ; Sun, 30 Jun 2002 12:34:20 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Sun, 30 Jun 2002 10:35:06 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 30 Jun 02 10:35:07 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 30 Jun 02 10:34:41 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 30 Jun 02 10:34:33 -0700 Message-ID: <001701c22054$460d65a0$390a640a@Transient> From: "Scott C. Lemon" To: References: <3D1D746E.000001.02228@bjapp1> Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Sun, 30 Jun 2002 10:36:22 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C22021.FA96ED80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C22021.FA96ED80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello Hai Wang, I have been thinking about the characteristics that I want in a radio = ... and working with a local company to develop one that might be well = oriented towards MANETs. When you say: > No matter what structure, what algorithm you use, when the number of = nodes increases,=20 > the routing OH or clustering OH will increase steadily(except we use = autonomous region=20 > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just = before that, when=20 > there is some point where the link quality is bad, the OH will choke = the traffic too, make the=20 > performance unacceptable. So, I think that the size limit of a MANET = may depend on=20 > smallest link bandwidth in a network. For hierarchical scheme, the = bandwidth of links=20 > among cluster heads will be of great concern. I have thought about one way to possibly deal with this, although I will = not claim to have thought this through with a lot of detail. What if I were able to use software to alter the output power and = sensitivity of my radio? When I found myself in a situation where I = have too many "peers" or the cluster size is getting very large (I am = not sure that this is accurate language as I am still coming up to = speed!) then I would issue software commands to the radio to decrease my = output power, and sensitivity so that I would decrease the radius that I = can effectively communicate. In a sense, what if I could decrease and increase my effective "cell" = size through software? Would that assist in this problem? Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------=_NextPart_000_0014_01C22021.FA96ED80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello Hai = Wang,
 
I have been thinking about the characteristics that I want in a = radio ...=20 and working with a local company to develop one that might be well = oriented=20 towards MANETs.  When you say:
 
> No matter what structure, what algorithm you use, when the = number of=20 nodes increases,
> the routing OH or clustering OH will increase steadily(except = we use=20 autonomous region
> concept in MANET :) ). At last, the OH will eat up the = bandwidth. Just=20 before that, when
> there is some point where the link quality is bad, the OH will = choke=20 the traffic too, make the
> performance unacceptable. So, I think that the size limit of a = MANET=20 may depend on
> smallest link bandwidth in a network. For hierarchical scheme, = the=20 bandwidth of links
> among cluster heads will be of great concern.
 
I have thought about one way to possibly deal with this, although I = will=20 not claim to have thought this through with a lot of detail.
 
What if I were able to use software to alter the output power and=20 sensitivity of my radio?  When I found myself in a situation = where I=20 have too many "peers" or the cluster size is getting very large (I am = not sure=20 that this is accurate language as I am still coming up to speed!) then I = would=20 issue software commands to the radio to decrease my output power, and=20 sensitivity so that I would decrease the radius that I can effectively=20 communicate.
 
In a sense, what if I could decrease and increase my effective = "cell" size=20 through software?  Would that assist in this problem?
 

Scott C. Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com<= BR>http://the.Inevitable.Org/anism<= /A>
 
   "People often talk about it being the journey, not the = destination.
        Consider the=20 possibility that there is no destination=20 ...
           =         =20 that in life there is only = journey!"
------=_NextPart_000_0014_01C22021.FA96ED80-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Jun 30 13:06:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06434 for ; Sun, 30 Jun 2002 13:06:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03601 for manet-archive@odin.ietf.org; Sun, 30 Jun 2002 13:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02150; Sun, 30 Jun 2002 12:35:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02121 for ; Sun, 30 Jun 2002 12:35:07 -0400 (EDT) Received: from villinski.com ([63.230.21.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05731 for ; Sun, 30 Jun 2002 12:34:20 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Sun, 30 Jun 2002 10:35:06 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 30 Jun 02 10:35:07 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 30 Jun 02 10:34:41 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 30 Jun 02 10:34:33 -0700 Message-ID: <001701c22054$460d65a0$390a640a@Transient> From: "Scott C. Lemon" To: References: <3D1D746E.000001.02228@bjapp1> Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Sun, 30 Jun 2002 10:36:22 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C22021.FA96ED80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C22021.FA96ED80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello Hai Wang, I have been thinking about the characteristics that I want in a radio = ... and working with a local company to develop one that might be well = oriented towards MANETs. When you say: > No matter what structure, what algorithm you use, when the number of = nodes increases,=20 > the routing OH or clustering OH will increase steadily(except we use = autonomous region=20 > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just = before that, when=20 > there is some point where the link quality is bad, the OH will choke = the traffic too, make the=20 > performance unacceptable. So, I think that the size limit of a MANET = may depend on=20 > smallest link bandwidth in a network. For hierarchical scheme, the = bandwidth of links=20 > among cluster heads will be of great concern. I have thought about one way to possibly deal with this, although I will = not claim to have thought this through with a lot of detail. What if I were able to use software to alter the output power and = sensitivity of my radio? When I found myself in a situation where I = have too many "peers" or the cluster size is getting very large (I am = not sure that this is accurate language as I am still coming up to = speed!) then I would issue software commands to the radio to decrease my = output power, and sensitivity so that I would decrease the radius that I = can effectively communicate. In a sense, what if I could decrease and increase my effective "cell" = size through software? Would that assist in this problem? Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------=_NextPart_000_0014_01C22021.FA96ED80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello Hai = Wang,
 
I have been thinking about the characteristics that I want in a = radio ...=20 and working with a local company to develop one that might be well = oriented=20 towards MANETs.  When you say:
 
> No matter what structure, what algorithm you use, when the = number of=20 nodes increases,
> the routing OH or clustering OH will increase steadily(except = we use=20 autonomous region
> concept in MANET :) ). At last, the OH will eat up the = bandwidth. Just=20 before that, when
> there is some point where the link quality is bad, the OH will = choke=20 the traffic too, make the
> performance unacceptable. So, I think that the size limit of a = MANET=20 may depend on
> smallest link bandwidth in a network. For hierarchical scheme, = the=20 bandwidth of links
> among cluster heads will be of great concern.
 
I have thought about one way to possibly deal with this, although I = will=20 not claim to have thought this through with a lot of detail.
 
What if I were able to use software to alter the output power and=20 sensitivity of my radio?  When I found myself in a situation = where I=20 have too many "peers" or the cluster size is getting very large (I am = not sure=20 that this is accurate language as I am still coming up to speed!) then I = would=20 issue software commands to the radio to decrease my output power, and=20 sensitivity so that I would decrease the radius that I can effectively=20 communicate.
 
In a sense, what if I could decrease and increase my effective = "cell" size=20 through software?  Would that assist in this problem?
 

Scott C. Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com<= BR>http://the.Inevitable.Org/anism<= /A>
 
   "People often talk about it being the journey, not the = destination.
        Consider the=20 possibility that there is no destination=20 ...
           =         =20 that in life there is only = journey!"
------=_NextPart_000_0014_01C22021.FA96ED80-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Jun 30 15:50:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09995 for ; Sun, 30 Jun 2002 15:50:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08193; Sun, 30 Jun 2002 15:27:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08162 for ; Sun, 30 Jun 2002 15:27:15 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09581 for ; Sun, 30 Jun 2002 15:26:28 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id OAA32168 for manet@ietf.org; Sun, 30 Jun 2002 14:26:39 -0500 Date: Sun, 30 Jun 2002 14:26:38 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Message-ID: <20020630142638.A31696@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001701c22054$460d65a0$390a640a@Transient>; from Scott.Lemon@humanxtensions.com on Sun, Jun 30, 2002 at 10:36:22AM -0600 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Scott, Power adjustments are definitely useful in a MANET. It is an interesting problem to choose the power level that keeps the network connected, that reduces the relaying burden, and that reduces interference. Some researchers are studying this. P.R. Kumar at UIUC has looked at the problem. You will find a paper on the topic at black.csl.uiuc.edu/~prkumar/postscript_files.html#Wireless%20Networks I do not know any 802.11 radio that supports per-packet power level adjustments, but there are a few with "master" TX power controls. Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power levels in the Prism chipset, too, are adjustable, but it is not known yet the mapping between register values and levels. Dave On Sun, Jun 30, 2002 at 10:36:22AM -0600, Scott C. Lemon wrote: > Hello Hai Wang, > > I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > > > No matter what structure, what algorithm you use, when the number of nodes increases, > > the routing OH or clustering OH will increase steadily(except we use autonomous region > > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > > there is some point where the link quality is bad, the OH will choke the traffic too, make the > > performance unacceptable. So, I think that the size limit of a MANET may depend on > > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > > among cluster heads will be of great concern. > > I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. > > What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. > > In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Jun 30 15:50:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10001 for ; Sun, 30 Jun 2002 15:50:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09522 for manet-archive@odin.ietf.org; Sun, 30 Jun 2002 15:51:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08193; Sun, 30 Jun 2002 15:27:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08162 for ; Sun, 30 Jun 2002 15:27:15 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09581 for ; Sun, 30 Jun 2002 15:26:28 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id OAA32168 for manet@ietf.org; Sun, 30 Jun 2002 14:26:39 -0500 Date: Sun, 30 Jun 2002 14:26:38 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Message-ID: <20020630142638.A31696@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001701c22054$460d65a0$390a640a@Transient>; from Scott.Lemon@humanxtensions.com on Sun, Jun 30, 2002 at 10:36:22AM -0600 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Scott, Power adjustments are definitely useful in a MANET. It is an interesting problem to choose the power level that keeps the network connected, that reduces the relaying burden, and that reduces interference. Some researchers are studying this. P.R. Kumar at UIUC has looked at the problem. You will find a paper on the topic at black.csl.uiuc.edu/~prkumar/postscript_files.html#Wireless%20Networks I do not know any 802.11 radio that supports per-packet power level adjustments, but there are a few with "master" TX power controls. Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power levels in the Prism chipset, too, are adjustable, but it is not known yet the mapping between register values and levels. Dave On Sun, Jun 30, 2002 at 10:36:22AM -0600, Scott C. Lemon wrote: > Hello Hai Wang, > > I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > > > No matter what structure, what algorithm you use, when the number of nodes increases, > > the routing OH or clustering OH will increase steadily(except we use autonomous region > > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > > there is some point where the link quality is bad, the OH will choke the traffic too, make the > > performance unacceptable. So, I think that the size limit of a MANET may depend on > > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > > among cluster heads will be of great concern. > > I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. > > What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. > > In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Jun 30 18:02:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12690 for ; Sun, 30 Jun 2002 18:02:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13913; Sun, 30 Jun 2002 17:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13884 for ; Sun, 30 Jun 2002 17:40:28 -0400 (EDT) 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 RAA12230 for ; Sun, 30 Jun 2002 17:39:40 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with SMTP id RAA24246 for ; Sun, 30 Jun 2002 17:39:55 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (NAVGW 2.5.2.11) with SMTP id M2002063017395621000 ; Sun, 30 Jun 2002 17:39:56 -0400 Message-Id: <5.0.1.4.2.20020630174623.01a49738@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 30 Jun 2002 17:48:58 -0400 To: "Adam J Schuhmacher" From: Joe Macker Cc: manet@ietf.org In-Reply-To: <86256BE6.006EE49E.00@smtp.advancedgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Re: MANET Assistance Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is VERY INAPPROPRIATE USE OF AN IETF MAILING LIST >At 03:02 PM 6/28/2002 -0500, you wrote: >Members of IETF and MANET, > >My company has been tasked by a Department of Defense contractor to identify a >Senior Systems Architect well versed in MANET technology to run the cradle to >grave development of the Next Generation Hand-Held Radio for the U.S. Military. >My hope is that many of the members of the IETF and MANET would be very >enthusiastic about this project as it will be one the biggest concrete >implementations of this technology. Please find the formal job description >attached below. Thank you so much for you time and attention. > >Regards, > >Adam Schuhmacher >Advanced Resources >847-466-7817 > >(See attached file: SYS Arch.doc) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Jun 30 18:02:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12698 for ; Sun, 30 Jun 2002 18:02:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15168 for manet-archive@odin.ietf.org; Sun, 30 Jun 2002 18:03:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13913; Sun, 30 Jun 2002 17:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13884 for ; Sun, 30 Jun 2002 17:40:28 -0400 (EDT) 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 RAA12230 for ; Sun, 30 Jun 2002 17:39:40 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with SMTP id RAA24246 for ; Sun, 30 Jun 2002 17:39:55 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (NAVGW 2.5.2.11) with SMTP id M2002063017395621000 ; Sun, 30 Jun 2002 17:39:56 -0400 Message-Id: <5.0.1.4.2.20020630174623.01a49738@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sun, 30 Jun 2002 17:48:58 -0400 To: "Adam J Schuhmacher" From: Joe Macker Cc: manet@ietf.org In-Reply-To: <86256BE6.006EE49E.00@smtp.advancedgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Re: MANET Assistance Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is VERY INAPPROPRIATE USE OF AN IETF MAILING LIST >At 03:02 PM 6/28/2002 -0500, you wrote: >Members of IETF and MANET, > >My company has been tasked by a Department of Defense contractor to identify a >Senior Systems Architect well versed in MANET technology to run the cradle to >grave development of the Next Generation Hand-Held Radio for the U.S. Military. >My hope is that many of the members of the IETF and MANET would be very >enthusiastic about this project as it will be one the biggest concrete >implementations of this technology. Please find the formal job description >attached below. Thank you so much for you time and attention. > >Regards, > >Adam Schuhmacher >Advanced Resources >847-466-7817 > >(See attached file: SYS Arch.doc) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet