From mailnull@www1.ietf.org Tue Apr 1 01:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15109 for ; Tue, 1 Apr 2003 01:57:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h317Kom02920 for manet-archive@odin.ietf.org; Tue, 1 Apr 2003 02:20:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317KnK02917 for ; Tue, 1 Apr 2003 02:20:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15105 for ; Tue, 1 Apr 2003 01:56:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h316qkK22819; Tue, 1 Apr 2003 01:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h316m6K22702 for ; Tue, 1 Apr 2003 01:48:06 -0500 Received: from cs.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14697 for ; Tue, 1 Apr 2003 01:23:59 -0500 (EST) Received: from ix.cs.uoregon.edu (manoj@ix.cs.uoregon.edu [128.223.4.21]) by cs.uoregon.edu (8.12.8/8.12.8) with ESMTP id h316QOg0016108; Mon, 31 Mar 2003 22:26:24 -0800 (PST) Date: Mon, 31 Mar 2003 22:26:24 -0800 (PST) From: Manoj K Pandey To: Siddharth Ray cc: Subject: Re: [manet] Simulating in Glomosim In-Reply-To: <20030401040541.25535.qmail@web20109.mail.yahoo.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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , hi Siddharth, you might want to modify the routing protocol where you want to do the implementation. Glomosim already has some [both unicast/multicast] of them in network directory. you could also build a generic crdit based system and put it in the network.pc file located in the same directory. The protocol being used could call these functions and update their credits. If you have some more specific questions, plz. let me know, I would try my best to be of help!! -manoj ****************************** Manoj Pandey, PhD student, #226, Deschutes, Computer and Information Science, University of Oregon, Phone# 541-346-1381 [Office], www.cs.uoregon.edu/~manoj ****************************** On Mon, 31 Mar 2003, Siddharth Ray wrote: > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > I am implementing "Mitigating routing misbehavior in > mobile ad hoc networks" using Glomosim. I am having > doubts regarding how to use glomosim i.e., how to > implement a credit based system which I plan to use in > the code i.e., which part of the code to change. > Altough I am having many ideas but am having trouble > with the simulator. I would really appreciate any > help... > Siddharth Ray > > ===== > "Keep me away from the wisdom which does not cry, the philosophy which does not laugh and the greatness which > does not bow before children." > - Kahlil Gibran > > MS, Department of Computer Sc. & Engg, > Pond Lab, State College, > PA - 16802, USA. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://platinum.yahoo.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 mailnull@www1.ietf.org Tue Apr 1 10:40:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21175 for ; Tue, 1 Apr 2003 10:40:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31G4a509815 for manet-archive@odin.ietf.org; Tue, 1 Apr 2003 11:04:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G4aK09812 for ; Tue, 1 Apr 2003 11:04:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21156 for ; Tue, 1 Apr 2003 10:40:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FkIK04839; Tue, 1 Apr 2003 10:46:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FcMK02107 for ; Tue, 1 Apr 2003 10:38:22 -0500 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18421 for ; Tue, 1 Apr 2003 10:14:04 -0500 (EST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h31FGSe29398; Tue, 1 Apr 2003 17:16:28 +0200 (MEST) Message-ID: <3E89AD4C.828CD987@inrialpes.fr> Date: Tue, 01 Apr 2003 17:16:28 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org CC: claude.castelluccia@inrialpes.fr Content-Type: multipart/alternative; boundary="------------1FCED884B7B948D193F69DC5" Subject: [manet] -HB-DSR- Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------1FCED884B7B948D193F69DC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, I have just published a new technical report that describes Hash-Based DSR. Hash-Based DSR is an extension of the DSR protocol that reduces the per-packet control overhead of DSR by compressing the source-route with a Bloom filter. Simulations on large networks show that HB-DSR increases the network capacity by a factor of up to 15. Another important property of HB-DSR is that, as opposed to DSR, its performance is similar for IPv4 and IPv6. While IPv6 large addresses is a show-stopper for DSR, we show by simulations that HB-DSR performs as well for both IP versions. This is important contribution considering the growing interest of the wireless network community for IPv6. The report can be retrieved at the following address: http://www.inrialpes.fr/people/ccastel/RT4784.ps I'd like very much to get your feedbacks/comments on this proposal. regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------1FCED884B7B948D193F69DC5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

I have just published a new technical report that describes Hash-Based DSR.
Hash-Based DSR is an extension of the DSR protocol that reduces the per-packet
control overhead of DSR by compressing the source-route with a Bloom filter.
Simulations on large networks show that  HB-DSR increases the network capacity
by a factor of up to 15.

Another important property of HB-DSR is that, as opposed to DSR,
its performance is similar for IPv4 and IPv6. While IPv6 large addresses is a
 show-stopper for DSR, we show by simulations that HB-DSR performs as well for both IP
versions. This is important contribution considering the growing interest
of the wireless network community for IPv6.

The report can be retrieved at the following address: http://www.inrialpes.fr/people/ccastel/RT4784.ps
I'd like very much to get your feedbacks/comments on this proposal.

regards,
Claude.
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------1FCED884B7B948D193F69DC5-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 1 11:14:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25396 for ; Tue, 1 Apr 2003 11:14:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31GcNY25877 for manet-archive@odin.ietf.org; Tue, 1 Apr 2003 11:38:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GcMK25874 for ; Tue, 1 Apr 2003 11:38:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25355 for ; Tue, 1 Apr 2003 11:14:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GIUK15746; Tue, 1 Apr 2003 11:18:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GBpK13963 for ; Tue, 1 Apr 2003 11:11:51 -0500 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22289 for ; Tue, 1 Apr 2003 10:47:31 -0500 (EST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h31Fnte01193; Tue, 1 Apr 2003 17:49:55 +0200 (MEST) Message-ID: <3E89B523.FD87EFF6@inrialpes.fr> Date: Tue, 01 Apr 2003 17:49:55 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org, claude.castelluccia@inrialpes.fr CC: einar.vollset@ncl.ac.uk References: <3E89AD4C.828CD987@inrialpes.fr> Content-Type: multipart/alternative; boundary="------------A08879EED3BA7923F0899D64" Subject: [manet] Re: -HB-DSR- Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------A08879EED3BA7923F0899D64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit me-again, oups, the url is my previous email was wrong. The correct one is http://www.inrialpes.fr/planete/people/ccastel/RT4784.ps sorry about that, Claude. Claude Castelluccia wrote: > Dear all, > > I have just published a new technical report that describes Hash-Based > DSR. > Hash-Based DSR is an extension of the DSR protocol that reduces the > per-packet > control overhead of DSR by compressing the source-route with a Bloom > filter. > Simulations on large networks show that HB-DSR increases the network > capacity > by a factor of up to 15. > > Another important property of HB-DSR is that, as opposed to DSR, > its performance is similar for IPv4 and IPv6. While IPv6 large > addresses is a > show-stopper for DSR, we show by simulations that HB-DSR performs as > well for both IP > versions. This is important contribution considering the growing > interest > of the wireless network community for IPv6. > > The report can be retrieved at the following address: > http://www.inrialpes.fr/people/ccastel/RT4784.ps > I'd like very much to get your feedbacks/comments on this proposal. > > regards, > Claude. > > > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > > -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------A08879EED3BA7923F0899D64 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

me-again,

oups, the url is my previous email was wrong. The correct one
is http://www.inrialpes.fr/planete/people/ccastel/RT4784.ps

sorry about that,
Claude.

Claude Castelluccia wrote:

Dear all,

I have just published a new technical report that describes Hash-Based DSR.
Hash-Based DSR is an extension of the DSR protocol that reduces the per-packet
control overhead of DSR by compressing the source-route with a Bloom filter.
Simulations on large networks show that  HB-DSR increases the network capacity
by a factor of up to 15.

Another important property of HB-DSR is that, as opposed to DSR,
its performance is similar for IPv4 and IPv6. While IPv6 large addresses is a
 show-stopper for DSR, we show by simulations that HB-DSR performs as well for both IP
versions. This is important contribution considering the growing interest
of the wireless network community for IPv6.

The report can be retrieved at the following address: http://www.inrialpes.fr/people/ccastel/RT4784.ps
I'd like very much to get your feedbacks/comments on this proposal.

regards,
Claude.
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
 
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------A08879EED3BA7923F0899D64-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 1 16:10:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15216 for ; Tue, 1 Apr 2003 16:10:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31LYMJ20723 for manet-archive@odin.ietf.org; Tue, 1 Apr 2003 16:34:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31LYMK20719 for ; Tue, 1 Apr 2003 16:34:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15211 for ; Tue, 1 Apr 2003 16:09:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KpZK17699; Tue, 1 Apr 2003 15:51:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Kg6K17202 for ; Tue, 1 Apr 2003 15:42:06 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13131 for ; Tue, 1 Apr 2003 15:17:38 -0500 (EST) 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 MAA00653 for ; Tue, 1 Apr 2003 12:20:04 -0800 (PST) Message-Id: <200304012020.MAA00653@pit.erg.sri.com> To: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] ID Progression and WG Input Date: Tue, 01 Apr 2003 12:20:04 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , All, As requested by Joe Macker, here is a list of mods to the TBRPF draft that we plan to make. Since Joe suggested that this week be a WG Last Call period, we would appreciate any additional comments by this Friday. - Reduce discussion of other protocols such as STAR, FTSP, PTSP, and earlier versions of TBRPF. (However, continue to reference papers presenting concepts on which TBRPF is based.) - In Section 8.4.4 (Updating the Reportable Node Set), change the following sentence to make it more precise: "Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j." - In step 8.1 of the procedure Process_Add_Update, change "u" to "v". - In Section 6.1, reverse the order of the flag bits in the TBRPF packet header, so that any extension fields occur in the same order as the corresponding flag bits. - Minor changes will be made to the Security Considerations section. Regards, Richard > All: > > Both TBRPF and OLSR have been posted for a few weeks, but as WG chair I feel a little more review time is needed. AODV and DSR both went through previous WG Last Call processes. I know some people have r eviewed the recent iterations and some others are in progress on reviewing them. Already, it was reported, that WG review input was received and collected by the OLSR authors (TBR PF may have received input as well?). Also, if the authors post a short summary of any in tended mods it may save on redundant commentary. I am suggesting that next week be a WG L ast Call period (ending on 1200 EST April 4, next Friday) for WG input prior to submission revision and consideration for both of these documents. It was indicated in San Francisc o that authors of these two IDs could commit to a short turnaround and I would like to tar get April 10 for submission consideration with any revisions. > > Authors please make sure you go over and check the ID author nits prior to any final rev isions.. > > http://www.ietf.org/ID-nits.html > > Although EXPERIMENTAL status may be more lenient on technical content nits,etc.. Specifi c ones to note: > > (1) Security Considerations Section....(something meaningful said about issues/risks..po ssible solutions)..AODV got through this so you may want to review any final statements wi th the authors since there are some risk similarities among most of the protocols. > > (2) Specific IPR claims and terms must not be in RFC (but should be on IPR web page) I t hink we are good here for all three documents with all present revisions I looked at. > > (3) IANA Considerations if needed ... > > -joe > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 2 01:14:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01037 for ; Wed, 2 Apr 2003 01:14:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h326cU327087 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 01:38:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326cTK27084 for ; Wed, 2 Apr 2003 01:38:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01032 for ; Wed, 2 Apr 2003 01:13:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326HDK25342; Wed, 2 Apr 2003 01:17:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3264uK24195 for ; Wed, 2 Apr 2003 01:04:56 -0500 Received: from tomts22-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00486 for ; Wed, 2 Apr 2003 00:40:19 -0500 (EST) Received: from yahoo.com ([65.93.187.64]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030402054247.BBXU25567.tomts22-srv.bellnexxia.net@yahoo.com>; Wed, 2 Apr 2003 00:42:47 -0500 Date: Wed, 2 Apr 2003 00:42:46 -0500 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: S Woodside To: fn-tech@freenetworks.org, manet@ietf.org, wireless@lists.bawug.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [manet] I have a dream Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, it's a fairly minor dream. What I imagine is this: I have DSL. My neighbour has DSL. We also both have WiFi APs that can reach each other, and connect at order-of-magnitude faster than the DSL links. What I dream is this: That we start routing internet across the link. When I start pulling packets off the internet, they can come to me not only through my own DSL but from hers as well. I think this boils down to an ultimate simplicity what all FN / CWNers want to achieve. What needs to happen before I can realize my dream. I need to get an IPv6 address ... at least one ... for free. I need to be able to set up multi-homing in my home router. I need to be able to advertise my routing path to the internet. The internet needs to be able to handle at a massive scale (since every neighbour connects...). We need a /lot/ more IP addresses than we have now. I need to use a /real/ IP address because I can't route internet traffic through a NAT/site-local address. I need to have an ad-hoc routing algorithm that can set up this bridge and route across it really easily (because I'm not a trained network admin). Forget about BGP, AS, etc., we need a way to handle the massive overload of routes at local scale, at a regional scale, at a global scale -- something that will scale gracefully as the internet topology shifts from a tree to a massively connected mesh. Please comment ... tell me what you think. Simon PS I'm cross-posting this to a bunch of lists because I don't know one it belongs on. If you think you know which is best, please tell me! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 02:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12581 for ; Wed, 2 Apr 2003 02:10:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h327YBP09161 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 02:34:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327YBK09158 for ; Wed, 2 Apr 2003 02:34:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12031 for ; Wed, 2 Apr 2003 02:09:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327A8K01759; Wed, 2 Apr 2003 02:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3270fK28091 for ; Wed, 2 Apr 2003 02:00:41 -0500 Received: from marfik.upv.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01353 for ; Wed, 2 Apr 2003 01:36:03 -0500 (EST) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by marfik.upv.es (8.11.6/8.11.6) with ESMTP id h326cQM08849; Wed, 2 Apr 2003 08:38:26 +0200 Received: from smtp2.upv.es (smtp02.cc.upv.es [158.42.249.52]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id h326cmk23313; Wed, 2 Apr 2003 08:38:48 +0200 (METDST) Received: from nao.disca.upv.es (nao.disca.upv.es [158.42.53.70]) by smtp2.upv.es (8.11.4p2/8.11.4) with ESMTP id h326cOx02221; Wed, 2 Apr 2003 08:38:25 +0200 Received: from ieee.org (msanchez.disca.upv.es [158.42.53.17]) by nao.disca.upv.es (Postfix on SuSE eMail Server 2.0) with ESMTP id 2E0401FE8B; Wed, 2 Apr 2003 08:38:04 +0200 (CEST) Message-ID: <3E8A857B.4060900@ieee.org> Date: Wed, 02 Apr 2003 08:38:51 +0200 From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: S Woodside Cc: fn-tech@freenetworks.org, manet@ietf.org, wireless@lists.bawug.org Subject: Re: [manet] I have a dream References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Simon, While you can think datagram throughput can be boosted this way you may be surprised that TCP-based applications will be confused about your setup. TCP flow control is based on a round-trip time (RTT) estimation for each connection. While assuming large variations may happen, connections will work better when RTT does not change a lot (if it does may trigger unneeded retransmissions that will also reduce congestion window and will speed down you data flow). And because switching from IPv4 to IPv6 does not change this phenomena, I'm not sure this approach will be convenient for bulk data transfers. However, it may be convenient for web browsing (as far as you keep on using HTTP/1.0). Just my two cent, Dr. Miguel Sanchez Polytechnic University of Valencia, Spain S Woodside wrote: > Well, it's a fairly minor dream. What I imagine is this: I have DSL. > My neighbour has DSL. We also both have WiFi APs that can reach each > other, and connect at order-of-magnitude faster than the DSL links. > What I dream is this: That we start routing internet across the link. > When I start pulling packets off the internet, they can come to me not > only through my own DSL but from hers as well. I think this boils down > to an ultimate simplicity what all FN / CWNers want to achieve. > > What needs to happen before I can realize my dream. I need to get an > IPv6 address ... at least one ... for free. I need to be able to set > up multi-homing in my home router. I need to be able to advertise my > routing path to the internet. The internet needs to be able to handle > at a massive scale (since every neighbour connects...). We need a > /lot/ more IP addresses than we have now. I need to use a /real/ IP > address because I can't route internet traffic through a > NAT/site-local address. I need to have an ad-hoc routing algorithm > that can set up this bridge and route across it really easily (because > I'm not a trained network admin). Forget about BGP, AS, etc., we need > a way to handle the massive overload of routes at local scale, at a > regional scale, at a global scale -- something that will scale > gracefully as the internet topology shifts from a tree to a massively > connected mesh. > > Please comment ... tell me what you think. > > Simon > > PS I'm cross-posting this to a bunch of lists because I don't know one > it belongs on. If you think you know which is best, please tell me! > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 2 02:21:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20049 for ; Wed, 2 Apr 2003 02:21:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h327jhV10677 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 02:45:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327jhK10674 for ; Wed, 2 Apr 2003 02:45:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19482 for ; Wed, 2 Apr 2003 02:21:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327TSK08537; Wed, 2 Apr 2003 02:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327JAK07603 for ; Wed, 2 Apr 2003 02:19:10 -0500 Received: from copland.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02029 for ; Wed, 2 Apr 2003 01:54:33 -0500 (EST) Received: from udel.edu (host75-11.student.udel.edu [128.175.75.11]) by copland.udel.edu (8.12.9/8.12.9) with ESMTP id h326v0Mv022104; Wed, 2 Apr 2003 01:57:00 -0500 (EST) Message-ID: <3E8A89C8.7090201@udel.edu> Date: Wed, 02 Apr 2003 01:57:12 -0500 From: Chavalit Srisathapornphat Reply-To: srisatha@cis.udel.edu Organization: CIS UD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, th MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 NOSPAM_INC,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [manet] AODV RREP Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I setup a mobile ad hoc network simulation using Qualnet consisting of a small number of nodes in a very large terrain. The transmission range is set to 10 km. All nodes are sources of CBR sessions with some of them generate very high volumn of traffic. When I ran the simulation with AODV and varying transmission rate, I encountered the error: AODV: Relaying RREP with ttl > AODV-NET-DIAMETER This only happens in some configuration, especially when the data rate is very low (where contention is extremely high). I found that RREP from intermediate node indicates a large hop count value. Have anyone encountered the same or similar problem (with Qualnet or other simulation tools) when using AODV? Thank you, Chavalit _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 03:04:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00098 for ; Wed, 2 Apr 2003 03:04:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h328SxV14217 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 03:28:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328SxK14214 for ; Wed, 2 Apr 2003 03:28:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00089 for ; Wed, 2 Apr 2003 03:04:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328EsK12963; Wed, 2 Apr 2003 03:14:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3285NK11816 for ; Wed, 2 Apr 2003 03:05:23 -0500 Received: from web12106.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29394 for ; Wed, 2 Apr 2003 02:40:43 -0500 (EST) Message-ID: <20030402074311.11757.qmail@web12106.mail.yahoo.com> Received: from [130.192.9.46] by web12106.mail.yahoo.com via HTTP; Tue, 01 Apr 2003 23:43:11 PST Date: Tue, 1 Apr 2003 23:43:11 -0800 (PST) From: John Home Cortes To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Research extensions available Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi everybody. I'm working on secure routing protocol for Ad Hoc Networks and I have to simulate protocols such as ARAN,SRP, ARIADNE, SAODV and SAR. I had found different network's ad-hoc simulator such as APE o Glomosin. I would like to know which is better or which suports the extensions for this protocols? I currently donwloaded the software Ns-2 and I found there is some development for Ariadne and there is something for Aran with Glomosim, but i need more information. If someone knows something, I would appreciate for your help Thanks in advance.. John Home __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 08:17:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07988 for ; Wed, 2 Apr 2003 08:17:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32DfqW06064 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 08:41:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DfqK06061 for ; Wed, 2 Apr 2003 08:41:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07980 for ; Wed, 2 Apr 2003 08:17:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DScK04410; Wed, 2 Apr 2003 08:28:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DISK03887 for ; Wed, 2 Apr 2003 08:18:28 -0500 Received: from xenia.media.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07385 for ; Wed, 2 Apr 2003 07:53:43 -0500 (EST) From: ankur.j@media.mit.edu Received: from MAP11 ([203.145.171.34]) by xenia.media.mit.edu (8.12.9/8.12.9/XENIA) with ESMTP id h32Cu4M2380810; Wed, 2 Apr 2003 07:56:06 -0500 (EST) Reply-To: To: "'A. Bruce McDonald'" Cc: Subject: RE: [manet] Interlayer Interactions Date: Wed, 2 Apr 2003 18:26:47 -0800 Organization: Media Lab Asia Message-ID: <000201c2f917$3b2268b0$8401a8c0@MAP11> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Bruce for starting the thread again. I fully agree with you that we need to have forward thinking about this. So, let's start discussion on this once again and if the outcome of our discussion will prove that cross-layer interaction is not of great use, we will drop this idea... What are the opinions of other members of manet community? I am sure many people won't like this idea but there are some who will like it.. Regards Ankur -----Original Message----- From: A. Bruce McDonald [mailto:mcdonald@ECE.NEU.EDU] Sent: Tuesday, April 01, 2003 2:08 PM To: ankur.j@media.mit.edu Cc: manet@ietf.org Subject: Re: [manet] Interlayer Interactions Hi All; IMHO the concept of interlayer interaction is not simply a matter of 'ad hoc' communications across a control plane. The idea is much more to the core of understanding the issues involved with the design of ad hoc networks. The example I like to give involves the inherent 'coupling' between the MAC-layer and routing. This is fundamental property in the case of a random access MAC---the problem is that channel contention at the MAC-layer spans multiuple hops; moreover, the *solutions* to problems such as the hidden-terminal actually *cause* a phenomena we refer to as 'path-coupling'. In effect, apparently disjoint paths can experience 'induced-load'; in some situations this is necesssary to prevent collisions, however, there are many scenarios when the induced load is an artifact that prevents a node from transmiting even if the transmission would not cause a collission. This is a concrete example of a more fundamental issue. That is, the question as to whether or not a graph model (time varying, random, or whatever) is an appropriate model for an ad hoc network. Can anyone justify it? Show me links and explain to me how a topological routing algorithm would use knowledge of these link even if it were possible to gather complete accurate global topology information? The concept of a "link" and, hence, the graph model itself is inhernetly flawed. The question is what effect this has on the design of routing algorithms which are themselves based on a graph model? Do they make sense? Perhaps a better model exists, perhaps not. Understanding the nature of the cross-layer interaction could perhaps allow us approximate the ad hoc network using a graph. Just a thought. The essence of my argument is that 'cross-layer interaction' should not be just a buzz word for sharing information between arbitrary layers, or using layer-X information to control some aspect of layer-(X-2). Instead, it should be thought of in terms of the systematic study the how the characteristics, properties and algorithms we associate with layer X affect the performance of all other layers. The outcome of this line of thinking is to enhance our understanding of these complex relationships so that we can then---either build new models and algorithms, or, add an inter-layer control/management plane. It seems likely that both will be required to some extent. However, carving a solid understanding first will lead to more effective and robust solutions in the future. As a community we need to be forward thinking---I know there is a fly or die attitude in some corners that has difficulty with the snail pace. Just turn to the cell phone/PCS industry---the fundamental technical ideas are 30 years old. The reason for the success today is due to advances in DSP technology and chip density. Best regards, Bruce -------------------------------------------------------- A. Bruce McDonald f:617.373.8970 Assistant Prof. v:617.373.3028 ECE Dept., 417 Dana mcdonald@ece.neu.edu 360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald Northeastern University Boston, MA 02115 -------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 10:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14266 for ; Wed, 2 Apr 2003 10:40:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32G4YF18280 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 11:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32G4YK18277 for ; Wed, 2 Apr 2003 11:04:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14261 for ; Wed, 2 Apr 2003 10:39:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FoPK17041; Wed, 2 Apr 2003 10:50:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FchK16359 for ; Wed, 2 Apr 2003 10:38:43 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12916 for ; Wed, 2 Apr 2003 10:13:53 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA01873; Wed, 2 Apr 2003 07:16:21 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id HAA13154; Wed, 2 Apr 2003 07:16:21 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h32FGKO06830; Wed, 2 Apr 2003 07:16:20 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Apr 2003 10:15:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [manet] I have a dream Date: Wed, 2 Apr 2003 10:15:45 -0500 Message-ID: Thread-Topic: [manet] I have a dream Thread-Index: AcL43ZGaGrO6HUbVQOStl2rAOag77wAS1gOA From: "Manfredi, Albert E" To: "S Woodside" , X-OriginalArrivalTime: 02 Apr 2003 15:15:45.0310 (UTC) FILETIME=[BBB773E0:01C2F92A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32FchK16360 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Why can't this dream be realized easily, without any MANET? Your wireless host gets two IP addresses, either NATed or real. One address belongs to your WLAN, connected to your own ADSL link. The other one to your neighbor's. Your host is configured as a router. You either include a static routing table to drive packets through one or the other WLAN based on whatever criteria you come up with, or you let the router function figure out the best route to use, e.g. with ICMP redirects. Alternatively, use a single WLAN for yourself and your neighbor, if within range. Then you have a simple case of a default router and an alternate router, and you can add "route add" commands in your wireless host to force packets on one or the other router, depending on where they are going. Alternatively, tie the two WLANs together into a single link layer, even if using two different frequencies, then proceed as the paragraph above. If the wireless links are only used to connect to fixed APs, there's no MANET needed in this equation at all. Bert > -----Original Message----- > From: S Woodside [mailto:sbwoodside@yahoo.com] > Sent: Wednesday, April 02, 2003 12:43 AM > To: fn-tech@freenetworks.org; manet@ietf.org; wireless@lists.bawug.org > Subject: [manet] I have a dream > > > Well, it's a fairly minor dream. What I imagine is this: I > have DSL. My > neighbour has DSL. We also both have WiFi APs that can reach each > other, and connect at order-of-magnitude faster than the DSL links. > What I dream is this: That we start routing internet across the link. > When I start pulling packets off the internet, they can come > to me not > only through my own DSL but from hers as well. I think this > boils down > to an ultimate simplicity what all FN / CWNers want to achieve. > > What needs to happen before I can realize my dream. I need to get an > IPv6 address ... at least one ... for free. I need to be able > to set up > multi-homing in my home router. I need to be able to advertise my > routing path to the internet. The internet needs to be able to handle > at a massive scale (since every neighbour connects...). We > need a /lot/ > more IP addresses than we have now. I need to use a /real/ IP address > because I can't route internet traffic through a NAT/site-local > address. I need to have an ad-hoc routing algorithm that can set up > this bridge and route across it really easily (because I'm not a > trained network admin). Forget about BGP, AS, etc., we need a way to > handle the massive overload of routes at local scale, at a regional > scale, at a global scale -- something that will scale > gracefully as the > internet topology shifts from a tree to a massively connected mesh. > > Please comment ... tell me what you think. > > Simon > > PS I'm cross-posting this to a bunch of lists because I don't > know one > it belongs on. If you think you know which is best, please tell me! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 13:30:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22136 for ; Wed, 2 Apr 2003 13:30:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32ItBB03003 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 13:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32ItBK03000 for ; Wed, 2 Apr 2003 13:55:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22089 for ; Wed, 2 Apr 2003 13:30:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IcPK01557; Wed, 2 Apr 2003 13:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IWSK00461 for ; Wed, 2 Apr 2003 13:32:28 -0500 Received: from mailhost2.malibunetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21192 for ; Wed, 2 Apr 2003 13:07:36 -0500 (EST) Received: by mailhost2.malibunetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Apr 2003 10:10:02 -0800 Message-ID: <6BA802CE965EBC48A39C558B258EFB93019394@mailhost.malibunetworks.com> From: Ken Peirce To: "'S Woodside'" , fn-tech@freenetworks.org, manet@ietf.org, wireless@lists.bawug.org Subject: RE: [manet] I have a dream Date: Wed, 2 Apr 2003 10:09:35 -0800 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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , You're looking at combining the multiple links into one as far as TCP can tell. This is what Multilink PPP does. Unfortunately, the problem will be the dissimilar link speeds. Packet reordering is evil for TCP and the slow DSL link will not only be the limiting factor but will likely cause the bundle of links to perform like a weak DSL connection. My $.02 Ken -----Original Message----- From: S Woodside [mailto:sbwoodside@yahoo.com] Sent: Tuesday, April 01, 2003 9:43 PM To: fn-tech@freenetworks.org; manet@ietf.org; wireless@lists.bawug.org Subject: [manet] I have a dream Well, it's a fairly minor dream. What I imagine is this: I have DSL. My neighbour has DSL. We also both have WiFi APs that can reach each other, and connect at order-of-magnitude faster than the DSL links. What I dream is this: That we start routing internet across the link. When I start pulling packets off the internet, they can come to me not only through my own DSL but from hers as well. I think this boils down to an ultimate simplicity what all FN / CWNers want to achieve. What needs to happen before I can realize my dream. I need to get an IPv6 address ... at least one ... for free. I need to be able to set up multi-homing in my home router. I need to be able to advertise my routing path to the internet. The internet needs to be able to handle at a massive scale (since every neighbour connects...). We need a /lot/ more IP addresses than we have now. I need to use a /real/ IP address because I can't route internet traffic through a NAT/site-local address. I need to have an ad-hoc routing algorithm that can set up this bridge and route across it really easily (because I'm not a trained network admin). Forget about BGP, AS, etc., we need a way to handle the massive overload of routes at local scale, at a regional scale, at a global scale -- something that will scale gracefully as the internet topology shifts from a tree to a massively connected mesh. Please comment ... tell me what you think. Simon PS I'm cross-posting this to a bunch of lists because I don't know one it belongs on. If you think you know which is best, please tell me! _______________________________________________ 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 mailnull@www1.ietf.org Wed Apr 2 14:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24007 for ; Wed, 2 Apr 2003 14:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32JlMJ08255 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 14:47:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JlMK08246 for ; Wed, 2 Apr 2003 14:47:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23961 for ; Wed, 2 Apr 2003 14:22:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JVVK06142; Wed, 2 Apr 2003 14:31:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JPiK05813 for ; Wed, 2 Apr 2003 14:25:44 -0500 Received: from mm02snlnto.son.sandia.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23184 for ; Wed, 2 Apr 2003 14:00:51 -0500 (EST) Received: from 132.175.109.4 by MM01SNLNTO.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.0)); Wed, 02 Apr 2003 12:03:15 -0600 Received: from es08snlnt.sandia.gov (smtp-in.sandia.gov [134.253.130.11] ) by mailgate2.sandia.gov (8.12.8/8.12.8) with ESMTP id h32J3EU1019497 for ; Wed, 2 Apr 2003 12:03:14 -0700 (MST) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id <2AAHC7V4>; Wed, 2 Apr 2003 12:03:15 -0700 Message-ID: From: "Van Leeuwen, Brian P" To: "'manet@ietf.org'" Date: Wed, 2 Apr 2003 12:03:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1295EC79352831-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, What kind of systems have ad hoc networks been used in to date? I'm aware of the Army's interest in using ad hoc networks in their future systems but has the Army or other organization built any ad hoc network based system? Have any systems, government or commercial, been developed to date that use wireless ad hoc networks? I'm interested in learning what systems, experimental or deployed, have been built and if they published their experience. Any comments or suggestions are welcome. Thanks for your help, Brian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 16:03:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09079 for ; Wed, 2 Apr 2003 16:03:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LSJf18266 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 16:28:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LSJK18263 for ; Wed, 2 Apr 2003 16:28:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09055 for ; Wed, 2 Apr 2003 16:03:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LCEK16987; Wed, 2 Apr 2003 16:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32L78K16088 for ; Wed, 2 Apr 2003 16:07:08 -0500 Received: from tomts26-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08310 for ; Wed, 2 Apr 2003 15:42:13 -0500 (EST) Received: from yahoo.com ([65.93.185.34]) by tomts26-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030402204441.LOJC13343.tomts26-srv.bellnexxia.net@yahoo.com>; Wed, 2 Apr 2003 15:44:41 -0500 Date: Wed, 2 Apr 2003 15:44:43 -0500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , , To: "Jared Valentine" From: S Woodside In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32L79K16103 Subject: [manet] Re: [BAWUG] I have a dream - and it's mostly available today! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit On Wednesday, April 2, 2003, at 12:38 PM, Jared Valentine wrote: > Well, you can get pretty close to this. Check out the Nexland > routers: [...] > They can load balance two separate connections. I don't believe this > works > for a "single" FTP transfer, for example... it works by loadbalancing > separate transfers. Things like surfing, multi-part transfers, etc. > all > happen at 2x the speed. No, it's a different issue from load-balancing. That's only done when the two connections are both controlled by a single entity, usually at both ends. The difference is, that under my situation, we are acting as uncoordinated separate entities both on the internet, with essentially a network border between us. On Wednesday, April 2, 2003, at 01:38 AM, Miguel Sánchez wrote: > While you can think datagram throughput can be boosted this way you may > be surprised that TCP-based applications will be confused about your > setup. > TCP flow control is based on a round-trip time (RTT) estimation for > each > connection. While assuming large variations may happen, connections > will > work better when RTT does not change a lot (if it does may trigger > unneeded retransmissions that will also reduce congestion window and > will speed down you data flow). Well there's actually two different situations, (1) my neighbours uses my ISP, or, (2) my neighbour uses a different ISP. To discount situation 2, it's not a problem at all. In situation 2 we don't need to worry about packet reordering as the routes are going to be completely different and IP will probably choose one or the other for any given TCP connection. The problem if the situation is (1) where IP is probably going to be sending packets down the different paths at random since the routes will be identical. So then you have multi-path problems. But, on the other hand, in this case the two paths are likely to be almost identical so that reordering will be minimal. I don't see a problem, the paths will either be very different or very similar. simon _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 16:14:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09517 for ; Wed, 2 Apr 2003 16:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Lcpg19881 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 16:38:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LcpK19878 for ; Wed, 2 Apr 2003 16:38:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09497 for ; Wed, 2 Apr 2003 16:13:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LM6K17707; Wed, 2 Apr 2003 16:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LI9K17446 for ; Wed, 2 Apr 2003 16:18:09 -0500 Received: from tomts12-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08679 for ; Wed, 2 Apr 2003 15:53:13 -0500 (EST) Received: from yahoo.com ([65.93.185.34]) by tomts12-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030402205542.GLKN20288.tomts12-srv.bellnexxia.net@yahoo.com>; Wed, 2 Apr 2003 15:55:42 -0500 Date: Wed, 2 Apr 2003 15:55:39 -0500 Subject: Re: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'manet@ietf.org'" To: "Van Leeuwen, Brian P" From: S Woodside In-Reply-To: Message-Id: <75F9E1B6-654D-11D7-9A55-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit MeshAP from LocustWorld uses AODV http://www.locustworld.com/ simon On Wednesday, April 2, 2003, at 02:03 PM, Van Leeuwen, Brian P wrote: > Hello, > > What kind of systems have ad hoc networks been used in to date? I'm > aware of > the Army's interest in using ad hoc networks in their future systems > but has > the Army or other organization built any ad hoc network based system? > Have > any systems, government or commercial, been developed to date that use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. > > Any comments or suggestions are welcome. > > Thanks for your help, > > Brian > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > -- anti-spam: do not post this address publicly www.simonwoodside.com -- 99% Devil, 1% Angel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 16:48:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11184 for ; Wed, 2 Apr 2003 16:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32MCYQ23732 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 17:12:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MCXK23729 for ; Wed, 2 Apr 2003 17:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11155 for ; Wed, 2 Apr 2003 16:47:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LuSK21289; Wed, 2 Apr 2003 16:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LqaK20911 for ; Wed, 2 Apr 2003 16:52:36 -0500 Received: from tomts17-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10113 for ; Wed, 2 Apr 2003 16:27:39 -0500 (EST) Received: from yahoo.com ([65.93.185.34]) by tomts17-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030402190919.YDXH2665.tomts17-srv.bellnexxia.net@yahoo.com>; Wed, 2 Apr 2003 14:09:19 -0500 Date: Wed, 2 Apr 2003 14:09:20 -0500 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: fn-tech@freenetworks.org, , , "Tony Hain" To: Joel Jaeggli From: S Woodside In-Reply-To: Message-Id: <9BCB4486-653E-11D7-9A55-000393414368@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [manet] Re: [BAWUG] I have a dream Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, April 2, 2003, at 01:02 AM, Joel Jaeggli wrote: > um... the internet routing architecture didn't explode in 1997 becuase > we'd didn't do this. meshed network edges need an igp, some sanity and > cooperative upstreams, otherwise you'll just have a very large very > messy > subnet with not external routing. Not true at all. With IPv6 there's plenty of ways to solve the problem. This is one: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt It is frequently assumed that any address format that is not based on provider aggregation will degenerate into the 'swamp' that came to describe pre-CIDR IPv4, with the result that the routing table grows unabated. The goal of this scheme is to allow sites to be independent of any provider, while still allowing aggregation for those who do not require explicit global routing policy. As a result, there will need to be consistently applied rules for when a prefix gets aggregated and when it doesn't. These will be discussed in the recommendations section. simon > joelja > > > On Wed, 2 Apr 2003, S Woodside wrote: > >> Well, it's a fairly minor dream. What I imagine is this: I have DSL. >> My >> neighbour has DSL. We also both have WiFi APs that can reach each >> other, and connect at order-of-magnitude faster than the DSL links. >> What I dream is this: That we start routing internet across the link. >> When I start pulling packets off the internet, they can come to me not >> only through my own DSL but from hers as well. I think this boils down >> to an ultimate simplicity what all FN / CWNers want to achieve. >> >> What needs to happen before I can realize my dream. I need to get an >> IPv6 address ... at least one ... for free. I need to be able to set >> up >> multi-homing in my home router. I need to be able to advertise my >> routing path to the internet. The internet needs to be able to handle >> at a massive scale (since every neighbour connects...). We need a >> /lot/ >> more IP addresses than we have now. I need to use a /real/ IP address >> because I can't route internet traffic through a NAT/site-local >> address. I need to have an ad-hoc routing algorithm that can set up >> this bridge and route across it really easily (because I'm not a >> trained network admin). Forget about BGP, AS, etc., we need a way to >> handle the massive overload of routes at local scale, at a regional >> scale, at a global scale -- something that will scale gracefully as >> the >> internet topology shifts from a tree to a massively connected mesh. >> >> Please comment ... tell me what you think. >> >> Simon >> >> PS I'm cross-posting this to a bunch of lists because I don't know one >> it belongs on. If you think you know which is best, please tell me! >> >> -- >> general wireless list, a bawug thing >> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless >> > > -- > ----------------------------------------------------------------------- > --- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E > -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > > > -- > general wireless list, a bawug thing > [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless > > -- anti-spam: do not post this address publicly www.simonwoodside.com -- 99% Devil, 1% Angel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Apr 2 17:07:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11798 for ; Wed, 2 Apr 2003 17:07:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32MVvf24949 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 17:31:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MVvK24946 for ; Wed, 2 Apr 2003 17:31:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11782 for ; Wed, 2 Apr 2003 17:07:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MFEK23864; Wed, 2 Apr 2003 17:15:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32M9HK23554 for ; Wed, 2 Apr 2003 17:09:17 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11097 for ; Wed, 2 Apr 2003 16:44:19 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA14498; Wed, 2 Apr 2003 13:46:47 -0800 (PST) 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-02) with ESMTP id NAA09139; Wed, 2 Apr 2003 13:46:47 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h32Lkjr09459; Wed, 2 Apr 2003 13:46:46 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Apr 2003 16:46:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [manet] Re: [BAWUG] I have a dream Date: Wed, 2 Apr 2003 16:46:40 -0500 Message-ID: Thread-Topic: [manet] Re: [BAWUG] I have a dream Thread-Index: AcL5X/kXIlBBmLtDQKCbJ+nih12aIwAAIPOg From: "Manfredi, Albert E" To: "S Woodside" Cc: X-OriginalArrivalTime: 02 Apr 2003 21:46:40.0269 (UTC) FILETIME=[57F62BD0:01C2F961] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32M9HK23555 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Whether the scheme is geographically-based or provider-based, the important thing is to be able to aggregate routes. MANET does nothing to solve this routing scale problem, in a *global* sense. You still have to tie the MANET to the wired Internet efficiently. Bert > -----Original Message----- > From: S Woodside [mailto:sbwoodside@yahoo.com] > Sent: Wednesday, April 02, 2003 2:09 PM > To: Joel Jaeggli > Cc: fn-tech@freenetworks.org; manet@ietf.org; > wireless@lists.bawug.org; > Tony Hain > Subject: [manet] Re: [BAWUG] I have a dream > > > On Wednesday, April 2, 2003, at 01:02 AM, Joel Jaeggli wrote: > > > um... the internet routing architecture didn't explode in > 1997 becuase > > we'd didn't do this. meshed network edges need an igp, some > sanity and > > cooperative upstreams, otherwise you'll just have a very > large very > > messy > > subnet with not external routing. > > Not true at all. With IPv6 there's plenty of ways to solve > the problem. > This is one: > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt > > It is frequently assumed that any address format > that is not > based > on provider aggregation will degenerate into the > 'swamp' that > came > to describe pre-CIDR IPv4, with the result that the routing > table > grows unabated. The goal of this scheme is to allow > sites to be > independent of any provider, while still allowing > aggregation > for > those who do not require explicit global routing policy. As a > result, there will need to be consistently applied > rules for > when a > prefix gets aggregated and when it doesn't. These will be > discussed > in the recommendations section. > > simon > > > joelja > > > > > > On Wed, 2 Apr 2003, S Woodside wrote: > > > >> Well, it's a fairly minor dream. What I imagine is this: I > have DSL. > >> My > >> neighbour has DSL. We also both have WiFi APs that can reach each > >> other, and connect at order-of-magnitude faster than the DSL links. > >> What I dream is this: That we start routing internet > across the link. > >> When I start pulling packets off the internet, they can > come to me not > >> only through my own DSL but from hers as well. I think > this boils down > >> to an ultimate simplicity what all FN / CWNers want to achieve. > >> > >> What needs to happen before I can realize my dream. I need > to get an > >> IPv6 address ... at least one ... for free. I need to be > able to set > >> up > >> multi-homing in my home router. I need to be able to advertise my > >> routing path to the internet. The internet needs to be > able to handle > >> at a massive scale (since every neighbour connects...). We need a > >> /lot/ > >> more IP addresses than we have now. I need to use a /real/ > IP address > >> because I can't route internet traffic through a NAT/site-local > >> address. I need to have an ad-hoc routing algorithm that can set up > >> this bridge and route across it really easily (because I'm not a > >> trained network admin). Forget about BGP, AS, etc., we > need a way to > >> handle the massive overload of routes at local scale, at a regional > >> scale, at a global scale -- something that will scale > gracefully as > >> the > >> internet topology shifts from a tree to a massively connected mesh. > >> > >> Please comment ... tell me what you think. > >> > >> Simon > >> > >> PS I'm cross-posting this to a bunch of lists because I > don't know one > >> it belongs on. If you think you know which is best, please tell me! > >> > >> -- > >> general wireless list, a bawug thing > >> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless > >> > > > > -- > > > -------------------------------------------------------------- > --------- > > --- > > Joel Jaeggli Academic User Services > joelja@darkwing.uoregon.edu > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 > A30D 121E > > -- > > In Dr. Johnson's famous dictionary patriotism is defined > as the last > > resort of the scoundrel. With all due respect to an > enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > > > > > -- > > general wireless list, a bawug thing > > [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless > > > > > -- > anti-spam: do not post this address publicly > www.simonwoodside.com -- 99% Devil, 1% Angel > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 2 18:02:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14364 for ; Wed, 2 Apr 2003 18:02:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32NQsL30382 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 18:26:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NQoK30379 for ; Wed, 2 Apr 2003 18:26:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14336 for ; Wed, 2 Apr 2003 18:01:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NB1K29013; Wed, 2 Apr 2003 18:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32N50K27591 for ; Wed, 2 Apr 2003 18:05:00 -0500 Received: from memphis.ece.cornell.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12754 for ; Wed, 2 Apr 2003 17:40:04 -0500 (EST) From: haas@ece.cornell.edu Received: from verdi.ece.cornell.edu (verdi.ece.cornell.edu [128.84.210.27]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h32MgMm17651; Wed, 2 Apr 2003 17:42:29 -0500 Date: Wed, 2 Apr 2003 17:41:26 -0500 (EST) To: "Van Leeuwen, Brian P" cc: "'manet@ietf.org'" , Zygmunt Haas Subject: Re: [manet] Ad Hoc Networks Implemented in Deployed Systems?? In-Reply-To: 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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Brian, MobileRoute(TM) from Scientific Research Corporation, which is based on ZRP. See: http://www.scires.com/mobileroute.htm and their white paper: http://www.scires.com/pdfs/mr-wp.pdf Zygmunt. ===--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Wed, 2 Apr 2003, Van Leeuwen, Brian P wrote: > Hello, > > What kind of systems have ad hoc networks been used in to date? I'm aware of > the Army's interest in using ad hoc networks in their future systems but has > the Army or other organization built any ad hoc network based system? Have > any systems, government or commercial, been developed to date that use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. > > Any comments or suggestions are welcome. > > Thanks for your help, > > Brian > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 2 19:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18100 for ; Wed, 2 Apr 2003 19:04:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3306ko02664 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 19:06:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3306kK02660 for ; Wed, 2 Apr 2003 19:06:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18090 for ; Wed, 2 Apr 2003 19:04:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NpCK01844; Wed, 2 Apr 2003 18:51:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NjdK01657 for ; Wed, 2 Apr 2003 18:45:39 -0500 Received: from exstudent9.city.unisa.edu.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16147 for ; Wed, 2 Apr 2003 18:43:08 -0500 (EST) Received: by exstudent9.city.unisa.edu.au with Internet Mail Service (5.5.2656.59) id <21MDJ507>; Thu, 3 Apr 2003 09:15:30 +0930 Message-ID: From: "Liaw, Yong Shyang - LIAYS001" To: "'ankur.j@media.mit.edu'" , "'A. Bruce McDonald'" Cc: manet@ietf.org Subject: RE: [manet] Interlayer Interactions Date: Thu, 3 Apr 2003 09:16:55 +0930 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, I agree that cross-layer interaction needs more study than already done. The death of L2-trigger at IETF does not mean it is end of this topic -- in fact, it is being discussed in some other WGs. Cross-layer interaction will likely to prove useful in MANET, where link layer information may be used for selecting routes. I also think that cross-layer interaction between protocols needs more study as well, as there are few studies done. > -----Original Message----- > From: ankur.j@media.mit.edu [mailto:ankur.j@media.mit.edu] > Sent: Thursday, 3 April 2003 11:57 > To: 'A. Bruce McDonald' > Cc: manet@ietf.org > Subject: RE: [manet] Interlayer Interactions > > > Thanks Bruce for starting the thread again. > > I fully agree with you that we need to have forward thinking > about this. > > > So, let's start discussion on this once again and if the > outcome of our > discussion will prove that cross-layer interaction is not of > great use, > we will drop this idea... > > What are the opinions of other members of manet community? I am sure > many people won't like this idea but there are some who will like it.. > > Regards > Ankur > > > > -----Original Message----- > From: A. Bruce McDonald [mailto:mcdonald@ECE.NEU.EDU] > Sent: Tuesday, April 01, 2003 2:08 PM > To: ankur.j@media.mit.edu > Cc: manet@ietf.org > Subject: Re: [manet] Interlayer Interactions > > > Hi All; > > IMHO the concept of interlayer interaction is not simply a > matter of 'ad > hoc' communications across a control plane. The idea is much > more to the > core of understanding the issues involved with the design of ad hoc > networks. The example I like to give involves the inherent 'coupling' > between the MAC-layer and routing. This is fundamental property in the > case of a random access MAC---the problem is that channel > contention at > the MAC-layer spans multiuple hops; moreover, the *solutions* to > problems > such as the hidden-terminal actually *cause* a phenomena we > refer to as > 'path-coupling'. In effect, apparently disjoint paths can experience > 'induced-load'; in some situations this is necesssary to prevent > collisions, however, there are many scenarios when the induced load is > an > artifact that prevents a node from transmiting even if the > transmission > would not cause a collission. > > This is a concrete example of a more > fundamental issue. That is, the question as to whether or not a graph > model (time varying, random, or whatever) is an appropriate > model for an > ad hoc network. Can anyone justify it? Show me links and > explain to me > how a topological routing algorithm would use knowledge of these link > even > if it were possible to gather complete accurate global topology > information? The concept of a "link" and, hence, the graph > model itself > is inhernetly flawed. The question is what effect this has on the > design > of routing algorithms which are themselves based on a graph model? Do > they make sense? Perhaps a better model exists, perhaps not. > Understanding the nature of the cross-layer interaction could perhaps > allow us approximate the ad hoc network using a graph. Just a thought. > > The essence of my argument is that 'cross-layer interaction' > should not > be > just a buzz word for sharing information between arbitrary layers, or > using layer-X information to control some aspect of layer-(X-2). > Instead, > it should be thought of in terms of the systematic study the how the > characteristics, properties and algorithms we associate with layer X > affect the performance of all other layers. The outcome of > this line of > thinking is to enhance our understanding of these complex > relationships > so > that we can then---either build new models and algorithms, or, add an > inter-layer control/management plane. It seems likely that > both will be > required to some extent. However, carving a solid understanding first > will > lead to more effective and robust solutions in the future. > > As a community > we need to be forward thinking---I know there is a fly or die attitude > in > some corners that has difficulty with the snail pace. Just turn to the > cell phone/PCS industry---the fundamental technical ideas are 30 years > old. The reason for the success today is due to advances in DSP > technology > and chip density. > > Best regards, > > Bruce > > -------------------------------------------------------- > A. Bruce McDonald f:617.373.8970 > Assistant Prof. v:617.373.3028 > ECE Dept., 417 Dana mcdonald@ece.neu.edu > 360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald > Northeastern University > Boston, MA 02115 > -------------------------------------------------------- > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 2 21:15:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21326 for ; Wed, 2 Apr 2003 21:15:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h332HF313133 for manet-archive@odin.ietf.org; Wed, 2 Apr 2003 21:17:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h332HFK13130 for ; Wed, 2 Apr 2003 21:17:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21323 for ; Wed, 2 Apr 2003 21:14:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3320nK11596; Wed, 2 Apr 2003 21:00:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h331uZK11435 for ; Wed, 2 Apr 2003 20:56:35 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20923 for ; Wed, 2 Apr 2003 20:54:01 -0500 (EST) From: Leping.Huang@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h3320S522290 for ; Thu, 3 Apr 2003 05:00:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 04:56:29 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 04:56:27 +0300 Received: from toebe001.NOE.Nokia.com ([172.24.109.35]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 04:56:27 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [manet] Interlayer Interactions Date: Thu, 3 Apr 2003 10:56:20 +0900 Message-ID: Thread-Topic: [manet] Interlayer Interactions Thread-Index: AcL5dGRX3PtLYs2tR/aaE9EV4ZF5OgAC4LiQ To: , , Cc: X-OriginalArrivalTime: 03 Apr 2003 01:56:27.0559 (UTC) FILETIME=[3D152370:01C2F984] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h331uZK11436 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Here is another paper regarding to the cross-layer interaction. CHEN, K., S. H. SHAH, et al. (2002). Cross-Layer Design for Data Accessibility in Mobile Ad Hoc Networks. Wireless Personal Communications 21, Kluwer Academic Publishers. One of my feeling from that paper is that QoS is obviously a cross-layer concept, we need to translate the user QoS to network layer QoS, then to link layer QoS. So the cross-layer design can be widely accepted. But routing is generally a OSI layer 3 issues, most of the people do not want to violate this rule. BTW, can anyone tell me what is penalty we need to pay if we violate the Layer 2 and layer3 barrier? Yours Leping -----Original Message----- From: ext Liaw, Yong Shyang - LIAYS001 [mailto:Yong.Liaw@postgrads.unisa.edu.au] Sent: Thursday, April 03, 2003 8:47 AM To: 'ankur.j@media.mit.edu'; 'A. Bruce McDonald' Cc: manet@ietf.org Subject: RE: [manet] Interlayer Interactions Hi, I agree that cross-layer interaction needs more study than already done. The death of L2-trigger at IETF does not mean it is end of this topic -- in fact, it is being discussed in some other WGs. Cross-layer interaction will likely to prove useful in MANET, where link layer information may be used for selecting routes. I also think that cross-layer interaction between protocols needs more study as well, as there are few studies done. > -----Original Message----- > From: ankur.j@media.mit.edu [mailto:ankur.j@media.mit.edu] > Sent: Thursday, 3 April 2003 11:57 > To: 'A. Bruce McDonald' > Cc: manet@ietf.org > Subject: RE: [manet] Interlayer Interactions > > > Thanks Bruce for starting the thread again. > > I fully agree with you that we need to have forward thinking > about this. > > > So, let's start discussion on this once again and if the > outcome of our > discussion will prove that cross-layer interaction is not of > great use, > we will drop this idea... > > What are the opinions of other members of manet community? I am sure > many people won't like this idea but there are some who will like it.. > > Regards > Ankur > > > > -----Original Message----- > From: A. Bruce McDonald [mailto:mcdonald@ECE.NEU.EDU] > Sent: Tuesday, April 01, 2003 2:08 PM > To: ankur.j@media.mit.edu > Cc: manet@ietf.org > Subject: Re: [manet] Interlayer Interactions > > > Hi All; > > IMHO the concept of interlayer interaction is not simply a > matter of 'ad > hoc' communications across a control plane. The idea is much > more to the > core of understanding the issues involved with the design of ad hoc > networks. The example I like to give involves the inherent 'coupling' > between the MAC-layer and routing. This is fundamental property in the > case of a random access MAC---the problem is that channel > contention at > the MAC-layer spans multiuple hops; moreover, the *solutions* to > problems > such as the hidden-terminal actually *cause* a phenomena we > refer to as > 'path-coupling'. In effect, apparently disjoint paths can experience > 'induced-load'; in some situations this is necesssary to prevent > collisions, however, there are many scenarios when the induced load is > an > artifact that prevents a node from transmiting even if the > transmission > would not cause a collission. > > This is a concrete example of a more > fundamental issue. That is, the question as to whether or not a graph > model (time varying, random, or whatever) is an appropriate > model for an > ad hoc network. Can anyone justify it? Show me links and > explain to me > how a topological routing algorithm would use knowledge of these link > even > if it were possible to gather complete accurate global topology > information? The concept of a "link" and, hence, the graph > model itself > is inhernetly flawed. The question is what effect this has on the > design > of routing algorithms which are themselves based on a graph model? Do > they make sense? Perhaps a better model exists, perhaps not. > Understanding the nature of the cross-layer interaction could perhaps > allow us approximate the ad hoc network using a graph. Just a thought. > > The essence of my argument is that 'cross-layer interaction' > should not > be > just a buzz word for sharing information between arbitrary layers, or > using layer-X information to control some aspect of layer-(X-2). > Instead, > it should be thought of in terms of the systematic study the how the > characteristics, properties and algorithms we associate with layer X > affect the performance of all other layers. The outcome of > this line of > thinking is to enhance our understanding of these complex > relationships > so > that we can then---either build new models and algorithms, or, add an > inter-layer control/management plane. It seems likely that > both will be > required to some extent. However, carving a solid understanding first > will > lead to more effective and robust solutions in the future. > > As a community > we need to be forward thinking---I know there is a fly or die attitude > in > some corners that has difficulty with the snail pace. Just turn to the > cell phone/PCS industry---the fundamental technical ideas are 30 years > old. The reason for the success today is due to advances in DSP > technology > and chip density. > > Best regards, > > Bruce > > -------------------------------------------------------- > A. Bruce McDonald f:617.373.8970 > Assistant Prof. v:617.373.3028 > ECE Dept., 417 Dana mcdonald@ece.neu.edu > 360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald > Northeastern University > Boston, MA 02115 > -------------------------------------------------------- > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Apr 3 03:47:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10391 for ; Thu, 3 Apr 2003 03:47:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h338nXn22133 for manet-archive@odin.ietf.org; Thu, 3 Apr 2003 03:49:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338nXK22130 for ; Thu, 3 Apr 2003 03:49:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10388 for ; Thu, 3 Apr 2003 03:46:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338MhK19681; Thu, 3 Apr 2003 03:22:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h338DfK19352 for ; Thu, 3 Apr 2003 03:13:41 -0500 Received: from mailhub02.unibe.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09769 for ; Thu, 3 Apr 2003 03:10:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mailhub02.unibe.ch (Postfix) with ESMTP id CA6EF76825 for ; Thu, 3 Apr 2003 10:13:24 +0200 (MEST) Received: from mailhub02.unibe.ch ([127.0.0.1]) by localhost (mailhub02 [127.0.0.1:10024]) (amavisd-new) with LMTP id 29125-01-28 for ; Thu, 3 Apr 2003 10:13:24 +0200 (MEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub02.unibe.ch (Postfix) with ESMTP id 437B87681E for ; Thu, 3 Apr 2003 10:13:24 +0200 (MEST) Received: from iam.unibe.ch (kirok [130.92.65.230]) by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h338DOK19524 for ; Thu, 3 Apr 2003 10:13:24 +0200 (MET DST) Message-ID: <3E8BECFB.6030904@iam.unibe.ch> Date: Thu, 03 Apr 2003 10:12:43 +0200 From: =?ISO-8859-1?Q?Marc_Heissenb=FCttel?= Organization: Detp. of CS, University of Bern, Switzerland User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-checked: by University of Berne Content-Transfer-Encoding: 8bit Subject: [manet] Re: Ad Hoc Networks Implemented in Deployed Systems?? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Brian, also have a look at http://www.meshnetworks.com/ and http://www.greenpacket.com/ Regards, Marc > Subject: > [manet] Ad Hoc Networks Implemented in Deployed Systems?? > From: > "Van Leeuwen, Brian P" > Date: > Wed, 2 Apr 2003 12:03:12 -0700 > To: > "'manet@ietf.org'" > > Hello, > > What kind of systems have ad hoc networks been used in to date? I'm aware of > the Army's interest in using ad hoc networks in their future systems but has > the Army or other organization built any ad hoc network based system? Have > any systems, government or commercial, been developed to date that use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. > > Any comments or suggestions are welcome. > > Thanks for your help, > > Brian > > > > -- Marc Heissenbüttel Computer Networks and Distributed Systems Institute of Computer Science and Applied Mathematics University of Bern Neubrückstrasse 10 CH-3012 Bern Switzerland Tel: +41 31 631 86 91 (Direct) Tel: +41 31 631 89 57 (Secretary) Fax: +41 31 631 32 61 Email: heissen@iam.unibe.ch http://www.iam.unibe.ch _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Apr 3 10:35:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25281 for ; Thu, 3 Apr 2003 10:35:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33FbNU25338 for manet-archive@odin.ietf.org; Thu, 3 Apr 2003 10:37:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FbNK25333 for ; Thu, 3 Apr 2003 10:37:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25250 for ; Thu, 3 Apr 2003 10:34:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FEVK23208; Thu, 3 Apr 2003 10:14:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F4VK21872 for ; Thu, 3 Apr 2003 10:04:31 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22317 for ; Thu, 3 Apr 2003 10:01:41 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h33F3wjZ014245; Thu, 3 Apr 2003 10:03:58 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h33F3rWe007023; Thu, 3 Apr 2003 10:03:53 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040310035220540 ; Thu, 03 Apr 2003 10:03:53 -0500 Message-Id: <5.1.1.5.2.20030403094956.016d94f8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 10:03:44 -0500 To: , "'A. Bruce McDonald'" From: Joe Macker Subject: RE: [manet] Interlayer Interactions Cc: In-Reply-To: <000201c2f917$3b2268b0$8401a8c0@MAP11> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , FYI, this is an old thread....see some very old minutes/briefs... My observation is that most WG members agree that some level of cross-layer interaction is useful to improve performance. Present specifications even have placeholders for it. The non-existence of standard mechanisms is the main problem. Many implementors I speak with are investigating such interactions, but we would still like code that works in the absence of such mechanisms. -joe At 06:26 PM 4/2/2003 -0800, ankur.j@media.mit.edu wrote: >Thanks Bruce for starting the thread again. > >I fully agree with you that we need to have forward thinking about this. > > >So, let's start discussion on this once again and if the outcome of our >discussion will prove that cross-layer interaction is not of great use, >we will drop this idea... > >What are the opinions of other members of manet community? I am sure >many people won't like this idea but there are some who will like it.. > >Regards >Ankur > > > >-----Original Message----- >From: A. Bruce McDonald [mailto:mcdonald@ECE.NEU.EDU] >Sent: Tuesday, April 01, 2003 2:08 PM >To: ankur.j@media.mit.edu >Cc: manet@ietf.org >Subject: Re: [manet] Interlayer Interactions > > >Hi All; > >IMHO the concept of interlayer interaction is not simply a matter of 'ad >hoc' communications across a control plane. The idea is much more to the >core of understanding the issues involved with the design of ad hoc >networks. The example I like to give involves the inherent 'coupling' >between the MAC-layer and routing. This is fundamental property in the >case of a random access MAC---the problem is that channel contention at >the MAC-layer spans multiuple hops; moreover, the *solutions* to >problems >such as the hidden-terminal actually *cause* a phenomena we refer to as >'path-coupling'. In effect, apparently disjoint paths can experience >'induced-load'; in some situations this is necesssary to prevent >collisions, however, there are many scenarios when the induced load is >an >artifact that prevents a node from transmiting even if the transmission >would not cause a collission. > >This is a concrete example of a more >fundamental issue. That is, the question as to whether or not a graph >model (time varying, random, or whatever) is an appropriate model for an >ad hoc network. Can anyone justify it? Show me links and explain to me >how a topological routing algorithm would use knowledge of these link >even >if it were possible to gather complete accurate global topology >information? The concept of a "link" and, hence, the graph model itself >is inhernetly flawed. The question is what effect this has on the >design >of routing algorithms which are themselves based on a graph model? Do >they make sense? Perhaps a better model exists, perhaps not. >Understanding the nature of the cross-layer interaction could perhaps >allow us approximate the ad hoc network using a graph. Just a thought. > >The essence of my argument is that 'cross-layer interaction' should not >be >just a buzz word for sharing information between arbitrary layers, or >using layer-X information to control some aspect of layer-(X-2). >Instead, >it should be thought of in terms of the systematic study the how the >characteristics, properties and algorithms we associate with layer X >affect the performance of all other layers. The outcome of this line of >thinking is to enhance our understanding of these complex relationships >so >that we can then---either build new models and algorithms, or, add an >inter-layer control/management plane. It seems likely that both will be >required to some extent. However, carving a solid understanding first >will >lead to more effective and robust solutions in the future. > >As a community >we need to be forward thinking---I know there is a fly or die attitude >in >some corners that has difficulty with the snail pace. Just turn to the >cell phone/PCS industry---the fundamental technical ideas are 30 years >old. The reason for the success today is due to advances in DSP >technology >and chip density. > >Best regards, > >Bruce > >-------------------------------------------------------- >A. Bruce McDonald f:617.373.8970 >Assistant Prof. v:617.373.3028 >ECE Dept., 417 Dana mcdonald@ece.neu.edu >360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald >Northeastern University >Boston, MA 02115 >-------------------------------------------------------- > >_______________________________________________ >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 mailnull@www1.ietf.org Thu Apr 3 10:55:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26574 for ; Thu, 3 Apr 2003 10:55:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Fvso27678 for manet-archive@odin.ietf.org; Thu, 3 Apr 2003 10:57:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FvsK27675 for ; Thu, 3 Apr 2003 10:57:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26561 for ; Thu, 3 Apr 2003 10:55:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FbxK25738; Thu, 3 Apr 2003 10:37:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FTHK24363 for ; Thu, 3 Apr 2003 10:29:17 -0500 Received: from mail04.gmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24806 for ; Thu, 3 Apr 2003 10:26:26 -0500 (EST) Received: from Isovaio002 ([65.213.193.39]) by mail04.gmu.edu (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPA id <0HCR000UAXNHZT@mail04.gmu.edu> for manet@ietf.org; Thu, 03 Apr 2003 10:28:30 -0500 (EST) Date: Thu, 03 Apr 2003 10:28:50 -0500 From: Ali Nabi Zadeh Subject: RE: [manet] Interlayer Interactions In-reply-to: To: manet@ietf.org Reply-to: anabizad@gmu.edu Message-id: <000201c2f9f5$bad65e70$27c1d541@Isovaio002> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, Also, look at the Optimum transmission strategy section in the following paper. It has some examples of how cross layer optimization can result in higher system throughput. Self-Organizing Packet Radio Ad Hoc Networks with Overlay (SOPRANO) Ali N. Zadeh, Bijan Jabbari, Raymond Pickholtz and Branimir Vojcic IEEE Communications Magazine, June, 2002. http://mason.gmu.edu/~anabizad/Publications/ComMag02.pdf Regards, Ali. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Leping.Huang@nokia.com > Sent: Wednesday, April 02, 2003 8:56 PM > To: Yong.Liaw@postgrads.unisa.edu.au; ankur.j@media.mit.edu; > mcdonald@ece.neu.edu > Cc: manet@ietf.org > Subject: RE: [manet] Interlayer Interactions > > > Hi, > > Here is another paper regarding to the cross-layer interaction. > > CHEN, K., S. H. SHAH, et al. (2002). Cross-Layer Design for > Data Accessibility in Mobile Ad Hoc Networks. > Wireless Personal Communications 21, Kluwer Academic Publishers. > > One of my feeling from that paper is that QoS is obviously a > cross-layer concept, we need to translate > the user QoS to network layer QoS, then to link layer QoS. > So the cross-layer design can be widely accepted. But routing > is generally a OSI layer 3 issues, most of the people do not > want to violate this rule. BTW, can anyone tell me what is > penalty we need to pay if we violate the Layer 2 and layer3 barrier? > > > Yours > Leping > > -----Original Message----- > From: ext Liaw, Yong Shyang - LIAYS001 > [mailto:Yong.Liaw@postgrads.unisa.edu.au] > Sent: Thursday, April 03, 2003 8:47 AM > To: 'ankur.j@media.mit.edu'; 'A. Bruce McDonald' > Cc: manet@ietf.org > Subject: RE: [manet] Interlayer Interactions > > > Hi, > > I agree that cross-layer interaction needs more study than > already done. The death of L2-trigger at IETF does not mean > it is end of this topic -- in fact, it is being discussed in > some other WGs. Cross-layer interaction will likely to prove > useful in MANET, where link layer information may be used for > selecting routes. I also think that cross-layer interaction > between protocols needs more study as well, as there are few > studies done. > > > > -----Original Message----- > > From: ankur.j@media.mit.edu [mailto:ankur.j@media.mit.edu] > > Sent: Thursday, 3 April 2003 11:57 > > To: 'A. Bruce McDonald' > > Cc: manet@ietf.org > > Subject: RE: [manet] Interlayer Interactions > > > > > > Thanks Bruce for starting the thread again. > > > > I fully agree with you that we need to have forward thinking > > about this. > > > > > > So, let's start discussion on this once again and if the > > outcome of our > > discussion will prove that cross-layer interaction is not of > > great use, > > we will drop this idea... > > > > What are the opinions of other members of manet community? > I am sure > > many people won't like this idea but there are some who > will like it.. > > > > Regards > > Ankur > > > > > > > > -----Original Message----- > > From: A. Bruce McDonald [mailto:mcdonald@ECE.NEU.EDU] > > Sent: Tuesday, April 01, 2003 2:08 PM > > To: ankur.j@media.mit.edu > > Cc: manet@ietf.org > > Subject: Re: [manet] Interlayer Interactions > > > > > > Hi All; > > > > IMHO the concept of interlayer interaction is not simply a > > matter of 'ad > > hoc' communications across a control plane. The idea is much > > more to the > > core of understanding the issues involved with the design of ad hoc > > networks. The example I like to give involves the inherent > 'coupling' > > between the MAC-layer and routing. This is fundamental > property in the > > case of a random access MAC---the problem is that channel > > contention at > > the MAC-layer spans multiuple hops; moreover, the *solutions* to > > problems > > such as the hidden-terminal actually *cause* a phenomena we > > refer to as > > 'path-coupling'. In effect, apparently disjoint paths can experience > > 'induced-load'; in some situations this is necesssary to prevent > > collisions, however, there are many scenarios when the > induced load is > > an > > artifact that prevents a node from transmiting even if the > > transmission > > would not cause a collission. > > > > This is a concrete example of a more > > fundamental issue. That is, the question as to whether or > not a graph > > model (time varying, random, or whatever) is an appropriate > model for > > an ad hoc network. Can anyone justify it? Show me links and > > explain to me > > how a topological routing algorithm would use knowledge of > these link > > even > > if it were possible to gather complete accurate global topology > > information? The concept of a "link" and, hence, the graph > > model itself > > is inhernetly flawed. The question is what effect this has on the > > design > > of routing algorithms which are themselves based on a graph > model? Do > > they make sense? Perhaps a better model exists, perhaps not. > > Understanding the nature of the cross-layer interaction > could perhaps > > allow us approximate the ad hoc network using a graph. Just > a thought. > > > > The essence of my argument is that 'cross-layer interaction' > > should not > > be > > just a buzz word for sharing information between arbitrary > layers, or > > using layer-X information to control some aspect of layer-(X-2). > > Instead, > > it should be thought of in terms of the systematic study the how the > > characteristics, properties and algorithms we associate with layer X > > affect the performance of all other layers. The outcome of > > this line of > > thinking is to enhance our understanding of these complex > > relationships > > so > > that we can then---either build new models and algorithms, > or, add an > > inter-layer control/management plane. It seems likely that > > both will be > > required to some extent. However, carving a solid > understanding first > > will > > lead to more effective and robust solutions in the future. > > > > As a community > > we need to be forward thinking---I know there is a fly or > die attitude > > in some corners that has difficulty with the snail pace. > Just turn to > > the cell phone/PCS industry---the fundamental technical > ideas are 30 > > years old. The reason for the success today is due to > advances in DSP > > technology > > and chip density. > > > > Best regards, > > > > Bruce > > > > -------------------------------------------------------- > > A. Bruce McDonald f:617.373.8970 > > Assistant Prof. v:617.373.3028 > > ECE Dept., 417 Dana mcdonald@ece.neu.edu > > 360 Huntington Ave. www.ece.neu.edu/faculty/mcdonald > > Northeastern University > > Boston, MA 02115 > > -------------------------------------------------------- > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Thu Apr 3 11:54:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29427 for ; Thu, 3 Apr 2003 11:54:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33GuPv01190 for manet-archive@odin.ietf.org; Thu, 3 Apr 2003 11:56:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33GuPK01186 for ; Thu, 3 Apr 2003 11:56:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29345 for ; Thu, 3 Apr 2003 11:53:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Gb1K31539; Thu, 3 Apr 2003 11:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33GWFK31171 for ; Thu, 3 Apr 2003 11:32:15 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28330 for ; Thu, 3 Apr 2003 11:29:23 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h33GVojZ019262; Thu, 3 Apr 2003 11:31:50 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h33GViWe007961; Thu, 3 Apr 2003 11:31:44 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040311314320961 ; Thu, 03 Apr 2003 11:31:43 -0500 Message-Id: <5.1.1.5.2.20030403105850.032af840@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 11:31:35 -0500 To: "A. Bruce McDonald" From: Joe Macker Subject: RE: [manet] Interlayer Interactions Cc: ankur.j@media.mit.edu, In-Reply-To: References: <5.1.1.5.2.20030403094956.016d94f8@pop.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 10:38 AM 4/3/2003 -0500, A. Bruce McDonald wrote: >Hi Joe, > >It seems there are two ways to look at this which differ semantically. > >My perspective is that 'cross-layer interaction' is a property, >characteristic, or side-effect that is inherent in the layered system---in >this case the ad hoc network. My example was that certain attributes of >the MAC that are unique (more-or-less) to ad hoc networks have a certain I agree with your semantic argument and I think different MAC layers will differ in what they can or cannot offer and routing protocols will differ in what interaction may be useful. >inherent impact on higher layers, and, hence, perhaps should be considered >in the design of routing algorithms. In short, the cross-layer >interaction is something to be studied and understood--it is not a >mechansim or something to be defined and implemented. Agreed, that is the right scientific approach. Certainly if a MAC layer has robust information like "neighbor link up/down" that would may be useful right away to most wireless routing protocols. The broader interaction issues are more complex. >Once we have better models and deeper understanding of the nature of these >inherent interactions that may couple the performance of different layers >in ways that are fundamentally different than other networks, then we can >investigate how the mechansims for inter-layer control and/or design of >algorithms can reflect this understanding to perform better. Agreed this is a great ongoing research topic worth pursuing further, but I feel the potential value of it is nothing that hasn't been discussed already (both in research forum and IETF circles). I , for one, would encourage more investigation in the appropriate circles. Some previous posts have been implying its something new that has not been discussed before or that people aren't interested in it. I don't think that is true. Its a matter of scope and the appropriate forum. The ANS IRTF list may want to comment and may be an appropriate venue for broadening the knowledge base further over time. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Apr 3 16:21:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14668 for ; Thu, 3 Apr 2003 16:21:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LO4B31516 for manet-archive@odin.ietf.org; Thu, 3 Apr 2003 16:24:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LO4K31513 for ; Thu, 3 Apr 2003 16:24:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14659 for ; Thu, 3 Apr 2003 16:21:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LAPK30173; Thu, 3 Apr 2003 16:10:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326ObK25780 for ; Wed, 2 Apr 2003 01:24:37 -0500 Received: from darkwing.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00774 for ; Wed, 2 Apr 2003 01:00:00 -0500 (EST) Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h3262PC0016877 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 1 Apr 2003 22:02:25 -0800 (PST) Date: Tue, 1 Apr 2003 22:02:21 -0800 (PST) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: S Woodside cc: fn-tech@freenetworks.org, , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: [BAWUG] I have a dream Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , um... the internet routing architecture didn't explode in 1997 becuase we'd didn't do this. meshed network edges need an igp, some sanity and cooperative upstreams, otherwise you'll just have a very large very messy subnet with not external routing. joelja On Wed, 2 Apr 2003, S Woodside wrote: > Well, it's a fairly minor dream. What I imagine is this: I have DSL. My > neighbour has DSL. We also both have WiFi APs that can reach each > other, and connect at order-of-magnitude faster than the DSL links. > What I dream is this: That we start routing internet across the link. > When I start pulling packets off the internet, they can come to me not > only through my own DSL but from hers as well. I think this boils down > to an ultimate simplicity what all FN / CWNers want to achieve. > > What needs to happen before I can realize my dream. I need to get an > IPv6 address ... at least one ... for free. I need to be able to set up > multi-homing in my home router. I need to be able to advertise my > routing path to the internet. The internet needs to be able to handle > at a massive scale (since every neighbour connects...). We need a /lot/ > more IP addresses than we have now. I need to use a /real/ IP address > because I can't route internet traffic through a NAT/site-local > address. I need to have an ad-hoc routing algorithm that can set up > this bridge and route across it really easily (because I'm not a > trained network admin). Forget about BGP, AS, etc., we need a way to > handle the massive overload of routes at local scale, at a regional > scale, at a global scale -- something that will scale gracefully as the > internet topology shifts from a tree to a massively connected mesh. > > Please comment ... tell me what you think. > > Simon > > PS I'm cross-posting this to a bunch of lists because I don't know one > it belongs on. If you think you know which is best, please tell me! > > -- > general wireless list, a bawug thing > [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Apr 4 10:59:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27518 for ; Fri, 4 Apr 2003 10:59:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34G2FN26953 for manet-archive@odin.ietf.org; Fri, 4 Apr 2003 11:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34G2E826950 for ; Fri, 4 Apr 2003 11:02:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27504 for ; Fri, 4 Apr 2003 10:58:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fcv825565; Fri, 4 Apr 2003 10:38:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34FV3824307 for ; Fri, 4 Apr 2003 10:31:03 -0500 Received: from zeus.sim.uni-hannover.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26233 for ; Fri, 4 Apr 2003 10:27:43 -0500 (EST) Received: from sim.uni-hannover.de (drozda@roma [130.75.24.72]) by zeus.sim.uni-hannover.de (8.12.8p1/8.12.8p1) with ESMTP id h34FUCEd007553 for ; Fri, 4 Apr 2003 17:30:12 +0200 (MEST) Message-ID: <3E8DA504.D275A2A8@sim.uni-hannover.de> Date: Fri, 04 Apr 2003 17:30:12 +0200 From: Martin Drozda Organization: =?iso-8859-1?Q?Universit=E4t?= Hannover X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: sk, en MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] Interlayer Interactions References: <5.1.1.5.2.20030403094956.016d94f8@pop.itd.nrl.navy.mil> <5.1.1.5.2.20030403105850.032af840@pop.itd.nrl.navy.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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We have used ANOVA (Analysis of Variance) to argue about existence or non-existence of (interlayer) interactions in various classes of ad hoc networks. Employing a statistical approach allows for a very straightforward definition of interactions between setup parameters. This is very helpful if one needs to compare across different setups and very useful for protocol engineering. Also the method is not limited to interlayer (semantic) interaction (between protocols) but, in general, can evaluate interactions between any input parameters and their combinations. Our results show that 2-, 3-, or 4-way interactions are present. A 4-way interaction would be an interaction among 4 input parameters that can be any of MAC, routing protocols, speed of nodes, topology, injection rate etc. Thus, certain forms of interactions can be extremely COMPLEX. A 2-way interaction between routing and MAC protocols was present for almost any class of ad hoc networks that we studied. Currently, we are trying to extend the results to non-synthetic topologies with high enough number of nodes to draw more general conclusions. Take a look at the two references below for details. md Christopher L. Barrett, Martin Drozda, Achla Marathe, and Madhav V. Marathe. Analyzing Interaction Between Network Protocols, Topology and Traffic in Wireless Radio Networks. Proc. IEEE Wireless Communications and Networking Conference (WCNC'03), New Orleans, Louisiana, 2003. http://www.sim.uni-hannover.de/~drozda/papers/wcnc_2003.pdf Christopher L. Barrett, Martin Drozda, Achla Marathe, and Madhav V. Marathe. Characterizing the Interaction Between Routing and MAC Protocols in Ad-Hoc Networks. Proc. The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing (MOBIHOC 2002), June 2002, Lausanne, Switzerland. http://www.sim.uni-hannover.de/~drozda/papers/Mobihoc_2002.pdf _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Apr 4 11:06:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27750 for ; Fri, 4 Apr 2003 11:06:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34G9G728015 for manet-archive@odin.ietf.org; Fri, 4 Apr 2003 11:09:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34G9F828012 for ; Fri, 4 Apr 2003 11:09:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27735 for ; Fri, 4 Apr 2003 11:05:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fld825978; Fri, 4 Apr 2003 10:47:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Fbu825520 for ; Fri, 4 Apr 2003 10:37:56 -0500 Received: from mmtelum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26474 for ; Fri, 4 Apr 2003 10:34:35 -0500 (EST) Received: from altair not authenticated [207.248.48.160] by mmtelum.com with NetMail SMTP Agent $Revision: 3.9 $ on Linux; Fri, 04 Apr 2003 10:07:06 -0600 From: "Noe Francisco Davila Arteaga" To: Cc: Date: Fri, 4 Apr 2003 09:27:50 -0600 Message-ID: <000001c2fabe$c0a95bd0$a030f8cf@telum.com.mx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C2FA8C.760EEBD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [manet] Introduce myself Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2FA8C.760EEBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The reason because I added to the mail list, is I=92m interesting in wireless network adhoc routing problem, I looking for a relevant problem with discovery route and maintained route. =20 Actually I=92m study my master degree, and my thesis is focus in the = topic network adhoc routing. =20 This is my Tech =96 University. Instituto Tecnol=F3gico y de Estudios Superiores de Monterrey (ITESM).=20 =20 This is my Intelligent System Center. Centro de Sistemas Inteligentes (CIS). =20 Regards. =20 No=E9 Francisco D=E1vila Arteaga=20 Tecnologia Informatica Telum=20 Multimedios Redes Tel. +52(81)80404400 ext. 3182=20 Fax. +52(81)80404401=20 Pager +52(81)81511000 clave 1601463=20 "El presente correo y los documentos que en l se adjuntan son confidenciales y son propiedad de Televisi n Internacional S.A. de C.V. Su contenido debe ser conocido exclusivamente por la persona o entidad destinataria. Queda estrictamente prohibido cualquier empleo, copia o difusin por cualquier medio del contenido de este correo, salvo aquellos expresamente autorizados por Televisi n Internacional S.A. de C.V. Si considera que por error ha recibido este correo, agradeceremos por favor lo reenve inmediatamente al remitente." =20 ------=_NextPart_000_0001_01C2FA8C.760EEBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

The reason because I added to the mail list, is = I’m interesting in wireless network adhoc = routing problem, I looking for a relevant problem with discovery route and = maintained route.

 

Actually I’m study my master degree, and my = thesis is focus in the topic network adhoc = routing.

 

This is my Tech – = University.

Instituto Tecnol=F3gico y de Estudios = Superiores de Monterrey (ITESM).

 

This is my = Intelligent = System = Center.

Centro de Sistemas Inteligentes (CIS).

 

Regards.

 

No=E9 Francisco D=E1vila Arteaga
Tecnologia Informatica
Telum

Multi= medios Redes


Tel. +52(81)80404400 ext. 3182
Fax. +52(81)80404401
Pager +52(81)81511000 clave 1601463 =

"= ;El presente correo y los documentos que en l se adjuntan son = confidenciales y son propiedad de Televisi n Internacional S.A. de C.V. Su = contenido debe ser conocido exclusivamente por la persona o entidad destinataria. = Queda estrictamente prohibido cualquier empleo, copia o difusin por = cualquier medio del contenido de este correo, salvo aquellos expresamente autorizados = por Televisi n Internacional S.A. de C.V. Si considera que por error = ha recibido este correo, agradeceremos por favor lo reenve inmediatamente = al remitente."

 

------=_NextPart_000_0001_01C2FA8C.760EEBD0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Apr 4 16:38:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09034 for ; Fri, 4 Apr 2003 16:38:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34LeuE21640 for manet-archive@odin.ietf.org; Fri, 4 Apr 2003 16:40:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Leu821637 for ; Fri, 4 Apr 2003 16:40:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09008 for ; Fri, 4 Apr 2003 16:37:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LNw819938; Fri, 4 Apr 2003 16:23:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LIr819710 for ; Fri, 4 Apr 2003 16:18:53 -0500 Received: from snail.ecs.umass.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08384 for ; Fri, 4 Apr 2003 16:15:27 -0500 (EST) Received: from xq (ganz1.ecs.umass.edu [128.119.85.178]) by snail.ecs.umass.edu (8.12.8p1/8.12.8) with SMTP id h34LHs7Q007779 for ; Fri, 4 Apr 2003 16:17:56 -0500 (EST) Message-ID: <009b01c2faef$4e38d3b0$11070707@xq> From: "qi xue" To: References: <000001c2fabe$c0a95bd0$a030f8cf@telum.com.mx> Date: Fri, 4 Apr 2003 16:15:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C2FAC5.620B1530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) Subject: [manet] Packet size distribution in wireless networks. Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C2FAC5.620B1530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is there any measurement work on the packet size distribution in the = wireless networks? Especially, in wireless LANs. Can anybody point me to some related resources? Thank you! Qi ------=_NextPart_000_0098_01C2FAC5.620B1530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Is there any measurement work on the = packet size=20 distribution in the wireless networks? Especially, in wireless=20 LANs.
Can anybody point me to some related=20 resources?
 
Thank you!
 
Qi
 
 
------=_NextPart_000_0098_01C2FAC5.620B1530-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Apr 4 17:14:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10249 for ; Fri, 4 Apr 2003 17:14:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34MHHN25022 for manet-archive@odin.ietf.org; Fri, 4 Apr 2003 17:17:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34MHH825019 for ; Fri, 4 Apr 2003 17:17:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10242 for ; Fri, 4 Apr 2003 17:13:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34M0e823048; Fri, 4 Apr 2003 17:00:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LuQ822490 for ; Fri, 4 Apr 2003 16:56:26 -0500 Received: from quadra.novaengr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09435 for ; Fri, 4 Apr 2003 16:52:58 -0500 (EST) Received: by quadra.novaengr.com with Internet Mail Service (5.5.2653.19) id <2184PJRH>; Fri, 4 Apr 2003 16:55:10 -0500 Message-ID: <09624AD44E416B4D8BF29194221BA492088A4D@quadra.novaengr.com> From: Michael Rauf To: "Van Leeuwen, Brian P" Cc: "'manet@ietf.org'" , "'haas@ece.cornell.edu'" Subject: RE: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Date: Fri, 4 Apr 2003 16:55:08 -0500 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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Brian, Another implementation is the NovaRoam Mobile Router from Nova Engineering which contains embedded Ad Hoc routing algorithms and is available in commercial and tactical versions. Customers are currently using them in public safety (police), military, security, industrial networking and oil/gas exploration applications. The radio has a Direct Sequence Spread Spectrum (DSSS) interface and is available for use in the license free 900 MHz ISM and military 250 MHz bands. It is generally used when a long distance dynamic network is required and a cellular wireless network is not a viable alternative. Currently, the radio implements TORA, though the AODV algorithm has been ported to the existing design and is being used by select customers prior to release in the next generation of radios. The new NovaRoams contain a Linux-based OS which facilitates the porting of additional MANET algorithms and other features in the future. This new NovaRoam will be available soon on a commercial basis. In addition to the DSSS radio a Frequency Hopping Spread Spectrum (FHSS) radio will also be released with the AODV algorithm initially (June 2003). For more detail see: http://www.novaroam.com/novaroam.html ftp://ftp.novaroam.com/Pub/NovaRoam/novaroam_900.pdf Michael ____________________________________________ Michael Rauf Nova Engineering, Inc. Innovative Wireless + Digital Communication Solutions 1.513.642.3000 (main) 1.513.642.3174 (direct) 1.513.642.3374 (fax) mailto:mrauf@nova-eng.com http://www.nova-eng.com -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Wednesday, April 02, 2003 5:41 PM To: Van Leeuwen, Brian P Cc: 'manet@ietf.org'; Zygmunt Haas Subject: Re: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Hi Brian, MobileRoute(TM) from Scientific Research Corporation, which is based on ZRP. See: http://www.scires.com/mobileroute.htm and their white paper: http://www.scires.com/pdfs/mr-wp.pdf Zygmunt. ===--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Wed, 2 Apr 2003, Van Leeuwen, Brian P wrote: > Hello, > > What kind of systems have ad hoc networks been used in to date? I'm aware of > the Army's interest in using ad hoc networks in their future systems but has > the Army or other organization built any ad hoc network based system? Have > any systems, government or commercial, been developed to date that use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. > > Any comments or suggestions are welcome. > > Thanks for your help, > > Brian > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Apr 4 18:14:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13282 for ; Fri, 4 Apr 2003 18:14:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34NHL030326 for manet-archive@odin.ietf.org; Fri, 4 Apr 2003 18:17:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NHL830323 for ; Fri, 4 Apr 2003 18:17:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13202 for ; Fri, 4 Apr 2003 18:13:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34N0g827843; Fri, 4 Apr 2003 18:00:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34MuC827597 for ; Fri, 4 Apr 2003 17:56:12 -0500 Received: from mail.scires.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11078 for ; Fri, 4 Apr 2003 17:52:43 -0500 (EST) Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Fri, 04 Apr 2003 17:56:03 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Fri, 04 Apr 2003 17:55:35 -0500 From: "Pete Sholander" To: , Cc: , Subject: RE: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Zygmunt ... thanks for the SRC product plug! Since this is a vendor-neutral IETF mailing list ... I'll note that Mesh Networks (http://www.meshnetworks.com/) also has an interesting commercial product. There's also various vendors in the military market-space. --Pete Sholander >>> Michael Rauf 04/04/03 04:55PM >>> Brian, Another implementation is the NovaRoam Mobile Router from Nova Engineering which contains embedded Ad Hoc routing algorithms and is available in commercial and tactical versions. Customers are currently using them in public safety (police), military, security, industrial networking and oil/gas exploration applications. The radio has a Direct Sequence Spread Spectrum (DSSS) interface and is available for use in the license free 900 MHz ISM and military 250 MHz bands. It is generally used when a long distance dynamic network is required and a cellular wireless network is not a viable alternative. Currently, the radio implements TORA, though the AODV algorithm has been ported to the existing design and is being used by select customers prior to release in the next generation of radios. The new NovaRoams contain a Linux-based OS which facilitates the porting of additional MANET algorithms and other features in the future. This new NovaRoam will be available soon on a commercial basis. In addition to the DSSS radio a Frequency Hopping Spread Spectrum (FHSS) radio will also be released with the AODV algorithm initially (June 2003). For more detail see: http://www.novaroam.com/novaroam.html ftp://ftp.novaroam.com/Pub/NovaRoam/novaroam_900.pdf Michael ____________________________________________ Michael Rauf Nova Engineering, Inc. Innovative Wireless + Digital Communication Solutions 1.513.642.3000 (main) 1.513.642.3174 (direct) 1.513.642.3374 (fax) mailto:mrauf@nova-eng.com http://www.nova-eng.com -----Original Message----- From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Sent: Wednesday, April 02, 2003 5:41 PM To: Van Leeuwen, Brian P Cc: 'manet@ietf.org'; Zygmunt Haas Subject: Re: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Hi Brian, MobileRoute(TM) from Scientific Research Corporation, which is based on ZRP. See: http://www.scires.com/mobileroute.htm and their white paper: http://www.scires.com/pdfs/mr-wp.pdf Zygmunt. ===--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Wed, 2 Apr 2003, Van Leeuwen, Brian P wrote: > Hello, > > What kind of systems have ad hoc networks been used in to date? I'm aware of > the Army's interest in using ad hoc networks in their future systems but has > the Army or other organization built any ad hoc network based system? Have > any systems, government or commercial, been developed to date that use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. > > Any comments or suggestions are welcome. > > Thanks for your help, > > Brian > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Sat Apr 5 01:26:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19681 for ; Sat, 5 Apr 2003 01:26:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h356T2t26083 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 01:29:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356T2826080 for ; Sat, 5 Apr 2003 01:29:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19662 for ; Sat, 5 Apr 2003 01:25:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3561I823955; Sat, 5 Apr 2003 01:01:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355r7823599 for ; Sat, 5 Apr 2003 00:53:07 -0500 Received: from ltitlout.lntinfotech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18997 for ; Sat, 5 Apr 2003 00:49:29 -0500 (EST) Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.11) with ESMTP id 2003040511205124:32534 ; Sat, 5 Apr 2003 11:20:51 +0530 To: manet@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jagan S" Date: Sat, 5 Apr 2003 11:13:43 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 04/05/2003 11:13:46 AM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.11 |July 24, 2002) at 04/05/2003 11:20:51 AM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.11 |July 24, 2002) at 04/05/2003 11:23:25 AM, Serialize complete at 04/05/2003 11:23:25 AM Content-type: text/plain; charset=us-ascii Subject: [manet] Routing using IPv6 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, I'm a new member & have a question related to IPv6. Can someone tell me about the available stuff on using "IPv6 for providing routing mechanism in MANET" networks. Thanks in advance, - Jagan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 05:46:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04244 for ; Sat, 5 Apr 2003 05:46:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35Anu519986 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 05:49:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Ant819983 for ; Sat, 5 Apr 2003 05:49:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04239 for ; Sat, 5 Apr 2003 05:46:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35AQL818540; Sat, 5 Apr 2003 05:26:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35AK4818425 for ; Sat, 5 Apr 2003 05:20:04 -0500 Received: from prue.eim.surrey.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03883 for ; Sat, 5 Apr 2003 05:16:22 -0500 (EST) Received: from romeo.ee.surrey.ac.uk ([131.227.76.30] helo=eim.surrey.ac.uk ident=www) by prue.eim.surrey.ac.uk with smtp (Exim 3.33 #4) id 191kL4-0007A0-00 for manet@ietf.org; Sat, 05 Apr 2003 10:51:54 +0100 Received: from m150-mp1.cvx2-c.lng.dial.ntli.net ([62.252.188.150]) (SquirrelMail authenticated user eem1tk) by secure.eps.surrey.ac.uk with HTTP; Sat, 5 Apr 2003 10:51:54 +0100 (BST) Message-ID: <3095.62.252.188.150.1049536314.squirrel@secure.eps.surrey.ac.uk> Date: Sat, 5 Apr 2003 10:51:54 +0100 (BST) From: "Teng Kang" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-106.6 required=5.5 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *191kL4-0007A0-00*lpXV7Q0p3P.* (SECM, UniS) Content-Transfer-Encoding: 8bit Subject: [manet] How to subscribe the mailing list via Listserv@listserv.ulca.edu Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear all: I subscribed the mailing list in UCLA using the command,"SUBSCRIBE GLOMOSIM-ANNOUNC-L" serveral times, but every reply just said that my application was fowarded to be approved. After that I wait a period of time with no any further information. I really want to get more close topics related with my current work in that mailing list. Is there any one can give my any solution to deal with the problem. Thanks a lot in advance! best regards _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 10:04:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07332 for ; Sat, 5 Apr 2003 10:04:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35F7hY01263 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 10:07:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35F7h801260 for ; Sat, 5 Apr 2003 10:07:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07280 for ; Sat, 5 Apr 2003 10:03:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35EnJ832240; Sat, 5 Apr 2003 09:49:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Edv832013 for ; Sat, 5 Apr 2003 09:39:57 -0500 Received: from rrmail01.lab.flarion.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06818 for ; Sat, 5 Apr 2003 09:36:10 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <2KQJ9GM7>; Sat, 5 Apr 2003 09:38:38 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> From: Scott Corson To: "'Joe Macker'" , "'A. Bruce McDonald'" Cc: "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" Subject: RE: [manet] Interlayer Interactions Date: Sat, 5 Apr 2003 09:38:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a *very* old discussion. ;-) In the absence of standardized mechanisms, I also agree with Joe that we need code that does not require standard interlayer interaction mechanisms. > The ANS IRTF list may want to comment and may be an > appropriate venue for > broadening the knowledge base further over time. As to whether the ANS group will explore this issue, I would be very much in favor of it (note the cross posting), but the issue is *broader* than ad hoc networking. It pertains to IP-based cellular systems, WLAN and ad hoc schemes. In short any link layer where intermittent and dynamic connectivity may be a typical event. Of all the *trigger* and related IETF work I've seen proposed to date, IMO, the most sensible and general approach was articulated by Phil Neumiller in an interesting way. The proposal is that the IETF standardize IP's *underbelly*. I interpret what Phil meant as a general interface definition that would be built into the bottomhalf of standard IP kernels. Link layers could then be defined or extended to operate in accordance with this interface as desired. Most generally IP kernels understand 'point-to-point' and 'broadcast' link layers. What is necessary is *another* type of interface that blends and generalizes aspects of point-to-point and broadcast link layers to accomodate link *dynamics*. As such I refer to it as a *triggered* or *dynamic* interface for lack of a better name. In wireless, link layer broadcast communication (one-to-many) is the general case and must be supported as in Ethernet. At the same time, point-to-point 'peer-to-peer' associations (neighbors in an ad hoc sense) arise *dynamically* as a consequence of movement, power up, fading, etc. Many link layers efficiently detect the existence/non-existence and quality of these associations. This association information can be conveyed to an IP stack via the triggered interface construct, and the IP stack is free to use this information as desired (and it may ignore it as well). This mechanism is applicable to Ad hoc, WLAN and Cellular technologies. For those interested, this topic is explored a bit further in http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt Cheers, -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 11:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09876 for ; Sat, 5 Apr 2003 11:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35GCqH05533 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 11:12:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35GCq805530 for ; Sat, 5 Apr 2003 11:12:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09873 for ; Sat, 5 Apr 2003 11:09:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Fp8803912; Sat, 5 Apr 2003 10:51:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35FdD803539 for ; Sat, 5 Apr 2003 10:39:13 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09192 for ; Sat, 5 Apr 2003 10:35:16 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h35FcJGi022889 for ; Sat, 5 Apr 2003 23:38:20 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Sat, 05 Apr 2003 23:30:00 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 0179A30948; Sat, 5 Apr 2003 23:37:24 +0800 (SGT) Date: Sat, 5 Apr 2003 23:37:24 +0800 From: Sukanta Kumar Hazra To: Scott Corson Cc: "'Joe Macker'" , "'A. Bruce McDonald'" , "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" Subject: Re: [Ans-research] RE: [manet] Interlayer Interactions Message-ID: <20030405153724.GA12200@localhost> Mail-Followup-To: Scott Corson , 'Joe Macker' , "'A. Bruce McDonald'" , "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" References: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > This is a *very* old discussion. ;-) Indeed it is a *very* old discussion. But it resurfaces ever so often that it is imperative that something be done about it (IMHO). All the arguments that I have come across point to the need for a standardized interface for IP<->L2 interaction. Anyone remembers the arguments against it (as were discussed in the IP triggers BOF). - Sukanta > > In the absence of standardized mechanisms, I also agree with Joe that we > need code that does not require standard interlayer interaction mechanisms. > > > The ANS IRTF list may want to comment and may be an > > appropriate venue for > > broadening the knowledge base further over time. > > As to whether the ANS group will explore this issue, I would be very much in > favor of it (note the cross posting), but the issue is *broader* than ad hoc > networking. It pertains to IP-based cellular systems, WLAN and ad hoc > schemes. In short any link layer where intermittent and dynamic > connectivity may be a typical event. > > Of all the *trigger* and related IETF work I've seen proposed to date, IMO, > the most sensible and general approach was articulated by Phil Neumiller in > an interesting way. The proposal is that the IETF standardize IP's > *underbelly*. > > I interpret what Phil meant as a general interface definition that would be > built into the bottomhalf of standard IP kernels. Link layers could then be > defined or extended to operate in accordance with this interface as desired. > > Most generally IP kernels understand 'point-to-point' and 'broadcast' link > layers. What is necessary is *another* type of interface that blends and > generalizes aspects of point-to-point and broadcast link layers to > accomodate link *dynamics*. As such I refer to it as a *triggered* or > *dynamic* interface for lack of a better name. > > In wireless, link layer broadcast communication (one-to-many) is the general > case and must be supported as in Ethernet. At the same time, point-to-point > 'peer-to-peer' associations (neighbors in an ad hoc sense) arise > *dynamically* as a consequence of movement, power up, fading, etc. Many > link layers efficiently detect the existence/non-existence and quality of > these associations. This association information can be conveyed to an IP > stack via the triggered interface construct, and the IP stack is free to use > this information as desired (and it may ignore it as well). This mechanism > is applicable to Ad hoc, WLAN and Cellular technologies. > > For those interested, this topic is explored a bit further in > > http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt > > Cheers, > > -Scott > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 18:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17321 for ; Sat, 5 Apr 2003 18:09:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35NDE728236 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 18:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35NDD828233 for ; Sat, 5 Apr 2003 18:13:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17029 for ; Sat, 5 Apr 2003 18:08:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Mjj826572; Sat, 5 Apr 2003 17:45:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35MYj825554 for ; Sat, 5 Apr 2003 17:34:45 -0500 Received: from che.onthejob.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15945 for ; Sat, 5 Apr 2003 17:30:48 -0500 (EST) Received: from che.onthejob.net (localhost [127.0.0.1]) by che.onthejob.net (8.12.8/8.12.5) with ESMTP id h35MXIMs022679 for ; Sat, 5 Apr 2003 16:33:18 -0600 Received: (from dyoung@localhost) by che.onthejob.net (8.12.8/8.12.8/Submit) id h35MXIn3022674 for manet@ietf.org; Sat, 5 Apr 2003 16:33:18 -0600 Date: Sat, 5 Apr 2003 16:33:18 -0600 From: David Young To: "'manet@ietf.org'" Subject: Re: [manet] Interlayer Interactions Message-ID: <20030405223318.GC18648@che.onthejob.net> Mail-Followup-To: "'manet@ietf.org'" References: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> User-Agent: Mutt/1.4i Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , On Sat, Apr 05, 2003 at 09:38:35AM -0500, Scott Corson wrote: > > This is a *very* old discussion. ;-) > > In the absence of standardized mechanisms, I also agree with Joe that we > need code that does not require standard interlayer interaction mechanisms. > > > The ANS IRTF list may want to comment and may be an > > appropriate venue for > > broadening the knowledge base further over time. > > As to whether the ANS group will explore this issue, I would be very much in > favor of it (note the cross posting), but the issue is *broader* than ad hoc > networking. It pertains to IP-based cellular systems, WLAN and ad hoc > schemes. In short any link layer where intermittent and dynamic > connectivity may be a typical event. > > Of all the *trigger* and related IETF work I've seen proposed to date, IMO, > the most sensible and general approach was articulated by Phil Neumiller in > an interesting way. The proposal is that the IETF standardize IP's > *underbelly*. > > I interpret what Phil meant as a general interface definition that would be > built into the bottomhalf of standard IP kernels. Link layers could then be > defined or extended to operate in accordance with this interface as desired. > > Most generally IP kernels understand 'point-to-point' and 'broadcast' link > layers. What is necessary is *another* type of interface that blends and > generalizes aspects of point-to-point and broadcast link layers to > accomodate link *dynamics*. As such I refer to it as a *triggered* or > *dynamic* interface for lack of a better name. > > In wireless, link layer broadcast communication (one-to-many) is the general > case and must be supported as in Ethernet. At the same time, point-to-point > 'peer-to-peer' associations (neighbors in an ad hoc sense) arise > *dynamically* as a consequence of movement, power up, fading, etc. Many > link layers efficiently detect the existence/non-existence and quality of > these associations. This association information can be conveyed to an IP > stack via the triggered interface construct, and the IP stack is free to use > this information as desired (and it may ignore it as well). This mechanism > is applicable to Ad hoc, WLAN and Cellular technologies. I like that you have put this into terms where it becomes possible to produce an implementation in existing systems. I will suggest a conservative implementation of this "dynamic/triggered" interface idea in BSD UNIX. Adapt existing 802.11 drivers (e.g., wi0) to produce a virtual interface in {sta0, ..., staN} for each neighbor detected. Neighbors will be detected by their sending a beacon, unicast or multicast packet. Let the drivers keep per-destination unicast Tx/Rx statistics in the stats counters of sta0, ..., staN. Destroy a virtual interface whenever the neighbor it is associated with has not been "heard" in some preset interval. Join wi0, sta0, ..., staN into one interface with a software bridge (most BSDs provide this today). Assign an IP number to the bridge and run the routing function on it. Let a routing daemon listen to a routing socket for interface up/down events from sta0, ..., staN. These will indicate neighbors coming and going. Let a routing daemon also listen to the RTM_LOSING message, which it should be possible to use (abuse?) to tell that link conditions are changing on one of the staX devices---e.g., S/N is falling or many packets have been sent without ACKs---so that the routing daemon can examine the staX's statistics counters. There is already some precedence for virtual wireless interfaces: Linux-based access point assigns virtual interfaces to neighboring APs. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 19:09:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18685 for ; Sat, 5 Apr 2003 19:09:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h360Cgm31360 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 19:12:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h360Cg831357 for ; Sat, 5 Apr 2003 19:12:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18668 for ; Sat, 5 Apr 2003 19:08:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Nnn829882; Sat, 5 Apr 2003 18:49:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Ne7829737 for ; Sat, 5 Apr 2003 18:40:07 -0500 Received: from web20110.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18246 for ; Sat, 5 Apr 2003 18:36:08 -0500 (EST) Message-ID: <20030405233839.69016.qmail@web20110.mail.yahoo.com> Received: from [130.203.30.38] by web20110.mail.yahoo.com via HTTP; Sat, 05 Apr 2003 15:38:39 PST Date: Sat, 5 Apr 2003 15:38:39 -0800 (PST) From: Siddharth Ray To: manet@ietf.org In-Reply-To: <20030221170003.4203.43143.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Re: manet digest, Vol 1 #348 - 4 msgs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi All, I am trying to simulate routing misbehavior in glomosim on top of DSR. I want to know where the nodes that are actually getting allocated in glomosim. I want to read from a configuration file the behavior and assign it to each node before simulation starts in DSR. Where exactly to make this change... -Siddharth __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Apr 5 21:19:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20069 for ; Sat, 5 Apr 2003 21:19:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h362MkI04930 for manet-archive@odin.ietf.org; Sat, 5 Apr 2003 21:22:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h362Mk804927 for ; Sat, 5 Apr 2003 21:22:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20066 for ; Sat, 5 Apr 2003 21:18:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h361sj803401; Sat, 5 Apr 2003 20:54:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h361ia803253 for ; Sat, 5 Apr 2003 20:44:36 -0500 Received: from cs.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19572 for ; Sat, 5 Apr 2003 20:40:33 -0500 (EST) Received: from ix.cs.uoregon.edu (manoj@ix.cs.uoregon.edu [128.223.4.21]) by cs.uoregon.edu (8.12.9/8.12.8) with ESMTP id h361h5a4016774; Sat, 5 Apr 2003 17:43:05 -0800 (PST) Date: Sat, 5 Apr 2003 17:43:05 -0800 (PST) From: Manoj K Pandey To: Siddharth Ray cc: Subject: Re: [manet] Re: manet digest, Vol 1 #348 - 4 msgs In-Reply-To: <20030405233839.69016.qmail@web20110.mail.yahoo.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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , hi Siddharth, the nodes are assigned their initial configuration in "driver.pc" file [position, uniform/random, which partition etc]. Also, Each of the layer has an "Init" component. For example, if you are using a combination of CBR-DSR, there would be an cbrInit(), udpInit, dsrInit() and simliar Mac and Radio layer Inits. You could call the routing misbehavior from the dsrInit(). Hope it helps else if you can get a little more specific, we might be able to help you more on this. thnx, manoj ****************************** Manoj Pandey, PhD student, #226, Deschutes, Computer and Information Science, University of Oregon, Phone# 541-346-1381 [Office], www.cs.uoregon.edu/~manoj ****************************** On Sat, 5 Apr 2003, Siddharth Ray wrote: > Hi All, > I am trying to simulate routing misbehavior in > glomosim on top of DSR. I want > to know where the nodes that are actually getting > allocated in glomosim. I want > to read from a configuration file the behavior and > assign it to each node > before simulation starts in DSR. Where exactly to make > this change... > -Siddharth > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://tax.yahoo.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 mailnull@www1.ietf.org Sun Apr 6 03:03:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23296 for ; Sun, 6 Apr 2003 03:03:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3676v518405 for manet-archive@odin.ietf.org; Sun, 6 Apr 2003 03:06:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3676v818402 for ; Sun, 6 Apr 2003 03:06:57 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23281 for ; Sun, 6 Apr 2003 03:02:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366dL817402; Sun, 6 Apr 2003 01:39:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366Zg816517 for ; Sun, 6 Apr 2003 01:35:42 -0500 Received: from tomts25-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22742 for ; Sun, 6 Apr 2003 01:31:35 -0500 (EST) Received: from yahoo.com ([65.93.180.110]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030406063406.IOKY6158.tomts25-srv.bellnexxia.net@yahoo.com>; Sun, 6 Apr 2003 01:34:06 -0500 Date: Sun, 6 Apr 2003 01:34:06 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: benchun , manet@ietf.org, geeks@false-profit.com, dylan@false-profit.com To: Trail of Chaos From: S Woodside In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [manet] Re: [geeks] Fwd: [BAWUG] I have a dream Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, April 3, 2003, at 04:38 AM, Trail of Chaos wrote: > benchun writes: >>> When I start pulling packets off the internet, they can come to me >>> not only through my own DSL but from hers as well. > >> I need to be able to advertise my routing path to the internet. > IPv6 is a red herring (and it's Never Gonna Happen). IPv6 had a killer app (wireless cell phone stuff) that vanished into the wind. So now AFAI can tell, it's on the drawing board. If fixed wireless becomes a new killer app for IPv6, there's some hope to think that there might be interest in it again ... and one thing IPv6 has that the community wireless networks want is /lots/ of IP addresses. IPv6 tunelling? >> we need a way to handle the massive overload of routes at local scale, > > I agree -- http://www.megacz.com/psr.txt > > Source Routing is the only scalable solution. ??? broadcasting routing requests doesn't seem that scalable. Neither do huge route caches. I think that geographic routing has much more potential. simon _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Apr 6 17:58:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07093 for ; Sun, 6 Apr 2003 17:58:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h36M2ru05863 for manet-archive@odin.ietf.org; Sun, 6 Apr 2003 18:02:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36M2r805860 for ; Sun, 6 Apr 2003 18:02:53 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07079 for ; Sun, 6 Apr 2003 17:58:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36Ldm804980; Sun, 6 Apr 2003 17:39:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36LXJ804013 for ; Sun, 6 Apr 2003 17:33:19 -0400 Received: from panther.noc.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06603 for ; Sun, 6 Apr 2003 17:28:54 -0400 (EDT) Received: from MANTHOSM50 (Panther.CS.UCLA.EDU [131.179.128.25]) by panther.noc.ucla.edu (8.9.1a/8.9.1) with SMTP id OAA26550; Sun, 6 Apr 2003 14:31:23 -0700 (PDT) Message-ID: <00b501c2fc83$975cc570$0f02000a@MANTHOSM50> From: "Manthos Kazantzidis" To: Cc: Date: Sun, 6 Apr 2003 14:29:21 -0700 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] NS as a visual studio .dsw workspace Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, can anyone tell me if there is an NS distribution that compiles and debugs in Visual Studio ? I do not mean the nmake makefiles wrapped into a Visual Studio project. I believe it will have to be a workspace .dsw file, one that contains each ns source file not just the makefile. (The nmake makefiles do not support all debugging functions.) Thank you very much. Manthos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Apr 6 22:18:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12029 for ; Sun, 6 Apr 2003 22:18:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h372MCf20949 for manet-archive@odin.ietf.org; Sun, 6 Apr 2003 22:22:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h372MC820946 for ; Sun, 6 Apr 2003 22:22:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12009 for ; Sun, 6 Apr 2003 22:17:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3720Z819054; Sun, 6 Apr 2003 22:00:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h371pl818824 for ; Sun, 6 Apr 2003 21:51:47 -0400 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11460 for ; Sun, 6 Apr 2003 21:47:15 -0400 (EDT) Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h371nj3W016316 for ; Mon, 7 Apr 2003 10:49:45 +0900 (KST) Message-ID: <008101c2fca7$f7976f70$d92f024b@LocalHost> From: "Eunil" To: Date: Mon, 7 Apr 2003 10:49:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h371pl818825 Subject: [manet] CFP: IEEE INFOCOM 2004 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit CALL FOR PAPERS Sponsored by: The Institute of Electrical and Electronics Engineers, Inc. (IEEE), IEEE Computer Society & IEEE Communications Society IEEE INFOCOM 2004 The Conference on Computer Communications March 7 - 11, 2004, Hong Kong The Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies http://www.ieee-infocom.org/2004 General Chair: Victor O. K. Li, University of Hong Kong Technical Program Co-Chairs: Marwan Krunz, University of Arizona Bo Li, Hong Kong University of Science &Tech. Standing Committee Chair: Harvey Freeman, HeatSeeker Technology Partners, Inc. Topics of Interest: Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: Ad hoc & sensor networks Performance evaluation Addressing & location management Power control Capacity planning Pricing & billing Cellular networks Quality of service Congestion control Resource allocation Content distribution Routing Multicast Scheduling & buffer management Multimedia protocols Security & privacy Network applications & services Service overlay networks Network architectures Switches and switching Network control by pricing Topology inference Network design & planning Traffic analysis & control Network management Traffic engineering Optical networks Web performance Peer-to-peer communications Wireless LANs Important Dates Full paper due July 1, 2003 Notification of acceptance October 30, 2003 Final version due December 19, 2003 Workshop on High-Speed Networking 2004 (In conjunction with Infocom 2004) March 7, 2004 www.comsoc.org/tcgn/conference/hsn2004 OpenArch 2004 (In conjunction with Infocom 2004) March 12-13, 2004 www.openarch.org Information on: Submission instructions Program and registration Local arrangements Student and travel grants http://www.ieee-infocom.org/2004 ---------------------------------------------------------------------- Eunil Seo Research Engineer, i-Networking Lab. Samsung Advanced Institute of Technology Tel : +82-31-280-9593 Fax: +82-31-280-9587 Mobile : +82-11-9625-8325 E-mail: seoei2@yahoo.com or seoei2@sait.samsung.co.kr ---------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Apr 7 04:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07838 for ; Mon, 7 Apr 2003 04:02:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3786Ln20803 for manet-archive@odin.ietf.org; Mon, 7 Apr 2003 04:06:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3786K820800 for ; Mon, 7 Apr 2003 04:06:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07834 for ; Mon, 7 Apr 2003 04:01:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377eo818680; Mon, 7 Apr 2003 03:40:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377Zj817696 for ; Mon, 7 Apr 2003 03:35:45 -0400 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05892 for ; Mon, 7 Apr 2003 03:31:06 -0400 (EDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h377XNS19148; Mon, 7 Apr 2003 09:33:23 +0200 (MEST) Message-ID: <3E9129C2.2F5B7679@inrialpes.fr> Date: Mon, 07 Apr 2003 09:33:22 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: S Woodside CC: Trail of Chaos , benchun , manet@ietf.org, geeks@false-profit.com, dylan@false-profit.com, claude.castelluccia@inrialpes.fr Subject: Re: [manet] Re: [geeks] Fwd: [BAWUG] I have a dream References: Content-Type: multipart/alternative; boundary="------------20E355E6CEEE68769988021E" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------20E355E6CEEE68769988021E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit S Woodside wrote: > > Source Routing is the only scalable solution. > > ??? broadcasting routing requests doesn't seem that scalable. Hello, I believe that source routing and routing requests broadcasting are 2 different things. Source routing is used to route the packets from the source to the destination and as shown in http://www.inrialpes.fr/planete/people/ccastel/RT4784.ps this can be made scalable. Broadcasting the RREQ is used to discover the route from the source to the destination and i agree with you that this can be a potential scalability problem...as you suggested a geographic approach might be useful here... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------20E355E6CEEE68769988021E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit S Woodside wrote:
> Source Routing is the only scalable solution.

??? broadcasting routing requests doesn't seem that scalable.

Hello,
I believe that source routing and routing requests broadcasting are 2 different things.
Source routing is used to route the packets from the source to the destination and
as shown in http://www.inrialpes.fr/planete/people/ccastel/RT4784.ps  this can be made scalable.

Broadcasting the RREQ is used to discover
the route from the source to the destination and i agree with you that this can be
a potential scalability problem...as you suggested a geographic approach might be
useful here...
regards,
Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------20E355E6CEEE68769988021E-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Apr 7 07:07:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14744 for ; Mon, 7 Apr 2003 07:07:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37BBMV01072 for manet-archive@odin.ietf.org; Mon, 7 Apr 2003 07:11:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BBM801069 for ; Mon, 7 Apr 2003 07:11:22 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14721 for ; Mon, 7 Apr 2003 07:06:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AlD831707; Mon, 7 Apr 2003 06:47:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Aha831583 for ; Mon, 7 Apr 2003 06:43:36 -0400 Received: from web41812.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14215 for ; Mon, 7 Apr 2003 06:38:55 -0400 (EDT) Message-ID: <20030407104127.12371.qmail@web41812.mail.yahoo.com> Received: from [193.95.32.166] by web41812.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 12:41:27 CEST Date: Mon, 7 Apr 2003 12:41:27 +0200 (CEST) From: =?iso-8859-1?q?ines=20benbrahim?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-776089933-1049712087=:12003" Content-Transfer-Encoding: 8bit Subject: [manet] Research about ad hoc routing protocols!! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --0-776089933-1049712087=:12003 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi every body , I am a student in computer engineering, I prepare my memory about QOS and routing protocols on ad hoic networks! I still search how can we guaranteed the QOS on this networks without any problems( energy, low delay...) can you help me by proposing me a topic what I can start with it in my research!! thank you! --------------------------------- Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Testez le nouveau Yahoo! Mail --0-776089933-1049712087=:12003 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi every body ,

I am a student in computer engineering, I prepare my memory about QOS and routing protocols on ad hoic networks! I still search how can we guaranteed the QOS on this networks without any problems( energy, low delay...)

can you help me by proposing me a topic what I can start with it in my research!!

thank you!

 

 

 


Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail --0-776089933-1049712087=:12003-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 00:45:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16724 for ; Tue, 8 Apr 2003 00:45:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h384oSQ09545 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 00:50:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384oS809542 for ; Tue, 8 Apr 2003 00:50:28 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16721 for ; Tue, 8 Apr 2003 00:45:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384XG808130; Tue, 8 Apr 2003 00:33:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384Me807852 for ; Tue, 8 Apr 2003 00:22:40 -0400 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16323 for ; Tue, 8 Apr 2003 00:17:23 -0400 (EDT) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h384KQGi028272 for ; Tue, 8 Apr 2003 12:20:26 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Tue, 08 Apr 2003 12:12:18 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 08 Apr 2003 12:12:06 +0800 From: "Tan Kean Soon" To: "<" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h384Me807853 Subject: [manet] Adaptive routing protocol based on network/node load Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Is there any protocol that does smart routing decisions by taking the traffic load in the network into consideration. Normally, route selection criteria uses metric such as shortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all packets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this issue? Thanks. Regards, Kean Soon _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 01:53:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18046 for ; Tue, 8 Apr 2003 01:53:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h385wBd13368 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 01:58:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h385wB813365 for ; Tue, 8 Apr 2003 01:58:11 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18033 for ; Tue, 8 Apr 2003 01:53:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h385du812569; Tue, 8 Apr 2003 01:39:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h385Zc811684 for ; Tue, 8 Apr 2003 01:35:38 -0400 Received: from ims21.stu.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17486 for ; Tue, 8 Apr 2003 01:30:33 -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.5329); Tue, 8 Apr 2003 13:32:50 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [manet] Adaptive routing protocol based on network/node load Date: Tue, 8 Apr 2003 13:32:50 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E02E07646@MBXSRV26.stu.nus.edu.sg> Thread-Topic: [manet] Adaptive routing protocol based on network/node load Thread-Index: AcL9iqjCGVthelEqTNGux3YxIKZNTAAAxobh From: "Marwaha Shivanajay" To: "Tan Kean Soon" , X-OriginalArrivalTime: 08 Apr 2003 05:32:50.0726 (UTC) FILETIME=[4BB7F460:01C2FD90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h385Zc811685 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, There are adaptive routing techniques for MANETs like: 1. http://w3.antd.nist.gov/pubs/roux_m2000.pdf "COST ADAPTIVE MECHANISM TO PROVIDE NETWORK DIVERSITY FOR MANET REACTIVE ROUTING PROTOCOLS" 2. A fuzzy-decision-based routing protocol for mobile ad hoc networks, ICON 2002 Regards, Shivanajay -----Original Message----- From: Tan Kean Soon [mailto:tanks@i2r.a-star.edu.sg] Sent: Tue 4/8/2003 12:12 PM To: < Cc: Subject: [manet] Adaptive routing protocol based on network/node load Hi, Is there any protocol that does smart routing decisions by taking the traffic load in the network into consideration. Normally, route selection criteria uses metric such as shortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all packets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this issue? Thanks. Regards, Kean Soon _______________________________________________ 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 mailnull@www1.ietf.org Tue Apr 8 04:43:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02625 for ; Tue, 8 Apr 2003 04:43:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h388mQZ03876 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 04:48:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h388mQ803873 for ; Tue, 8 Apr 2003 04:48:26 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02611 for ; Tue, 8 Apr 2003 04:43:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h388Jj801779; Tue, 8 Apr 2003 04:19:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h388A3801422 for ; Tue, 8 Apr 2003 04:10:03 -0400 Received: from sarcoui.clermont.cemagref.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01950 for ; Tue, 8 Apr 2003 04:04:50 -0400 (EDT) Received: by sarcoui.clermont.cemagref.fr with Internet Mail Service (5.5.2653.19) id <230V1PMC>; Tue, 8 Apr 2003 10:10:00 +0200 Message-ID: <3C6FDAE5CB60E34099D07C93376F6F5BAC80@sarcoui.clermont.cemagref.fr> From: Chanet Jean-Pierre To: "'haas@ece.cornell.edu'" , "Van Leeuwen, Brian P" Cc: "'manet@ietf.org'" Subject: RE: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Date: Tue, 8 Apr 2003 10:10:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDA6.401B13B0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , 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_01C2FDA6.401B13B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Do you test mobileroute ? Where can we find it in europe ? Jean-Pierre Jean-Pierre Chanet Cemagref UR TSCF 24 Av. des Landais BP 50085 63172 Aubi=E8re T=E9l. 04 73 44 06 78 / Fax 04 73 44 06 97 http://www.clermont.cemagref.fr -----Message d'origine----- De : haas@ece.cornell.edu [mailto:haas@ece.cornell.edu] Envoy=E9 : jeudi 3 avril 2003 00:41 =C0 : Van Leeuwen, Brian P Cc : 'manet@ietf.org'; Zygmunt Haas Objet : Re: [manet] Ad Hoc Networks Implemented in Deployed Systems?? Hi Brian, MobileRoute(TM) from Scientific Research Corporation, which is based on ZRP. See: http://www.scires.com/mobileroute.htm and their white paper: http://www.scires.com/pdfs/mr-wp.pdf Zygmunt. =3D=3D=3D--=3D=3D-=3D=3D=3D=3D ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-= ~- Prof. Zygmunt J. Haas = http://people.ece.cornell.edu/haas=20 Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering =20 Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A =20 WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-= ~- On Wed, 2 Apr 2003, Van Leeuwen, Brian P wrote: > Hello, >=20 > What kind of systems have ad hoc networks been used in to date? I'm = aware of > the Army's interest in using ad hoc networks in their future systems = but has > the Army or other organization built any ad hoc network based system? = Have > any systems, government or commercial, been developed to date that = use > wireless ad hoc networks? I'm interested in learning what systems, > experimental or deployed, have been built and if they published their > experience. >=20 > Any comments or suggestions are welcome. >=20 > Thanks for your help, >=20 > Brian >=20 > =20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ------_=_NextPart_001_01C2FDA6.401B13B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [manet] Ad Hoc Networks Implemented in Deployed = Systems??

Hello,

Do you test mobileroute ?
Where can we find it in europe ?

Jean-Pierre


Jean-Pierre Chanet
Cemagref
UR TSCF
24 Av. des Landais BP 50085 63172 Aubi=E8re
T=E9l. 04 73 44 06 78 / Fax 04 73 44 06 97
http://www.clermont.cemagref.fr


-----Message d'origine-----
De : haas@ece.cornell.edu [mailto:haas@ece.cornell.edu]
Envoy=E9 : jeudi 3 avril 2003 00:41
=C0 : Van Leeuwen, Brian P
Cc : 'manet@ietf.org'; Zygmunt Haas
Objet : Re: [manet] Ad Hoc Networks Implemented in = Deployed Systems??


Hi Brian,

MobileRoute(TM) from Scientific Research Corporation, = which is based
on ZRP. See:
        http://www.scires.com/mobileroute.htm

and their white paper:
        http://www.scires.com/pdfs/mr-wp.pdf

Zygmunt.
=3D=3D=3D--=3D=3D-=3D=3D=3D=3D
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~= -~-~-~-~-~-
Prof. Zygmunt J. = Haas           &n= bsp;        http://people.ece.cornell.edu/haas
Wireless Networks Laboratory    =          http://wnl.ece.cornell.edu
School of Electrical = Engineering        
Cornell University      =         =          tel: = +1-607-255-3454
323 Frank Rhodes Hall   =         =          fax: = +1-607-255-9072
Ithaca, NY = 14853        =         =          e-mail: = haas@ece.cornell.edu
U.S.A         &nbs= p;           &nbs= p;      
        WNL web = page: http://wnl.ece.cornell.edu
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~= -~-~-~-~-~-



On Wed, 2 Apr 2003, Van Leeuwen, Brian P = wrote:

> Hello,
>
> What kind of systems have ad hoc networks been = used in to date? I'm aware of
> the Army's interest in using ad hoc networks in = their future systems but has
> the Army or other organization built any ad hoc = network based system? Have
> any systems, government or commercial, been = developed to date that use
> wireless ad hoc networks? I'm interested in = learning what systems,
> experimental or deployed, have been built and = if they published their
> experience.
>
> Any comments or suggestions are welcome.
>
> Thanks for your help,
>
> Brian
>
> 
>
>
> = _______________________________________________
> 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_01C2FDA6.401B13B0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 10:26:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13618 for ; Tue, 8 Apr 2003 10:26:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38EVIE29702 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 10:31:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EVH829699 for ; Tue, 8 Apr 2003 10:31:17 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13480 for ; Tue, 8 Apr 2003 10:25:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ECc828401; Tue, 8 Apr 2003 10:12:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E6a827264 for ; Tue, 8 Apr 2003 10:06:36 -0400 Received: from mx1.isti.cnr.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10396 for ; Tue, 8 Apr 2003 10:01:19 -0400 (EDT) Received: from CONVERSION.MAIL.IAT.CNR.IT by mx.isti.cnr.it (PMDF V6.2 #30641) id <01KUHO6N4CGW9BVJTK@mx.isti.cnr.it> for manet@ietf.org; Tue, 08 Apr 2003 16:02:41 +0200 Received: from iit.cnr.it (imacbruno.cnuce.cnr.it [146.48.82.118]) by mx.isti.cnr.it (PMDF V6.2 #30641) with ESMTP id <01KUHO6N06X29D4C0I@mx.isti.cnr.it> for manet@ietf.org; Tue, 08 Apr 2003 16:02:41 +0200 Date: Tue, 08 Apr 2003 16:02:35 +0200 From: Raffaele Bruno To: manet@ietf.org Message-id: <3E92D67B.7060205@iit.cnr.it> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h+p9117lnOzh0mEPVTpoUQ)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 Subject: [manet] PWC2003: CALL FOR PROJECTS' PRESENTATIONS Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --Boundary_(ID_h+p9117lnOzh0mEPVTpoUQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [Our apologies if you receive multiple copies of this message] CALL FOR PROJECTS' PRESENTATIONS PWC 2003 The Eight International Conference on Personal Wireless Communications Sponsored by the IFIP WG 6.8 - Mobile and Wireless Communications http://www.iit.cnr.it/pwc2003/project-call.html September 23-25, 2003 Telecom Italia Future Centre - Venice, Italy http://www.futurecentre.telecomitalia.it/eng/ PWC is the premier international forum for discussions between researchers, practitioners and students interested in the symbiosis of mobile computing and wireless networks. PWC 2003 is the eight conference of this series and is sponsored by IFIP WG 6.8 The PWC 2003 technical program committee is soliciting extended abstracts presenting on-going research projects on wireless and mobile communications. Areas of interest include those that are listed on the conference call for papers, which can be found at http://www.iit.cnr.it/pwc2003 We are looking for projects performed either at a single-country level or involving several countries (e.g., European Commission projects) WHY should you submit a project presentation? --------------------------------------------- This is a great chance for disseminating the results of your project to a wide audience. Dissemination is the previous activity to exploitation, and could be considered as the market strategy to create awareness around your project. WHAT you have to do NOW ----------------------- You must submit an extended abstract presenting your project. An extended abstract (maximum 1500 words) must clearly describe the scope of the project, the innovative ideas behind it, partners involved, etc. In addition, if appropriate, please shortly present results already achieved. Extended abstracts will be reviewed for novelty, timeliness, and relevance for this conference. Submissions should be sent by email to pwc2003@iit.cnr.it by April 27, 2003. Please use the following subject: "pwc2003 project presentation". WHAT you have to do if the submission is accepted ------------------------------------------------- Authors of accepted submissions will prepare a camera-ready version of the extended abstract to be published in the conference proceedings published by Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series http://www.springer.de/comp/lncs/index.html In addition, you have to prepare a poster presenting your project and attend the PWC2003 poster session to present your poster. A poster is a 1 meter x 1.25 meter rectangular board on which you can affix visually appealing material that describes your research. How you use this is up to you: you may choose to print out several 8.5"x11" or A4 sheets of paper (e.g., paper copies of overheads) and "tile" the poster board with these pages. Or, you may choose to print a single large sheet of paper describing the work and attach that to the poster board. Several document companies produce professional-looking posters from material produced on software like Powerpoint; you may want to use such a facility. IMPORTANT DATES =============== Project presentation proposal due: April 27, 2003 Notification: May 15, 2003 Camera Ready due: June 10, 2003 --Boundary_(ID_h+p9117lnOzh0mEPVTpoUQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit PWC2003: CALL FOR PROJECTS' PRESENTATIONS
[Our apologies if you receive multiple copies of this message]


CALL FOR PROJECTS' PRESENTATIONS

PWC 2003

The Eight International Conference on Personal Wireless Communications Sponsored
by the IFIP WG 6.8 - Mobile and Wireless Communications

September 23-25, 2003 Telecom Italia Future Centre - Venice, Italy


PWC is the premier international forum for discussions between researchers,
practitioners and students interested in the symbiosis of mobile computing and
wireless networks. PWC 2003 is the eight conference of this series and is
sponsored by IFIP WG 6.8


The PWC 2003 technical program committee is soliciting extended abstracts
presenting on-going research projects on wireless and mobile communications.
Areas of interest include those that are listed on the conference call for
papers, which can be found at http://www.iit.cnr.it/pwc2003
We are looking for projects performed either at a single-country level or
involving several countries (e.g., European Commission projects)

WHY should you submit a project presentation?
---------------------------------------------
This is a great chance for disseminating the results of your project to a wide
audience. Dissemination is the previous activity to exploitation, and could be
considered as the market strategy to create awareness around your project.


WHAT you have to do NOW
-----------------------
You must submit an extended abstract presenting your project. An extended
abstract (maximum 1500 words) must clearly describe the scope of the project, the innovative ideas behind it, partners involved, etc. In addition, if appropriate, please shortly present results already achieved. Extended abstracts will be reviewed  for novelty, timeliness, and relevance for this conference.

Submissions should be sent by email to pwc2003@iit.cnr.it by April 27, 2003. Please use the following subject: "pwc2003 project presentation".


WHAT you have to do if the submission is accepted
-------------------------------------------------
Authors of accepted submissions will prepare a camera-ready version of the extended
abstract to be published in the conference proceedings published by
Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series

In addition, you have to prepare a poster presenting your project and
attend the PWC2003 poster session to present your poster.

A poster is a 1 meter x 1.25 meter rectangular board on which you can affix
visually appealing material that describes your research. How you use this is up
to you: you may choose to print out several 8.5"x11" or A4 sheets of paper (e.g., paper copies of overheads) and "tile" the poster board with these pages. Or, you may choose to print a single large sheet of paper describing the work and attach that to the poster board. Several document companies produce professional-looking posters from material produced on software like Powerpoint; you may want to use such a facility.


IMPORTANT DATES
===============

Project presentation proposal due: April 27, 2003

Notification:   May 15, 2003

Camera Ready due: June 10, 2003
--Boundary_(ID_h+p9117lnOzh0mEPVTpoUQ)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 15:06:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27192 for ; Tue, 8 Apr 2003 15:06:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38JBIv21312 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 15:11:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38JBI821309 for ; Tue, 8 Apr 2003 15:11:18 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27130 for ; Tue, 8 Apr 2003 15:05:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IlU818978; Tue, 8 Apr 2003 14:47:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Iec818727 for ; Tue, 8 Apr 2003 14:40:38 -0400 Received: from prue.eim.surrey.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25615 for ; Tue, 8 Apr 2003 14:35:19 -0400 (EDT) Received: from romeo.ee.surrey.ac.uk ([131.227.76.30] helo=eim.surrey.ac.uk ident=www) by prue.eim.surrey.ac.uk with smtp (Exim 3.33 #4) id 192xyY-00045V-00 for manet@ietf.org; Tue, 08 Apr 2003 19:37:42 +0100 Received: from ucs332.surrey.ac.uk ([131.227.107.62]) (SquirrelMail authenticated user eem1tk) by secure.eps.surrey.ac.uk with HTTP; Tue, 8 Apr 2003 19:37:42 +0100 (BST) Message-ID: <2894.131.227.107.62.1049827062.squirrel@secure.eps.surrey.ac.uk> Date: Tue, 8 Apr 2003 19:37:42 +0100 (BST) From: "Teng Kang" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-109.3 required=5.5 tests=AWL,BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *192xyY-00045V-00*nj0BRKgeePs* (SECM, UniS) Content-Transfer-Encoding: 8bit Subject: [manet] Any advice on such situtation(mailing list of ULCA) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear all: As I mentioned before the problem on subscrbing the mailing list in UCLA still exists. Last time I didn't show the response from it. After it gave me such feedback below there is not any further information. I hope any one here can give me some hints to solve this problem. Now the command I used and the reply it backed are given below: > SUBSCRIBE GLOMOSIM-ANNOUNC-L Your request to join the GLOMOSIM-ANNOUNC-L list has been forwarded to the list owner for approval. If you have any question about the list, you can reach the list owner at GLOMOSIM-ANNOUNC-L-request@LISTSERV.UCLA.EDU. Summary of resource utilization ------------------------------- CPU time: 0.010 sec Overhead CPU: 0.030 sec CPU model: i86pc (320M) Job origin: eem1tk@EIM.SURREY.AC.UK All your answer are welcome and I am gratful to your help! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 15:11:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28010 for ; Tue, 8 Apr 2003 15:11:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38JGWA21668 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 15:16:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38JGW821665 for ; Tue, 8 Apr 2003 15:16:32 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27957 for ; Tue, 8 Apr 2003 15:11:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IrM819214; Tue, 8 Apr 2003 14:53:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ije818902 for ; Tue, 8 Apr 2003 14:45:40 -0400 Received: from caduceus.sc.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25799 for ; Tue, 8 Apr 2003 14:40:19 -0400 (EDT) Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by caduceus.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h38IfkT09111 for ; Tue, 8 Apr 2003 18:41:46 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h38Ifk113230 for ; Tue, 8 Apr 2003 18:41:46 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040811404517758 ; Tue, 08 Apr 2003 11:40:45 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 11:42:50 -0700 Message-ID: From: "Yang, Lily L" To: "'Elizabeth M. Belding-Royer'" , ans-research@www1.ietf.org Cc: manet@ietf.org Date: Tue, 8 Apr 2003 11:42:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] RE: [Ans-research] The Charter Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , I wasn't able to attend the BAR BOF -- personally I would like to understand how, among many interesting topics, scalability was chosen to be the one focus for this research group. Is that because people perceive the difficulty to scale ad hoc network into thousands or millions of nodes as the next biggest obstacle we face today in deploying such network? I would think there are many other challenges like QoS, self-configuration, seamless integration with the wired network, etc. -- even just for small to medium size networks -- that are more urgent but have not been adequately addressed in the research community. I was certainly hoping to see this group as a forum to discuss all these challenges in addition to scalability. Elizabeth suggested these topics can be discussed from the angle of how these interact with scalability issue. But my concern is that it is premature to discuss these issues for large networks while we don't even have good handle on them for small to medium size networks. Another concern I have on focusing on scalability is how this overlap with the current charter of the IETF MANET group. At the San Francisco MANET meeting, there was quite a heated disucssion without much resolution on how the MANET group proceed on standardizing one or two routing protocols for ad hoc networks. One of the suggestion is to come up with a set of network scenarios and evaluation metric so that fair evalution can be done on the existing protocols. This sounds a bit similar to what the ANS group is about to do as the first step, but of course with a focus on scalability. However, it wasn't clear to me whether scalability is one of the concern when evalauting the existing protocols produced by the MANET group in its effort to standardize one or two. So maybe the chairs of these two groups can explain exactly how the line is divided here between the work done by two groups? Overall I believe it is a good thing for the IETF MANET group to become very focus and engineering-oriented, but on the same time, I hope the ANS group can be more open in accomodating the research needs that are clearly outside of MANET but have been actively purseud by many people in the community. I post this to both groups because of the nature of my questions. Lily > -----Original Message----- > From: Elizabeth M. Belding-Royer [mailto:ebelding@cs.ucsb.edu] > Sent: Tuesday, April 08, 2003 9:12 AM > To: ans-research@www1.ietf.org > Subject: [Ans-research] The Charter > > > It is my understanding that IRTF group charters do not have > to be "strictly" adhered to in the sense that IETF charters > do. In that sense, you can take the charter goal of scalable > ad hoc networks rather loosely. So then, any ideas that will > help improve the scalability of ad hoc networks are welcome. > Hence, cross-layer interactions, addressing mechanisms, protocols > (new or rehashed), etc. are all welcome ideas if the end goal > is to improve the scalability of the network (of course, what > scalable means is what we are still working on). > > Another point to note is that scalability can be looked at > in a number of different areas. Routing, QoS, reliability, > etc. are all important topics because they can also affect the > scalability of the network. So Sukanta was right when he said > no topics have really received a red flag, except for security. > As long as the focus of the group remains narrow enough that > we are still able to make progress then I think we are headed > in the right direction. > > Elizabeth > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 15:14:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28257 for ; Tue, 8 Apr 2003 15:14:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38JIvV21766 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 15:18:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38JIv821763 for ; Tue, 8 Apr 2003 15:18:57 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28199 for ; Tue, 8 Apr 2003 15:13:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Its819375; Tue, 8 Apr 2003 14:55:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ijs818918 for ; Tue, 8 Apr 2003 14:45:54 -0400 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25815 for ; Tue, 8 Apr 2003 14:40:33 -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 LAA01491; Tue, 8 Apr 2003 11:43:00 -0700 (PDT) Message-Id: <200304081843.LAA01491@pit.erg.sri.com> To: "Tan Kean Soon" cc: "<" Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Adaptive routing protocol based on network/node load In-reply-to: Your message of "Tue, 08 Apr 2003 12:12:06 +0800." Date: Tue, 08 Apr 2003 11:43:00 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > Hi, > Is there any protocol that does smart routing decisions by taking the tra ffic load in the network into consideration. Normally, route selection crit eria uses metric such as shortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all pack ets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this is sue? Hi Kean, There are several such protocols. Here is one of them: P. Gupta and P. R. Kumar, ``A system and traffic dependent adaptive routing algorithm for ad hoc networks,'' Proceedings of the 36th IEEE Conference on Decision and Control, pp. 2375-2380, San Diego, Dec. 1997. Even before that, I designed such a protocol (with John Hight, Dave Beyer, and others) called STIP (Secure Tactical Internet Protocol) in 1993, which was not published but can be found in the following project report: J. Hight, E. Costa, D. Lee, R. Ogier, J. Wong. "Evaluation and Development of Multimedia Networks in Dynamic Stress (EDMUNDS): Final Technical Report", SRI Technical Report ITAD-8558-FR-93-277, October 1993. I know there are more recent routing protocols that take traffic load into account, but I wanted to point out that such protocols were developed 10 years ago. Richard > > Thanks. > > Regards, > Kean Soon > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Apr 8 16:41:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01307 for ; Tue, 8 Apr 2003 16:41:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Kk9A28559 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 16:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Kk9828556 for ; Tue, 8 Apr 2003 16:46:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01284 for ; Tue, 8 Apr 2003 16:40:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KHm826171; Tue, 8 Apr 2003 16:17:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KDe826054 for ; Tue, 8 Apr 2003 16:13:40 -0400 Received: from memphis.ece.cornell.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00210 for ; Tue, 8 Apr 2003 16:08:18 -0400 (EDT) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h38KAlR03267; Tue, 8 Apr 2003 16:10:47 -0400 Date: Tue, 8 Apr 2003 16:04:21 -0400 (EDT) From: Prince Samar To: Tan Kean Soon cc: manet@ietf.org, Zygmunt Haas Subject: Re: [manet] Adaptive routing protocol based on network/node load In-Reply-To: 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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Kean, We have extended the concept of ZRP to develop the Independent Zone Routing (IZR) framework, where each node has the capability to maintain an independently sized routing zone. This allows each node in the network to adaptively configure its own optimal zone radius in a distributed fashion. This ability of a node to provide fine-tuned adaptation to variations in network characteristics (like mobility, calling patterns and load) over time and space enables the framework to perform well in any kind of ad hoc network. The following paper is currently under review. P. Samar, M.R. Pearlman, Z.J. Haas, "Independent Zone Routing: An Adaptive Hybrid Routing Framework for Ad Hoc Wireless Networks," under review. Regards, Prince On Tue, 8 Apr 2003, Tan Kean Soon wrote: >Hi, >Is there any protocol that does smart routing decisions by taking the >traffic load in the network into consideration. Normally, route selection >criteria uses metric such as shortest number of hops and quickest >response time to a request. Such decision making can lead to the >situation where all packets are routed through the same node even if >there exist better routes where the traffic load is not as large. Could >somebody shed some light on this issue? > >Thanks. > >Regards, >Kean Soon > >_______________________________________________ >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 mailnull@www1.ietf.org Tue Apr 8 16:47:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01530 for ; Tue, 8 Apr 2003 16:47:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Kq4r28900 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 16:52:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Kq4828897 for ; Tue, 8 Apr 2003 16:52:04 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01523 for ; Tue, 8 Apr 2003 16:46:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KPY826595; Tue, 8 Apr 2003 16:25:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KMc826418 for ; Tue, 8 Apr 2003 16:22:38 -0400 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00336 for ; Tue, 8 Apr 2003 16:17:14 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h38KJdC28602; Tue, 8 Apr 2003 13:19:39 -0700 (PDT) Message-Id: <200304082019.h38KJdC28602@letters.cs.ucsb.edu> Date: Tue, 8 Apr 2003 13:19:39 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: ebelding@cs.ucsb.edu, ans-research@www1.ietf.org, lily.l.yang@intel.com Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iD8PxYK8P4jA7evdDdemKw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] RE: [Ans-research] The Charter Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , ~> ~> I wasn't able to attend the BAR BOF -- personally I would like to understand ~> how, among many interesting topics, scalability was chosen to be the one ~> focus for this research group. Is that because people perceive the ~> difficulty to scale ad hoc network into thousands or millions of nodes as ~> the next biggest obstacle we face today in deploying such network? I would ~> think there are many other challenges like QoS, self-configuration, seamless ~> integration with the wired network, etc. -- even just for small to medium ~> size networks -- that are more urgent but have not been adequately addressed ~> in the research community. I was certainly hoping to see this group as a ~> forum to discuss all these challenges in addition to scalability. Elizabeth ~> suggested these topics can be discussed from the angle of how these interact ~> with scalability issue. But my concern is that it is premature to discuss ~> these issues for large networks while we don't even have good handle on them ~> for small to medium size networks. ~> My understanding is that scalability was chosen in part to handle some of the research that had previously been submitted to MANET but was now out of scope because of the new MANET charter. The other part was because scalability has been far less researched than many other topics. There are already some reasonable ideas about what works and doesn't work in many areas of ad hoc networking, but little work has been done in the area of scalability. I don't know that IRTF groups are supposed to handle urgent topics. I'm speaking from my understanding of how the group was chartered. I actually became co-chair after the charter was already in place. Hopefuuly Scott can correct anything I said that it inaccurate. ~> Another concern I have on focusing on scalability is how this overlap with ~> the current charter of the IETF MANET group. At the San Francisco MANET ~> meeting, there was quite a heated disucssion without much resolution on how ~> the MANET group proceed on standardizing one or two routing protocols for ad ~> hoc networks. One of the suggestion is to come up with a set of network ~> scenarios and evaluation metric so that fair evalution can be done on the ~> existing protocols. This sounds a bit similar to what the ANS group is about ~> to do as the first step, but of course with a focus on scalability. However, ~> it wasn't clear to me whether scalability is one of the concern when ~> evalauting the existing protocols produced by the MANET group in its effort ~> to standardize one or two. So maybe the chairs of these two groups can ~> explain exactly how the line is divided here between the work done by two ~> groups? ~> In defining scalability, we are basically determining the dimensions on which an ad hoc network can be defined. I think this directly relates to what MANET is trying to do. They are trying to determine what metrics should be used to define a network, which is what we will determine when defining scalability. One of the goals of the ANS RG is to produce knowledge that is usable by other groups, such as MANET. ~> Overall I believe it is a good thing for the IETF MANET group to become very ~> focus and engineering-oriented, but on the same time, I hope the ANS group ~> can be more open in accomodating the research needs that are clearly outside ~> of MANET but have been actively purseud by many people in the community. ~> I hope I gave the impression in my prior email that the group was going to be accommodating in many areas. That was my intention. At the same time, I think its important to be realistic about how many topics a single group can incorporate while still being productive and reasonably focussed. If you look at the topics of the other IRTF research groups, I think you will find that we are headed in the direction of a much broader scope than the other previously chartered groups. I don't think you will find any single wired networking group that focuses on all of Scalability, Qos, Reliability, Multicast, etc. Each topic is typically the focus of a single group. In that sense, I think our focus is very broad (but hopefully not too broad if we keep scalability in mind). Elizabeth ~> I post this to both groups because of the nature of my questions. ~> ~> Lily ~> ~> > -----Original Message----- ~> > From: Elizabeth M. Belding-Royer [mailto:ebelding@cs.ucsb.edu] ~> > Sent: Tuesday, April 08, 2003 9:12 AM ~> > To: ans-research@www1.ietf.org ~> > Subject: [Ans-research] The Charter ~> > ~> > ~> > It is my understanding that IRTF group charters do not have ~> > to be "strictly" adhered to in the sense that IETF charters ~> > do. In that sense, you can take the charter goal of scalable ~> > ad hoc networks rather loosely. So then, any ideas that will ~> > help improve the scalability of ad hoc networks are welcome. ~> > Hence, cross-layer interactions, addressing mechanisms, protocols ~> > (new or rehashed), etc. are all welcome ideas if the end goal ~> > is to improve the scalability of the network (of course, what ~> > scalable means is what we are still working on). ~> > ~> > Another point to note is that scalability can be looked at ~> > in a number of different areas. Routing, QoS, reliability, ~> > etc. are all important topics because they can also affect the ~> > scalability of the network. So Sukanta was right when he said ~> > no topics have really received a red flag, except for security. ~> > As long as the focus of the group remains narrow enough that ~> > we are still able to make progress then I think we are headed ~> > in the right direction. ~> > ~> > Elizabeth ~> > ~> > _______________________________________________ ~> > Ans-research mailing list ~> > Ans-research@www1.ietf.org ~> > https://www1.ietf.org/mailman/listinfo/ans-research ~> > ~> _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 17:00:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01984 for ; Tue, 8 Apr 2003 17:00:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38L54j30213 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 17:05:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38L54830210 for ; Tue, 8 Apr 2003 17:05:04 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01950 for ; Tue, 8 Apr 2003 16:59:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Kfc828328; Tue, 8 Apr 2003 16:41:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Kcg828183 for ; Tue, 8 Apr 2003 16:38:42 -0400 Received: from web8007.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01026 for ; Tue, 8 Apr 2003 16:33:19 -0400 (EDT) Message-ID: <20030408203551.440.qmail@web8007.mail.in.yahoo.com> Received: from [202.141.80.20] by web8007.mail.in.yahoo.com via HTTP; Tue, 08 Apr 2003 21:35:51 BST Date: Tue, 8 Apr 2003 21:35:51 +0100 (BST) From: =?iso-8859-1?q?Jitesh=20Shah?= Subject: Re: [manet] Adaptive routing protocol based on network/node load To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Just to add to the list of the various Adaptive protocols based on the network/node load, we have developed the following routing protocol, which has incorporated the concept of cost function. Not only is it adaptive but also a secure routing scheme. Please download the paper from the following link: http://www.iitg.ernet.in/engfac/ece/~jshah/papers/adhoc/adapsec.pdf --- Prince Samar wrote: > > Hi Kean, > > We have extended the concept of ZRP to develop the > Independent Zone > Routing (IZR) framework, where each node has the > capability to maintain an > independently sized routing zone. This allows each > node in the network to > adaptively configure its own optimal zone radius in > a distributed fashion. > This ability of a node to provide fine-tuned > adaptation to variations in > network characteristics (like mobility, calling > patterns and load) over > time and space enables the framework to perform well > in any kind of ad hoc > network. The following paper is currently under > review. > > P. Samar, M.R. Pearlman, Z.J. Haas, "Independent > Zone Routing: An > Adaptive Hybrid Routing Framework for Ad Hoc > Wireless Networks," under > review. > > Regards, > Prince > > > On Tue, 8 Apr 2003, Tan Kean Soon wrote: > > >Hi, > >Is there any protocol that does smart routing > decisions by taking the > >traffic load in the network into consideration. > Normally, route selection > >criteria uses metric such as shortest number of > hops and quickest > >response time to a request. Such decision making > can lead to the > >situation where all packets are routed through the > same node even if > >there exist better routes where the traffic load is > not as large. Could > >somebody shed some light on this issue? > > > >Thanks. > > > >Regards, > >Kean Soon > > > >_______________________________________________ > >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 ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 17:22:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02898 for ; Tue, 8 Apr 2003 17:22:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38LRpF32332 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 17:27:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LRp832329 for ; Tue, 8 Apr 2003 17:27:51 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02890 for ; Tue, 8 Apr 2003 17:22:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38L1F829762; Tue, 8 Apr 2003 17:01:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KvN829201 for ; Tue, 8 Apr 2003 16:57:23 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01645 for ; Tue, 8 Apr 2003 16:52:00 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h38KsUgE015187; Tue, 8 Apr 2003 13:54:31 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AFX84212; Tue, 8 Apr 2003 13:52:48 -0700 (PDT) Message-Id: <5.2.0.9.2.20030408135123.076aee88@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 08 Apr 2003 13:53:58 -0700 To: "Jagan S" From: Fred Baker Subject: Re: [manet] Routing using IPv6 Cc: manet@ietf.org In-Reply-To: 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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 10:13 AM 4/5/2003 +0530, Jagan S wrote: >Can someone tell me about the available stuff on using "IPv6 for providing >routing mechanism in MANET" networks. Routing is generally a matter of creating a graph among the nodes in a graph - a lattice of routers with interconnection topologies - and then decorating the graph with prefixes. We can carry your favorite routing protocol in IPv4 or IPv6, and we can decorate the graph with IPv4 or IPv6 prefixes. The only thing that comes quickly to mind is my suggestion of using OSPF V3 last year, whose LSAs are designed around IPv6 and which identifies neighbors using IPv6 link local addresses. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 17:44:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03489 for ; Tue, 8 Apr 2003 17:44:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38LnBL01975 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 17:49:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LnB801972 for ; Tue, 8 Apr 2003 17:49:11 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03467 for ; Tue, 8 Apr 2003 17:43:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LMv832091; Tue, 8 Apr 2003 17:22:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LGt831852 for ; Tue, 8 Apr 2003 17:16:55 -0400 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02615 for ; Tue, 8 Apr 2003 17:11:31 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h38LE2ap014498; Tue, 8 Apr 2003 17:14:02 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h38LDvWe020579; Tue, 8 Apr 2003 17:13:57 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040817135607231 ; Tue, 08 Apr 2003 17:13:56 -0400 Message-Id: <5.1.1.5.2.20030408165258.0294ac28@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 08 Apr 2003 17:13:52 -0400 To: "Elizabeth M. Belding-Royer" , ebelding@cs.ucsb.edu, ans-research@www1.ietf.org, lily.l.yang@intel.com From: Joe Macker Cc: manet@ietf.org In-Reply-To: <200304082019.h38KJdC28602@letters.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] RE: [Ans-research] The Charter Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 01:19 PM 4/8/2003 -0700, Elizabeth M. Belding-Royer wrote: >~> >~> I wasn't able to attend the BAR BOF -- personally I would like to understand >~> how, among many interesting topics, scalability was chosen to be the one >~> focus for this research group. Is that because people perceive the >~> difficulty to scale ad hoc network into thousands or millions of nodes as >~> the next biggest obstacle we face today in deploying such network? I would >~> think there are many other challenges like QoS, self-configuration, seamless >~> integration with the wired network, etc. -- even just for small to medium >~> size networks -- that are more urgent but have not been adequately addressed >~> in the research community. I was certainly hoping to see this group as a >~> forum to discuss all these challenges in addition to scalability. Elizabeth >~> suggested these topics can be discussed from the angle of how these interact >~> with scalability issue. But my concern is that it is premature to discuss >~> these issues for large networks while we don't even have good handle on them >~> for small to medium size networks. >~> > >My understanding is that scalability was chosen in part to handle some >of the research that had previously been submitted to MANET but was >now out of scope because of the new MANET charter. The other part was >because scalability has been far less researched than many other topics. >There are already some reasonable ideas about what works and doesn't >work in many areas of ad hoc networking, but little work has been done >in the area of scalability. I don't know that IRTF groups are supposed >to handle urgent topics. I took back from the discussions that the IRTF effort would be flexible and more open in topic coverage. I think we can address some more basic configuration and integration issues for small to medium networks at the IETF level. There are more complex autoconfiguration scenarios and they may be appropriate for the IRTF what is your particular scenario of interest? I am also hoping the IRTF is reasonable flexible and open to new thoughts and ideas. BTW, I (and others) have setup quite a few networks operating this way today (Internet stub area operation and some basic autoconfiguration).. >I hope I gave the impression in my prior email that the group was >going to be accommodating in many areas. That was my intention. >At the same time, I think its important to be realistic about how >many topics a single group can incorporate while still being >productive and reasonably focussed. If you look at the topics of >the other IRTF research groups, I think you will find that we are >headed in the direction of a much broader scope than the other >previously chartered groups. I don't think you will find any single >wired networking group that focuses on all of Scalability, Qos, >Reliability, Multicast, etc. Each topic is typically the focus >of a single group. In that sense, I think our focus is very broad >(but hopefully not too broad if we keep scalability in mind). I think an IRTF is intended to be very flexible and open but it does need to direct its efforts over time to what seems suitable and useful. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 17:46:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03557 for ; Tue, 8 Apr 2003 17:46:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Lp7802088 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 17:51:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Lp7802085 for ; Tue, 8 Apr 2003 17:51:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03548 for ; Tue, 8 Apr 2003 17:45:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LSZ832366; Tue, 8 Apr 2003 17:28:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LJY831929 for ; Tue, 8 Apr 2003 17:19:34 -0400 Received: from tosh.netlab.uky.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02724 for ; Tue, 8 Apr 2003 17:14:10 -0400 (EDT) Received: from beech.netlab.uky.edu (beech.netlab.uky.edu [204.198.76.75]) by tosh.netlab.uky.edu (Postfix) with ESMTP id F2413CE86; Tue, 8 Apr 2003 17:16:43 -0400 (EDT) Received: by beech.netlab.uky.edu (Postfix, from userid 1109) id EE24A950ED; Tue, 8 Apr 2003 17:16:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by beech.netlab.uky.edu (Postfix) with ESMTP id EA95CFE93; Tue, 8 Apr 2003 17:16:43 -0400 (EDT) Date: Tue, 8 Apr 2003 17:16:43 -0400 (EDT) From: Krishna Prabhala To: =?iso-8859-1?q?Jitesh=20Shah?= Cc: manet@ietf.org Subject: Re: [manet] Adaptive routing protocol based on network/node load In-Reply-To: <20030408203551.440.qmail@web8007.mail.in.yahoo.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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, The link seems to be broken. Krishna. On Tue, 8 Apr 2003, Jitesh Shah wrote: - Hi, - - Just to add to the list of the various Adaptive - protocols based on the network/node load, we have - developed the following routing protocol, which has - incorporated the concept of cost function. Not only is - it adaptive but also a secure routing scheme. Please - download the paper from the following link: - - http://www.iitg.ernet.in/engfac/ece/~jshah/papers/adhoc/adapsec.pdf - - --- Prince Samar wrote: > - > Hi Kean, - > - > We have extended the concept of ZRP to develop the - > Independent Zone - > Routing (IZR) framework, where each node has the - > capability to maintain an - > independently sized routing zone. This allows each - > node in the network to - > adaptively configure its own optimal zone radius in - > a distributed fashion. - > This ability of a node to provide fine-tuned - > adaptation to variations in - > network characteristics (like mobility, calling - > patterns and load) over - > time and space enables the framework to perform well - > in any kind of ad hoc - > network. The following paper is currently under - > review. - > - > P. Samar, M.R. Pearlman, Z.J. Haas, "Independent - > Zone Routing: An - > Adaptive Hybrid Routing Framework for Ad Hoc - > Wireless Networks," under - > review. - > - > Regards, - > Prince - > - > - > On Tue, 8 Apr 2003, Tan Kean Soon wrote: - > - > >Hi, - > >Is there any protocol that does smart routing - > decisions by taking the - > >traffic load in the network into consideration. - > Normally, route selection - > >criteria uses metric such as shortest number of - > hops and quickest - > >response time to a request. Such decision making - > can lead to the - > >situation where all packets are routed through the - > same node even if - > >there exist better routes where the traffic load is - > not as large. Could - > >somebody shed some light on this issue? - > > - > >Thanks. - > > - > >Regards, - > >Kean Soon - > > - > >_______________________________________________ - > >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 - - ________________________________________________________________________ - Missed your favourite TV serial last night? Try the new, Yahoo! TV. - visit http://in.tv.yahoo.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 mailnull@www1.ietf.org Tue Apr 8 18:08:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04991 for ; Tue, 8 Apr 2003 18:08:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MD6h04099 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 18:13:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MD6804096 for ; Tue, 8 Apr 2003 18:13:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04918 for ; Tue, 8 Apr 2003 18:07:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ll2801820; Tue, 8 Apr 2003 17:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Lgv801642 for ; Tue, 8 Apr 2003 17:42:57 -0400 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03326 for ; Tue, 8 Apr 2003 17:37:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00640; Tue, 8 Apr 2003 14:40:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h38Le4Z11057; Tue, 8 Apr 2003 14:40:04 -0700 X-mProtect: <200304082140> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvOPW1H; Tue, 08 Apr 2003 14:40:02 PDT Message-ID: <3E9341B2.9B46CD5F@iprg.nokia.com> Date: Tue, 08 Apr 2003 14:40:02 -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: Jagan S CC: Fred Baker , manet@ietf.org Subject: Re: [manet] Routing using IPv6 References: <5.2.0.9.2.20030408135123.076aee88@mira-sjc5-b.cisco.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-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jagan, You can also take a look at AODV for IPv6: http://people.nokia.net/~charliep/txt/aodvid/aodv6.txt I reckon we ought to resubmit it sometime or another, but it should still work just fine. Also, for Internet Gateway connectivity, please see: http://www.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-02.txt Regards, Charlie P. Fred Baker wrote: > > At 10:13 AM 4/5/2003 +0530, Jagan S wrote: > >Can someone tell me about the available stuff on using "IPv6 for providing > >routing mechanism in MANET" networks. > > Routing is generally a matter of creating a graph among the nodes in a > graph - a lattice of routers with interconnection topologies - and then > decorating the graph with prefixes. We can carry your favorite routing > protocol in IPv4 or IPv6, and we can decorate the graph with IPv4 or IPv6 > prefixes. > > The only thing that comes quickly to mind is my suggestion of using OSPF V3 > last year, whose LSAs are designed around IPv6 and which identifies > neighbors using IPv6 link local addresses. > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Apr 8 18:16:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05940 for ; Tue, 8 Apr 2003 18:16:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MLqn04583 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 18:21:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MLq804580 for ; Tue, 8 Apr 2003 18:21:52 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05922 for ; Tue, 8 Apr 2003 18:16:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LwU802426; Tue, 8 Apr 2003 17:58:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LtP802282 for ; Tue, 8 Apr 2003 17:55:25 -0400 Received: from exchfe2.cs.cornell.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03678 for ; Tue, 8 Apr 2003 17:50:00 -0400 (EDT) Received: from EXCHVS2.cs.cornell.edu ([128.84.97.24]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Apr 2003 17:52:13 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [manet] Adaptive routing protocol based on network/node load Date: Tue, 8 Apr 2003 17:52:13 -0400 Message-ID: Thread-Topic: [manet] Adaptive routing protocol based on network/node load Thread-Index: AcL+Dgys2KO0PLHSQra8ajsM+wLcrwABzFNg From: "Venu Ramasubramanian" To: X-OriginalArrivalTime: 08 Apr 2003 21:52:13.0539 (UTC) FILETIME=[1D15A330:01C2FE19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38LtP802283 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, We have developed a hybrid and adaptive routing protocol called SHARP for mobile ad hoc networks. SHARP combines a proactive and a reactive routing algorithm and adapts the extent of proactive versus reactive routing based on observed network characteristics, such as link failure rate and node degree, and traffic characteristics, such as number of sources transmitting data to a destination and length of routes. SHARP enables each destination node to independently adjust the amount of hybridization in order to control the routing performance based on application requirements. Currently, SHARP based protocols enable nodes to achieve three different application-specific goals, namely, minimal routing overhead, bounded loss rate, and bounded delay jitter. A paper on SHARP would be presented in MobiHoc 2003. Venugopalan Ramasubramanian, Zygmunt J Haas, and Emin Gun Sirer. SHARP: A Hybrid Adaptive Routing Protocol for Mobile Ad Hoc Networks. In Proceedings of the Fourth International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc) 2003, Annapolis, MD, June 3-6, 2003. yours, rama ---------------------------------------------------------------------------------------------------------------------------- Ramasubramanian, Venugopalan (Rama) Dept. of Computer Science, Cornell University, Ithaca, NY 14853. Ph: 607-254-5075. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 18:40:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06908 for ; Tue, 8 Apr 2003 18:40:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MjKb06917 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 18:45:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MjK806914 for ; Tue, 8 Apr 2003 18:45:20 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06894 for ; Tue, 8 Apr 2003 18:39:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MI2804335; Tue, 8 Apr 2003 18:18:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MDs804132 for ; Tue, 8 Apr 2003 18:13:54 -0400 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05037 for ; Tue, 8 Apr 2003 18:08:28 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h38MArap017002; Tue, 8 Apr 2003 18:10:53 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h38MAhWg021326; Tue, 8 Apr 2003 18:10:48 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040818104807541 ; Tue, 08 Apr 2003 18:10:48 -0400 Message-Id: <5.1.1.5.2.20030408180347.014e1360@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 08 Apr 2003 18:10:47 -0400 To: Fred Baker , "Jagan S" From: Joe Macker Subject: Re: [manet] Routing using IPv6 Cc: manet@ietf.org In-Reply-To: <5.2.0.9.2.20030408135123.076aee88@mira-sjc5-b.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 01:53 PM 4/8/2003 -0700, Fred Baker wrote: >At 10:13 AM 4/5/2003 +0530, Jagan S wrote: >>Can someone tell me about the available stuff on using "IPv6 for providing >>routing mechanism in MANET" networks. > >Routing is generally a matter of creating a graph among the nodes in a graph - a lattice of routers with interconnection topologies - and then decorating the graph with prefixes. We can carry your favorite routing protocol in IPv4 or IPv6, and we can decorate the graph with IPv4 or IPv6 prefixes. > >The only thing that comes quickly to mind is my suggestion of using OSPF V3 last year, whose LSAs are designed around IPv6 and which identifies neighbors using IPv6 link local addresses. As Fred says, routing protocols can be made to support either. I have heard or seen of several prototype implementations around supporting IPv6 specifically (e.g., AODV, TBRPF, OLSR). Present releasability amd maturity varies..... >_______________________________________________ >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 mailnull@www1.ietf.org Tue Apr 8 18:44:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07016 for ; Tue, 8 Apr 2003 18:44:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MnQh07087 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 18:49:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MnQ807084 for ; Tue, 8 Apr 2003 18:49:26 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07005 for ; Tue, 8 Apr 2003 18:44:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MPw804810; Tue, 8 Apr 2003 18:25:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MLh804567 for ; Tue, 8 Apr 2003 18:21:43 -0400 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05900 for ; Tue, 8 Apr 2003 18:16:17 -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 PAA02253; Tue, 8 Apr 2003 15:18:47 -0700 (PDT) Message-Id: <200304082218.PAA02253@pit.erg.sri.com> To: "Tan Kean Soon" cc: "<" Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Adaptive routing protocol based on network/node load In-reply-to: Your message of "Tue, 08 Apr 2003 12:12:06 +0800." Date: Tue, 08 Apr 2003 15:18:47 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > Hi, > Is there any protocol that does smart routing decisions by taking the traffic load in the network into consideration. Normally, route selection criteria uses metric such as s hortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all packets are routed through the same node even if there e xist better routes where the traffic load is not as large. Could somebody shed some light on this issue? I understand that you are talking about selecting routes that avoid congestion, and possibly dividing traffic among multiple routes. The protocols I mentioned in my previous message address this. I want to point this out because the two recent posts from Cornell address a different problem: deciding the degree of proactive vs. reactive routing. Richard > > Thanks. > > Regards, > Kean Soon > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Apr 8 18:54:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07337 for ; Tue, 8 Apr 2003 18:54:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MxcP07599 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 18:59:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Mxc807596 for ; Tue, 8 Apr 2003 18:59:38 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07329 for ; Tue, 8 Apr 2003 18:54:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MZg805463; Tue, 8 Apr 2003 18:35:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MW8805292 for ; Tue, 8 Apr 2003 18:32:08 -0400 Received: from mail.scires.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06304 for ; Tue, 8 Apr 2003 18:26:42 -0400 (EDT) Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Tue, 08 Apr 2003 18:30:07 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 08 Apr 2003 18:29:37 -0400 From: "Pete Sholander" To: , Cc: Subject: Re: [manet] Adaptive routing protocol based on network/node load Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kean, Useful info on dynamic routing can also be gleaned from the canonic Telco routing book "Dynamic Routing in Telecommunications Networks", by Gerald R. Ash. That text covers some of the really "old-school" dynamic-routing algorithms for wired networks :) --Pete Sholander >>> 04/08/03 02:43PM >>> > Hi, > Is there any protocol that does smart routing decisions by taking the tra ffic load in the network into consideration. Normally, route selection crit eria uses metric such as shortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all pack ets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this is sue? Hi Kean, There are several such protocols. Here is one of them: P. Gupta and P. R. Kumar, ``A system and traffic dependent adaptive routing algorithm for ad hoc networks,'' Proceedings of the 36th IEEE Conference on Decision and Control, pp. 2375-2380, San Diego, Dec. 1997. Even before that, I designed such a protocol (with John Hight, Dave Beyer, and others) called STIP (Secure Tactical Internet Protocol) in 1993, which was not published but can be found in the following project report: J. Hight, E. Costa, D. Lee, R. Ogier, J. Wong. "Evaluation and Development of Multimedia Networks in Dynamic Stress (EDMUNDS): Final Technical Report", SRI Technical Report ITAD-8558-FR-93-277, October 1993. I know there are more recent routing protocols that take traffic load into account, but I wanted to point out that such protocols were developed 10 years ago. Richard > > Thanks. > > Regards, > Kean Soon > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Apr 8 19:23:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08059 for ; Tue, 8 Apr 2003 19:23:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38NSrT09819 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 19:28:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NSr809816 for ; Tue, 8 Apr 2003 19:28:53 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08026 for ; Tue, 8 Apr 2003 19:23:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38N2U807754; Tue, 8 Apr 2003 19:02:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Mvx807537 for ; Tue, 8 Apr 2003 18:57:59 -0400 Received: from memphis.ece.cornell.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07311 for ; Tue, 8 Apr 2003 18:52:33 -0400 (EDT) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h38Mt7R07842 for ; Tue, 8 Apr 2003 18:55:07 -0400 Date: Tue, 8 Apr 2003 18:48:42 -0400 (EDT) From: Edward Hua X-X-Sender: eyh5@photon.ece.cornell.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Billiard Mobility model Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, In most MANET simulations, random waypoint and billiard mobility models are the two most popularly used models governing the movements of the mobile nodes, and between the two the former dominates. I'm wondering if there's anybody that has done any research examining billiard mobility model, and/or how it fares compared with random waypoint. I know there's a paper that analyzes random waypoint, and would like to get my hands on any published literature on billiard mobility if possible. Thanks for your suggestions. -Ed _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 19:37:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08397 for ; Tue, 8 Apr 2003 19:37:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38NglR11256 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 19:42:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ngl811253 for ; Tue, 8 Apr 2003 19:42:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08386 for ; Tue, 8 Apr 2003 19:37:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NJo809317; Tue, 8 Apr 2003 19:19:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NGs809214 for ; Tue, 8 Apr 2003 19:16:54 -0400 Received: from rrmail01.lab.flarion.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07790 for ; Tue, 8 Apr 2003 19:11:28 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <2R3NNSZ0>; Tue, 8 Apr 2003 19:13:59 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01178B67@ftmail.lab.flarion.com> From: Scott Corson To: "'Elizabeth M. Belding-Royer'" , "'ans-research@www1.ietf.org'" , "'lily.l.yang@intel.com'" Cc: "'manet@ietf.org'" Date: Tue, 8 Apr 2003 19:13:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [manet] RE: [Ans-research] The Charter Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > My understanding is that scalability was chosen in part to handle some > of the research that had previously been submitted to MANET but was > now out of scope because of the new MANET charter. The other part was > because scalability has been far less researched than many > other topics. > There are already some reasonable ideas about what works and doesn't > work in many areas of ad hoc networking, but little work has been done > in the area of scalability. I don't know that IRTF groups > are supposed > to handle urgent topics. > > I'm speaking from my understanding of how the group was chartered. > I actually became co-chair after the charter was already in place. > Hopefuuly Scott can correct anything I said that it inaccurate. What Elizabeth says is basically correct. Scalability as a general topic is fairly immature as a research area, and was also the principle goal of many of the algorithms no longer in scope of the MANET charter. That said, IMO related areas such as QoS, auto-conf, addressing and interlayer interactions are all part of the unicast puzzle. For purposes of keeping a (somewhat) more narrowed scope, I believe we should avoid both multicast and security for the time being. > > > ~> Another concern I have on focusing on scalability is how > this overlap with > ~> the current charter of the IETF MANET group. At the San > Francisco MANET > ~> meeting, there was quite a heated disucssion without much > resolution on how > ~> the MANET group proceed on standardizing one or two > routing protocols for ad > ~> hoc networks. One of the suggestion is to come up with a > set of network > ~> scenarios and evaluation metric so that fair evalution can > be done on the > ~> existing protocols. This sounds a bit similar to what the > ANS group is about > ~> to do as the first step, but of course with a focus on > scalability. However, > ~> it wasn't clear to me whether scalability is one of the > concern when > ~> evalauting the existing protocols produced by the MANET > group in its effort > ~> to standardize one or two. So maybe the chairs of these > two groups can > ~> explain exactly how the line is divided here between the > work done by two > ~> groups? The MANET WG already took the path of quantitative protocol bakeoff in its early years (research-like phase). Things were learned, but the approach led to little engineering consensus. That type of work is now in the ANS scope of activities. The MANET WG future (if it has one) is focused work on two unified protocols: reactive and proactive. If the WG cannot come to consensus on these, then it will cease to exist. -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Apr 8 20:48:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10050 for ; Tue, 8 Apr 2003 20:48:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h390roG15667 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 20:53:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h390ro815664 for ; Tue, 8 Apr 2003 20:53:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10039 for ; Tue, 8 Apr 2003 20:48:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h390QO813784; Tue, 8 Apr 2003 20:26:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h390Mv813675 for ; Tue, 8 Apr 2003 20:22:57 -0400 Received: from ext-nj2gw-3.online-age.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09303 for ; Tue, 8 Apr 2003 20:17:31 -0400 (EDT) Received: from int-nj2gw-1.online-age.net (int-nj2gw-1.online-age.net [3.159.236.65]) by ext-nj2gw-3.online-age.net (8.12.9/8.12.8/990426-RLH) with ESMTP id h390JvnK018785; Tue, 8 Apr 2003 20:19:57 -0400 (EDT) Received: from crdns.crd.ge.com (localhost [127.0.0.1]) by int-nj2gw-1.online-age.net (8.12.8/8.12.8/990426-RLH) with ESMTP id h390JofF012468; Tue, 8 Apr 2003 20:19:51 -0400 (EDT) Received: from xbh01crdge.crd.ge.com (xbh01crdge.crd.ge.com [3.159.72.22]) by crdns.crd.ge.com (8.11.6/8.11.6) with ESMTP id h390JnX02995; Tue, 8 Apr 2003 20:19:50 -0400 (EDT) Received: by xbh01crdge.crd.ge.com with Internet Mail Service (5.5.2653.19) id <2RVQMG2P>; Tue, 8 Apr 2003 20:19:49 -0400 Message-ID: From: "Bush, Stephen F (Research)" To: "'Edward Hua'" , manet@ietf.org Subject: RE: [manet] Billiard Mobility model Date: Tue, 8 Apr 2003 20:19:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Edward, I am also interested in examining scalability issues both in terms of number of nodes as well as differential in movement capability. I don't know the precise definition of a "billiard mobility model", although, I have been studying the effect of applying initial force vectors to idealized mobile nodes that can "bounce" when collisions occur. Our approach has been to look at resulting force gradients and their relation to routing message flow. I would be glad to see pointers to papers by others who have done similar studies. Stephen F Bush (http://www.research.ge.com/~bushsf) -----Original Message----- From: Edward Hua [mailto:eyh5@ece.cornell.edu] Sent: Tuesday, April 08, 2003 5:49 PM To: manet@ietf.org Subject: [manet] Billiard Mobility model Hi, In most MANET simulations, random waypoint and billiard mobility models are the two most popularly used models governing the movements of the mobile nodes, and between the two the former dominates. I'm wondering if there's anybody that has done any research examining billiard mobility model, and/or how it fares compared with random waypoint. I know there's a paper that analyzes random waypoint, and would like to get my hands on any published literature on billiard mobility if possible. Thanks for your suggestions. -Ed _______________________________________________ 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 mailnull@www1.ietf.org Tue Apr 8 23:53:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14340 for ; Tue, 8 Apr 2003 23:53:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h393w8p27621 for manet-archive@odin.ietf.org; Tue, 8 Apr 2003 23:58:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h393w7827618 for ; Tue, 8 Apr 2003 23:58:07 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14330 for ; Tue, 8 Apr 2003 23:52:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h393X5825794; Tue, 8 Apr 2003 23:33:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h393R0825621 for ; Tue, 8 Apr 2003 23:27:00 -0400 Received: from po4.glue.umd.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13720 for ; Tue, 8 Apr 2003 23:21:28 -0400 (EDT) Received: from y.glue.umd.edu (IDENT:root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.11.6p2/8.11.6) with ESMTP id h393Nvo14276; Tue, 8 Apr 2003 23:23:57 -0400 (EDT) Received: from y.glue.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id XAA17536; Tue, 8 Apr 2003 23:23:56 -0400 (EDT) Received: from localhost (dineshd@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id XAA17530; Tue, 8 Apr 2003 23:23:56 -0400 (EDT) X-Authentication-Warning: y.glue.umd.edu: dineshd owned process doing -bs Date: Tue, 8 Apr 2003 23:23:56 -0400 (EDT) From: Dinesh Dharmaraju To: Tan Kean Soon cc: "<" Subject: Re: [manet] Adaptive routing protocol based on network/node load In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Tan, We have a QoS protocol called INORA, (which uses INSIGNIA signaling and TORA routing protocol) and choses routes based on the QoS requirements. This adjusts adaptively to the traffic load at different nodes. Please take a look at the following paper: D. Dharmaraju, A. Roy-Chowdhury, P. Hovareshti, J. S. Baras , "INORA- A Unified Signaling and Routing Protocol in Mobile AdHoc networks" IWAHN '02 http://techreports.isr.umd.edu/TechReports/ISR/2002/TR_2002-33/TR_2002-33.phtml Thank you. Regards, Dinesh On Tue, 8 Apr 2003, Tan Kean Soon wrote: > Hi, > Is there any protocol that does smart routing decisions by taking the traffic load in the network into consideration. Normally, route selection criteria uses metric such as shortest number of hops and quickest response time to a request. Such decision making can lead to the situation where all packets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this issue? > > Thanks. > > Regards, > Kean Soon > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 9 03:57:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17512 for ; Wed, 9 Apr 2003 03:57:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3982os21693 for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 04:02:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3982o821690 for ; Wed, 9 Apr 2003 04:02:50 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17501 for ; Wed, 9 Apr 2003 03:57:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h397ZR819336; Wed, 9 Apr 2003 03:35:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h397SL819060 for ; Wed, 9 Apr 2003 03:28:21 -0400 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16846 for ; Wed, 9 Apr 2003 03:22:46 -0400 (EDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h397Owo26174; Wed, 9 Apr 2003 09:24:58 +0200 (MEST) Message-ID: <3E93CAC9.2BB821A@inrialpes.fr> Date: Wed, 09 Apr 2003 09:24:57 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Corson CC: "'Elizabeth M. Belding-Royer'" , "'ans-research@www1.ietf.org'" , "'lily.l.yang@intel.com'" , "'manet@ietf.org'" References: <748C6D0A58C0F94CA63C198B6674697A01178B67@ftmail.lab.flarion.com> Content-Type: multipart/alternative; boundary="------------C09AD2D3EBDC735CFE82BD2E" Subject: [manet] Re: [Ans-research] The Charter Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------C09AD2D3EBDC735CFE82BD2E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott Corson wrote: > > For purposes of keeping a (somewhat) more narrowed scope, I believe we > should avoid both multicast and security for the time being. > Hello Scott, Do you mean that work on MANET's security should be postponed or should be the subject of another WG?... cheers, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------C09AD2D3EBDC735CFE82BD2E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Scott Corson wrote:
 
For purposes of keeping a (somewhat) more narrowed scope, I believe we
should avoid both multicast and security for the time being.
 
Hello Scott,

Do you mean that work on MANET's security should be postponed or should be the subject
of another WG?...
cheers,

Claude.
  




-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------C09AD2D3EBDC735CFE82BD2E--

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



From mailnull@www1.ietf.org  Wed Apr  9 04:38:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18244
	for ; Wed, 9 Apr 2003 04:38:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h398hYC25094
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 04:43:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h398hY825091
	for ; Wed, 9 Apr 2003 04:43:34 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18237
	for ; Wed, 9 Apr 2003 04:37:56 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h398Iw823129;
	Wed, 9 Apr 2003 04:18:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h398EQ822964
	for ; Wed, 9 Apr 2003 04:14:26 -0400
Received: from smtp2.bae.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17712
	for ; Wed, 9 Apr 2003 04:08:49 -0400 (EDT)
Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234])
	by smtp2.bae.co.uk (Switch-2.2.6/Switch-2.2.6) with ESMTP id h398BMn07144
	for ; Wed, 9 Apr 2003 09:11:22 +0100 (BST)
Received: from bsrsmtp02.ng.bae.co.uk ([141.245.68.242])
 by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998)
 with ESMTP id <0HD200HM8HE3LR@ngbaux.net.bae.co.uk> for manet@ietf.org; Wed,
 9 Apr 2003 09:10:52 +0100 (BST)
Received: from mspm01.btdc.gecm.com ([10.28.48.3])
 by 141.245.68.242 with InterScan Messaging Security Suite for SMTP; Wed,
 09 Apr 2003 09:11:07 +0100
Received: from gscexm05.gsc.glasgow.gecm.com ([10.1.128.17])
 by mspm01.btdc.gecm.com (PMDF V5.2-33 #39438)
 with ESMTP id <01KUIO1UYSV800048Q@mspm01.btdc.gecm.com> for manet@ietf.org;
 Wed, 09 Apr 2003 09:09:38 +0000 (GMT)
Received: by gscexm05.gsc.glasgow.gecm.com with Internet Mail Service
 (5.5.2653.19)	id <2G9W2CMQ>; Wed, 09 Apr 2003 09:11:05 +0100
Content-return: allowed
Date: Wed, 09 Apr 2003 09:11:02 +0100
From: "Dearlove, Chris" 
Subject: RE: [manet] RE: [Ans-research] The Charter
To: "'manet@ietf.org'" 
Message-id: <69B9BACEA89ED411BEC200B0D049FBE0013ECE9A@gbwexm01.gmrc.gecm.com>
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


> The MANET WG future (if it has one) is focused work on two unified
> protocols: reactive and proactive.

This is not what was said at the WG meeting, where (as it says in
the minutes) this split wasn't confirmed. Obviously it must be the
front runner however.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr  9 08:45:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25940
	for ; Wed, 9 Apr 2003 08:45:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39CoJe09967
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 08:50:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CoI809964
	for ; Wed, 9 Apr 2003 08:50:18 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25930
	for ; Wed, 9 Apr 2003 08:44:36 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CQ1807632;
	Wed, 9 Apr 2003 08:26:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CIK807259
	for ; Wed, 9 Apr 2003 08:18:20 -0400
Received: from waffle.cs.dal.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25127
	for ; Wed, 9 Apr 2003 08:12:35 -0400 (EDT)
Received: (from localhost user: 'zhen' uid#1728 fake: STDIN (zhen@borg))
	by waffle.cs.dal.ca id ;
	Wed, 9 Apr 2003 09:14:42 -0300
Date: 	Wed, 9 Apr 2003 09:14:42 -0300 (ADT)
From: Zhen 
X-X-Sender: zhen@borg
To: yihchun@cs.cmu.edu
cc: perrig@cmu.edu, dbj@cs.rice.edu, manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] The delay at nodes when calculating temporal leash
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Hello,friends,

I have a question in mind for the temporal leash in paper "Packet leash:
wormhole detection". (I know this may has been an old story for you,
if you don't mind because I am reading these papers on securing ad hoc
and this is the only paper addressing wormhole)When calculating the max
expiration time for
a packet(or network),have you considered the factor caused by queues in
nodes? Since 802.11 is a near range tech, the propagation time is in us
scale and I think the delay at nodes should be bigger than this. If
congestion happens, how could you tell a right expiration time?

Any answer will be appreciated

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



From mailnull@www1.ietf.org  Wed Apr  9 12:41:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05528
	for ; Wed, 9 Apr 2003 12:41:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39G6Gb25474
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 12:06:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39G6G825471
	for ; Wed, 9 Apr 2003 12:06:16 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03963
	for ; Wed, 9 Apr 2003 12:00:29 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Ffm824241;
	Wed, 9 Apr 2003 11:41:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39FUL823019
	for ; Wed, 9 Apr 2003 11:30:21 -0400
Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02725
	for ; Wed, 9 Apr 2003 11:24:35 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h39FQ5ap017945;
	Wed, 9 Apr 2003 11:26:05 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h39FPrWi027636;
	Wed, 9 Apr 2003 11:26:00 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040911255910246
 ; Wed, 09 Apr 2003 11:25:59 -0400
Message-Id: <5.1.1.5.2.20030409112213.02c30e78@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 09 Apr 2003 11:25:55 -0400
To: "Dearlove, Chris" ,
        "'manet@ietf.org'" 
From: Joe Macker 
Subject: RE: [manet] RE: [Ans-research] The Charter
In-Reply-To: <69B9BACEA89ED411BEC200B0D049FBE0013ECE9A@gbwexm01.gmrc.gec
 m.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 09:11 AM 4/9/2003 +0100, Dearlove, Chris wrote:

>> The MANET WG future (if it has one) is focused work on two unified
>> protocols: reactive and proactive.
>
>This is not what was said at the WG meeting, where (as it says in
>the minutes) this split wasn't confirmed. Obviously it must be the
>front runner however.

That is true.. 

That MAY be the way forward, but there is still a discussion period.
The meeting minutes address the fact that MAY be the likely taxonomy
for further work based upon previous work.



>********************************************************************
>This email and any attachments are confidential to the intended
>recipient and may also be privileged. If you are not the intended
>recipient please delete it from your system and notify the sender.
>You should not copy it or use it for any purpose nor disclose or
>distribute its contents to any other person.
>********************************************************************
>_______________________________________________
>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 mailnull@www1.ietf.org  Wed Apr  9 12:46:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05732
	for ; Wed, 9 Apr 2003 12:46:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39F6U120914
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 11:06:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39F6T820910
	for ; Wed, 9 Apr 2003 11:06:29 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01926
	for ; Wed, 9 Apr 2003 11:00:44 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EfM819396;
	Wed, 9 Apr 2003 10:41:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Eau818401
	for ; Wed, 9 Apr 2003 10:36:56 -0400
Received: from marfik.upv.es (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00730
	for ; Wed, 9 Apr 2003 10:31:03 -0400 (EDT)
Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11])
	by marfik.upv.es (8.11.6/8.11.6) with ESMTP id h39EXTM15187
	for ; Wed, 9 Apr 2003 16:33:29 +0200
Received: from smtp2.upv.es (smtp02.cc.upv.es [158.42.249.52])
	by pop.upv.es (8.11.3/8.11.3) with ESMTP id h39EYFN19369
	for ; Wed, 9 Apr 2003 16:34:15 +0200 (METDST)
Received: from nao.disca.upv.es (nao.disca.upv.es [158.42.53.70])
	by smtp2.upv.es (8.11.4p2/8.11.4) with ESMTP id h39EXRS00694
	for ; Wed, 9 Apr 2003 16:33:28 +0200
Received: from disca.upv.es (tux.grc.upv.es [158.42.61.34])
	by nao.disca.upv.es (Postfix on SuSE eMail Server 2.0) with ESMTP id C0B061FED5
	for ; Wed,  9 Apr 2003 16:33:03 +0200 (CEST)
Message-ID: <3E942F36.4040006@disca.upv.es>
Date: Wed, 09 Apr 2003 16:33:26 +0200
From: Carlos Miguel Calafate 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] Multipath DSR
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

Does anyone know where I can find an implementation of Multipath DSR for 
NS-2?

Thanks,
-- 
_________________________________________________
Carlos Miguel Tavares de Araújo Cesariny Calafate
Universidad Politécnica de Valencia
e-mail: calafate@disca.upv.es
http://reptar.grc.upv.es/~calafate/
_________________________________________________
\"In an open world without walls and fences who
needs Windows and Gates?\"

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



From mailnull@www1.ietf.org  Wed Apr  9 12:54:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06074
	for ; Wed, 9 Apr 2003 12:54:56 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39H0D730597
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 13:00:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39H0D830594
	for ; Wed, 9 Apr 2003 13:00:13 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06053
	for ; Wed, 9 Apr 2003 12:54:24 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39GZ6828223;
	Wed, 9 Apr 2003 12:35:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39GBv826720
	for ; Wed, 9 Apr 2003 12:11:57 -0400
Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04233
	for ; Wed, 9 Apr 2003 12:06:10 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA11885;
	Wed, 9 Apr 2003 09:08:43 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39G8gk09076;
	Wed, 9 Apr 2003 09:08:42 -0700
X-mProtect: <200304091608> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdbxZ4pw; Wed, 09 Apr 2003 09:08:40 PDT
Message-ID: <3E944588.EE37EDF6@iprg.nokia.com>
Date: Wed, 09 Apr 2003 09:08:40 -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: Joe Macker 
CC: "'manet@ietf.org'" 
Subject: Re: [manet] RE: [Ans-research] The Charter
References: <5.1.1.5.2.20030409112213.02c30e78@pop.itd.nrl.navy.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Joe,

Joe Macker wrote:

>>> The MANET WG future (if it has one) is focused work on two unified
>>> protocols: reactive and proactive.
                  ............
> That is true..
> 
> That MAY be the way forward, but there is still a discussion period.
> The meeting minutes address the fact that MAY be the likely taxonomy
> for further work based upon previous work.

I think that going for two documents is the most expedient
way forward, because the technologies, considered separately,
are on the way to being fairly well understood.

The idea of a combined proactive/reactive (or, perhaps, "hybrid")
scheme is in my opinion much less well-understood.  So, it would
take a lot longer to get the combined scheme, and in the meantime
we would benefit from the existence of some Proposed Standards for
the two well-understood technologies.  After we get to that point,
I think we would be much better prepared to judge our chances for
success on combining the technologies.

However, I hope we also make space in the charter for:

- Internet connectivity
- Efficient broadcast/multicast

These are obviously needed, and techniques are known
for accomplishing them.

Regards,
Charlie P.



>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. 

I am feeling privileged, too :-)
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr  9 12:59:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06198
	for ; Wed, 9 Apr 2003 12:59:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39H4N630848
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 13:04:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39H4N830845
	for ; Wed, 9 Apr 2003 13:04:23 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06186
	for ; Wed, 9 Apr 2003 12:58:35 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Ggx829385;
	Wed, 9 Apr 2003 12:42:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39GG5826980
	for ; Wed, 9 Apr 2003 12:16:05 -0400
Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04477
	for ; Wed, 9 Apr 2003 12:10:17 -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 JAA12521;
	Wed, 9 Apr 2003 09:12:51 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39GCn114534;
	Wed, 9 Apr 2003 09:12:49 -0700
X-mProtect: <200304091612> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpduClLQU; Wed, 09 Apr 2003 09:12:48 PDT
Message-ID: <3E944681.807CE22E@iprg.nokia.com>
Date: Wed, 09 Apr 2003 09:12:49 -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: "Manfredi, Albert E" 
CC: S Woodside , manet@ietf.org
Subject: Re: [manet] Re: [BAWUG] I have a dream
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Bert,


"Manfredi, Albert E" wrote:

> Whether the scheme is geographically-based or provider-based,
> the important thing is to be able to aggregate routes.

Check.

> MANET does nothing to solve this routing scale problem,
> in a *global* sense. You still have to tie the MANET to
> the wired Internet efficiently.

Since we aren't demanding any internal route aggregation
within the ad-hoc network, the only answer is to somehow
shield the "wired" (<--maybe not for long) Internet from
the internal (and dynamic!) routing arrangements inside
the ad hoc network.

Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr  9 13:41:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07449
	for ; Wed, 9 Apr 2003 13:41:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39HkT702546
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 13:46:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39HkT802543
	for ; Wed, 9 Apr 2003 13:46:29 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07434
	for ; Wed, 9 Apr 2003 13:40:40 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39HNt832725;
	Wed, 9 Apr 2003 13:23:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39HHF832462
	for ; Wed, 9 Apr 2003 13:17:15 -0400
Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06656
	for ; Wed, 9 Apr 2003 13:11:26 -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 KAA05701;
	Wed, 9 Apr 2003 10:14:00 -0700 (PDT)
Message-Id: <200304091714.KAA05701@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: Wed, 09 Apr 2003 10:14:00 -0700
Subject: [manet] Neighbor addresses in OLSR HELLO messages
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


In the latest OLSR draft, it is not clear whether HELLO 
messages contain the "main addresses" or the interface 
addresses of neighbors. Previous versions of OLSR used 
the term "Neighbor Interface Address" to describe these 
addresses, but the current version changed this to 
"Neighbor Address", defined as "An address of a neighbor node".

What does "an address" mean?  Interface address or main address?

On page 27 it is stated that the neighbor *interface* addresses
(L_neighbor_iface_addr) are advertised in a HELLO.

However, page 33 says the following, which implies that the
neighbor addresses in a HELLO are *main* addresses:

     1    for each address (henceforth: 2-hop neighbor address), listed
          in the HELLO message with Neighbor Type equal to SYM_NEIGH or
          MPR_NEIGH:

          1.1  if 2-hop neighbor address = main address of receiving
                node:

This seems inconsistent to me, but I could be missing something.
I was assuming that OLSR uses interface addresses in HELLOs
(there was a previous discussion about why it is important for 
HELLOs to advertise interface addresses in wireless networks),
but there must be some reason for the above changes.

Regards,
Richard

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



From mailnull@www1.ietf.org  Wed Apr  9 16:09:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12567
	for ; Wed, 9 Apr 2003 16:09:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39KEXU24675
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 16:14:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39KEX824672
	for ; Wed, 9 Apr 2003 16:14:33 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12558
	for ; Wed, 9 Apr 2003 16:08:41 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39JnQ822549;
	Wed, 9 Apr 2003 15:49:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Jfj822350
	for ; Wed, 9 Apr 2003 15:41:45 -0400
Received: from mailhost.cs.auc.dk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11647
	for ; Wed, 9 Apr 2003 15:35:54 -0400 (EDT)
Received: from armada (voop@pico.cs.auc.dk [130.225.194.80])
	by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h39JcNPO029168;
	Wed, 9 Apr 2003 21:38:23 +0200 (MEST)
Date: Wed, 9 Apr 2003 21:38:22 +0200
From: Thomas Heide Clausen 
To: ogier@erg.sri.com
Cc: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Message-Id: <20030409213822.23b9b121.T.Clausen@computer.org>
In-Reply-To: <200304091714.KAA05701@pit.erg.sri.com>
References: <200304091714.KAA05701@pit.erg.sri.com>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.14
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Richard,

Your observation is correct, this is slightly inconsistant in the
text. HELLO messages do advertice interface adresses, so your
understanding is correct, it seems. We've already clarified this in
the version which we will submit to the IETF shortly (within this
week).

Thanks for being alert :)

--thomas


On Wed, 09 Apr 2003 10:14:00 -0700
ogier@erg.sri.com wrote:

> 
> In the latest OLSR draft, it is not clear whether HELLO 
> messages contain the "main addresses" or the interface 
> addresses of neighbors. Previous versions of OLSR used 
> the term "Neighbor Interface Address" to describe these 
> addresses, but the current version changed this to 
> "Neighbor Address", defined as "An address of a neighbor node".
> 
> What does "an address" mean?  Interface address or main address?
> 
> On page 27 it is stated that the neighbor *interface* addresses
> (L_neighbor_iface_addr) are advertised in a HELLO.
> 
> However, page 33 says the following, which implies that the
> neighbor addresses in a HELLO are *main* addresses:
> 
>      1    for each address (henceforth: 2-hop neighbor address),
>      listed
>           in the HELLO message with Neighbor Type equal to
>           SYM_NEIGH or MPR_NEIGH:
> 
>           1.1  if 2-hop neighbor address = main address of
>           receiving
>                 node:
> 
> This seems inconsistent to me, but I could be missing something.
> I was assuming that OLSR uses interface addresses in HELLOs
> (there was a previous discussion about why it is important for 
> HELLOs to advertise interface addresses in wireless networks),
> but there must be some reason for the above changes.
> 
> Regards,
> Richard
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr  9 18:02:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16285
	for ; Wed, 9 Apr 2003 18:02:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39M7Vl01054
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 18:07:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M7V801051
	for ; Wed, 9 Apr 2003 18:07:31 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16275
	for ; Wed, 9 Apr 2003 18:01:36 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Lif831616;
	Wed, 9 Apr 2003 17:44:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Las830563
	for ; Wed, 9 Apr 2003 17:36:54 -0400
Received: from tomts14-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15633
	for ; Wed, 9 Apr 2003 17:31:00 -0400 (EDT)
Received: from yahoo.com ([65.93.180.25]) by tomts14-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030409213333.NKTL2534.tomts14-srv.bellnexxia.net@yahoo.com>;
          Wed, 9 Apr 2003 17:33:33 -0400
Date: Wed, 9 Apr 2003 17:33:34 -0400
Subject: Re: [manet] Re: [geeks] Fwd: [BAWUG] I have a dream
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Claude Castelluccia ,
        benchun , manet@ietf.org,
        geeks@false-profit.com, dylan@false-profit.com
To: Adam Megacz 
From: S Woodside 
In-Reply-To: 
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Tuesday, April 8, 2003, at 04:51  AM, Adam Megacz wrote:

>
>>>> Source Routing is the only scalable solution.
>
>>> ??? broadcasting routing requests doesn't seem that scalable.
>
>> source routing and routing requests broadcasting are 2 different 
>> things.
>
> Exactly.  PSR isn't so much about the route discovery as it is about
> the routing algorithm and addressing structure.  Geographic techniques
> could be used to augment route discovery without altering the rest of
> the protocol.  Simon, do you have any suggestions on the best way to
> do this?

Nothing concrete. Perhaps geographic routing would be the default and 
in a Source routing scenario, the source routing discovery and routing 
would only be used on links that don't have geo knowledge at both ends. 
So that, on any given link, the router will examine the packet header 
first for a geographic address, and if it knows how to route it 
geographically, will ignore the source routing table in the packet 
header. That could cut down on the header size for SR as the number of 
geographically enable routers increases.

> I have two concerns with all-geographic techniques:
>
>   1. The Internet is non-euclidean.  Packets almost never follow the
>      as-the-crow-flies shortest path from source to destination, so
>      geographic information is often misleading and suboptimal.

With wireless this is less true no? (because of the range limitations).

>   2. Given the name "www.yahoo.com", how do you obtain the
>      latitude/longitude?  Any sort of system like DNS will introduce a
>      Single Point Of Failure, which is the biggest problem with the
>      Internet today (take out the root servers and the whole internet
>      comes crashing down).

Well ... one challenge at a time ? ;-)

simon

> This is why I lean towards flood filling with geographic "hints".
>
> Also, flood-filling works in tiered networks.  BGP is essentially
> route flooding within the backbone tier (the set of routers with no
> default entry in their routing tables), and it's working today.
>
>   - a
>
>

--
www.simonwoodside.com -- 99% Devil, 1% Angel

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



From mailnull@www1.ietf.org  Wed Apr  9 19:29:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20120
	for ; Wed, 9 Apr 2003 19:29:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39NZ7N06272
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 19:35:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39NZ7806269
	for ; Wed, 9 Apr 2003 19:35:07 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20084
	for ; Wed, 9 Apr 2003 19:29:10 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39NE2805698;
	Wed, 9 Apr 2003 19:14:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39N66804729
	for ; Wed, 9 Apr 2003 19:06:06 -0400
Received: from hematita.dcc.ufmg.br (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19553
	for ; Wed, 9 Apr 2003 19:00:10 -0400 (EDT)
Received: from turmalina.dcc.ufmg.br (turmalina [150.164.10.1])
	by hematita.dcc.ufmg.br (8.12.8/8.12.8) with ESMTP id h39N2Xuc012777;
	Wed, 9 Apr 2003 20:02:33 -0300 (EST)
Date: Wed, 9 Apr 2003 20:02:27 -0300 (EST)
From: Daniel Camara 
To: S Woodside 
cc: Adam Megacz ,
        Claude Castelluccia ,
        benchun , manet@ietf.org,
        geeks@false-profit.com, dylan@false-profit.com
Subject: Re: [manet] Re: [geeks] Fwd: [BAWUG] I have a dream
In-Reply-To: 
Message-ID: 
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 www1.ietf.org id h39N67804730
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit


On Wed, 9 Apr 2003, S Woodside wrote:
> Nothing concrete. Perhaps geographic routing would be the default and 
> in a Source routing scenario, the source routing discovery and routing 
> would only be used on links that don't have geo knowledge at both ends. 
> So that, on any given link, the router will examine the packet header 
> first for a geographic address, and if it knows how to route it 
> geographically, will ignore the source routing table in the packet 
> header. That could cut down on the header size for SR as the number of 
> geographically enable routers increases.

        First of all, to solve the problem of nodes with out geographic
knowledge, nodes that do not have knowledge of its geographic position can
use other "near" nodes as a proxy and send messages through them. The
header is not necessarily a bad thing if it carries useful information
about other network nodes.  For example, their most updated position. I
agree that the header size is a point to observe, but I think the
information on it can be useful, see:
	Câmara, D., Loureiro A.: A Novel Routing Algorithm for Hoc
	Networks. Baltzer Journal of Telecommunications Systems 18:1-3, 
	Kluwer Academic Publishers(2001) 85-100 

> >   2. Given the name "www.yahoo.com", how do you obtain the
> >      latitude/longitude?  Any sort of system like DNS will introduce a
> >      Single Point Of Failure, which is the biggest problem with the
> >      Internet today (take out the root servers and the whole internet
> >      comes crashing down).
> 
> Well ... one challenge at a time ? ;-)

        In the paper the algorithm uses the packet header to spread the
geographic information, and the routing algorithm uses it in a very simple
way.  The algorithm also observes if the actual node has a better route to
the destination and re-routes the packet if so.

 	The main problem is that the algorithm is based on distance
vector.  So every node has a table with the position of every other node
on the network. In this case each node have at least a guess to which side
the destination node is. Even though this is not scalable for huge
networks it is for sure a start point.

        Best regards ...

	Daniel 

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



From mailnull@www1.ietf.org  Wed Apr  9 20:38:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21554
	for ; Wed, 9 Apr 2003 20:38:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A0fae11099
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 20:41:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A0fa811096
	for ; Wed, 9 Apr 2003 20:41:36 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21432
	for ; Wed, 9 Apr 2003 20:35:40 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A0Gt809160;
	Wed, 9 Apr 2003 20:16:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A08k808934
	for ; Wed, 9 Apr 2003 20:08:46 -0400
Received: from gaucho.cse.ucsc.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20792
	for ; Wed, 9 Apr 2003 20:02:49 -0400 (EDT)
Received: from localhost (baolc@localhost) by gaucho.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id RAA09629 for ; Wed, 9 Apr 2003 17:05:23 -0700
X-Authentication-Warning: gaucho.cse.ucsc.edu: baolc owned process doing -bs
Date: Wed, 9 Apr 2003 17:05:23 -0700 (PDT)
From: Lichun Bao 
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] Why retry 7 times in IEEE 802.11?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Hi.

In IEEE 802.11, the value of dot11ShortRetryLimit for short frame
retransmissions is set to 7 by default. Is there any theoretical
background for this?

Thanks,

Lichun Bao


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



From mailnull@www1.ietf.org  Wed Apr  9 21:38:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22677
	for ; Wed, 9 Apr 2003 21:38:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A1iDN15295
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 21:44:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1iD815292
	for ; Wed, 9 Apr 2003 21:44:13 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22666
	for ; Wed, 9 Apr 2003 21:38:15 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1MB813360;
	Wed, 9 Apr 2003 21:22:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1FP813126
	for ; Wed, 9 Apr 2003 21:15:25 -0400
Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22172
	for ; Wed, 9 Apr 2003 21:09:27 -0400 (EDT)
Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243])
	by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h3A1CaGi023322
	for ; Thu, 10 Apr 2003 09:12:36 +0800 (SGT)
Received: from bkdom-MTA by mailer.icr.a-star.edu.sg
	with Novell_GroupWise; Thu, 10 Apr 2003 09:04:25 +0800
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 6.0.3
Date: Thu, 10 Apr 2003 09:04:54 +0800
From: "Paul Tan Hock Lai" 
To: , 
Subject: Re: [manet] Why retry 7 times in IEEE 802.11?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3A1FP813127
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

i guess it is trying to retransmit at the lower layer as many times (e.g. 7 times) as possible before the upper layer(e.g. tcp) notice the transmisssion failure. i think it should be easy to co-relate between these two.

cheers,
Paul Tan


Best Regards,
Paul Tan
Institute for Communications Research
http://www.icr.a-star.edu.sg
Tel: (65)68709324

***************************************************
This email is confidential and may be privileged.  If you are not the
intended recipient, please delete it and notify us immediately.  Please
do not copy or use it for any purpose, or disclose its contents to any
other person. Thank you.
***************************************************
>>> Lichun Bao  04/10/03 08:36 AM >>>
Hi.

In IEEE 802.11, the value of dot11ShortRetryLimit for short frame
retransmissions is set to 7 by default. Is there any theoretical
background for this?

Thanks,

Lichun Bao


_______________________________________________
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 mailnull@www1.ietf.org  Wed Apr  9 21:47:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22957
	for ; Wed, 9 Apr 2003 21:47:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A1qdc15736
	for manet-archive@odin.ietf.org; Wed, 9 Apr 2003 21:52:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1qd815733
	for ; Wed, 9 Apr 2003 21:52:39 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22951
	for ; Wed, 9 Apr 2003 21:46:41 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1R5813566;
	Wed, 9 Apr 2003 21:27:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A1K7813297
	for ; Wed, 9 Apr 2003 21:20:07 -0400
Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22220
	for ; Wed, 9 Apr 2003 21:14:09 -0400 (EDT)
Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243])
	by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h3A1HHGi023380
	for ; Thu, 10 Apr 2003 09:17:17 +0800 (SGT)
Received: from bkdom-MTA by mailer.icr.a-star.edu.sg
	with Novell_GroupWise; Thu, 10 Apr 2003 09:09:07 +0800
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 6.0.3
Date: Thu, 10 Apr 2003 09:09:37 +0800
From: "Paul Tan Hock Lai" 
To: 
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3A1K7813298
Subject: [manet] Running MANETs over other Access Techonogies ?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

hi,

i have noticed much work of manet on ieee 802.11. i would like to know if there are any works that work on a different technology (L1/L2).

any comments?

cheers,
Paul Tan
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Thu Apr 10 09:00:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18662
	for ; Thu, 10 Apr 2003 09:00:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3AD6f208011
	for manet-archive@odin.ietf.org; Thu, 10 Apr 2003 09:06:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AD6f808008
	for ; Thu, 10 Apr 2003 09:06:41 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18634
	for ; Thu, 10 Apr 2003 09:00:28 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ACis807055;
	Thu, 10 Apr 2003 08:44:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ACdH806812
	for ; Thu, 10 Apr 2003 08:39:17 -0400
Received: from smtp2.bae.co.uk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17822
	for ; Thu, 10 Apr 2003 08:33:03 -0400 (EDT)
Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234])
	by smtp2.bae.co.uk (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3ACZbn07901
	for ; Thu, 10 Apr 2003 13:35:37 +0100 (BST)
Received: from bsrsmtp02.ng.bae.co.uk ([141.245.68.242])
 by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998)
 with ESMTP id <0HD4001OLO1A5O@ngbaux.net.bae.co.uk> for manet@ietf.org; Thu,
 10 Apr 2003 13:29:34 +0100 (BST)
Received: from mspm01.btdc.gecm.com ([10.28.48.3])
 by 141.245.68.242 with InterScan Messaging Security Suite for SMTP; Thu,
 10 Apr 2003 13:29:56 +0100
Received: from gscexm05.gsc.glasgow.gecm.com ([10.1.128.17])
 by mspm01.btdc.gecm.com (PMDF V5.2-33 #39438)
 with ESMTP id <01KUKBD77KPG0005LY@mspm01.btdc.gecm.com>; Thu,
 10 Apr 2003 13:28:31 +0000 (GMT)
Received: by gscexm05.gsc.glasgow.gecm.com with Internet Mail Service
 (5.5.2653.19)	id <2G9W285V>; Thu, 10 Apr 2003 13:29:59 +0100
Content-return: allowed
Date: Thu, 10 Apr 2003 13:29:57 +0100
From: "Dearlove, Chris" 
To: "'Charles E. Perkins'" ,
        Joe Macker 
Cc: "'manet@ietf.org'" 
Message-id: <69B9BACEA89ED411BEC200B0D049FBE0013ECEA6@gbwexm01.gmrc.gecm.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
Subject: [manet] Hybrid routing protocols (was RE: [Ans-research] The Charter)
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


> I think that going for two documents is the most expedient
> way forward, because the technologies, considered separately,
> are on the way to being fairly well understood.

I can certainly see the logic here. As background I asked the
question at the meeting largely as a request for information,
although I did comment that I could see attractions in a hybrid
protocol in scenarios of interest to us. (I presume everyone else 
can too, so won't give any details here.)

> The idea of a combined proactive/reactive (or, perhaps, "hybrid")
> scheme is in my opinion much less well-understood.  So, it would
> take a lot longer to get the combined scheme, and in the meantime
> we would benefit from the existence of some Proposed Standards for
> the two well-understood technologies.  After we get to that point,
> I think we would be much better prepared to judge our chances for
> success on combining the technologies.

Such limited thought as I've given to the subject are (not unlike ZRP)
basically proactive islands in a reactive sea (logically, not
necessarily physically). However I was thinking more in terms of nodes
choosing whether to act proactively, and the proactive islands thus
forming in an ad hoc manner. The intent would be for the basic unit
of the reactive protocol then not being the node but the proactive
network. If no one acts proactively it is then just a reactive network;
if everyone acts proactively it is then just a proactive network.
(Actually more than two behaviours are possible, but that's a later
detail.)

I'm sure others have already had this idea and taken it further -
hopefully to the point where the problems I can already see, such as
how proactive groups aren't exactly like nodes, and others I haven't
yet seen, have been solved or found to be showstoppers. I'd appreciate
any pointers to literature on the subject, in particular actual attempts
along these lines.

The only way I could see this, or another hybrid, approach being
compatible with the manet group would be if the new manet protocols
were built in blocks (as was suggested by more than one person).
Like ZRP there would then be multiple protocols: a proactive
protocol, but with "hooks" to handle reactive messages, a reactive
protocol, but capable of handling groups of nodes as a unit, and a
how to put them together protocol. However a key point would be that
you could opt into a single mode and only use one of the first two
protocols. Perhaps it would be sufficient to develop separate protocols,
as you are suggesting, with enough flexibility provided in each to
allow a combining protocol to be built later, extending the two base
protocols.

Apologies for what comes next, it's out of my control, but everyone
is privileged.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Fri Apr 11 03:30:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02066
	for ; Fri, 11 Apr 2003 03:30:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3B7aN201757
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 03:36:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B7aM801754
	for ; Fri, 11 Apr 2003 03:36:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02045
	for ; Fri, 11 Apr 2003 03:29:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193sij-0007Uq-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 03:13:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 193sij-0007Un-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 03:13:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B7Dg800739;
	Fri, 11 Apr 2003 03:13:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B73v832005
	for ; Fri, 11 Apr 2003 03:03:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01530
	for ; Fri, 11 Apr 2003 02:57:23 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193sDN-0007MO-00
	for manet@ietf.org; Fri, 11 Apr 2003 02:40:45 -0400
Received: from tomts7.bellnexxia.net ([209.226.175.40] helo=tomts7-srv.bellnexxia.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 193sDM-0007ML-00
	for manet@ietf.org; Fri, 11 Apr 2003 02:40:44 -0400
Received: from yahoo.com ([65.93.190.21]) by tomts7-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030411065957.YVRR28244.tomts7-srv.bellnexxia.net@yahoo.com>;
          Fri, 11 Apr 2003 02:59:57 -0400
Date: Fri, 11 Apr 2003 02:59:57 -0400
Subject: Re: [manet] Re: [geeks] Fwd: [BAWUG] I have a dream
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Claude Castelluccia ,
        benchun , manet@ietf.org,
        geeks@false-profit.com, dylan@false-profit.com
To: Adam Megacz 
From: S Woodside 
In-Reply-To: 
Message-Id: <34A0F2B0-6BEB-11D7-99B6-000393414368@yahoo.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Thursday, April 10, 2003, at 04:42  AM, Adam Megacz wrote:
> S Woodside  writes:
>>>   1. The Internet is non-euclidean.  Packets almost never follow the
>>>      as-the-crow-flies shortest path from source to destination, so
>>>      geographic information is often misleading and suboptimal.
>
>> With wireless this is less true no? (because of the range 
>> limitations).
>
> Ah, yes.  We're probably looking at different applications here; most
> of my work is aimed at coming up with an internet-wide routing
> protocol.

I think we're talking about the same thing. I'm coming from the 
Community Wireless Network perspective, where the ideal situation is a 
seamless integration between co-operative style networks and the wired 
internet. Ideally, that means, that the protocol used in both is the 
same, so that the massive-multihoming/mesh style network that CWN 
people would like to develop, will be able to route internet traffic. 
For that to work, requires massive scalability.

Consider that there may be broad "swathes" of area that are connected 
in a mesh fashion because there is no broadband wired infrastructure 
available. Certain parts of the mesh might have wired links because 
they are in the right place, or they are "injection points" where 
people have banded together to fund a higher-priced wired link. So 
that, arbitrary points in the mesh would be connected to the wired 
internet.

If it can be made to work ... there are broad advantages as the 
marginal cost of spreading the network into rural / unconnected areas 
would be zero. (perhaps not, but there are incentives in such a 
situation to be closer to a connection point / to bring a connection 
point closer to oneself)

> By the way, there are some grad students at Rice who've been able to
> do [2-D] triangulation with a pair of off-the-shelf 802.11 base
> stations.  Pretty neat stuff.

Cool. I hear that http://www.wifimaps.com/ also has some kind of 
triangulation system based on massive wardriving data!

simon

>
>   - a
>
>

--
www.simonwoodside.com -- 99% Devil, 1% Angel

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



From mailnull@www1.ietf.org  Fri Apr 11 08:44:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10510
	for ; Fri, 11 Apr 2003 08:44:15 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BCoPw23164
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 08:50:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BCoP823161
	for ; Fri, 11 Apr 2003 08:50:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10477
	for ; Fri, 11 Apr 2003 08:43:44 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193xcX-0001wm-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 08:27:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 193xcX-0001wj-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 08:27:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BCSE821203;
	Fri, 11 Apr 2003 08:28:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BCKx820856
	for ; Fri, 11 Apr 2003 08:20:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09249
	for ; Fri, 11 Apr 2003 08:14:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193xA3-0001a0-00
	for manet@ietf.org; Fri, 11 Apr 2003 07:57:39 -0400
Received: from bay2-f159.bay2.hotmail.com ([65.54.247.159] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 193xA3-0001Zr-00
	for manet@ietf.org; Fri, 11 Apr 2003 07:57:39 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 11 Apr 2003 04:56:02 -0700
Received: from 195.12.26.4 by by2fd.bay2.hotmail.msn.com with HTTP;
	Fri, 11 Apr 2003 11:56:02 GMT
X-Originating-IP: [195.12.26.4]
X-Originating-Email: [jianwu53@hotmail.com]
From: "jian wu" 
To: manet@ietf.org
Date: Fri, 11 Apr 2003 11:56:02 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 11 Apr 2003 11:56:02.0413 (UTC) FILETIME=[531239D0:01C30021]
Subject: [manet] qos routing
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3BCSE821203
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3BCoP823161
Content-Transfer-Encoding: 8bit

Dear all

I am a PhD student currently working on QoS routing in MANET. I found that 
previous works have mainly concentrated on networks which have TDMA-based 
MAC (e.g. Chenxi Zhu and Corson¡¦s paper) or CDMA (e.g. Lin and Liu¡¦s JSAC 
paper). I wonder whether there is any work addressing QoS routing for 802.11 
(CSMA/CA) type ad hoc networks? In particular, if we consider a 
bandwidth-based QoS routing problem, how to calculate bandwidth in such 
networks?

Any suggestions? Many thanks.

Jian






_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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



From mailnull@www1.ietf.org  Fri Apr 11 10:38:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15874
	for ; Fri, 11 Apr 2003 10:38:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BEiM432077
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 10:44:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BEiM832074
	for ; Fri, 11 Apr 2003 10:44:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15852
	for ; Fri, 11 Apr 2003 10:37:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193zOm-0002wd-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 10:21:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 193zOm-0002wa-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 10:21:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BERl830025;
	Fri, 11 Apr 2003 10:27:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BELK829692
	for ; Fri, 11 Apr 2003 10:21:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13972
	for ; Fri, 11 Apr 2003 10:14:38 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 193z2U-0002UN-00
	for manet@ietf.org; Fri, 11 Apr 2003 09:57:58 -0400
Received: from grebe.mail.pas.earthlink.net ([207.217.120.46])
	by ietf-mx with esmtp (Exim 4.12)
	id 193z2U-0002UK-00
	for manet@ietf.org; Fri, 11 Apr 2003 09:57:58 -0400
Received: from sdn-ar-019casfrmp207.dialsprint.net ([158.252.223.209] helo=erg.sri.com)
	by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 193zKz-0003tw-00; Fri, 11 Apr 2003 07:17:11 -0700
Message-ID: <3E96CE2A.8106D3CA@erg.sri.com>
Date: Fri, 11 Apr 2003 07:16:10 -0700
From: Richard Ogier 
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: manet@ietf.org
CC: ogier@erg.sri.com
Subject: Re: [manet] Routing using IPv6
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Fred Baker wrote:

> Routing is generally a matter of creating a graph among the nodes in a
> graph - a lattice of routers with interconnection topologies - and then
> decorating the graph with prefixes. We can carry your favorite routing
> protocol in IPv4 or IPv6, and we can decorate the graph with IPv4 or IPv6
> prefixes.
>
> The only thing that comes quickly to mind is my suggestion of using OSPF V3
> last year, whose LSAs are designed around IPv6 and which identifies
> neighbors using IPv6 link local addresses.

A link-local address in IPv6 has the following format (RFC 2373):

   |   10     |
   |  bits    |        54 bits          |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+


Therefore, if the HELLO messages in OLSR and TBRPF for IPv6 
contain only link-local neighbor interface addresses, then it 
is not necessary to include the entire 128-bit IPv6 address.  
Only the interface IDs need to be included in HELLO messages. 
This can reduce overhead significantly.

In TBRPF, topology updates contain only 32-bit router IDs, for 
both IPv4 and IPv6 (similar to OSPF for IPv6), which saves a lot 
of overhead.  IPv6 addresses are advertised in separate messages, 
which can be sent less frequently.

The "IPv6 Considerations" section of the OLSR draft says:

 "All the operations and parameters described in this document used by
  OLSR for IP version 4 are the same as those used by OLSR for IP ver-
  sion 6.  However, to operate with IP version 6, the only required
  change is to replace the IPv4 addresses with IPv6 address."

Thomas, Are you really proposing to use 128-bit IPv6 addresses
in HELLOs and TC messages?  Or are you changing this in your
updated draft?  

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



From mailnull@www1.ietf.org  Fri Apr 11 13:54:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22873
	for ; Fri, 11 Apr 2003 13:54:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BI10a14570
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 14:01:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BI10814567
	for ; Fri, 11 Apr 2003 14:01:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22869
	for ; Fri, 11 Apr 2003 13:54:13 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1942ld-0004d0-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 13:56:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1942lc-0004cx-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 13:56:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHhO813606;
	Fri, 11 Apr 2003 13:43:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BHa1812518
	for ; Fri, 11 Apr 2003 13:36:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22263
	for ; Fri, 11 Apr 2003 13:29:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1942NT-0004TZ-00
	for manet@ietf.org; Fri, 11 Apr 2003 13:31:51 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 1942NS-0004TV-00
	for manet@ietf.org; Fri, 11 Apr 2003 13:31:50 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3BHVIgE026721;
	Fri, 11 Apr 2003 10:31:18 -0700 (PDT)
Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with SMTP id AGA51222;
	Fri, 11 Apr 2003 10:29:48 -0700 (PDT)
Message-Id: <5.2.0.9.2.20030411102551.05e05638@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 11 Apr 2003 10:29:43 -0700
To: Richard Ogier 
From: Fred Baker 
Subject: Re: [manet] Routing using IPv6
Cc: manet@ietf.org
In-Reply-To: <3E96CE2A.8106D3CA@erg.sri.com>
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 07:16 AM 4/11/2003 -0700, Richard Ogier wrote:
>In TBRPF, topology updates contain only 32-bit router IDs, for both IPv4 
>and IPv6 (similar to OSPF for IPv6), which saves a lot of overhead.  IPv6 
>addresses are advertised in separate messages, which can be sent less 
>frequently.

And OSPF is different? OSPF uses a 32 bit router ID as well, and in OSPF V3 
always advertises prefixes in separate LSAs.

You are running into the same error we made in OSPF V2 regarding unnumbered 
links. In a number of cases, it is possible to come up with more than one 
way to get to a specified neighbor (maybe you have two radios and can talk 
with him via either) and it is important for operational reasons which 
route you take. If you can't identify them easily, you can't do this. So it 
is not sufficient to say "I have two routes to this neighbor", you have to 
be able to identify them.

OSPF V3 uses the link local address for that purpose. 

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



From mailnull@www1.ietf.org  Fri Apr 11 16:08:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28170
	for ; Fri, 11 Apr 2003 16:08:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BKEiF25919
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 16:14:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BKEi825916
	for ; Fri, 11 Apr 2003 16:14:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28157
	for ; Fri, 11 Apr 2003 16:07:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944r0-0005OM-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 16:10:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944qz-0005OI-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 16:10:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJwD822951;
	Fri, 11 Apr 2003 15:58:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJox822657
	for ; Fri, 11 Apr 2003 15:50:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27225
	for ; Fri, 11 Apr 2003 15:44:10 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944U2-0005Ci-00
	for manet@ietf.org; Fri, 11 Apr 2003 15:46:46 -0400
Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944U2-0005CR-00
	for manet@ietf.org; Fri, 11 Apr 2003 15:46:46 -0400
Received: by mail.eecis.udel.edu (Postfix, from userid 62)
	id C9C9F328E6; Fri, 11 Apr 2003 15:46:41 -0400 (EDT)
Received: from buckwheat.cis.udel.edu (buckwheat.cis.udel.edu [128.4.131.43])
	by mail.eecis.udel.edu (Postfix) with ESMTP id B59C732890
	for ; Fri, 11 Apr 2003 15:46:40 -0400 (EDT)
Date: Fri, 11 Apr 2003 15:46:40 -0400 (EDT)
From: Sonny Rajagopalan 
X-X-Sender: 
To: 
Message-ID: 
X-Spam-Status: No, hits=-4.5 required=6.0
	tests=DEPT_RCVD,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,
	      SPAM_PHRASE_01_02,SUPERLONG_LINE,USER_AGENT_PINE
	version=2.43
X-Sanitizer: This message has been sanitized!
X-Sanitizer-URL: http://mailtools.anomy.net/
X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [manet] Addendum: Adaptive routing protocol based on network/node load
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

---------- Forwarded message ----------
Date: Thu, 10 Apr 2003 11:05:39 -0400 (EDT)
From: Sonny Rajagopalan 
To: manet@ieft.org
Subject: Re: [manet] Adaptive routing protocol based on network/node load

Hello All,

We will soon have a paper out which is related to this thread. The
abstract of the paper appears below:

- --------------BEGIN ABSTRACT------------------------------------------

There are  a number  of unicast routing   protocols for mobile  ad hoc
networks, but none of  them  effectively address  the whole range   of
problems       ad  hoc   networks face.  Furthermore, protocols   that
perform well  in one scenario do not  perform well in all scenarios --
to counter this, we need a general  purpose protocol which assumes the
``face'' of   the  protocol that performs the    best  in the  current
situation --  i.e., we will  need  a protocol   that adapts itself  to
changing network demands autonomously.   This general purpose protocol
is to be a hybrid protocol (to improve  scalability properties) and is
designed to accomodate the following three aspects : (a) shift between
the amount  of proactive routing  and reactive routing autonomously to
improve network metrics, (b) capable of performing relay-based routing
to  accomodate  for  extreme  network    conditions, and  (c)    adapt
dynamically to other network and load characteristics.

This paper describes  the design and implementation  of a  new unicast
routing protocol  for mobile ad   hoc  networks. Our unicast   routing
protocol is  a hybrid, survivable routing  protocol inspired  from the
swarm  intelligence  metaphor, and draws  on  many positive aspects of
swarm intelligence techniques  -- flexibility,  resilience to  network
characteristics.   We have tested a  preliminary implementation of our
and compared it with AODV, and the results are encouraging.

- ---------------END ABSTRACT------------------------------------------

Cheers,
Sonny.
- ----
>From the desk of Sonny Rajagopalan @ http://www.cis.udel.edu/~rajagopa
                                                                  ----

On Tue, 8 Apr 2003, Dinesh Dharmaraju wrote:

> Hi Tan,
>   We have a QoS protocol called INORA, (which uses INSIGNIA signaling and
> TORA routing protocol) and choses routes based on the QoS requirements.
> This adjusts adaptively to the traffic load at different nodes.
>
> Please take a look at the following paper:
> D. Dharmaraju, A. Roy-Chowdhury, P. Hovareshti, J. S. Baras , "INORA- A
> Unified Signaling and Routing Protocol in Mobile AdHoc networks"  IWAHN '02
>
> http://techreports.isr.umd.edu/TechReports/ISR/2002/TR_2002-33/TR_2002-33.phtml
>
> Thank you.
> Regards,
> Dinesh
>
> On Tue, 8 Apr 2003, Tan Kean Soon wrote:
>
> > Hi,
> > Is there any protocol that does smart routing decisions by taking the  traffic load in the network  into consideration. Normally, route selection criteria uses metric such as shortest number of hops and quickest response time to a request. Such decision making  can lead to the situation where all packets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this issue?
> >
> > Thanks.
> >
> > Regards,
> > Kean Soon
> >
> > _______________________________________________
> > 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 mailnull@www1.ietf.org  Fri Apr 11 16:14:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28322
	for ; Fri, 11 Apr 2003 16:14:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BKKQO26288
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 16:20:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BKKP826285
	for ; Fri, 11 Apr 2003 16:20:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28314
	for ; Fri, 11 Apr 2003 16:13:35 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944wV-0005Qp-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 16:16:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944wV-0005Qm-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 16:16:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BK4u823439;
	Fri, 11 Apr 2003 16:04:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJrU822788
	for ; Fri, 11 Apr 2003 15:53:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27342
	for ; Fri, 11 Apr 2003 15:46:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944WS-0005E0-00
	for manet@ietf.org; Fri, 11 Apr 2003 15:49:16 -0400
Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu)
	by ietf-mx with esmtp (Exim 4.12)
	id 1944WS-0005Dx-00
	for manet@ietf.org; Fri, 11 Apr 2003 15:49:16 -0400
Received: by mail.eecis.udel.edu (Postfix, from userid 62)
	id 5182132890; Fri, 11 Apr 2003 15:49:16 -0400 (EDT)
Received: from buckwheat.cis.udel.edu (buckwheat.cis.udel.edu [128.4.131.43])
	by mail.eecis.udel.edu (Postfix) with ESMTP id 5F41E328E5
	for ; Fri, 11 Apr 2003 15:49:15 -0400 (EDT)
Date: Fri, 11 Apr 2003 15:49:15 -0400 (EDT)
From: Sonny Rajagopalan 
X-X-Sender: 
To: 
Message-ID: 
X-Spam-Status: No, hits=-4.5 required=6.0
	tests=DEPT_RCVD,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,
	      SPAM_PHRASE_01_02,SUPERLONG_LINE,USER_AGENT_PINE
	version=2.43
X-Sanitizer: This message has been sanitized!
X-Sanitizer-URL: http://mailtools.anomy.net/
X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [manet] Addendum: Adaptive routing protocol based on network/node load
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

---------- Forwarded message ----------
Date: Thu, 10 Apr 2003 11:05:39 -0400 (EDT)
From: Sonny Rajagopalan 
To: manet@ieft.org
Subject: Re: [manet] Adaptive routing protocol based on network/node load

Hello All,

We will soon have a paper out which is related to this thread. The
abstract of the paper appears below:

- --------------BEGIN ABSTRACT------------------------------------------

There are  a number  of unicast routing   protocols for mobile  ad hoc
networks, but none of  them  effectively address  the whole range   of
problems       ad  hoc   networks face.  Furthermore, protocols   that
perform well  in one scenario do not  perform well in all scenarios --
to counter this, we need a general  purpose protocol which assumes the
``face'' of   the  protocol that performs the    best  in the  current
situation --  i.e., we will  need  a protocol   that adapts itself  to
changing network demands autonomously.   This general purpose protocol
is to be a hybrid protocol (to improve  scalability properties) and is
designed to accomodate the following three aspects : (a) shift between
the amount  of proactive routing  and reactive routing autonomously to
improve network metrics, (b) capable of performing relay-based routing
to  accomodate  for  extreme  network    conditions, and  (c)    adapt
dynamically to other network and load characteristics.

This paper describes  the design and implementation  of a  new unicast
routing protocol  for mobile ad   hoc  networks. Our unicast   routing
protocol is  a hybrid, survivable routing  protocol inspired  from the
swarm  intelligence  metaphor, and draws  on  many positive aspects of
swarm intelligence techniques  -- flexibility,  resilience to  network
characteristics.   We have tested a  preliminary implementation of our
and compared it with AODV, and the results are encouraging.

- ---------------END ABSTRACT------------------------------------------

Cheers,
Sonny.
- ----
>From the desk of Sonny Rajagopalan @ http://www.cis.udel.edu/~rajagopa
                                                                  ----

On Tue, 8 Apr 2003, Dinesh Dharmaraju wrote:

> Hi Tan,
>   We have a QoS protocol called INORA, (which uses INSIGNIA signaling and
> TORA routing protocol) and choses routes based on the QoS requirements.
> This adjusts adaptively to the traffic load at different nodes.
>
> Please take a look at the following paper:
> D. Dharmaraju, A. Roy-Chowdhury, P. Hovareshti, J. S. Baras , "INORA- A
> Unified Signaling and Routing Protocol in Mobile AdHoc networks"  IWAHN '02
>
> http://techreports.isr.umd.edu/TechReports/ISR/2002/TR_2002-33/TR_2002-33.phtml
>
> Thank you.
> Regards,
> Dinesh
>
> On Tue, 8 Apr 2003, Tan Kean Soon wrote:
>
> > Hi,
> > Is there any protocol that does smart routing decisions by taking the  traffic load in the network  into consideration. Normally, route selection criteria uses metric such as shortest number of hops and quickest response time to a request. Such decision making  can lead to the situation where all packets are routed through the same node even if there exist better routes where the traffic load is not as large. Could somebody shed some light on this issue?
> >
> > Thanks.
> >
> > Regards,
> > Kean Soon
> >
> > _______________________________________________
> > 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 mailnull@www1.ietf.org  Fri Apr 11 17:33:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01587
	for ; Fri, 11 Apr 2003 17:33:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BLdYf01029
	for manet-archive@odin.ietf.org; Fri, 11 Apr 2003 17:39:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLdY801026
	for ; Fri, 11 Apr 2003 17:39:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01572
	for ; Fri, 11 Apr 2003 17:32:44 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1946B4-00069S-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 17:35:18 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1946B4-00069P-00
	for manet-web-archive@ietf.org; Fri, 11 Apr 2003 17:35:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLR0831884;
	Fri, 11 Apr 2003 17:27:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BLIK831465
	for ; Fri, 11 Apr 2003 17:18:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00645
	for ; Fri, 11 Apr 2003 17:11:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1945qX-0005x7-00
	for manet@ietf.org; Fri, 11 Apr 2003 17:14:05 -0400
Received: from 66-152-29-4.ded.btitelecom.net ([66.152.29.4] helo=mail.scires.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1945qW-0005wy-00
	for manet@ietf.org; Fri, 11 Apr 2003 17:14:04 -0400
Received: from SRCATL-MTA by mail.scires.com
	with Novell_GroupWise; Fri, 11 Apr 2003 17:14:25 -0400
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta
Date: Fri, 11 Apr 2003 17:13:52 -0400
From: "Pete Sholander" 
To: , ,
        
Cc: 
Subject: [manet] Hybrid routing protocols (was RE: [Ans-research] The
	Charter)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

To briefly summarize my "Fall Flame-fest" on this topic, IMHO ...

a) the case where every MANET node can exhibit hybrid behavior is
probably an IRTF topic.

b) the case where a pre-selected set of nodes can speak a proactive
protocol out of one logical interface and a reactive protocol out of a
different logical interface *might* be an IETF topic.  This case would
cover a stub AODV MANET interfacing to an OSPF core.  (The
commercial/educational case.)  It would also address military
applications wherein a ground-based maneuver network (using proactive
techniques?) interfaces with a UAV cloud or sensor network (that use
reactive techniques because of mobility rates and/or energy concerns?).


c) Work on items (a) or (b) must NOT impede the IETF's drive towards
solid Standards for basic Reactive Protocols and basic Proactive
Protocols.  (I'll sidestep whether there's one of each, or two!)      


On a related note, my org did open-air tests of our ZRP variant during
March (20 nodes including man-pack, vehicle mount and a Cessna in
"realistic terrain".)   Maybe I can feed some summarized results into
the IRTF process later this year.  (The basic result was that additional
cross-layer optimizations are definitely needed for practical MANETs.)

--Pete Sholander

>>> "Dearlove, Chris"  04/10/03 08:29AM
>>>

(Note: the ">text" is from Charlie Perkins' posts.)

> I think that going for two documents is the most expedient
> way forward, because the technologies, considered separately,
> are on the way to being fairly well understood.

I can certainly see the logic here. As background I asked the
question at the meeting largely as a request for information,
although I did comment that I could see attractions in a hybrid
protocol in scenarios of interest to us. (I presume everyone else 
can too, so won't give any details here.)

> The idea of a combined proactive/reactive (or, perhaps, "hybrid")
> scheme is in my opinion much less well-understood.  So, it would
> take a lot longer to get the combined scheme, and in the meantime
> we would benefit from the existence of some Proposed Standards for
> the two well-understood technologies.  After we get to that point,
> I think we would be much better prepared to judge our chances for
> success on combining the technologies.

> However, I hope we also make space in the charter for:

> - Internet connectivity
> - Efficient broadcast/multicast

> These are obviously needed, and techniques are known
> for accomplishing them.



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



From mailnull@www1.ietf.org  Sat Apr 12 12:44:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00472
	for ; Sat, 12 Apr 2003 12:44:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CGpfP09377
	for manet-archive@odin.ietf.org; Sat, 12 Apr 2003 12:51:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CGpf809374
	for ; Sat, 12 Apr 2003 12:51:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00465
	for ; Sat, 12 Apr 2003 12:44:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194O9d-0001om-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 12:47:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194O9c-0001oj-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 12:47:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CGcg808783;
	Sat, 12 Apr 2003 12:38:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CGUh807779
	for ; Sat, 12 Apr 2003 12:30:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00098
	for ; Sat, 12 Apr 2003 12:23:29 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194NpL-0001ic-00
	for manet@ietf.org; Sat, 12 Apr 2003 12:26:03 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 194NpL-0001iT-00
	for manet@ietf.org; Sat, 12 Apr 2003 12:26:03 -0400
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 JAA19643;
	Sat, 12 Apr 2003 09:25:31 -0700 (PDT)
Message-Id: <200304121625.JAA19643@pit.erg.sri.com>
To: Thomas Heide Clausen 
cc: ogier@erg.sri.com, manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Wed, 09 Apr 2003 21:38:22 +0200."
             <20030409213822.23b9b121.T.Clausen@computer.org> 
Date: Sat, 12 Apr 2003 09:25:31 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Thomas Heide Clausen wrote:

> Richard,
> 
> Your observation is correct, this is slightly inconsistant in the
> text. HELLO messages do advertice interface adresses, so your
> understanding is correct, it seems. We've already clarified this in
> the version which we will submit to the IETF shortly (within this
> week).

I was hoping you would explain *why* these changes
were made that led to the inconsistency.

It looks like you want to use neighbor interface addresses
for the purpose of discovering 1-hop neighbors (and neighbor
interfaces), but you want to use main node addresses (RIDs) 
for the purpose of discovering 2-hop neighbors, since the
main addresses of 2-hop neighbors are useful for computing
MPRs.  (You want MPRs to cover all 2-hop neighbor nodes, 
not all 2-hop neighbor interfaces.)

I guess you could have it both ways, i.e., a HELLO would
include neighbor interface addresses ONLY for neighbors
that have multiple interfaces that use the same channel
(e.g., for multiple beams of a directional antenna).
Nodes with this property would set a bit in their HELLOs 
to indicate this.

This is one advantage of protocols (e.g., TBRPF and OSPF)
that do not use HELLOs for discovering 2-hop neighbors 
(so the above problem does not occur).  TBRPF and OSPF use 
topology updates for that purpose, which contain RIDs.  
Another advantage is modularity, e.g., so that the same HELLO 
protocol can be used by other routing protocols that do not 
need 2-hop neighbor information. 

I should mention that our TBRPF update (to be submitted in the 
next few days) uses only neighbor interface addresses (instead 
of neighbor RIDs) in HELLOs. The need for using neighbor interface 
addresses in wireless networks was discussed previously 
on the manet list, and Philippe Jacquet recently reminded
me of this, which convinced me to make the change.
The problem is that a node with a directional antenna can
have multiple interfaces that use the same channel, corresponding 
to different beams.
Thus, two different local interfaces could be used to reached 
the same neighbor interface. If HELLOs do not contain neighbor
interface addresses, a node may not know which local interface 
is actually heard by the neighbor.

Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
so it cannot support directional antennas.

Regards,
Richard

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



From mailnull@www1.ietf.org  Sat Apr 12 15:33:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03584
	for ; Sat, 12 Apr 2003 15:33:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CJe1i18688
	for manet-archive@odin.ietf.org; Sat, 12 Apr 2003 15:40:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJe1818678
	for ; Sat, 12 Apr 2003 15:40:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03569
	for ; Sat, 12 Apr 2003 15:32:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194QmT-0002I7-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 15:35:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194QmT-0002I4-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 15:35:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CIRi814150;
	Sat, 12 Apr 2003 14:27:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CIL4814011
	for ; Sat, 12 Apr 2003 14:21:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01543
	for ; Sat, 12 Apr 2003 14:13:48 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194PY6-00024D-00
	for manet@ietf.org; Sat, 12 Apr 2003 14:16:22 -0400
Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 194PY6-00024A-00
	for manet@ietf.org; Sat, 12 Apr 2003 14:16:22 -0400
Received: from armada (voop@pico.cs.auc.dk [130.225.194.80])
	by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h3CIGIPO004423;
	Sat, 12 Apr 2003 20:16:19 +0200 (MEST)
Date: Sat, 12 Apr 2003 20:16:18 +0200
From: Thomas Heide Clausen 
To: ogier@erg.sri.com, manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Message-Id: <20030412201618.21677849.T.Clausen@computer.org>
In-Reply-To: <200304121625.JAA19643@pit.erg.sri.com>
References: <20030409213822.23b9b121.T.Clausen@computer.org>
	<200304121625.JAA19643@pit.erg.sri.com>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Scanned-By: MIMEDefang 2.14
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id h3CIGIPO004423
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3CIL4814012
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3CIRi814150
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3CJe1818678
Content-Transfer-Encoding: 8bit

Dear Richard,

Thanks for your email. I will clarify below in the text.

On Sat, 12 Apr 2003 09:25:31 -0700
ogier@erg.sri.com wrote:

> Thomas Heide Clausen wrote:
> 
> > Richard,
> > 
> > Your observation is correct, this is slightly inconsistant in the
> > text. HELLO messages do advertice interface adresses, so your
> > understanding is correct, it seems. We've already clarified this
> > in the version which we will submit to the IETF shortly (within
> > this week).
> 
> I was hoping you would explain *why* these changes
> were made that led to the inconsistency.
> 

 

> This is one advantage of protocols (e.g., TBRPF and OSPF)
> that do not use HELLOs for discovering 2-hop neighbors 
> (so the above problem does not occur).  TBRPF and OSPF use 
> topology updates for that purpose, which contain RIDs.  
> Another advantage is modularity, e.g., so that the same HELLO 
> protocol can be used by other routing protocols that do not 
> need 2-hop neighbor information. 

Well, if you understand well OLSR, the modularity is there as well.
Basically, there are four seperate activities:

	- link sensing,
	- neighborhood discovery (or "discovering two-hop neighbors", as you
	  call it),
	- MPR selection signalling,
	- global link-state diffusion.

Since the three first (link sensing, neighborhood discovery and MPR
selection signalling) "are locally scoped", i.e. involves a node and
its neighborhood, a common signalling mechanism is employed: periodic
exchange of HELLO messages.

You could - of course - employ one message type for each activity if
you really want to emphasize "modularity". Algorithmically, this is
no change from what we do in OLSR. However you would potentially end
up transmitting exactly the same address in three different messages
- i.e. you would just generate more protocol overhead that way.

So we've choosen to propose the same mechanism for the three "locally
scoped" activities in order to not generate a lot of "unnecessesary"
control messages.

Now, as to why the inconsistancy in the text appeared: between v7 and
v8, we did a large editorial change to simplify the description of
multiple interfaces. The inconsistancy simply slipped in during the
editorial process.

I do believe, that keeping interface addresses in the HELLO messages
is the right thing for OLSR: it allows fine-grained control of which
actual links exists between neighbor nodes, even in the case where a
node has directional antennas operating within the same frequency
range or other such oddities :) 

> 
> I should mention that our TBRPF update (to be submitted in the 
> next few days) uses only neighbor interface addresses (instead 
> of neighbor RIDs) in HELLOs. The need for using neighbor interface 
> addresses in wireless networks was discussed previously 
> on the manet list, and Philippe Jacquet recently reminded
> me of this, which convinced me to make the change.
> The problem is that a node with a directional antenna can
> have multiple interfaces that use the same channel, corresponding 
> to different beams.
> Thus, two different local interfaces could be used to reached 
> the same neighbor interface. If HELLOs do not contain neighbor
> interface addresses, a node may not know which local interface 
> is actually heard by the neighbor.
> 

I am not sure what exactly you are saying in the above: will TBRPF
choose not to support nodes with multiple interfaces? Or will there
be a future version of the TBRPF-specification, which supports this?

> Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
> so it cannot support directional antennas.
> 

I believe that if OSPF (any version) was directly appliable in
MANETs, then the MANET wg would not exist :) So it's only natural
that we need to, occationally, design beyond what is in OSPF.

--thomas

> Regards,
> Richard
> 


-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sat Apr 12 15:54:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03919
	for ; Sat, 12 Apr 2003 15:54:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CK1J119322
	for manet-archive@odin.ietf.org; Sat, 12 Apr 2003 16:01:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CK1J819319
	for ; Sat, 12 Apr 2003 16:01:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03898
	for ; Sat, 12 Apr 2003 15:54:00 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194R75-0002Mz-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 15:56:35 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194R74-0002Mw-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 15:56:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJmd818883;
	Sat, 12 Apr 2003 15:48:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CJeP818717
	for ; Sat, 12 Apr 2003 15:40:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03580
	for ; Sat, 12 Apr 2003 15:33:07 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Qmr-0002IN-00
	for manet@ietf.org; Sat, 12 Apr 2003 15:35:41 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 194Qmr-0002Hx-00
	for manet@ietf.org; Sat, 12 Apr 2003 15:35:41 -0400
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 MAA20128;
	Sat, 12 Apr 2003 12:35:10 -0700 (PDT)
Message-Id: <200304121935.MAA20128@pit.erg.sri.com>
To: Thomas Heide Clausen 
cc: ogier@erg.sri.com, manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Sat, 12 Apr 2003 20:16:18 +0200."
             <20030412201618.21677849.T.Clausen@computer.org> 
Date: Sat, 12 Apr 2003 12:35:10 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Thomas,

> Dear Richard,
> 
> Thanks for your email. I will clarify below in the text.
> 
> On Sat, 12 Apr 2003 09:25:31 -0700
> ogier@erg.sri.com wrote:
> 
> > Thomas Heide Clausen wrote:
> > 
> > > Richard,
> > > 
> > > Your observation is correct, this is slightly inconsistant in the
> > > text. HELLO messages do advertice interface adresses, so your
> > > understanding is correct, it seems. We've already clarified this
> > > in the version which we will submit to the IETF shortly (within
> > > this week).
> > 
> > I was hoping you would explain *why* these changes
> > were made that led to the inconsistency.
> > 
> 
>  
> 
> > This is one advantage of protocols (e.g., TBRPF and OSPF)
> > that do not use HELLOs for discovering 2-hop neighbors 
> > (so the above problem does not occur).  TBRPF and OSPF use 
> > topology updates for that purpose, which contain RIDs.  
> > Another advantage is modularity, e.g., so that the same HELLO 
> > protocol can be used by other routing protocols that do not 
> > need 2-hop neighbor information. 
> 
> Well, if you understand well OLSR, the modularity is there as well.
> Basically, there are four seperate activities:
> 
> 	- link sensing,
> 	- neighborhood discovery (or "discovering two-hop neighbors", as you
> 	  call it),
> 	- MPR selection signalling,
> 	- global link-state diffusion.
> 
> Since the three first (link sensing, neighborhood discovery and MPR
> selection signalling) "are locally scoped", i.e. involves a node and
> its neighborhood, a common signalling mechanism is employed: periodic
> exchange of HELLO messages.
> 
> You could - of course - employ one message type for each activity if
> you really want to emphasize "modularity". Algorithmically, this is

I thought the working group consensus was that modularity
*should* be emphasized.

> no change from what we do in OLSR. However you would potentially end
> up transmitting exactly the same address in three different messages
> - i.e. you would just generate more protocol overhead that way.

TBRPF has managed to avoid most of this redundancy, by using 
only differential HELLOs, and reporting neighbors periodically
only in topology updates.  I realize that OLSR could do the same,
so my point is that maybe OLSR (or the final proactive protocol)
should do something like this to achieve better modularity.

> So we've choosen to propose the same mechanism for the three "locally
> scoped" activities in order to not generate a lot of "unnecessesary"
> control messages.
> 
> Now, as to why the inconsistancy in the text appeared: between v7 and
> v8, we did a large editorial change to simplify the description of
> multiple interfaces. The inconsistancy simply slipped in during the
> editorial process.
> 
> I do believe, that keeping interface addresses in the HELLO messages
> is the right thing for OLSR: it allows fine-grained control of which
> actual links exists between neighbor nodes, even in the case where a
> node has directional antennas operating within the same frequency
> range or other such oddities :) 
> 
> > 
> > I should mention that our TBRPF update (to be submitted in the 
> > next few days) uses only neighbor interface addresses (instead 
> > of neighbor RIDs) in HELLOs. The need for using neighbor interface 
> > addresses in wireless networks was discussed previously 
> > on the manet list, and Philippe Jacquet recently reminded
> > me of this, which convinced me to make the change.
> > The problem is that a node with a directional antenna can
> > have multiple interfaces that use the same channel, corresponding 
> > to different beams.
> > Thus, two different local interfaces could be used to reached 
> > the same neighbor interface. If HELLOs do not contain neighbor
> > interface addresses, a node may not know which local interface 
> > is actually heard by the neighbor.
> > 
> 
> I am not sure what exactly you are saying in the above: will TBRPF
> choose not to support nodes with multiple interfaces? Or will there
> be a future version of the TBRPF-specification, which supports this?

TBRPF has supported multiple interfaces for a long time, but
the inclusion of neighbor interface addresses in HELLOs
(which as I said will be in the version to be submitted in
a few days) will allow the support of directional antennas.

> > Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
> > so it cannot support directional antennas.
> 
> I believe that if OSPF (any version) was directly appliable in
> MANETs, then the MANET wg would not exist :) So it's only natural
> that we need to, occationally, design beyond what is in OSPF.

Really?  Then maybe we haven't been wasting our time developing OLSR 
and TBRPF. :)  Actually, I meant more specifically that the use of
RIDs in OSPF HELLOs prevents it from supporting directional antennas.
I'm not sure whether Fred Baker considered this in his proposed
modifications to OSPF.

Regards,
Richard

> 
> --thomas
> 
> > Regards,
> > Richard
> > 
> 
> 
> -- 
> 
> -------------------------------------------
>   Thomas Heide Clausen
>   Civilingeniør i Datateknik (cand.polyt)
>   M.Sc in Computer Engineering
> 
>   E-Mail: T.Clausen@computer.org
>   WWW:    http://www.cs.auc.dk/~voop
> -------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sat Apr 12 16:59:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04853
	for ; Sat, 12 Apr 2003 16:59:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CL6Ut23124
	for manet-archive@odin.ietf.org; Sat, 12 Apr 2003 17:06:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CL6T823121
	for ; Sat, 12 Apr 2003 17:06:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04846
	for ; Sat, 12 Apr 2003 16:59:09 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194S88-0002aZ-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 17:01:44 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194S88-0002aV-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 17:01:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CKs3822068;
	Sat, 12 Apr 2003 16:54:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CKjH821919
	for ; Sat, 12 Apr 2003 16:45:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04478
	for ; Sat, 12 Apr 2003 16:37:56 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Rnb-0002Th-00
	for manet@ietf.org; Sat, 12 Apr 2003 16:40:31 -0400
Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Rnb-0002Te-00
	for manet@ietf.org; Sat, 12 Apr 2003 16:40:31 -0400
Received: from armada (voop@pico.cs.auc.dk [130.225.194.80])
	by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h3CKeSPO010191;
	Sat, 12 Apr 2003 22:40:29 +0200 (MEST)
Date: Sat, 12 Apr 2003 22:40:28 +0200
From: Thomas Heide Clausen 
To: ogier@erg.sri.com
Cc: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Message-Id: <20030412224028.3a6e9f9f.T.Clausen@computer.org>
In-Reply-To: <200304121935.MAA20128@pit.erg.sri.com>
References: <20030412201618.21677849.T.Clausen@computer.org>
	<200304121935.MAA20128@pit.erg.sri.com>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Scanned-By: MIMEDefang 2.14
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id h3CKeSPO010191
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3CKjH821920
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3CKs3822068
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3CL6T823121
Content-Transfer-Encoding: 8bit

Dear Richard,

On Sat, 12 Apr 2003 12:35:10 -0700
ogier@erg.sri.com wrote:

> Thomas,
> 
> > Dear Richard,
> > 
> > Thanks for your email. I will clarify below in the text.
> > 
> > On Sat, 12 Apr 2003 09:25:31 -0700
> > ogier@erg.sri.com wrote:
> > 
> > > Thomas Heide Clausen wrote:
> > > 
> > > > Richard,
> > > > 
> > > > Your observation is correct, this is slightly inconsistant in
> > > > the text. HELLO messages do advertice interface adresses, so
> > > > your understanding is correct, it seems. We've already
> > > > clarified this in the version which we will submit to the
> > > > IETF shortly (within this week).
> > > 
> > > I was hoping you would explain *why* these changes
> > > were made that led to the inconsistency.
> > > 
> > 
> >  
> > 
> > > This is one advantage of protocols (e.g., TBRPF and OSPF)
> > > that do not use HELLOs for discovering 2-hop neighbors 
> > > (so the above problem does not occur).  TBRPF and OSPF use 
> > > topology updates for that purpose, which contain RIDs.  
> > > Another advantage is modularity, e.g., so that the same HELLO 
> > > protocol can be used by other routing protocols that do not 
> > > need 2-hop neighbor information. 
> > 
> > Well, if you understand well OLSR, the modularity is there as
> > well. Basically, there are four seperate activities:
> > 
> > 	- link sensing,
> > 	- neighborhood discovery (or "discovering two-hop neighbors",
> > 	as you
> > 	  call it),
> > 	- MPR selection signalling,
> > 	- global link-state diffusion.
> > 
> > Since the three first (link sensing, neighborhood discovery and
> > MPR selection signalling) "are locally scoped", i.e. involves a
> > node and its neighborhood, a common signalling mechanism is
> > employed: periodic exchange of HELLO messages.
> > 
> > You could - of course - employ one message type for each activity
> > if you really want to emphasize "modularity". Algorithmically,
> > this is
> 
> I thought the working group consensus was that modularity
> *should* be emphasized.

I think that there was some discussion on "designing independant
modules/components" at some point, but I don't think it ended out in
a decission for the wg? If it did, then it failed misserably,
considering that we have four complete protocols and no seperated
"modules".

That said, I believe that modularity is emphasized in OLSR. As I said
it's basically a matter of seperate activities, which just happen to
benefit from the same signalling mechanism. Actually, I even think
(if you really insist to do so) that with the notion of link codes in
the OLSR spec, it is possible for an implementation to emit seperate
HELLOs for each activity. I.e. a "link-sensing-hello", a
"MPR-signalling-hello" and a "neighbor discovery hello" independantly
(Ok, a neighbor type of "unknown" might be required for this to work,
but you could stick in a bit for that - again, if you *really* want
to do this).

Of course, a node will then send three times as much control
messages, so noone would probably ever do so - which is why OLSR is
designed such that these three signalling mechanisms can be combined.
I do not think that this in any ways compromize modularity. Rather, I
think it is a good combination of modularity and low overhead.

> > no change from what we do in OLSR. However you would potentially
> > end up transmitting exactly the same address in three different
> > messages- i.e. you would just generate more protocol overhead
> > that way.
> 
> TBRPF has managed to avoid most of this redundancy, by using 
> only differential HELLOs, and reporting neighbors periodically
> only in topology updates.  I realize that OLSR could do the same,
> so my point is that maybe OLSR (or the final proactive protocol)
> should do something like this to achieve better modularity.

I am not sure that the question is one of "which protocol is more
modular" at this point. I believe that one could argue that "doing
neighbor updates with topology updates is not very modular since they
are fundamentally different activities", but I don't think that this
is a very constructive exercise, and I won't go into that. 

As for approaches for the "final proactive protocol", I'd be happy to
discuss such when we get a little closer to actually engineering that
protocol. Currently, the WG is still shaping the future charter and
pushing the exp. protocols forward.

However basically (as I believe I have said before, I think in
London), I think that an important first step will be to define the
"information sets" (to use an OLSR term) that the algorithm(s) will
operate on. E.g. the content of a "local link set" and a "topology
set" (etc) - which will form the interface between the "information
being exchanged" and the "algorithms". The actual method for
population of these sets is an orthogonal issue (where we can start
arguing performance, overhead, differential- vs. full- vs. periodic-
vs. whatever-updates), but we will have a framework for such
arguments - and it may even be possible to have two fundamentally
different mechanism "populate" the same information set. Once we've
gotten this initial design ironed out, we can start investigating how
things can be tuned, how different signalling mechanisms can feasibly
be combined etc. 

However I think that this is somewhat premature at this point - or at
least, that we should discuss such under a different subject-line to
get as many peoples input as possible.



> > 
> > I am not sure what exactly you are saying in the above: will
> > TBRPF choose not to support nodes with multiple interfaces? Or
> > will there be a future version of the TBRPF-specification, which
> > supports this?
> 
> TBRPF has supported multiple interfaces for a long time, but
> the inclusion of neighbor interface addresses in HELLOs
> (which as I said will be in the version to be submitted in
> a few days) will allow the support of directional antennas.

Ok, I will be looking forward to reading that spec. How much does
that change of the operation(s) in TBRPF?

> 
> > > Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
> > > so it cannot support directional antennas.
> > 
> > I believe that if OSPF (any version) was directly appliable in
> > MANETs, then the MANET wg would not exist :) So it's only natural
> > that we need to, occationally, design beyond what is in OSPF.
> 
> Really?  Then maybe we haven't been wasting our time developing
> OLSR and TBRPF. :) 

Well, if nothing else then we've had fun doing it. Even better if
what we've done has been usefull for someone, right :)

--thomas

> Actually, I meant more specifically that the
> use of RIDs in OSPF HELLOs prevents it from supporting directional
> antennas. I'm not sure whether Fred Baker considered this in his
> proposed modifications to OSPF.
> 
> Regards,
> Richard
> 
> > 
> > --thomas
> > 
> > > Regards,
> > > Richard
> > > 
> > 
> > 
> > -- 
> > 
> > -------------------------------------------
> >   Thomas Heide Clausen
> >   Civilingeniør i Datateknik (cand.polyt)
> >   M.Sc in Computer Engineering
> > 
> >   E-Mail: T.Clausen@computer.org
> >   WWW:    http://www.cs.auc.dk/~voop
> > -------------------------------------------
> 


-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sat Apr 12 18:41:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07060
	for ; Sat, 12 Apr 2003 18:41:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CMmQ128931
	for manet-archive@odin.ietf.org; Sat, 12 Apr 2003 18:48:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CMmQ828928
	for ; Sat, 12 Apr 2003 18:48:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07053
	for ; Sat, 12 Apr 2003 18:41:05 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Tik-0002pV-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 18:43:38 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Tik-0002pS-00
	for manet-web-archive@ietf.org; Sat, 12 Apr 2003 18:43:38 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CMZn827643;
	Sat, 12 Apr 2003 18:35:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CMRv827449
	for ; Sat, 12 Apr 2003 18:27:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06787
	for ; Sat, 12 Apr 2003 18:20:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194TOw-0002lc-00
	for manet@ietf.org; Sat, 12 Apr 2003 18:23:10 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 194TOv-0002lZ-00
	for manet@ietf.org; Sat, 12 Apr 2003 18:23:09 -0400
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 PAA20563;
	Sat, 12 Apr 2003 15:22:40 -0700 (PDT)
Message-Id: <200304122222.PAA20563@pit.erg.sri.com>
To: Thomas Heide Clausen 
cc: ogier@erg.sri.com, manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Sat, 12 Apr 2003 22:40:28 +0200."
             <20030412224028.3a6e9f9f.T.Clausen@computer.org> 
Date: Sat, 12 Apr 2003 15:22:40 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Thomas,

> Dear Richard,
> 
> On Sat, 12 Apr 2003 12:35:10 -0700
> ogier@erg.sri.com wrote:
> 
> > Thomas,
> > 
> > > Dear Richard,
> > > 
> > > Thanks for your email. I will clarify below in the text.
> > > 
> > > On Sat, 12 Apr 2003 09:25:31 -0700
> > > ogier@erg.sri.com wrote:
> > > 
> > > > Thomas Heide Clausen wrote:
> > > > 
> > > > > Richard,
> > > > > 
> > > > > Your observation is correct, this is slightly inconsistant in
> > > > > the text. HELLO messages do advertice interface adresses, so
> > > > > your understanding is correct, it seems. We've already
> > > > > clarified this in the version which we will submit to the
> > > > > IETF shortly (within this week).
> > > > 
> > > > I was hoping you would explain *why* these changes
> > > > were made that led to the inconsistency.
> > > > 
> > > 
> > >  
> > > 
> > > > This is one advantage of protocols (e.g., TBRPF and OSPF)
> > > > that do not use HELLOs for discovering 2-hop neighbors 
> > > > (so the above problem does not occur).  TBRPF and OSPF use 
> > > > topology updates for that purpose, which contain RIDs.  
> > > > Another advantage is modularity, e.g., so that the same HELLO 
> > > > protocol can be used by other routing protocols that do not 
> > > > need 2-hop neighbor information. 
> > > 
> > > Well, if you understand well OLSR, the modularity is there as
> > > well. Basically, there are four seperate activities:
> > > 
> > > 	- link sensing,
> > > 	- neighborhood discovery (or "discovering two-hop neighbors",
> > > 	as you
> > > 	  call it),
> > > 	- MPR selection signalling,
> > > 	- global link-state diffusion.
> > > 
> > > Since the three first (link sensing, neighborhood discovery and
> > > MPR selection signalling) "are locally scoped", i.e. involves a
> > > node and its neighborhood, a common signalling mechanism is
> > > employed: periodic exchange of HELLO messages.
> > > 
> > > You could - of course - employ one message type for each activity
> > > if you really want to emphasize "modularity". Algorithmically,
> > > this is
> > 
> > I thought the working group consensus was that modularity
> > *should* be emphasized.
> 
> I think that there was some discussion on "designing independant
> modules/components" at some point, but I don't think it ended out in
> a decission for the wg? If it did, then it failed misserably,
> considering that we have four complete protocols and no seperated
> "modules".
> 
> That said, I believe that modularity is emphasized in OLSR. As I said
> it's basically a matter of seperate activities, which just happen to
> benefit from the same signalling mechanism. Actually, I even think
> (if you really insist to do so) that with the notion of link codes in
> the OLSR spec, it is possible for an implementation to emit seperate
> HELLOs for each activity. I.e. a "link-sensing-hello", a
> "MPR-signalling-hello" and a "neighbor discovery hello" independantly
> (Ok, a neighbor type of "unknown" might be required for this to work,
> but you could stick in a bit for that - again, if you *really* want
> to do this).
> 
> Of course, a node will then send three times as much control
> messages, so noone would probably ever do so - which is why OLSR is
> designed such that these three signalling mechanisms can be combined.

The three different control messages could be put into the same packet,
so the question is how much additional overhead would occur, due to 
the same node appearing redundantly in multiple messages.

The way OLSR is designed, you are right that a lot of redundancy
would occur.  But the main reason for that is that OLSR reports
neighbor information periodically even when differential reporting
is sufficient.  (TBRPF is one example of how neighbor sensing can be
done with differential reporting.)  MPR updates also can be differential,
since the MPR selector only needs to report its selected MPRs
to the MPRs themselves, and not to new neighbors.
(There are simple ways to do this reliably, which we don't need
to discuss now.)

Of course, I am not suggesting that you modify OLSR now.
I am talking about how to design the final proactive protocol.

> I do not think that this in any ways compromize modularity. Rather, I
> think it is a good combination of modularity and low overhead.
> 
> > > no change from what we do in OLSR. However you would potentially
> > > end up transmitting exactly the same address in three different
> > > messages- i.e. you would just generate more protocol overhead
> > > that way.
> > 
> > TBRPF has managed to avoid most of this redundancy, by using 
> > only differential HELLOs, and reporting neighbors periodically
> > only in topology updates.  I realize that OLSR could do the same,
> > so my point is that maybe OLSR (or the final proactive protocol)
> > should do something like this to achieve better modularity.
> 
> I am not sure that the question is one of "which protocol is more modular"

If you read my above paragraph again you will see that that was not my point.
My point is "Which way should it be done in the final protocol?"

> at this point. I believe that one could argue that "doing
> neighbor updates with topology updates is not very modular since they
> are fundamentally different activities", but I don't think that this

That depends on what you mean by "doing neighbor updates".
I am talking about discovering 2-hop neighbors via topology updates, 
not 1-hop neighbors (which are done with HELLOs).
2-hop neighbors are not really neighbors (in the sense of most routing
protocols like OSPF).  So 2-hop neighbor discovery is usually considered 
part of topology discovery.  However, if some application needs
ONLY 2-hop neighbor information and not information for > 2 hops,
then one can easily separate topology updates into those that
report local links (to neighbors) and those that report non-local links.
(Or one can simply limit the scope of the routing protocol to 2 hops.)

> is a very constructive exercise, and I won't go into that. 
> 
> As for approaches for the "final proactive protocol", I'd be happy to
> discuss such when we get a little closer to actually engineering that
> protocol. Currently, the WG is still shaping the future charter and
> pushing the exp. protocols forward.

OK.  Maybe I am a bit early.  But you know the expression:
"Better early than never."  

> However basically (as I believe I have said before, I think in
> London), I think that an important first step will be to define the
> "information sets" (to use an OLSR term) that the algorithm(s) will
> operate on. E.g. the content of a "local link set" and a "topology
> set" (etc) - which will form the interface between the "information
> being exchanged" and the "algorithms". The actual method for
> population of these sets is an orthogonal issue (where we can start
> arguing performance, overhead, differential- vs. full- vs. periodic-
> vs. whatever-updates), but we will have a framework for such
> arguments - and it may even be possible to have two fundamentally
> different mechanism "populate" the same information set. Once we've
> gotten this initial design ironed out, we can start investigating how
> things can be tuned, how different signalling mechanisms can feasibly
> be combined etc. 

I disagree!  It was Atlanta, not London. :)
Actually, it sounds like a good plan.

> However I think that this is somewhat premature at this point - or at
> least, that we should discuss such under a different subject-line to
> get as many peoples input as possible.
> 
> 
> 
> > > 
> > > I am not sure what exactly you are saying in the above: will
> > > TBRPF choose not to support nodes with multiple interfaces? Or
> > > will there be a future version of the TBRPF-specification, which
> > > supports this?
> > 
> > TBRPF has supported multiple interfaces for a long time, but
> > the inclusion of neighbor interface addresses in HELLOs
> > (which as I said will be in the version to be submitted in
> > a few days) will allow the support of directional antennas.
> 
> Ok, I will be looking forward to reading that spec. How much does
> that change of the operation(s) in TBRPF?

Not much, really.  It is mosly a matter of defining local links
to go to neighbor interfaces instead of to neighbor nodes
(as in OLSR). Topology discovery is not affected since it uses RIDs.

> > > > Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
> > > > so it cannot support directional antennas.
> > > 
> > > I believe that if OSPF (any version) was directly appliable in
> > > MANETs, then the MANET wg would not exist :) So it's only natural
> > > that we need to, occationally, design beyond what is in OSPF.
> > 
> > Really?  Then maybe we haven't been wasting our time developing
> > OLSR and TBRPF. :) 
> 
> Well, if nothing else then we've had fun doing it. Even better if
> what we've done has been usefull for someone, right :)

Right. 

Regards,
Richard


> 
> --thomas
> 
> > Actually, I meant more specifically that the
> > use of RIDs in OSPF HELLOs prevents it from supporting directional
> > antennas. I'm not sure whether Fred Baker considered this in his
> > proposed modifications to OSPF.
> > 
> > Regards,
> > Richard
> > 
> > > 
> > > --thomas
> > > 
> > > > Regards,
> > > > Richard
> > > > 
> > > 
> > > 
> > > -- 
> > > 
> > > -------------------------------------------
> > >   Thomas Heide Clausen
> > >   Civilingeniør i Datateknik (cand.polyt)
> > >   M.Sc in Computer Engineering
> > > 
> > >   E-Mail: T.Clausen@computer.org
> > >   WWW:    http://www.cs.auc.dk/~voop
> > > -------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sun Apr 13 05:00:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26161
	for ; Sun, 13 Apr 2003 05:00:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3D978611669
	for manet-archive@odin.ietf.org; Sun, 13 Apr 2003 05:07:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D978811666
	for ; Sun, 13 Apr 2003 05:07:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26141
	for ; Sun, 13 Apr 2003 04:59:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194dNH-0004mC-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 05:02:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194dNG-0004m9-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 05:02:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8pF810916;
	Sun, 13 Apr 2003 04:51:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8iB810730
	for ; Sun, 13 Apr 2003 04:44:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25859
	for ; Sun, 13 Apr 2003 04:36:37 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194d15-0004hE-00
	for manet@ietf.org; Sun, 13 Apr 2003 04:39:11 -0400
Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 194d15-0004h5-00
	for manet@ietf.org; Sun, 13 Apr 2003 04:39:11 -0400
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59)
	id <25785HQ5>; Sun, 13 Apr 2003 04:38:37 -0400
Message-ID: <748C6D0A58C0F94CA63C198B6674697A01178DAD@ftmail.lab.flarion.com>
From: Scott Corson 
To: "'Claude Castelluccia'" ,
        Scott Corson
	 
Cc: "'Elizabeth M. Belding-Royer'" ,
        "'ans-research@www1.ietf.org'" ,
        "'lily.l.yang@intel.com'" ,
        "'manet@ietf.org'"
	 
Subject: RE: [manet] Re: [Ans-research] The Charter
Date: Sun, 13 Apr 2003 04:38:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30198.0878FF30"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

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_01C30198.0878FF30
Content-Type: text/plain

Claude,
 
I was referring to the ANS work... not MANET.  Sorry for the confusion that
cross-posting on two lists can create.
 
-Scott

-----Original Message-----
From: Claude Castelluccia [mailto:Claude.castelluccia@inrialpes.fr] 
Sent: Wednesday, April 09, 2003 3:25 AM
To: Scott Corson
Cc: 'Elizabeth M. Belding-Royer'; 'ans-research@www1.ietf.org';
'lily.l.yang@intel.com'; 'manet@ietf.org'
Subject: [manet] Re: [Ans-research] The Charter


Scott Corson wrote: 


For purposes of keeping a (somewhat) more narrowed scope, I believe we 
should avoid both multicast and security for the time being. 
   

Hello Scott, 

Do you mean that work on MANET's security should be postponed or should be
the subject 
of another WG?... 
cheers, 


Claude. 
  


-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


------_=_NextPart_001_01C30198.0878FF30
Content-Type: text/html




Message




Claude,


 


I was 
referring to the ANS work... not MANET.  Sorry for the confusion that 
cross-posting on two lists can create.


 


-Scott



  

  
-----Original Message-----
From: Claude 
  Castelluccia [mailto:Claude.castelluccia@inrialpes.fr] 
Sent: 
  Wednesday, April 09, 2003 3:25 AM
To: Scott Corson
Cc: 
  'Elizabeth M. Belding-Royer'; 'ans-research@www1.ietf.org'; 
  'lily.l.yang@intel.com'; 'manet@ietf.org'
Subject: [manet] Re: 
  [Ans-research] The Charter

Scott Corson wrote: 
  
 
For purposes of keeping a (somewhat) more 
    narrowed scope, I believe we 
should avoid both multicast and security 
    for the time being. 
 
Hello 
  Scott, 
  
Do you mean that work on MANET's security should be postponed or should be 
  the subject 
of another WG?... 
cheers, 
  
Claude. 
  
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  



------_=_NextPart_001_01C30198.0878FF30--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sun Apr 13 07:05:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27333
	for ; Sun, 13 Apr 2003 07:05:53 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3DBCxP18169
	for manet-archive@odin.ietf.org; Sun, 13 Apr 2003 07:12:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DBCw818166
	for ; Sun, 13 Apr 2003 07:12:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27327
	for ; Sun, 13 Apr 2003 07:05:22 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194fL1-000517-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 07:07:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194fL1-000514-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 07:07:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DAvK816944;
	Sun, 13 Apr 2003 06:57:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DApq816855
	for ; Sun, 13 Apr 2003 06:51:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27121
	for ; Sun, 13 Apr 2003 06:44:16 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194f0b-0004xa-00
	for manet@ietf.org; Sun, 13 Apr 2003 06:46:49 -0400
Received: from dirf.bris.ac.uk ([137.222.10.72])
	by ietf-mx with esmtp (Exim 4.12)
	id 194f0b-0004xX-00
	for manet@ietf.org; Sun, 13 Apr 2003 06:46:49 -0400
Received: from golf.een.bris.ac.uk by dirf.bris.ac.uk with SMTP-PRIV 
          with ESMTP; Sun, 13 Apr 2003 11:46:46 +0100
Received: from EEN9097.een.bris.ac.uk (een9097.een.bris.ac.uk [137.222.189.97]) 
          by golf.een.bris.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA10063 
          for ; Sun, 13 Apr 2003 11:45:30 +0100 (BST)
From: "D Kothris, Electrical & Electronic Engineering" 
Date: Sun, 13 Apr 2003 11:45:33 +0100
To: manet@ietf.org
Message-ID: 
Priority: NORMAL
X-Mailer: Execmail for Win32 Version 5.0.1 Build (55)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Subject: [manet] MAC
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Hi,

Could anyone provide or point out where i can find a 
FSM diagramm or a pseudo algorithm representation of the
802.11/DCF  RTS/CTS/DATA/ACK mac protocol?

Cheers

_________________________________________________________________ 
*****************************************************************
Dimosthenis Kothris	      Centre for Communications Research, 
			      University of Bristol,
			      Network & Protocols group

Address:		      Contact numbers: 	
_________________________________________________________________ 
Network & Protocols
Center for Communcations research
Merchant Venturers Building         Tel   :            +44 117 903 1104
Woodland Road                       Fax   :            +44 117 954 5206
Bristol BS8 1UB                     Mobile:           +44 7779 40 48 42
United Kingdom                      Email :     d.kothris@bristol.ac.uk
*****************************************************************

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



From mailnull@www1.ietf.org  Sun Apr 13 19:14:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08568
	for ; Sun, 13 Apr 2003 19:14:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3DNM7G23712
	for manet-archive@odin.ietf.org; Sun, 13 Apr 2003 19:22:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DNM7823709
	for ; Sun, 13 Apr 2003 19:22:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08554
	for ; Sun, 13 Apr 2003 19:14:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194qiO-0006bJ-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 19:16:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194qiN-0006bF-00
	for manet-web-archive@ietf.org; Sun, 13 Apr 2003 19:16:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DN0Q822243;
	Sun, 13 Apr 2003 19:00:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMn0821988
	for ; Sun, 13 Apr 2003 18:49:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08139
	for ; Sun, 13 Apr 2003 18:41:08 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194qCM-0006U7-00
	for manet@ietf.org; Sun, 13 Apr 2003 18:43:42 -0400
Received: from diver.doc.ic.ac.uk ([146.169.1.47] ident=exim)
	by ietf-mx with esmtp (Exim 4.12)
	id 194qCM-0006U3-00
	for manet@ietf.org; Sun, 13 Apr 2003 18:43:42 -0400
Received: from siskin.doc.ic.ac.uk ([146.169.2.61] ident=slk)
	by diver.doc.ic.ac.uk with esmtp (Exim 3.16 #7)
	id 194qCF-0005rZ-00
	for manet@ietf.org; Sun, 13 Apr 2003 23:43:35 +0100
Date: Sun, 13 Apr 2003 23:43:35 +0100 (BST)
From: Sye Loong Keoh 
To: manet@ietf.org
In-Reply-To: <20030413160003.32028.1419.Mailman@www1.ietf.org>
Message-ID: 
References: <20030413160003.32028.1419.Mailman@www1.ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] NIST AODV kernel module - segmentation fault
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Dear All,

Recently I tried to load the aodv kernel into two linux machines (kernel
version 2.4.18). I managed to complied the aodv kernel and set up the
machines in ad-hoc mode.

When I have loaded the aodv kernel (kernel_aodv.o), I tried to run cat
/proc/adov/route_table, I get a segmentation fault error. I have no idea
what happened. If you have came across this problem or you have any idea
why this happen, could you please let me know?

Thanks and kind regards.

Sye Loong.

------------------------------------------------
Sye Loong KEOH
Distributed Software Engineering (DSE) Group
Department of Computing, Imperial College London
http://www.doc.ic.ac.uk/~slk
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 14 11:13:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08822
	for ; Mon, 14 Apr 2003 11:13:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EFL5W29510
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 11:21:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFL5829507
	for ; Mon, 14 Apr 2003 11:21:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08803
	for ; Mon, 14 Apr 2003 11:12:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955g6-0002s1-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:15:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955g5-0002ry-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:15:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EF3c827587;
	Mon, 14 Apr 2003 11:03:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEp7827093
	for ; Mon, 14 Apr 2003 10:51:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07968
	for ; Mon, 14 Apr 2003 10:42:56 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955D6-0002ge-00
	for manet@ietf.org; Mon, 14 Apr 2003 10:45:28 -0400
Received: from s2.itd.nrl.navy.mil ([132.250.83.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1955D6-0002gQ-00
	for manet@ietf.org; Mon, 14 Apr 2003 10:45:28 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.9+Sun/8.12.8) with ESMTP id h3EEj4MZ008573;
	Mon, 14 Apr 2003 10:45:04 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.9+Sun/8.12.2) with SMTP id h3EEitFM009503;
	Mon, 14 Apr 2003 10:44:58 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003041410445801075
 ; Mon, 14 Apr 2003 10:44:58 -0400
Message-Id: <5.1.1.5.2.20030414104358.0251a720@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 14 Apr 2003 10:44:34 -0400
To: "Charles E. Perkins" 
From: Joe Macker 
Subject: Re: [manet] RE: [Ans-research] The Charter
Cc: "'manet@ietf.org'" 
In-Reply-To: <3E944588.EE37EDF6@iprg.nokia.com>
References: <5.1.1.5.2.20030409112213.02c30e78@pop.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 09:08 AM 4/9/2003 -0700, Charles E. Perkins wrote:

>Hello Joe,
>
>Joe Macker wrote:
>
>>>> The MANET WG future (if it has one) is focused work on two unified
>>>> protocols: reactive and proactive.
>                  ............
>> That is true..
>> 
>> That MAY be the way forward, but there is still a discussion period.
>> The meeting minutes address the fact that MAY be the likely taxonomy
>> for further work based upon previous work.
>
>I think that going for two documents is the most expedient
>way forward, because the technologies, considered separately,
>are on the way to being fairly well understood.

I agree..


>The idea of a combined proactive/reactive (or, perhaps, "hybrid")
>scheme is in my opinion much less well-understood.  So, it would
>take a lot longer to get the combined scheme, and in the meantime
>we would benefit from the existence of some Proposed Standards for
>the two well-understood technologies.  After we get to that point,
>I think we would be much better prepared to judge our chances for
>success on combining the technologies.
>
>However, I hope we also make space in the charter for:
>
>- Internet connectivity
>- Efficient broadcast/multicast

I also agree..


>These are obviously needed, and techniques are known
>for accomplishing them.
>
>Regards,
>Charlie P.
>
>
>
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. 
>
>I am feeling privileged, too :-)
>_______________________________________________
>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 mailnull@www1.ietf.org  Mon Apr 14 11:17:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09007
	for ; Mon, 14 Apr 2003 11:17:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EFPS929695
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 11:25:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFPS829692
	for ; Mon, 14 Apr 2003 11:25:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08972
	for ; Mon, 14 Apr 2003 11:17:16 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955kK-0002tT-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:19:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955kK-0002tQ-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:19:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEuB827258;
	Mon, 14 Apr 2003 10:56:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEnX827012
	for ; Mon, 14 Apr 2003 10:49:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07944
	for ; Mon, 14 Apr 2003 10:41:22 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955Bb-0002g6-00
	for manet@ietf.org; Mon, 14 Apr 2003 10:43:55 -0400
Received: from s2.itd.nrl.navy.mil ([132.250.83.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1955Ba-0002fw-00
	for manet@ietf.org; Mon, 14 Apr 2003 10:43:54 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.9+Sun/8.12.8) with ESMTP id h3EEgDMZ008449;
	Mon, 14 Apr 2003 10:42:13 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.9+Sun/8.12.2) with SMTP id h3EEg8FI009445;
	Mon, 14 Apr 2003 10:42:08 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003041410420701063
 ; Mon, 14 Apr 2003 10:42:07 -0400
Message-Id: <5.1.1.5.2.20030414104023.02b51e18@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 14 Apr 2003 10:41:43 -0400
To: Sye Loong Keoh , manet@ietf.org
From: Joe Macker 
Subject: Re: [manet] NIST AODV kernel module - segmentation fault
In-Reply-To: 
References: <20030413160003.32028.1419.Mailman@www1.ietf.org>
 <20030413160003.32028.1419.Mailman@www1.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

please post such questions and responses to the AODV implementors list or to the NIST developers.
-joe

At 11:43 PM 4/13/2003 +0100, Sye Loong Keoh wrote:
>Dear All,
>
>Recently I tried to load the aodv kernel into two linux machines (kernel
>version 2.4.18). I managed to complied the aodv kernel and set up the
>machines in ad-hoc mode.
>
>When I have loaded the aodv kernel (kernel_aodv.o), I tried to run cat
>/proc/adov/route_table, I get a segmentation fault error. I have no idea
>what happened. If you have came across this problem or you have any idea
>why this happen, could you please let me know?
>
>Thanks and kind regards.
>
>Sye Loong.


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



From mailnull@www1.ietf.org  Mon Apr 14 11:27:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09221
	for ; Mon, 14 Apr 2003 11:27:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EFYsX30226
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 11:34:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFYs830223
	for ; Mon, 14 Apr 2003 11:34:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09203
	for ; Mon, 14 Apr 2003 11:26:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955tS-0002xX-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:29:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955tS-0002xU-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 11:29:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFID829284;
	Mon, 14 Apr 2003 11:18:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFDA829087
	for ; Mon, 14 Apr 2003 11:13:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08527
	for ; Mon, 14 Apr 2003 11:04:59 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1955YR-0002pL-00
	for manet@ietf.org; Mon, 14 Apr 2003 11:07:31 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 1955YQ-0002p1-00
	for manet@ietf.org; Mon, 14 Apr 2003 11:07:30 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3EF71gG016655;
	Mon, 14 Apr 2003 08:07:03 -0700 (PDT)
Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with SMTP id AGB93724;
	Mon, 14 Apr 2003 08:05:05 -0700 (PDT)
Message-Id: <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 14 Apr 2003 08:07:00 -0700
To: ogier@erg.sri.com, Thomas Heide Clausen 
From: Fred Baker 
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Cc: manet@ietf.org
In-Reply-To: <20030412201618.21677849.T.Clausen@computer.org>
References: <200304121625.JAA19643@pit.erg.sri.com>
 <20030409213822.23b9b121.T.Clausen@computer.org>
 <200304121625.JAA19643@pit.erg.sri.com>
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 08:16 PM 4/12/2003 +0200, Thomas Heide Clausen wrote:
>I believe that if OSPF (any version) was directly appliable in MANETs, 
>then the MANET wg would not exist :) So it's only natural that we need to, 
>occationally, design beyond what is in OSPF.

I was the chair of the IET at the time the working group was formed. It was 
understood to be a research group, and would have been sent at the time to 
the IRTF if the IRTF had been functional; it was barely so at the time, so 
the IETF picked up the group and gave it a fair bit of leeway.

At the time, we felt there was quite a bit of room for experimentation, and 
that we didn't want to prejudge questions like whether or not OSPF was 
usable for the purpose. The WG/RG - take your pick - came up with a number 
of protocols that experimented with various aspects of the problem. This is 
was expected.

However, none of the manet proposals has addressed its own use in a 
non-manet network, which means that if someone has a manet that interacts 
with a static network, they at lest nominally have to exchange prefixes 
between two routing protocols. Operationally, I won't call that a 
non-starter, but it is a huge impediment; every device that might operate 
in either way must be configured twice, and someone needs to think very 
carefully about the policies for leaking routes between them. This is 
non-trivial in the extreme. Finding a way to run one protocol - whatever it 
is - in both the manet and the non-manet zone of a network reduces a lot of 
operational issues.

Few of the manet protocols have directly addressed security issues as 
raised in 
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-00.txt. 
Given that no protocol can become an *informational* RFC, much less a 
standard, without seriously addressing security, ...

None has addressed management of the router using the protocol, or even a 
management model. None has addressed scaling of address management issues, 
in the sense that OSPF or IS-IS do in deploying areas, beyond wondering how 
it might reduce message count. None has...

I would count no protocol out of action, whether TBRPF, OLSR, AODV, OSPF, 
or IS-IS. Each has its strengths and weaknesses, and opportunities to 
address those weaknesses. If you want to talk about taking any manet 
routing protocol to Proposed Standard, however, I think it is only fair 
that you assume you will have to jump the same hurdles that the rest of us 
have (RFC 1264, which is probably dated but is what we were measured 
against), and that the protocol will need to be at least as operationally 
useful in a real network run by a real operator, not just one jerry-rigged 
to test certain aspects of research.

And given that none of the protocols have significantly addressed the 
issues that separate the "men" from the "boys" among routing protocols, I 
personally find the continued notes that one or another does particular 
poorly or particularly well on some narrowly chosen test to be a bit 
tiresome. Go finish the job, publish your counterparts to RFC 1245 and 
1246, and then we'll discuss it. 

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



From mailnull@www1.ietf.org  Mon Apr 14 12:49:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11706
	for ; Mon, 14 Apr 2003 12:49:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EGvDb04745
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 12:57:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGvC804742
	for ; Mon, 14 Apr 2003 12:57:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11682
	for ; Mon, 14 Apr 2003 12:48:58 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957B5-0003Sd-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 12:51:31 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957B5-0003Sa-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 12:51:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGe2803758;
	Mon, 14 Apr 2003 12:40:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGXj802653
	for ; Mon, 14 Apr 2003 12:33:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10875
	for ; Mon, 14 Apr 2003 12:25:32 -0400 (EDT)
From: sandy@tislabs.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1956oP-0003Hq-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:28:05 -0400
Received: from sentry.gw.tislabs.com ([192.94.214.100] ident=firewall-user)
	by ietf-mx with esmtp (Exim 4.12)
	id 1956oO-0003Hn-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:28:04 -0400
Received: by sentry.gw.tislabs.com; id MAA26583; Mon, 14 Apr 2003 12:29:13 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma026528; Mon, 14 Apr 03 12:28:19 -0400
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id h3EGRGG05087;
	Mon, 14 Apr 2003 12:27:16 -0400 (EDT)
Date: Mon, 14 Apr 2003 12:27:16 -0400 (EDT)
Message-Id: <200304141627.h3EGRGG05087@raven.gw.tislabs.com>
To: T.Clausen@computer.org, fred@cisco.com, ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Cc: manet@ietf.org
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

>Few of the manet protocols have directly addressed security issues as 
>raised in 
>http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-00.txt. 

For those who have not visited the rpsec mailing list, I should note that
this draft is still very much a work in progress.  In particular, I think
that some of the language shows a wired world focus and would not fit
a wireless world.  As I've said in various comments to the rpsec list.
I invite anyone interested in the security of manet protocols to visit
the rpsec list to add an informed voice to the discussion.

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



From mailnull@www1.ietf.org  Mon Apr 14 12:59:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12011
	for ; Mon, 14 Apr 2003 12:59:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EH7FP05707
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 13:07:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EH7F805704
	for ; Mon, 14 Apr 2003 13:07:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11997
	for ; Mon, 14 Apr 2003 12:59:00 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957Kn-0003Xi-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:01:33 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957Kn-0003Xf-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:01:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGpM804390;
	Mon, 14 Apr 2003 12:51:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGmF804206
	for ; Mon, 14 Apr 2003 12:48:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11360
	for ; Mon, 14 Apr 2003 12:40:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19572Q-0003OM-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:42:34 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 19572P-0003OD-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:42:33 -0400
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 JAA01149;
	Mon, 14 Apr 2003 09:42:07 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3EGg7I27694;
	Mon, 14 Apr 2003 09:42:07 -0700
X-mProtect: <200304141642> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdxprPy2; Mon, 14 Apr 2003 09:42:05 PDT
Message-ID: <3E9AE4DD.D91C6DE8@iprg.nokia.com>
Date: Mon, 14 Apr 2003 09:42:05 -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: Fred Baker 
CC: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
References: <200304121625.JAA19643@pit.erg.sri.com>
	 <20030409213822.23b9b121.T.Clausen@computer.org>
	 <200304121625.JAA19643@pit.erg.sri.com> <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Fred,

Fred Baker wrote:

> At the time, we felt there was quite a bit of room for experimentation, and
> that we didn't want to prejudge questions like whether or not OSPF was
> usable for the purpose. The WG/RG - take your pick - came up with a number
> of protocols that experimented with various aspects of the problem. This is
> was expected.

In particular, as I remember from the BOFs, there was a great
deal of pessimism that OSPF could possibly do the job, resulting
from experiments that were presented showing that OSPF consumed
120% of the available bandwidth for some particular scenario.
Of course, it would do better in many other scenarios.

> However, none of the manet proposals has addressed its own use in a
> non-manet network, which means that if someone has a manet that interacts
> with a static network, they at lest nominally have to exchange prefixes
> between two routing protocols.

This is true, and is largely a result of the desire to avoid
disseminating host routes into larger routing domains.
The question of ad-hoc subnet formation, address allocation,
and aggregation may be beyond even what is currently reasonable
for the IRTF group.  I'm interested, and would help, but I don't
see anything being standard soon.  It seems to me that OSPF
works better when there is some subnet structure that one can
use effectively for aggregation.  On the other hand, there
is far more about OSPF that I do not know, compared to the
little bit I do know, so if my impressions are wrong I would
appreciate getting the better understanding.

>                                    Operationally, I won't call that a
> non-starter, but it is a huge impediment; every device that might operate
> in either way must be configured twice, and someone needs to think very
> carefully about the policies for leaking routes between them. This is
> non-trivial in the extreme. Finding a way to run one protocol - whatever it
> is - in both the manet and the non-manet zone of a network reduces a lot of
> operational issues.

Maybe this is related to the "hybridization" idea -- in this case,
we need one variant to deal with the nonaggregable parts of the
overall route table, and another variant to deal with the aggregable
part(s).

On the other hand, it is my belief that advances in protocol
design that result from work on ad hoc networks _should_ be
considered for use with other protocols (e.g., OSPF).  Is it
feasible to put this on the charter for manet-ng?

> Few of the manet protocols have directly addressed security issues as
> raised in
> http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-00.txt.
> Given that no protocol can become an *informational* RFC, much less a
> standard, without seriously addressing security, ...

Maybe so, but my understanding is that the U.S. military is
showing very strong interest in manet protocols.  Joe probably
could say more about that.  The military probably has pretty
strong security requirements.  Putting these two ideas together,
I get that the military is able to live within the realm of
applicability defined by the security properties of the protocols
they are trying to use.  This probably means that they have
some other key management, outside the particular specification
of the routing protocol they may be trying to use.  That at least
allows messages to be authenticated and encrypted under the
particular assumptions in use.

> None has addressed management of the router using the protocol, or even a
> management model. None has addressed scaling of address management issues,
> in the sense that OSPF or IS-IS do in deploying areas, beyond wondering how
> it might reduce message count. None has...

The management model for ad hoc nodes that I favor, is that
the user does not have to do any management whatsoever.
If my wireless, dynamic, multihop device requires me to type
in anything as complicated as what router experts are used to,
then the result will be almost a total failure.  Thus, I really
think your evaluation is far too harsh.  I would go so far as
to suggest that zero management is preferable to even the slightest
user inconvenience.

In fact, it is my belief that the IETF is driving productivity
to zero by insisting on unsatisfiably universal security demands,
instead of just making sure that protocols are secure for their
particular usage scenarios.  That's like saying since we can't
have everything, then by golly we'll show "them" and have nothing.
Oops, wrong soapbox!  I'll step off now...

> I would count no protocol out of action, whether TBRPF, OLSR, AODV, OSPF,
> or IS-IS. Each has its strengths and weaknesses, and opportunities to
> address those weaknesses. If you want to talk about taking any manet
> routing protocol to Proposed Standard, however, I think it is only fair
> that you assume you will have to jump the same hurdles that the rest of us
> have (RFC 1264, which is probably dated but is what we were measured
> against), and that the protocol will need to be at least as operationally
> useful in a real network run by a real operator, not just one jerry-rigged
> to test certain aspects of research.

I think instead that we ought to characterize the intended use
model well enough that it can be satisfied by something besides
big iron and routing priesthood.  I also think that it is quite
unfair to characterize all of the ad hoc research as jerry-rigging.
Who is Jerry, anyway??  Maybe that terminology is a descendent
of "gerrymandering"?

> And given that none of the protocols have significantly addressed the
> issues that separate the "men" from the "boys" among routing protocols, I
> personally find the continued notes that one or another does particular
> poorly or particularly well on some narrowly chosen test to be a bit
> tiresome. Go finish the job, publish your counterparts to RFC 1245 and
> 1246, and then we'll discuss it.

Fred, while no one (and least of all me, as you well know) would
doubt your good intentions here, I think that it comes off as
macho and insensitive to the issues needing discussion.  I'm sorry
if you have found all the foregoing work to be tiresome.  Maybe
the words "routing protocol" have too much baggage and history
within the IETF, and we need some other terminology to denote
the kind of cooperative network procedures needed for ad hoc.
Or maybe someone ought to express the ground rules for IETF participation
to make it clear whether manet qualifies.  If only complicated,
universally secure, fully managed network protocols can qualify,
maybe IETF is just plain the wrong place.  It would be nice to know.

Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 14 13:05:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12226
	for ; Mon, 14 Apr 2003 13:05:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EHD3n06604
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 13:13:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHD3806601
	for ; Mon, 14 Apr 2003 13:13:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12214
	for ; Mon, 14 Apr 2003 13:04:49 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957QP-0003Zv-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:07:22 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957QP-0003Zs-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:07:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGvc804771;
	Mon, 14 Apr 2003 12:57:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGsr804620
	for ; Mon, 14 Apr 2003 12:54:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11589
	for ; Mon, 14 Apr 2003 12:46:39 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19578q-0003Ri-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:49:12 -0400
Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 19578p-0003Rf-00
	for manet@ietf.org; Mon, 14 Apr 2003 12:49:11 -0400
Received: from armada (voop@pico.cs.auc.dk [130.225.194.80])
	by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h3EGnFne010221
	for ; Mon, 14 Apr 2003 18:49:15 +0200 (MEST)
Date: Mon, 14 Apr 2003 18:49:15 +0200
From: Thomas Heide Clausen 
To: manet@ietf.org
Message-Id: <20030414184915.7bb4e9cc.T.Clausen@computer.org>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Scanned-By: MIMEDefang 2.14
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.cs.auc.dk id h3EGnFne010221
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EGsr804621
Subject: [manet] OLSR progression
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3EGvc804771
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EHD3806601
Content-Transfer-Encoding: 8bit

Guys,

We're in the final stages of reviewing the OLSR spec, which should be
submitted to the IETF shortly. The main changes since the last
version of the spec (v8) are those which were adverticed at the last
IETF WG meeting, namely:

	- merge the "multiple interface" and "single interface" 
	  link sensing sections,

	- further clarify the seperation between link sensing, neighbor
	  sensing and MPR selector signalling in the specification,

	- reinserted the routing table update through 2-hop information (was
	  in v7, but accidentially removed in v8).

Many thanks to those of you who've read and commented on the draft -
either during the IETF or in private mails since.

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: T.Clausen@computer.org
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 14 13:51:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13969
	for ; Mon, 14 Apr 2003 13:51:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EHx4009412
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 13:59:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHx4809409
	for ; Mon, 14 Apr 2003 13:59:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13914
	for ; Mon, 14 Apr 2003 13:50:48 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19588v-0003oO-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:53:21 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19588v-0003oK-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 13:53:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHbw808442;
	Mon, 14 Apr 2003 13:37:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHYv807518
	for ; Mon, 14 Apr 2003 13:34:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12944
	for ; Mon, 14 Apr 2003 13:26:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1957lb-0003gC-00
	for manet@ietf.org; Mon, 14 Apr 2003 13:29:15 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 1957la-0003fv-00
	for manet@ietf.org; Mon, 14 Apr 2003 13:29:14 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3EHSkgG010320;
	Mon, 14 Apr 2003 10:28:48 -0700 (PDT)
Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with SMTP id AGC05688;
	Mon, 14 Apr 2003 10:26:49 -0700 (PDT)
Message-Id: <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 14 Apr 2003 10:17:40 -0700
To: "Charles E. Perkins" 
From: Fred Baker 
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Cc: manet@ietf.org
In-Reply-To: <3E9AE4DD.D91C6DE8@iprg.nokia.com>
References: <200304121625.JAA19643@pit.erg.sri.com>
 <20030409213822.23b9b121.T.Clausen@computer.org>
 <200304121625.JAA19643@pit.erg.sri.com>
 <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 09:42 AM 4/14/2003 -0700, Charles E. Perkins wrote:
> > However, none of the manet proposals has addressed its own use in a
> > non-manet network, which means that if someone has a manet that interacts
> > with a static network, they at lest nominally have to exchange prefixes
> > between two routing protocols.
>
>This is true, and is largely a result of the desire to avoid disseminating 
>host routes into larger routing domains.

The issue I am raising is in the following vein. In a manet network, for 
example, a truck (which has an internal wired LAN with some number of 
computers and a router connecting it to the manet) might drive into a yard 
and jack into the local network, becoming both a mobile and a fixed node. I 
think this is what you call a "hybrid" network; I find the concept a little 
tortured, as to me *every* network contains a mixture of local network 
types varying from serial lines to LANs to wireless LANs - every network is 
a hybrid. Calling this special case a "hybrid" and requiring it to use 
special protocols seems a bit daft, to be honest. But I digress.

Now, by military rules, the truck is supposed to have an address assigned 
by its unit, so what it probably does is generate a local address in the 
fixed network using DHCP and then advertise reachability to its mobile 
prefix. Hence, the mobile prefix is now floating in both IGPs. If the 
*intended* router between the IGPs now leaks the prefix back in either 
direction, problems can develop.

What said router wants to do is advertise a general prefix for the manet 
network into the base network that can be over-ridden using a longest-match 
rule, and only leak the route back if it is not being advertised within the 
manet network, or provide some form of hierarchy such as OSPF's prefix LSA 
and AS-external Summary LSA do. OSPF in the wired network addresses the 
issue; I don't see anything in the manet protocols to address it, leaving 
the issue to configuration and cleverness in the interface router.

Of course, if we could just say that the wired world and the wireless world 
were different areas in the same IGP's network (using IS-IS or OSPF 
language, but I'm not limiting my thinking to those protocols), the problem 
would sort itself out instantly.

Hence, I find myself wanting to use a single protocol in both the wireless 
and wired worlds. I want to treat the manet zone as part of the whole 
network, not a separate network that somehow gets tangled and untangled 
with the other one.

>On the other hand, it is my belief that advances in protocol design that 
>result from work on ad hoc networks _should_ be considered for use with 
>other protocols (e.g., OSPF).  Is it
>feasible to put this on the charter for manet-ng?

To be discussed. I certainly don't have a problem with learning from the 
manet experience.

>I get that the military is able to live within the realm of applicability 
>defined by the security properties of the protocols they are trying to use.

Maybe, and Joe would know better. I would suspect that they are working 
around the issues in the protocols as opposed to accepting the issues.

>I'm sorry if you have found all the foregoing work to be tiresome.

I have not, and that's not what I said. What I said is that the periodic 
messages that say "pick me, because my protocol is better on some specific 
test" are tiresome.

And as to finishing the job, in the end someone has to actually run 
networks that use the protocols. Writing the spec is the fun and 
interesting part, but (as someone once said) the job isn't don't until the 
paperwork, the drudge part, is done. My point is that making the protocol 
work operationally is important too, and we need to get on with that.  

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



From mailnull@www1.ietf.org  Mon Apr 14 15:13:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18216
	for ; Mon, 14 Apr 2003 15:13:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EJLJl15838
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 15:21:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EJLJ815835
	for ; Mon, 14 Apr 2003 15:21:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18151
	for ; Mon, 14 Apr 2003 15:13:03 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1959QV-0004aw-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 15:15:35 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1959QU-0004at-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 15:15:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EJ5K814152;
	Mon, 14 Apr 2003 15:05:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EIr6813732
	for ; Mon, 14 Apr 2003 14:53:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15896
	for ; Mon, 14 Apr 2003 14:44:51 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1958zC-0004E8-00
	for manet@ietf.org; Mon, 14 Apr 2003 14:47:22 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1958zC-0004Dy-00
	for manet@ietf.org; Mon, 14 Apr 2003 14:47:22 -0400
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 LAA06558;
	Mon, 14 Apr 2003 11:46:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3EIktq18543;
	Mon, 14 Apr 2003 11:46:55 -0700
X-mProtect: <200304141846> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdPFVo4e; Mon, 14 Apr 2003 11:46:54 PDT
Message-ID: <3E9B021E.3AE01DA9@iprg.nokia.com>
Date: Mon, 14 Apr 2003 11:46: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: Fred Baker 
CC: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
References: <200304121625.JAA19643@pit.erg.sri.com>
	 <20030409213822.23b9b121.T.Clausen@computer.org>
	 <200304121625.JAA19643@pit.erg.sri.com>
	 <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello Fred,

Thanks for your note.  It puts your previous message in
a different light for me.

Fred Baker wrote:

           ........ example of truck associating with a fixed network
                    with fixed addressing rules ...

> Now, by military rules, the truck is supposed to have an address assigned
> by its unit, so what it probably does is generate a local address in the
> fixed network using DHCP and then advertise reachability to its mobile
> prefix. Hence, the mobile prefix is now floating in both IGPs. If the
> *intended* router between the IGPs now leaks the prefix back in either
> direction, problems can develop.

Here's what I would suggest:

- Run manet on the truck
- Advertise fixed prefix to manet nodes
- Run manet router as an Internet gateway
- Allow truck manet nodes to run Mobile IP
  using the advertised prefix for allocating
  a care-of address
- Allow the manet nodes and the nodes in the
  fixed network to run route optimization.

If the manet nodes have an IP address which
is "never" topologically correct, then indeed
the manet router has to disseminate topology
information into the fixed network.  Otherwise,
the home agent for the topologically correct
network for a manet node's IP address has to
know about the care-of address.   Of course,
running route optimization amounts to disseminating
host routes to correspondent nodes in the fixed
network.

Some of these things seem to be definitional
consequences of having a fixed IP address to
be accessible from "the Internet".  I don't
see how the mobile network can avoid
the need to describe the topology to the
fixed network unless that topology is already
described implicitly by Internet hierarchical
routing.

> >I'm sorry if you have found all the foregoing work to be tiresome.
> 
> I have not, and that's not what I said. What I said is that the periodic
> messages that say "pick me, because my protocol is better on some specific
> test" are tiresome.
> 
> And as to finishing the job, in the end someone has to actually run
> networks that use the protocols. Writing the spec is the fun and
> interesting part, but (as someone once said) the job isn't don't until the
> paperwork, the drudge part, is done. My point is that making the protocol
> work operationally is important too, and we need to get on with that.

Check, double-check, and triple-check, except that
writing the spec isn't so much fun after about the first
dozen Internet Drafts of it.

Regards,
Charlie P.
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 14 15:30:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19225
	for ; Mon, 14 Apr 2003 15:30:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EJcA417641
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 15:38:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EJc9817638
	for ; Mon, 14 Apr 2003 15:38:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19210
	for ; Mon, 14 Apr 2003 15:29:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1959gn-0004io-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 15:32:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1959gm-0004il-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 15:32:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EJMV815896;
	Mon, 14 Apr 2003 15:22:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EJFL815451
	for ; Mon, 14 Apr 2003 15:15:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17372
	for ; Mon, 14 Apr 2003 15:07:06 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1959Kj-0004U7-00
	for manet@ietf.org; Mon, 14 Apr 2003 15:09:37 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1959Eo-0004M7-00
	for manet@ietf.org; Mon, 14 Apr 2003 15:03:30 -0400
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 MAA07166;
	Mon, 14 Apr 2003 12:03:05 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3EJ34f15358;
	Mon, 14 Apr 2003 12:03:04 -0700
X-mProtect: <200304141903> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdbZUsPa; Mon, 14 Apr 2003 12:03:01 PDT
Message-ID: <3E9B065E.1080702@iprg.nokia.com>
Date: Mon, 14 Apr 2003 12:05:02 -0700
From: "Fred L. Templin" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker 
CC: "Charles E. Perkins" , manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
References: <200304121625.JAA19643@pit.erg.sri.com> <20030409213822.23b9b121.T.Clausen@computer.org> <200304121625.JAA19643@pit.erg.sri.com> <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Fred,

Fred Baker wrote:
> Hence, I find myself wanting to use a single protocol in both the 
> wireless and wired worlds. I want to treat the manet zone as part of the 
> whole network, not a separate network that somehow gets tangled and 
> untangled with the other one.

It seems then that you would favor a solution that provides the greatest
efficiency/scalability/etc in both worlds?

>> I'm sorry if you have found all the foregoing work to be tiresome.
> 
> I have not, and that's not what I said. What I said is that the periodic 
> messages that say "pick me, because my protocol is better on some 
> specific test" are tiresome.

Where are you seeing such messages? The messages I have seen recently
seem to be in a spirit of mutual collaboration toward a common goal,
and in keeping with the new wg charter. Have I missed something?

Thanks,

Fred
ftemplin@iprg.nokia.com

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



From mailnull@www1.ietf.org  Mon Apr 14 16:52:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21398
	for ; Mon, 14 Apr 2003 16:52:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EL02W22551
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 17:00:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EL02822540
	for ; Mon, 14 Apr 2003 17:00:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21292
	for ; Mon, 14 Apr 2003 16:51:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Axz-00056M-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 16:54:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Axy-00056J-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 16:54:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EKfH821718;
	Mon, 14 Apr 2003 16:41:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EKZF820644
	for ; Mon, 14 Apr 2003 16:35:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20631
	for ; Mon, 14 Apr 2003 16:26:57 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Aa1-0004zU-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:29:29 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Aa0-0004zL-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:29:28 -0400
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 NAA28568;
	Mon, 14 Apr 2003 13:28:48 -0700 (PDT)
Message-Id: <200304142028.NAA28568@pit.erg.sri.com>
To: Fred Baker 
cc: "Charles E. Perkins" , manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Mon, 14 Apr 2003 10:17:40 PDT."
             <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com> 
Date: Mon, 14 Apr 2003 13:28:48 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


Fred Baker wrote:

> >I'm sorry if you have found all the foregoing work to be tiresome.
> 
> I have not, and that's not what I said. What I said is that the periodic 
> messages that say "pick me, because my protocol is better on some specific 
> test" are tiresome.

I haven't see much of that lately.  The purpose of the recent messages
between me and Thomas Clausen was to try to decide which candidate
techniques/features should be included in the final proactive routing 
protocol. (It may be early for that, but that is not the point.) 
These techniques can come from OLSR, TBRPF, OSPF, and other 
protocols. For example, I pointed out that the use of RIDs in OSPF
HELLO packets prevents it from supporting directional antennas,
which I think is an imortant point. (Maybe this is the "specific test"
you are talking about? If so, maybe you could comment on it.)  
For the most part, we are talking about modularity and efficiency in 
typical mobile ad hoc networks, and not about "specific tests".  
I think that OLSR does some things better than TBRPF, and TBRPF does 
some things better than OLSR.  In the latter case, it might look like 
I am saying "pick TBRPF", but I would not be objective or honest if 
I always said "pick OLSR or OSPF".  

Fred Templin wrote:

> Where are you seeing such messages? The messages I have seen recently
> seem to be in a spirit of mutual collaboration toward a common goal,
> and in keeping with the new wg charter. Have I missed something?

Thanks, Fred.  You have not missed anything.  But I can see how someone
can get the wrong impression if they read the messages too quickly.

Regards,
Richard

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



From mailnull@www1.ietf.org  Mon Apr 14 17:03:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21875
	for ; Mon, 14 Apr 2003 17:03:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ELBXP24525
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 17:11:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELBX824522
	for ; Mon, 14 Apr 2003 17:11:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21871
	for ; Mon, 14 Apr 2003 17:03:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195B99-0005FH-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:05:47 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195B98-0005FE-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:05:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EKq5822153;
	Mon, 14 Apr 2003 16:52:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EKll822022
	for ; Mon, 14 Apr 2003 16:47:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21008
	for ; Mon, 14 Apr 2003 16:39:29 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Am8-00052g-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:42:01 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Am8-00052X-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:42:00 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3EKfYmi026641;
	Mon, 14 Apr 2003 13:41:34 -0700 (PDT)
Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with SMTP id AGC27567;
	Mon, 14 Apr 2003 13:39:36 -0700 (PDT)
Message-Id: <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 14 Apr 2003 13:40:06 -0700
To: "Charles E. Perkins" 
From: Fred Baker 
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Cc: manet@ietf.org
In-Reply-To: <3E9B021E.3AE01DA9@iprg.nokia.com>
References: <200304121625.JAA19643@pit.erg.sri.com>
 <20030409213822.23b9b121.T.Clausen@computer.org>
 <200304121625.JAA19643@pit.erg.sri.com>
 <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
 <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 11:46 AM 4/14/2003 -0700, Charles E. Perkins wrote:
>- Allow truck manet nodes to run Mobile IP
>   using the advertised prefix for allocating
>   a care-of address

yes, one could use mobile IP in this special case. I'm looking at this as a 
general *routing* problem, not a special case scenario that can be worked 
around with special case addressing. My point stands that if the problem is 
handled generally, one need not do anything special - redistributing routes 
between protocols or using Mobile IP or anything else - in this special 
case. I'm looking for a deployable and operative solution that treats the 
entire network as a network, not as separate networks with some partially 
defined relationship to each other. 

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



From mailnull@www1.ietf.org  Mon Apr 14 17:19:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22492
	for ; Mon, 14 Apr 2003 17:19:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ELQuE25452
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 17:26:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELQu825449
	for ; Mon, 14 Apr 2003 17:26:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22480
	for ; Mon, 14 Apr 2003 17:18:37 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195BO1-0005Oi-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:21:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195BO0-0005Of-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:21:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EL7G823846;
	Mon, 14 Apr 2003 17:07:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EL2a822994
	for ; Mon, 14 Apr 2003 17:02:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21506
	for ; Mon, 14 Apr 2003 16:54:17 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195B0T-0005AT-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:56:49 -0400
Received: from s2.itd.nrl.navy.mil ([132.250.83.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 195B0T-0005AC-00
	for manet@ietf.org; Mon, 14 Apr 2003 16:56:49 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.9+Sun/8.12.8) with ESMTP id h3EKtdMZ028101;
	Mon, 14 Apr 2003 16:55:39 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.9+Sun/8.12.2) with SMTP id h3EKtYFI018267;
	Mon, 14 Apr 2003 16:55:34 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003041416553302850
 ; Mon, 14 Apr 2003 16:55:33 -0400
Message-Id: <5.1.1.5.2.20030414141335.025a4368@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 14 Apr 2003 16:55:08 -0400
To: Fred Baker ,
        "Charles E. Perkins" 
From: Joe Macker 
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Cc: manet@ietf.org
In-Reply-To: <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
References: <3E9AE4DD.D91C6DE8@iprg.nokia.com>
 <200304121625.JAA19643@pit.erg.sri.com>
 <20030409213822.23b9b121.T.Clausen@computer.org>
 <200304121625.JAA19643@pit.erg.sri.com>
 <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 10:17 AM 4/14/2003 -0700, Fred Baker wrote:
>At 09:42 AM 4/14/2003 -0700, Charles E. Perkins wrote:
>>> However, none of the manet proposals has addressed its own use in a
>>> non-manet network, which means that if someone has a manet that interacts
>>> with a static network, they at lest nominally have to exchange prefixes
>>> between two routing protocols.
>>
>>This is true, and is largely a result of the desire to avoid disseminating host routes into larger routing domains.

Just chiming in with a few comments..

Honestly, we had discussed some of this in the past meetings and earlier on in the WG we focused on stub network application goal for manet, which simplifies a number of interconnection management issues. For initial application, I (and perhaps others) used managed prefixes for these areas. There are large variety of applications here but they are largely limited edge network applications with some topological relevance. I don't know about others, but I have deployed some experimental protocols in useful scenarios and they work. Lots more work to do and discussions to have of course.

I, for one, at least supported and would continue to support IETF discussions of  OSPF+ manet extensions (especially based off of OSPFv3) because I felt there were some less dynamic network backbone application areas that could benefit from the synergy of ideas (wireless interface handling, efficiency, convergence improvements)... and some of us (I am including a larger community than just manet WG) have done work in both experimenting with and deploying wireless OSPF variants already.  The main starting idea is some additional "nuts and bolts" MAY go a long way to having a more appropriate protocol for dynamic, wireless applications, especially in a more managed, backbone network scenarios.  I still don't think it would be right for all applications and is not a catch-all replacement for other manet related work.

I, for one, never saw this as a "one size fits all" situation, but see the benefits in both areas of work.


>The issue I am raising is in the following vein. In a manet network, for example, a truck (which has an internal wired LAN with some number of computers and a router connecting it to the manet) might drive into a yard and jack into the local network, becoming both a mobile and a fixed node. I think this is what you call a "hybrid" network; I find the concept a little tortured, as to me *every* network contains a mixture of local network types varying from serial lines to LANs to wireless LANs - every network is a hybrid. Calling this special case a "hybrid" and requiring it to use special protocols seems a bit daft, to be honest. But I digress.

I must have missed that hybrid thread.. Normal internetworking is multiple, heterogeneous interfacing.


Hybrid, as a term, has been used in many different ways in the manet community and within related literature,etc. Sometimes it means a mix of reactive/proactive.  Sometimes..something else.. 

I have also been using it to describe "hybrid manet routing grids" where a portion of the manet routers are more static, pseudo-managed nodes (not much motion but the normal wireless dynamics occurring...these nodes are perhaps pre-placed strategically in a factory, etc)...and another set of nodes are transient through this "access grid" extending the routing infrastructure IF NEEDED.  In this scenario, typically only a few hops are needed before Internet backbone access is achieved.  The assumption here is Internet connection is the high preference requirement and nodes prefer routing through the "access grid nodes".

Ergot, the richness and abuse of the term hybrid.



>Hence, I find myself wanting to use a single protocol in both the wireless and wired worlds. I want to treat the manet zone as part of the whole network, not a separate network that somehow gets tangled and untangled with the other one.

The single protocol is IP ;-)  

I think multiple interface support is important..We may also wish to manage different routing solutions in different spaces when warranted. Most "interconnected" manet routing deployments should be topologically relevant at some level.


>>On the other hand, it is my belief that advances in protocol design that result from work on ad hoc networks _should_ be considered for use with other protocols (e.g., OSPF).  Is it
>>feasible to put this on the charter for manet-ng?
>
>To be discussed. I certainly don't have a problem with learning from the manet experience.

I think we pointed out a few potential "lessons learned"...interface behavior, neighbor discovery, link state scaling mechanism.. that might be borrowed or shared already.... Fred you helped with pointing those out  as well as anyone else.  There is a good opportunity for being synergistic here with engineering ideas.


>>I'm sorry if you have found all the foregoing work to be tiresome.
>
>I have not, and that's not what I said. What I said is that the periodic messages that say "pick me, because my protocol is better on some specific test" are tiresome.

Despite being weary myself ... I am encouraged by recent strong commitments to a more cooperative engineering approach. Suggest we move forward with that mantra.


>And as to finishing the job, in the end someone has to actually run networks that use the protocols. Writing the spec is the fun and interesting part, but (as someone once said) the job isn't don't until the paperwork, the drudge part, is done. My point is that making the protocol work operationally is important too, and we need to get on with that.  

Agreed..
Let's not forget there are different operational problem spaces...

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



From mailnull@www1.ietf.org  Mon Apr 14 17:35:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22904
	for ; Mon, 14 Apr 2003 17:35:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ELh6l26991
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 17:43:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELh6826988
	for ; Mon, 14 Apr 2003 17:43:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22898
	for ; Mon, 14 Apr 2003 17:34:46 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Bdf-0005Uo-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:37:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Bde-0005Ul-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 17:37:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELIO824746;
	Mon, 14 Apr 2003 17:18:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELFs824656
	for ; Mon, 14 Apr 2003 17:15:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21942
	for ; Mon, 14 Apr 2003 17:07:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195BDL-0005GY-00
	for manet@ietf.org; Mon, 14 Apr 2003 17:10:08 -0400
Received: from lennier.cc.vt.edu ([198.82.162.213])
	by ietf-mx with esmtp (Exim 4.12)
	id 195BDL-0005GV-00
	for manet@ietf.org; Mon, 14 Apr 2003 17:10:07 -0400
Received: from steiner.cc.vt.edu (IDENT:mirapoint@steiner-lb.cc.vt.edu [10.1.1.14])
	by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id h3ELAB6A378798;
	Mon, 14 Apr 2003 17:10:12 -0400 (EDT)
Received: from LAPTOPPC (h80ad37c6.dhcp.vt.edu [128.173.55.198])
	by steiner.cc.vt.edu (Mirapoint Messaging Server MOS 3.3.2-CR)
	with ESMTP id BGB71439;
	Mon, 14 Apr 2003 17:10:10 -0400 (EDT)
Message-ID: <002d01c302ca$35e31630$c637ad80@LAPTOPPC>
From: "Tao Lin" 
To: "Fred Baker" ,
        "Charles E. Perkins" 
Cc: 
References: <200304121625.JAA19643@pit.erg.sri.com> <20030409213822.23b9b121.T.Clausen@computer.org> <200304121625.JAA19643@pit.erg.sri.com> <5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Date: Mon, 14 Apr 2003 17:09:59 -0400
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, Fred,

Basically, I think the "general routing problem" mentioned in your emails
can be considered as an inter-operation issue between MANET and normal
network routing protocols.

As an alternative approach, we can incorporate a common solution to current
MANET protocols such as OLSR and TBRPF by introducing a gateway approach
(Gateway machines are nodes that connect directly to nodes in both MANET and
normal networks).  Gateway machines can broadcast information of associated
normal networks into MANETs when they discover a normal network.  These
gateway machines can also declare network-lost when their connections to
normal networks are lost.

It *might* be slightly different for reactive protocols.  In reactive
protocols, the gateway nodes may proactively broadcast new discovered
networks into MANETs, otherwise, MANET nodes may not be awared when a new
normal network is connected or lost.

Just my personal opinion.

Thanks

 Tao Lin
 Ph.D. Candidate
 ECE Dept.
 Virginia Tech.
 USA


----- Original Message -----
From: "Fred Baker" 
To: "Charles E. Perkins" 
Cc: 
Sent: Monday, April 14, 2003 4:40 PM
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages


> At 11:46 AM 4/14/2003 -0700, Charles E. Perkins wrote:
> >- Allow truck manet nodes to run Mobile IP
> >   using the advertised prefix for allocating
> >   a care-of address
>
> yes, one could use mobile IP in this special case. I'm looking at this as
a
> general *routing* problem, not a special case scenario that can be worked
> around with special case addressing. My point stands that if the problem
is
> handled generally, one need not do anything special - redistributing
routes
> between protocols or using Mobile IP or anything else - in this special
> case. I'm looking for a deployable and operative solution that treats the
> entire network as a network, not as separate networks with some partially
> defined relationship to each other.
>
> _______________________________________________
> 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 mailnull@www1.ietf.org  Mon Apr 14 18:11:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24454
	for ; Mon, 14 Apr 2003 18:11:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3EMJbY29149
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 18:19:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EMJb829146
	for ; Mon, 14 Apr 2003 18:19:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24407
	for ; Mon, 14 Apr 2003 18:11:16 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195CCy-0005fb-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 18:13:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195CCx-0005fY-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 18:13:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EM3f827747;
	Mon, 14 Apr 2003 18:03:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELwf827606
	for ; Mon, 14 Apr 2003 17:58:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23328
	for ; Mon, 14 Apr 2003 17:50:21 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Bsj-0005aN-00
	for manet@ietf.org; Mon, 14 Apr 2003 17:52:53 -0400
Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Bsj-0005aK-00
	for manet@ietf.org; Mon, 14 Apr 2003 17:52:53 -0400
Received: from armada (voop@pico.cs.auc.dk [130.225.194.80])
	by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h3ELqqne025618;
	Mon, 14 Apr 2003 23:52:53 +0200 (MEST)
Date: Mon, 14 Apr 2003 23:52:49 +0200
From: Thomas Heide Clausen 
To: "Tao Lin" 
Cc: fred@cisco.com, charliep@iprg.nokia.com, manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Message-Id: <20030414235249.271d516e.T.Clausen@computer.org>
In-Reply-To: <002d01c302ca$35e31630$c637ad80@LAPTOPPC>
References: <200304121625.JAA19643@pit.erg.sri.com>
	<20030409213822.23b9b121.T.Clausen@computer.org>
	<200304121625.JAA19643@pit.erg.sri.com>
	<5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
	<5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
	<5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
	<002d01c302ca$35e31630$c637ad80@LAPTOPPC>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.14
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Tao,

On Mon, 14 Apr 2003 17:09:59 -0400
"Tao Lin"  wrote:

> Hi, Fred,
> 
> Basically, I think the "general routing problem" mentioned in your
> emails can be considered as an inter-operation issue between MANET
> and normal network routing protocols.
> 
> As an alternative approach, we can incorporate a common solution to
> current MANET protocols such as OLSR and TBRPF by introducing a
> gateway approach(Gateway machines are nodes that connect directly
> to nodes in both MANET and normal networks).  Gateway machines can
> broadcast information of associated normal networks into MANETs
> when they discover a normal network.  These gateway machines can
> also declare network-lost when their connections to normal networks
> are lost.

Such solutions for this exists OLSR (and, I think, in TBRPF aswell -
Richard, supplement here?) already. Working roughly as you sketch
above, even :) 

> 
> It *might* be slightly different for reactive protocols.  In
> reactive protocols, the gateway nodes may proactively broadcast new
> discovered networks into MANETs, otherwise, MANET nodes may not be
> awared when a new normal network is connected or lost.

I believe that Ryuji Waikikawa et. al. published an internet draft on
global connectivity, outlining how this can be done for reactive
protocols. The spec is IPv6-centric, but this should not make much
difference:

http://www.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-02.txt

These solutions, indeed, deal with a MANET as stub network with a
managed/dedicated prefix which, as Fred point out in another posting,
is a specific solution to a specific case which may or may not apply
in all situations. However this is different situation from having
the MANET be "just another area" in the larger routing
infrastructure.

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



From mailnull@www1.ietf.org  Mon Apr 14 19:19:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26524
	for ; Mon, 14 Apr 2003 19:19:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ENRFb00674
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 19:27:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENRF800671
	for ; Mon, 14 Apr 2003 19:27:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26515
	for ; Mon, 14 Apr 2003 19:18:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195DGP-00065X-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 19:21:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195DGP-00065U-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 19:21:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENEU832663;
	Mon, 14 Apr 2003 19:14:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EN2J831544
	for ; Mon, 14 Apr 2003 19:02:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26087
	for ; Mon, 14 Apr 2003 18:53:58 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195CsJ-0005yg-00
	for manet@ietf.org; Mon, 14 Apr 2003 18:56:31 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 195CsI-0005yW-00
	for manet@ietf.org; Mon, 14 Apr 2003 18:56:30 -0400
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 PAA29181;
	Mon, 14 Apr 2003 15:55:52 -0700 (PDT)
Message-Id: <200304142255.PAA29181@pit.erg.sri.com>
To: Fred Baker 
cc: "Charles E. Perkins" , manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Mon, 14 Apr 2003 13:40:06 PDT."
             <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com> 
Date: Mon, 14 Apr 2003 15:55:52 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

> At 11:46 AM 4/14/2003 -0700, Charles E. Perkins wrote:
> >- Allow truck manet nodes to run Mobile IP
> >   using the advertised prefix for allocating
> >   a care-of address
> 
> yes, one could use mobile IP in this special case. I'm looking at this as a 
> general *routing* problem, not a special case scenario that can be worked 
> around with special case addressing. My point stands that if the problem is 
> handled generally, one need not do anything special - redistributing routes 
> between protocols or using Mobile IP or anything else - in this special 
> case. I'm looking for a deployable and operative solution that treats the 
> entire network as a network, not as separate networks with some partially 
> defined relationship to each other. 

Some of the MANET routing protocols allow a node to have multiple interfaces,
some of which can be wired (e.g., Ethernet).  The TBRPF draft specifically
mentions Ethernet as a possibility.  Thus, a *single* network can include 
MANET links, wired broadcast links (Ethernet), and point-to-point links.

Multiple routers attached to the same Ethernet all advertise their links
to the other attached routers, i.e., we do not elect a designated router
as in OSPF, so there is room for improvement.  But such "hybrid" networks
are supported (or can be supported with slight modifications) by some
of the MANET routing protocols.

OLSR and TBRPF also advertise network prefixes (whether internal or external) 
and associated hosts. 

Tao, Your latest message deals with gateways between *separate* networks.
I think Fred is talking about a single network that does not need gateways
to connect its MANET units.

Regards,
Richard


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



From mailnull@www1.ietf.org  Mon Apr 14 19:51:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27237
	for ; Mon, 14 Apr 2003 19:51:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ENww702835
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 19:58:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENww802832
	for ; Mon, 14 Apr 2003 19:58:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27227
	for ; Mon, 14 Apr 2003 19:50:35 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Dl6-0006Ha-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 19:53:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Dl5-0006HX-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 19:53:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENkr802142;
	Mon, 14 Apr 2003 19:46:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENbx801869
	for ; Mon, 14 Apr 2003 19:37:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26709
	for ; Mon, 14 Apr 2003 19:29:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195DQn-00068Q-00
	for manet@ietf.org; Mon, 14 Apr 2003 19:32:09 -0400
Received: from mailhost.iprg.nokia.com ([205.226.5.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 195DQm-00068C-00
	for manet@ietf.org; Mon, 14 Apr 2003 19:32:08 -0400
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 QAA18722;
	Mon, 14 Apr 2003 16:31:43 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3ENVgc03574;
	Mon, 14 Apr 2003 16:31:42 -0700
X-mProtect: <200304142331> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdS6JHtQ; Mon, 14 Apr 2003 16:31:40 PDT
Message-ID: <3E9B4555.7070003@iprg.nokia.com>
Date: Mon, 14 Apr 2003 16:33:41 -0700
From: "Fred L. Templin" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ogier@erg.sri.com
CC: Fred Baker ,
        "Charles E. Perkins"
 , manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
References: <200304142255.PAA29181@pit.erg.sri.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

FYI, there is an interesting document entitled:

   "Multi-link Subnet Support in IPv6"
   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-multilink-subnets-00.txt

that speaks to nodes with multiple links connecting to a single network.

Fred
ftemplin@iprg.nokia.com

P.S. The above document is a somewhat controversial wg item of the
      IPv6 wg; this message should be seen as informational-only and
      not an endorsement.

ogier@erg.sri.com wrote:
>>At 11:46 AM 4/14/2003 -0700, Charles E. Perkins wrote:
>>
>>>- Allow truck manet nodes to run Mobile IP
>>>  using the advertised prefix for allocating
>>>  a care-of address
>>
>>yes, one could use mobile IP in this special case. I'm looking at this as a 
>>general *routing* problem, not a special case scenario that can be worked 
>>around with special case addressing. My point stands that if the problem is 
>>handled generally, one need not do anything special - redistributing routes 
>>between protocols or using Mobile IP or anything else - in this special 
>>case. I'm looking for a deployable and operative solution that treats the 
>>entire network as a network, not as separate networks with some partially 
>>defined relationship to each other. 
> 
> 
> Some of the MANET routing protocols allow a node to have multiple interfaces,
> some of which can be wired (e.g., Ethernet).  The TBRPF draft specifically
> mentions Ethernet as a possibility.  Thus, a *single* network can include 
> MANET links, wired broadcast links (Ethernet), and point-to-point links.
> 
> Multiple routers attached to the same Ethernet all advertise their links
> to the other attached routers, i.e., we do not elect a designated router
> as in OSPF, so there is room for improvement.  But such "hybrid" networks
> are supported (or can be supported with slight modifications) by some
> of the MANET routing protocols.
> 
> OLSR and TBRPF also advertise network prefixes (whether internal or external) 
> and associated hosts. 
> 
> Tao, Your latest message deals with gateways between *separate* networks.
> I think Fred is talking about a single network that does not need gateways
> to connect its MANET units.
> 
> Regards,
> Richard
> 
> 
> _______________________________________________
> 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 mailnull@www1.ietf.org  Mon Apr 14 21:37:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29714
	for ; Mon, 14 Apr 2003 21:37:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F1jBq09634
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 21:45:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1jB809631
	for ; Mon, 14 Apr 2003 21:45:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29705
	for ; Mon, 14 Apr 2003 21:36:48 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195FPr-0006jr-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 21:39:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195FPq-0006jo-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 21:39:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1WR808364;
	Mon, 14 Apr 2003 21:32:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1NP808173
	for ; Mon, 14 Apr 2003 21:23:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29494
	for ; Mon, 14 Apr 2003 21:15:02 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195F4n-0006gi-00
	for manet@ietf.org; Mon, 14 Apr 2003 21:17:33 -0400
Received: from [209.182.100.115] (helo=mail.rivierapartners.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 195F4n-0006gf-00
	for manet@ietf.org; Mon, 14 Apr 2003 21:17:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 14 Apr 2003 18:17:29 -0700
Message-ID: 
Thread-Topic: [manet] IP-802.11 interface
Thread-Index: AcLydZJb7Uo6SxlMTmCzdzDe+Vt/JwAA9vfg
From: "Michael Morell" 
To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3F1NP808174
Subject: [manet] Seeking VP, Product Management
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Looking for help on where I might find someone qualified.
My client is developing a solution for ad hoc mobile networking.
I understand this probably isn't a appropriate post, but I need some help on where to look
Thanks,
Mike
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 14 23:48:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02336
	for ; Mon, 14 Apr 2003 23:48:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F3u5617622
	for manet-archive@odin.ietf.org; Mon, 14 Apr 2003 23:56:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3u5817619
	for ; Mon, 14 Apr 2003 23:56:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02315
	for ; Mon, 14 Apr 2003 23:47:38 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195HST-0007Kf-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 23:50:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195HST-0007Kc-00
	for manet-web-archive@ietf.org; Mon, 14 Apr 2003 23:50:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3eO817151;
	Mon, 14 Apr 2003 23:40:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3UE816101
	for ; Mon, 14 Apr 2003 23:30:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01709
	for ; Mon, 14 Apr 2003 23:21:48 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195H3U-0007Bl-00
	for manet@ietf.org; Mon, 14 Apr 2003 23:24:20 -0400
Received: from plant.sfc.wide.ad.jp ([203.178.143.91])
	by ietf-mx with esmtp (Exim 4.12)
	id 195H3P-0007Bi-00
	for manet@ietf.org; Mon, 14 Apr 2003 23:24:15 -0400
Received: from localhost (localhost [127.0.0.1])
	by plant.sfc.wide.ad.jp (Postfix) with ESMTP
	id 16C9D253FF; Tue, 15 Apr 2003 12:24:20 +0900 (JST)
Date: Tue, 15 Apr 2003 12:24:18 +0900 (JST)
Message-Id: <20030415.122418.76689753.yasu@sfc.wide.ad.jp>
To: fred@cisco.com
Cc: charliep@iprg.nokia.com, manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
From: Yasuhiro Ohara 
In-Reply-To: <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
	<5.2.0.9.2.20030413144909.05e4f410@mira-sjc5-b.cisco.com>
	<3E9AE4DD.D91C6DE8@iprg.nokia.com>
	<5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
References: <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com>
	<3E9B021E.3AE01DA9@iprg.nokia.com>
	<5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi, I wanted to have some comments as an OSPF-centric researcher.
# May need to change subject ...

> However, none of the manet proposals has addressed its own use in a 
> non-manet network, which means that if someone has a manet that interacts 
> with a static network, they at lest nominally have to exchange prefixes 
> between two routing protocols. Operationally, I won't call that a 
> non-starter, but it is a huge impediment; every device that might operate 
> in either way must be configured twice, and someone needs to think very 
> carefully about the policies for leaking routes between them. This is 
> non-trivial in the extreme. Finding a way to run one protocol - whatever it 
> is - in both the manet and the non-manet zone of a network reduces a lot of 
> operational issues.

I felt that this is another issue, and should be discussed separately.

I know leaking/redistributing routes is highly policy dependent and so
complicated issue, and can create operational issues/problems.
But even with respect to IGP-EGP redistributing, there's no standard
except for the de facto one. The de facto one was developed with many
tries and errors *after* the protocol had been specified, isn't it ?

MANET wg should concentrate on specifying protocols efficient for
the communication within "Ad-hoc network", at least first.
I feel that the redistributing issue is the main subject of NEMO wg ...

> In particular, as I remember from the BOFs, there was a great
> deal of pessimism that OSPF could possibly do the job, resulting
> from experiments that were presented showing that OSPF consumed
> 120% of the available bandwidth for some particular scenario.
> Of course, it would do better in many other scenarios.

I personally think that OSPF is not appropriate for the MANET use.

OSPF based on the segment concept has the prerequisite:
"If A can talk with B and A can talk with C, B can talk with C"
which is not applicable to MANET. (What was the name of the problem,
"line-of-sight problem" ?) Nor OSPF supports directional links.

> see anything being standard soon.  It seems to me that OSPF
> works better when there is some subnet structure that one can
> use effectively for aggregation.  On the other hand, there

Regarding to aggregation, all OSPF does is (generally) to use subnets
as the destination of the packet, rather than host-routes.
Area boundary may aggregate routes, but it's hard (requires pre-defined
address range for the area). It seems that segment/subnet concept
is hard to apply to the MANET environment, so I guess OSPF have no
advantage about aggregation.

> think this is what you call a "hybrid" network; I find the concept a little 
> tortured, as to me *every* network contains a mixture of local network 
> types varying from serial lines to LANs to wireless LANs - every network is 
> a hybrid. Calling this special case a "hybrid" and requiring it to use 
> special protocols seems a bit daft, to be honest. But I digress.

I definitely agree the sentence "Every network is a hybrid", but it's
regarding to layer-2 technology.

I think it's better to separate MANET area and the rest Internet, as done
in IGP-EGP separation. No one desires that MANET frequency of topology
changes affects the IGP routing domain.

The word "hybrid" should be interpreted as "Hybrid of area separation"
(wrong english ?) rather than "Hybrid of wired/wireless network",
isn't it ?

> Now, by military rules, the truck is supposed to have an address assigned 
> by its unit, so what it probably does is generate a local address in the 
> fixed network using DHCP and then advertise reachability to its mobile 
> prefix. Hence, the mobile prefix is now floating in both IGPs. If the 
> *intended* router between the IGPs now leaks the prefix back in either 
> direction, problems can develop.

Again route leaking is separate issues ...

> What said router wants to do is advertise a general prefix for the manet 
> network into the base network that can be over-ridden using a longest-match 
> rule, and only leak the route back if it is not being advertised within the 
> manet network, or provide some form of hierarchy such as OSPF's prefix LSA 
> and AS-external Summary LSA do. OSPF in the wired network addresses the 
> issue; I don't see anything in the manet protocols to address it, leaving 
> the issue to configuration and cleverness in the interface router.
> 
> Of course, if we could just say that the wired world and the wireless world 
> were different areas in the same IGP's network (using IS-IS or OSPF 
> language, but I'm not limiting my thinking to those protocols), the problem 
> would sort itself out instantly.

I agree.

> Hence, I find myself wanting to use a single protocol in both the wireless 
> and wired worlds. I want to treat the manet zone as part of the whole 
> network, not a separate network that somehow gets tangled and untangled 
> with the other one.

I disagree here. Regardless of wired or not, the MANET area should be
separated from the static network. Current IGP routing protocol (i.e.
OSPF or IS-IS, namely most link-state protocol) is very sensitive about the
topology changes at any single point within the domain.

If you assume using some kind of area separation of current IGP,
that is separated, in essence. Whether to use a new routing protocol
or not in that separate area is another issue, and MANET wg should
not specify (force) that, just like IGP choice is left to administrators.

> yes, one could use mobile IP in this special case. I'm looking at this as a 
> general *routing* problem, not a special case scenario that can be worked 
> around with special case addressing. My point stands that if the problem is 
> handled generally, one need not do anything special - redistributing routes 
> between protocols or using Mobile IP or anything else - in this special 
> case. I'm looking for a deployable and operative solution that treats the 
> entire network as a network, not as separate networks with some partially 
> defined relationship to each other. 

I understand "if problem handled generally one need not do anything
special" and feel the same way: simple is the best, conditions should
be kept minimum.

But separating areas don't break simplicity, or may even gain
the simplicity.


I feel that this will be my fault saying this, not knowing how MANET
is working in real network (and if so I sincerely apologize),
but it seems that showing how MANET is working in real network
is what all Fred wants. If it's obvious that MANET will work in real,
then we will know some sort of management strategy and security issues.

I guess the reason why OSPF is deployed and trusted today, is because
J. Moy showed the example of working OSPF system in some
corporate (some kind of big, important) networks.


If I'm missing the point of this discussion, or if I said something
completely wrong, forgive me as it is whim of youth ;p)

regards,
yasu


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



From mailnull@www1.ietf.org  Tue Apr 15 00:29:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03201
	for ; Tue, 15 Apr 2003 00:29:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F4b1219923
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 00:37:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4b1819915
	for ; Tue, 15 Apr 2003 00:37:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03192
	for ; Tue, 15 Apr 2003 00:28:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195I64-0007Vd-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 00:31:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195I64-0007Va-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 00:31:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4Kf819238;
	Tue, 15 Apr 2003 00:20:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4BM818956
	for ; Tue, 15 Apr 2003 00:11:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02559
	for ; Tue, 15 Apr 2003 00:02:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195HhG-0007Pj-00
	for manet@ietf.org; Tue, 15 Apr 2003 00:05:26 -0400
Received: from plant.sfc.wide.ad.jp ([203.178.143.91])
	by ietf-mx with esmtp (Exim 4.12)
	id 195HhF-0007Pg-00
	for manet@ietf.org; Tue, 15 Apr 2003 00:05:26 -0400
Received: from localhost (localhost [127.0.0.1])
	by plant.sfc.wide.ad.jp (Postfix) with ESMTP
	id 80A46253FF; Tue, 15 Apr 2003 13:05:31 +0900 (JST)
Date: Tue, 15 Apr 2003 13:05:31 +0900 (JST)
Message-Id: <20030415.130531.122311235.yasu@sfc.wide.ad.jp>
To: fred@cisco.com
Cc: charliep@iprg.nokia.com, manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
From: Yasuhiro Ohara 
In-Reply-To: <20030415.122418.76689753.yasu@sfc.wide.ad.jp>
References: <3E9B021E.3AE01DA9@iprg.nokia.com>
	<5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
	<20030415.122418.76689753.yasu@sfc.wide.ad.jp>
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> I know leaking/redistributing routes is highly policy dependent and so
> complicated issue, and can create operational issues/problems.
> But even with respect to IGP-EGP redistributing, there's no standard
> except for the de facto one. The de facto one was developed with many
> tries and errors *after* the protocol had been specified, isn't it ?

I found a lie in my message. "There's no standard except for the
de facto one" was a bit wrong, it is specified by RFC 1403
with respect to the interaction between BGP and OSPF .

My point was route redistribution is another issue and specifying it
can be deferred until after some deployments of MANET ...

regards,
yasu


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



From mailnull@www1.ietf.org  Tue Apr 15 01:16:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04067
	for ; Tue, 15 Apr 2003 01:16:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F5O2T23451
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 01:24:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5O2823448
	for ; Tue, 15 Apr 2003 01:24:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04064
	for ; Tue, 15 Apr 2003 01:15:33 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195IpZ-0007h3-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 01:18:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195IpY-0007h0-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 01:18:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F58S822694;
	Tue, 15 Apr 2003 01:08:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4xq821625
	for ; Tue, 15 Apr 2003 00:59:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03639
	for ; Tue, 15 Apr 2003 00:51:24 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195ISC-0007a9-00
	for manet@ietf.org; Tue, 15 Apr 2003 00:53:56 -0400
Received: from che.onthejob.net ([63.146.38.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 195ISB-0007a4-00
	for manet@ietf.org; Tue, 15 Apr 2003 00:53:55 -0400
Received: from che.onthejob.net (localhost [127.0.0.1])
	by che.onthejob.net (8.12.8/8.12.5) with ESMTP id h3F4rQMs012566
	for ; Mon, 14 Apr 2003 23:53:26 -0500
Received: (from dyoung@localhost)
	by che.onthejob.net (8.12.8/8.12.8/Submit) id h3F4rQYu012564
	for manet@ietf.org; Mon, 14 Apr 2003 23:53:26 -0500
Date: Mon, 14 Apr 2003 23:53:26 -0500
From: David Young 
To: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
Message-ID: <20030415045326.GB9845@che.onthejob.net>
Mail-Followup-To: manet@ietf.org
References: <5.2.0.9.2.20030414100241.05b6e010@mira-sjc5-b.cisco.com> <3E9B021E.3AE01DA9@iprg.nokia.com> <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com> <20030415.122418.76689753.yasu@sfc.wide.ad.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030415.122418.76689753.yasu@sfc.wide.ad.jp>
User-Agent: Mutt/1.4i
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

On Tue, Apr 15, 2003 at 12:24:18PM +0900, Yasuhiro Ohara wrote:
> > In particular, as I remember from the BOFs, there was a great
> > deal of pessimism that OSPF could possibly do the job, resulting
> > from experiments that were presented showing that OSPF consumed
> > 120% of the available bandwidth for some particular scenario.
> > Of course, it would do better in many other scenarios.
> 
> I personally think that OSPF is not appropriate for the MANET use.
> 
> OSPF based on the segment concept has the prerequisite:
> "If A can talk with B and A can talk with C, B can talk with C"
> which is not applicable to MANET. (What was the name of the problem,
> "line-of-sight problem" ?)

  In the point-to-multipoint mode, OSPF does not make that assumption.

> Nor OSPF supports directional links.

  There is a variant of OSPF supporting directional links called Radio
  OSPF or RSPF (???) which amateur radio operators use for their packet
  radio networks.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Tue Apr 15 02:49:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17029
	for ; Tue, 15 Apr 2003 02:49:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F6vMZ08226
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 02:57:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6vL808223
	for ; Tue, 15 Apr 2003 02:57:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17012
	for ; Tue, 15 Apr 2003 02:48:50 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195KHq-0000Vi-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 02:51:22 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195KHq-0000Vf-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 02:51:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6ic807710;
	Tue, 15 Apr 2003 02:44:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6eg807514
	for ; Tue, 15 Apr 2003 02:40:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16626
	for ; Tue, 15 Apr 2003 02:32:10 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195K1j-0000RU-00
	for manet@ietf.org; Tue, 15 Apr 2003 02:34:43 -0400
Received: from plant.sfc.wide.ad.jp ([203.178.143.91])
	by ietf-mx with esmtp (Exim 4.12)
	id 195K1i-0000RR-00
	for manet@ietf.org; Tue, 15 Apr 2003 02:34:42 -0400
Received: from localhost (localhost [127.0.0.1])
	by plant.sfc.wide.ad.jp (Postfix) with ESMTP
	id D9D2F253FF; Tue, 15 Apr 2003 15:34:46 +0900 (JST)
Date: Tue, 15 Apr 2003 15:34:45 +0900 (JST)
Message-Id: <20030415.153445.117425439.yasu@sfc.wide.ad.jp>
To: dyoung@pobox.com
Cc: manet@ietf.org
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages
From: Yasuhiro Ohara 
In-Reply-To: <20030415045326.GB9845@che.onthejob.net>
References: <5.2.0.9.2.20030414133659.03164e20@mira-sjc5-b.cisco.com>
	<20030415.122418.76689753.yasu@sfc.wide.ad.jp>
	<20030415045326.GB9845@che.onthejob.net>
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> > I personally think that OSPF is not appropriate for the MANET use.
> > 
> > OSPF based on the segment concept has the prerequisite:
> > "If A can talk with B and A can talk with C, B can talk with C"
> > which is not applicable to MANET. (What was the name of the problem,
> > "line-of-sight problem" ?)
> 
>   In the point-to-multipoint mode, OSPF does not make that assumption.

Right, and my mistake is that I didn't re-read Fred's slide ...

> > Nor OSPF supports directional links.
> 
>   There is a variant of OSPF supporting directional links called Radio
>   OSPF or RSPF (???) which amateur radio operators use for their packet
>   radio networks.

Interesting, I'll check it. thanks.

regards,
yasu

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



From mailnull@www1.ietf.org  Tue Apr 15 07:14:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22097
	for ; Tue, 15 Apr 2003 07:14:51 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FBMvq26834
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 07:22:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBMv826831
	for ; Tue, 15 Apr 2003 07:22:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22075
	for ; Tue, 15 Apr 2003 07:14:20 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OQm-0001U8-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 07:16:52 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OQm-0001U5-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 07:16:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FB3r825332;
	Tue, 15 Apr 2003 07:03:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAxw825141
	for ; Tue, 15 Apr 2003 06:59:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21371
	for ; Tue, 15 Apr 2003 06:51:22 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195O4Y-0001P5-00
	for manet@ietf.org; Tue, 15 Apr 2003 06:53:54 -0400
Received: from smtp3.poczta.onet.pl ([213.180.130.29])
	by ietf-mx with esmtp (Exim 4.12)
	id 195O4X-0001P2-00
	for manet@ietf.org; Tue, 15 Apr 2003 06:53:53 -0400
Received: from nat.riviera.pw.edu.pl ([194.29.137.67]:29192 "HELO marclon")
	by ps3.test.onet.pl with SMTP id ;
	Tue, 15 Apr 2003 12:52:59 +0200
Message-ID: <009501c3033d$07725e50$0a6f03c0@marclon>
From: "Marcin Laska" 
To: 
Date: 	Tue, 15 Apr 2003 12:51:54 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3765.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [manet] Question about ad-hoc simulators
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello, I'd like to ask group members about simulators of MANET. I know about
ns-2, ansim, BonnMotion. I need to use simulator for my master's thesis -
The topic of this is "Localization in ad hoc networks". I need a tool, a
simple one in which I could implement  location algorithms etc. I don't need
very advanced simulation of radio, rather good simulation of mobility. I
prefer C++ language based programs, but any other would also be very
helpful. If you could give me some links, or send me some sources I would
appreciate it very much.
Thank you, bye bye
Martin Laska

Division of Teletransmission Systems, Warsaw University of Technology.
mailto: marclon@poczta.onet.pl


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



From mailnull@www1.ietf.org  Tue Apr 15 14:01:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05647
	for ; Tue, 15 Apr 2003 14:01:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FI9EQ24486
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 14:09:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FI9E824483
	for ; Tue, 15 Apr 2003 14:09:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05634
	for ; Tue, 15 Apr 2003 14:00:29 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Ulp-0003oD-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 14:03:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Ulo-0003o9-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 14:03:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHu5822961;
	Tue, 15 Apr 2003 13:56:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHlr822627
	for ; Tue, 15 Apr 2003 13:47:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05072
	for ; Tue, 15 Apr 2003 13:39:09 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195URA-0003gW-00
	for manet@ietf.org; Tue, 15 Apr 2003 13:41:40 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 195URA-0003gH-00
	for manet@ietf.org; Tue, 15 Apr 2003 13:41:40 -0400
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 KAA02595;
	Tue, 15 Apr 2003 10:40:58 -0700 (PDT)
Message-Id: <200304151740.KAA02595@pit.erg.sri.com>
To: Yasuhiro Ohara 
cc: fred@cisco.com, charliep@iprg.nokia.com, manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] Neighbor addresses in OLSR HELLO messages 
In-reply-to: Your message of "Tue, 15 Apr 2003 12:24:18 +0900."
             <20030415.122418.76689753.yasu@sfc.wide.ad.jp> 
Date: Tue, 15 Apr 2003 10:40:58 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


I will make some brief points now (since I am busy with other things)
but I want to think more about this issue later.

> > yes, one could use mobile IP in this special case. I'm looking at this as a 
> > general *routing* problem, not a special case scenario that can be worked 
> > around with special case addressing. My point stands that if the problem is 
> > handled generally, one need not do anything special - redistributing routes 
> > between protocols or using Mobile IP or anything else - in this special 
> > case. I'm looking for a deployable and operative solution that treats the 
> > entire network as a network, not as separate networks with some partially 
> > defined relationship to each other. 
> 
> I understand "if problem handled generally one need not do anything
> special" and feel the same way: simple is the best, conditions should
> be kept minimum.
> 
> But separating areas don't break simplicity, or may even gain
> the simplicity.

Separating a "hybrid" network into areas can make things more complex
if those areas have to be dynamically redefined due to mobility.
Also, separating the network into areas can result in suboptimal paths.

The main reason for areas in OSPF is for scalability.
As I said yesterday, some of the MANET routing protocols already
support "hybrid" networks with multiple wireless and wired interfaces.
So I don't think it is *necessary* to separate a hybrid network into 
areas (or domains or autonomous systems), although in some cases it 
may be desirable to do so.
For very large networks, scalability can be achieved using 
area routing or landmark routing.

There are some issues regarding how MANET routing protocols should
support a single hybrid network:
Should each node be aware of how non-local interfaces fit into the
topology?  In OLSR and TBRPF, each node maintains a logical
topology of the network represented by point-to-point links, which 
contains no knowledge about the *types* of links (wired, wireless,
point-to-point, Ethernet, etc.) that are represented by the 
logical point-to-point links.  (Of course, each node knows which
types of *local* interfaces it has, and which neighbors can be
reached thru each local interface.)  Unlike OLSR and TBRPF, OSPF 
distinguishes between different types of interfaces/links in LSAs,
and the LSAs describe how these interfaces fit into the topology,
and also assign a metric to each interface.  
So one question is: Should we do the same?

Richard

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



From mailnull@www1.ietf.org  Tue Apr 15 14:50:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07031
	for ; Tue, 15 Apr 2003 14:50:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FIwRb27621
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 14:58:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIwR827618
	for ; Tue, 15 Apr 2003 14:58:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06999
	for ; Tue, 15 Apr 2003 14:49:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195VXQ-00043n-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 14:52:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195VXQ-00043k-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 14:52:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIg8826845;
	Tue, 15 Apr 2003 14:42:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIc4826655
	for ; Tue, 15 Apr 2003 14:38:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06281
	for ; Tue, 15 Apr 2003 14:29:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195VDi-0003vq-00
	for manet@ietf.org; Tue, 15 Apr 2003 14:31:50 -0400
Received: from slb-smtpout-01.boeing.com ([130.76.64.48])
	by ietf-mx with esmtp (Exim 4.12)
	id 195VDh-0003vn-00
	for manet@ietf.org; Tue, 15 Apr 2003 14:31:49 -0400
Received: from slb-av-02.boeing.com ([129.172.13.7])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA07318;
	Tue, 15 Apr 2003 11:31:34 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA18167;
	Tue, 15 Apr 2003 11:31:53 -0700 (PDT)
Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3FIVqf01138;
	Tue, 15 Apr 2003 11:31:52 -0700 (PDT)
Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Apr 2003 14:31:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [manet] Neighbor addresses in OLSR HELLO messages
Date: Tue, 15 Apr 2003 14:31:50 -0400
Message-ID: 
Thread-Topic: [manet] Neighbor addresses in OLSR HELLO messages
Thread-Index: AcMC9y3OwPEWflxYQZW/6cCcYPtlrwAgVZMg
From: "Manfredi, Albert E" 
To: "Fred Baker" 
Cc: 
X-OriginalArrivalTime: 15 Apr 2003 18:31:51.0500 (UTC) FILETIME=[484850C0:01C3037D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3FIc4826656
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Fred Baker wrote:

> The issue I am raising is in the following vein. In a manet 
> network, for 
> example, a truck (which has an internal wired LAN with some number of 
> computers and a router connecting it to the manet) might 
> drive into a yard 
> and jack into the local network, becoming both a mobile and a 
> fixed node.

I understand your sentiment that a single protocol for mobile hosts and the fixed Internet would be preferable. But ...

Somehow, that's not a scenario I would postulate for a MANET. The truck can park in a yard and plug into a fixed network as you describe. If the IP addresses inside the truck are globally unique, then I would think a standard IGP outside the truck will have time to announce routes to the trucks hosts, and the IGP inside the truck ditto. No? No need for any MANET here, that I can see.

If the IP addresses inside the truck, and all other similar trucks, are NOT globally unique, e.g. they are taken from the private address space (extremely likely), then a NAT will have to be used between truck and fixed Internet. Again, no need for any MANET. This is just like connecting a home with multiple PCs to an ISP.

I think the MANET part would only come into play if many of these trucks were running around a large battlefield, for instance, and wanted to remain in constant communications among each other and hopefully also with the wired Internet. AND if this were to be by means of wireless links *between trucks* only. One or more trucks would also have to be within range of a fixed Internet AP. I emphasize large battlefield, because again, if each truck were within range of the AP, then no MANET is needed.

The problem here is that the topology changes too fast for traditional IGPs to keep up. And there's very little likelihood that route aggregation can be used to make this beast scale. So a poorly scaling but rapidly updating routing protocol would be used between trucks, but you wouldn't want to burden the fixed Internet this way. The presumption is that there won't be too many trucks in this MANET.

The easy way out of this one is to connect each truck to a satellite link, and let both truck-truck and truck-Internet comms occur via that link. In which case, once again, no MANET needed. In this example, functionally, every truck here is within range of the fixed Internet AP. The satellite link is the AP.

> Now, by military rules, the truck is supposed to have an 
> address assigned 
> by its unit, so what it probably does is generate a local 
> address in the 
> fixed network using DHCP and then advertise reachability to 
> its mobile 
> prefix. Hence, the mobile prefix is now floating in both IGPs. If the 
> *intended* router between the IGPs now leaks the prefix back 
> in either 
> direction, problems can develop.

Yes, but I just don't see THIS as being a MANET candidate. If the truck is parked in that yard for any length of time at all, OSPF should stabilize. Especially if a NAT is used, so that the truck's temporary prefix to the outside world is a well-known prefix for that particular location.

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



From mailnull@www1.ietf.org  Tue Apr 15 16:03:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09894
	for ; Tue, 15 Apr 2003 16:03:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FKCED00458
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 16:12:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKCE800455
	for ; Tue, 15 Apr 2003 16:12:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09891
	for ; Tue, 15 Apr 2003 16:03:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Wgo-0004Jh-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 16:05:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Wgo-0004Je-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 16:05:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FJxJ831571;
	Tue, 15 Apr 2003 15:59:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FJs4831422
	for ; Tue, 15 Apr 2003 15:54:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09455
	for ; Tue, 15 Apr 2003 15:45:19 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195WPF-0004Ee-00
	for manet@ietf.org; Tue, 15 Apr 2003 15:47:49 -0400
Received: from ponyexpress.ee.columbia.edu ([128.59.64.61] ident=[THlCEx4xTugvuuDLkvq1rJEw8tN1K16w])
	by ietf-mx with esmtp (Exim 4.12)
	id 195WPF-0004Eb-00
	for manet@ietf.org; Tue, 15 Apr 2003 15:47:49 -0400
Received: from farseer (dhcp-65-107.ee.columbia.edu [128.59.65.107])
	(authenticated bits=0)
	by ponyexpress.ee.columbia.edu (8.12.8/8.12.1) with ESMTP id h3FJlvKR007648
	for ; Tue, 15 Apr 2003 15:47:57 -0400
From: "SeoungBum Lee" 
To: 
Date: Tue, 15 Apr 2003 15:48:04 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0000_01C30366.66C749F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <004701c302fd$417c4330$ca413b80@SWEETPEA>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Subject: [manet] HMP (Hotspot Mitigation Protocol)
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C30366.66C749F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello:

We have been looking at the issue of congestion control
in MANET and designed HMP (Hotspot Mitigation Protocol)
that can interwork with some of the MANET routing protocols.

In HMP, nodes independently monitor local conditions, and
take local actions:
-to declare a node to be a hotspot if a combination of MAC
contention/delays, packet loss, buffer occupancy, and
energy reserves exceed certain predefined system thresholds;
-to suppress new route requests at hotspots to ensure that
routed traffic does not compound the hotspot's congestion
problems; and
-to throttle traffic locally at hotspots to force TCP flows to slow down.

We have completed extensive simulations and almost completed
the testbed implementation with AODV. We intend to write an ID
based on our design/implementations experience from the code.
Until then those interested can look at the following paper:

Seoung-Bum Lee and Andrew T. Campbell, "HMP: Hotspot Mitigation
Protocol for Mobile Ad hoc Networks"11th IEEE/IFIP International
Workshop on Quality of Service (IWQOS 2003), Monterey, CA, June 2-4,
2003.

Any comments are appreciated.

Regards,
Seoung-Bum 

------=_NextPart_000_0000_01C30366.66C749F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hello:

We have been looking at the issue of =
congestion=20
control
in MANET and designed HMP (Hotspot Mitigation =
Protocol)
that can=20
interwork with some of the MANET routing protocols.

In HMP, nodes =

independently monitor local conditions, and
take local =
actions:
-to=20
declare a node to be a hotspot if a combination of =
MAC
contention/delays,=20
packet loss, buffer occupancy, and
energy reserves exceed certain =
predefined=20
system thresholds;
-to suppress new route requests at hotspots to =
ensure=20
that
routed traffic does not compound the hotspot's =
congestion
problems;=20
and
-to throttle traffic locally at hotspots to force TCP flows to =
slow=20
down.

We have completed extensive simulations and almost =
completed
the=20
testbed implementation with AODV. We intend to write an ID
based on =
our=20
design/implementations experience from the code.
Until then those =
interested=20
can look at the following paper:

Seoung-Bum Lee and Andrew T. =
Campbell,=20
"HMP:=20
Hotspot Mitigation
Protocol for Mobile Ad hoc Networks"11th =
IEEE/IFIP=20
International
Workshop on Quality of Service (IWQOS 2003), Monterey, =
CA, June=20
2-4,
2003.

Any comments are=20
appreciated.

Regards,
Seoung-Bum 


------=_NextPart_000_0000_01C30366.66C749F0--

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



From mailnull@www1.ietf.org  Tue Apr 15 16:37:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10933
	for ; Tue, 15 Apr 2003 16:37:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FKjwZ02912
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 16:45:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKjw802909
	for ; Tue, 15 Apr 2003 16:45:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10930
	for ; Tue, 15 Apr 2003 16:37:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195XDR-0004Sw-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 16:39:41 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195XDR-0004St-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 16:39:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKWk801351;
	Tue, 15 Apr 2003 16:32:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKSU801162
	for ; Tue, 15 Apr 2003 16:28:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10285
	for ; Tue, 15 Apr 2003 16:19:44 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195WwY-0004NH-00
	for manet@ietf.org; Tue, 15 Apr 2003 16:22:14 -0400
Received: from web21005.mail.yahoo.com ([216.136.227.59])
	by ietf-mx with smtp (Exim 4.12)
	id 195WwY-0004NE-00
	for manet@ietf.org; Tue, 15 Apr 2003 16:22:14 -0400
Message-ID: <20030415202221.73964.qmail@web21005.mail.yahoo.com>
Received: from [141.225.138.64] by web21005.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 13:22:21 PDT
Date: Tue, 15 Apr 2003 13:22:21 -0700 (PDT)
From: Yang Xiao 
Reply-To: YangXiao@ieee.org
Subject: Re: [manet] 802.11 - minor optimization
To: "Nitin H. Vaidya" , MANET mailing list 
Cc: yangxiao@ieee.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

nitin

I am sorry that my response to this email is quick late.

I read your email today and feel that I can not understand your
argument. I might be missing something.

In your example, 

> and 1, 2, 3, 4 with the new modification.
  
> With the modification:
> 
>    A will transmit DIFS + 0 slot after current transmission ends.
>    B will transmit DIFS + 0 slot after A's transmission.
>    C will transmit DIFS + 0 slot after B's transmission.
>    D will transmit DIFS + 0 slot after C's transmission.

I am not sure how you get above observations. Since the backoff counter
is stopped when busy, it seems to me that the above argument might not
be correct. It seems to me that

    A will transmit DIFS + 1 slot after current transmission ends.
    B will transmit DIFS + 1 slot after A's transmission.
    C will transmit DIFS + 1 slot after B's transmission.
    D will transmit DIFS + 1 slot after C's transmission.

Therefore, backoff [1 CW] seems to me "did not gain 1 slot"

I might be wrong. Please let me know.

Sorry for the late response

Best Regards

Yang


--- "Nitin H. Vaidya"  wrote:
> 
> Hello all:
> 
> Anyone on the list from 802.11 standards group ?
> Here is a trivial idea worth 2 cents (more like 5%) ...
> 
> A simple optimization for 802.11 that might improve
> performance 5% without any real change to the protocol :
> 
> As I understand 802.11 DCF, the backoff intervals are chosen
> in the range of [0,CW] and then the backoff counter is
> decremented at the END of each idle slot. Transmit immediately
> when counter reaches 0.
> 
> Suggested modification:
> 
>   Choose backoff interval in the range [1,cw], and decrement
>   backoff counter at the START of each slot. Transmit immediately
>   when counter reaches 0.
> 
> CW in 802.11 is specifed as 2^k-1 for interger k. With the above
> change CW should be simply 2^k so that the range of values
> for backoff remains same as 802.11 (or, to put it differently,
> choose new backoff as 802.11 backoff + 1).
> 
> Unless I am mistaken, the above change can save 1 idle
> slot for each transmitted packets (with some exceptions).
> 
> To see this consider the case when 4 nodes (A, B, C, D) receive
> a packet from upper layers while the channel is busy. Let us say that
> they choose backoff intervals 0, 1, 2, 3 with the original 802.11,
> and 1, 2, 3, 4 with the new modification.
> 
> In the original 802.11:
> 
>    A will transmit DIFS + 0 slot after current transmission ends.
>    B will transmit DIFS + 1 slot after A's transmission.
>    C will transmit DIFS + 1 slot after B's transmission.
>    D will transmit DIFS + 1 slot after C's transmission.
> 
> With the modification:
> 
>    A will transmit DIFS + 0 slot after current transmission ends.
>    B will transmit DIFS + 0 slot after A's transmission.
>    C will transmit DIFS + 0 slot after B's transmission.
>    D will transmit DIFS + 0 slot after C's transmission.
> 
> So we save 1 slot for each of the last 3 transmissions -- in general,
> 1 slot may be saved whenever a non-zero backoff counter is chosen
> by original 802.11 for a packet that arrives on a busy channel.
> 
> Any reason not to use the above modification to 802.11 ?
> About 5 minutes of thought went into this suggestion, so if there
> is a bug in my argument, feel free to point it out.
> 
> Happy holidays!
> 
> - nitin
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Tue Apr 15 17:00:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11746
	for ; Tue, 15 Apr 2003 17:00:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FL8n805535
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 17:08:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FL8n805532
	for ; Tue, 15 Apr 2003 17:08:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11709
	for ; Tue, 15 Apr 2003 17:00:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195XZY-0004eI-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 17:02:32 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195XZX-0004eF-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 17:02:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKpA803142;
	Tue, 15 Apr 2003 16:51:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKlI802990
	for ; Tue, 15 Apr 2003 16:47:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10953
	for ; Tue, 15 Apr 2003 16:38:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195XEk-0004T5-00
	for manet@ietf.org; Tue, 15 Apr 2003 16:41:02 -0400
Received: from amber.crhc.uiuc.edu ([130.126.143.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 195XEj-0004T2-00
	for manet@ietf.org; Tue, 15 Apr 2003 16:41:01 -0400
Received: from godel.crhc.uiuc.edu (godel.crhc.uiuc.edu [130.126.142.150])
	by amber.crhc.uiuc.edu (8.12.9/8.12.9) with ESMTP id h3FKerFc029388;
	Tue, 15 Apr 2003 15:40:53 -0500 (CDT)
Received: from localhost (nhv@localhost)
	by godel.crhc.uiuc.edu (8.11.6/8.11.6) with ESMTP id h3FKerT16389;
	Tue, 15 Apr 2003 15:40:53 -0500
X-Authentication-Warning: godel.crhc.uiuc.edu: nhv owned process doing -bs
Date: Tue, 15 Apr 2003 15:40:53 -0500 (CDT)
From: "Nitin H. Vaidya" 
To: YangXiao@ieee.org
cc: MANET mailing list 
Subject: Re: [manet] 802.11 - minor optimization
In-Reply-To: <20030415202221.73964.qmail@web21005.mail.yahoo.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


Yang:

On Tue, 15 Apr 2003, Yang Xiao wrote:

.  >>nitin
.  >>
.  >>I am sorry that my response to this email is quick late.
.  >>
.  >>I read your email today and feel that I can not understand your
.  >>argument. I might be missing something.
.  >>
.  >>In your example, 
.  >>
.  >>> and 1, 2, 3, 4 with the new modification.
.  >>  
.  >>> With the modification:
.  >>> 
.  >>>    A will transmit DIFS + 0 slot after current transmission ends.
.  >>>    B will transmit DIFS + 0 slot after A's transmission.
.  >>>    C will transmit DIFS + 0 slot after B's transmission.
.  >>>    D will transmit DIFS + 0 slot after C's transmission.
.  >>
.  >>I am not sure how you get above observations. Since the backoff counter
.  >>is stopped when busy, it seems to me that the above argument might not
.  >>be correct. It seems to me that
.  >>
.  >>    A will transmit DIFS + 1 slot after current transmission ends.

Node A decrements at the START of an idle slot (so it will decrement after
DIFS interval, reach 0 at that time, and transmit).
- nitin

.  >>    B will transmit DIFS + 1 slot after A's transmission.
.  >>    C will transmit DIFS + 1 slot after B's transmission.
.  >>    D will transmit DIFS + 1 slot after C's transmission.
.  >>
.  >>Therefore, backoff [1 CW] seems to me "did not gain 1 slot"
.  >>
.  >>I might be wrong. Please let me know.
.  >>
.  >>Sorry for the late response
.  >>
.  >>Best Regards
.  >>
.  >>Yang
.  >>
.  >>
.  >>--- "Nitin H. Vaidya"  wrote:
.  >>> 
.  >>> Hello all:
.  >>> 
.  >>> Anyone on the list from 802.11 standards group ?
.  >>> Here is a trivial idea worth 2 cents (more like 5%) ...
.  >>> 
.  >>> A simple optimization for 802.11 that might improve
.  >>> performance 5% without any real change to the protocol :
.  >>> 
.  >>> As I understand 802.11 DCF, the backoff intervals are chosen
.  >>> in the range of [0,CW] and then the backoff counter is
.  >>> decremented at the END of each idle slot. Transmit immediately
.  >>> when counter reaches 0.
.  >>> 
.  >>> Suggested modification:
.  >>> 
.  >>>   Choose backoff interval in the range [1,cw], and decrement
.  >>>   backoff counter at the START of each slot. Transmit immediately
.  >>>   when counter reaches 0.
.  >>> 
.  >>> CW in 802.11 is specifed as 2^k-1 for interger k. With the above
.  >>> change CW should be simply 2^k so that the range of values
.  >>> for backoff remains same as 802.11 (or, to put it differently,
.  >>> choose new backoff as 802.11 backoff + 1).
.  >>> 
.  >>> Unless I am mistaken, the above change can save 1 idle
.  >>> slot for each transmitted packets (with some exceptions).
.  >>> 
.  >>> To see this consider the case when 4 nodes (A, B, C, D) receive
.  >>> a packet from upper layers while the channel is busy. Let us say that
.  >>> they choose backoff intervals 0, 1, 2, 3 with the original 802.11,
.  >>> and 1, 2, 3, 4 with the new modification.
.  >>> 
.  >>> In the original 802.11:
.  >>> 
.  >>>    A will transmit DIFS + 0 slot after current transmission ends.
.  >>>    B will transmit DIFS + 1 slot after A's transmission.
.  >>>    C will transmit DIFS + 1 slot after B's transmission.
.  >>>    D will transmit DIFS + 1 slot after C's transmission.
.  >>> 
.  >>> With the modification:
.  >>> 
.  >>>    A will transmit DIFS + 0 slot after current transmission ends.
.  >>>    B will transmit DIFS + 0 slot after A's transmission.
.  >>>    C will transmit DIFS + 0 slot after B's transmission.
.  >>>    D will transmit DIFS + 0 slot after C's transmission.
.  >>> 
.  >>> So we save 1 slot for each of the last 3 transmissions -- in general,
.  >>> 1 slot may be saved whenever a non-zero backoff counter is chosen
.  >>> by original 802.11 for a packet that arrives on a busy channel.
.  >>> 
.  >>> Any reason not to use the above modification to 802.11 ?
.  >>> About 5 minutes of thought went into this suggestion, so if there
.  >>> is a bug in my argument, feel free to point it out.
.  >>> 
.  >>> Happy holidays!
.  >>> 
.  >>> - nitin
.  >>> 
.  >>> _______________________________________________
.  >>> manet mailing list
.  >>> manet@ietf.org
.  >>> https://www1.ietf.org/mailman/listinfo/manet
.  >>
.  >>
.  >>__________________________________________________
.  >>Do you Yahoo!?
.  >>The New Yahoo! Search - Faster. Easier. Bingo
.  >>http://search.yahoo.com
.  >>

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



From mailnull@www1.ietf.org  Tue Apr 15 18:17:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14687
	for ; Tue, 15 Apr 2003 18:17:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FMQ4610753
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 18:26:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMQ4810750
	for ; Tue, 15 Apr 2003 18:26:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14639
	for ; Tue, 15 Apr 2003 18:17:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195YmH-00054A-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 18:19:45 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195YmG-000547-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 18:19:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMD0810136;
	Tue, 15 Apr 2003 18:13:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FM8i810005
	for ; Tue, 15 Apr 2003 18:08:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13172
	for ; Tue, 15 Apr 2003 17:59:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195YVW-0004yD-00
	for manet@ietf.org; Tue, 15 Apr 2003 18:02:26 -0400
Received: from web21003.mail.yahoo.com ([216.136.227.57])
	by ietf-mx with smtp (Exim 4.12)
	id 195YVV-0004yA-00
	for manet@ietf.org; Tue, 15 Apr 2003 18:02:25 -0400
Message-ID: <20030415220213.49581.qmail@web21003.mail.yahoo.com>
Received: from [141.225.138.64] by web21003.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 15:02:13 PDT
Date: Tue, 15 Apr 2003 15:02:13 -0700 (PDT)
From: Yang Xiao 
Reply-To: YangXiao@ieee.org
Subject: Re: [manet] 802.11 - minor optimization
To: "Nitin H. Vaidya" , YangXiao@ieee.org
Cc: MANET mailing list 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Nitin

Thanks for the comments. 

Now I understand your point.

You are saying that instead of 

"Decrementing backoff counter at the END of each slot. Transmit in the
next slot if it reaches zero"

you modify it as 

"Decrement backoff counter at the START of each slot. Transmit
immediately when counter reaches 0."

However, as for my impression, the device may not sense that "fast" so
that it can not sense the channel idle and transmit at the same slot.
It will takes D1 time that the device to get a conclusion that the slot
is idle. D1 wrote:
> 
> Yang:
> 
> On Tue, 15 Apr 2003, Yang Xiao wrote:
> 
> .  >>nitin
> .  >>
> .  >>I am sorry that my response to this email is quick late.
> .  >>
> .  >>I read your email today and feel that I can not understand your
> .  >>argument. I might be missing something.
> .  >>
> .  >>In your example, 
> .  >>
> .  >>> and 1, 2, 3, 4 with the new modification.
> .  >>  
> .  >>> With the modification:
> .  >>> 
> .  >>>    A will transmit DIFS + 0 slot after current transmission
> ends.
> .  >>>    B will transmit DIFS + 0 slot after A's transmission.
> .  >>>    C will transmit DIFS + 0 slot after B's transmission.
> .  >>>    D will transmit DIFS + 0 slot after C's transmission.
> .  >>
> .  >>I am not sure how you get above observations. Since the backoff
> counter
> .  >>is stopped when busy, it seems to me that the above argument
> might not
> .  >>be correct. It seems to me that
> .  >>
> .  >>    A will transmit DIFS + 1 slot after current transmission
> ends.
> 
> Node A decrements at the START of an idle slot (so it will decrement
> after
> DIFS interval, reach 0 at that time, and transmit).
> - nitin
> 
> .  >>    B will transmit DIFS + 1 slot after A's transmission.
> .  >>    C will transmit DIFS + 1 slot after B's transmission.
> .  >>    D will transmit DIFS + 1 slot after C's transmission.
> .  >>
> .  >>Therefore, backoff [1 CW] seems to me "did not gain 1 slot"
> .  >>
> .  >>I might be wrong. Please let me know.
> .  >>
> .  >>Sorry for the late response
> .  >>
> .  >>Best Regards
> .  >>
> .  >>Yang
> .  >>
> .  >>
> .  >>--- "Nitin H. Vaidya"  wrote:
> .  >>> 
> .  >>> Hello all:
> .  >>> 
> .  >>> Anyone on the list from 802.11 standards group ?
> .  >>> Here is a trivial idea worth 2 cents (more like 5%) ...
> .  >>> 
> .  >>> A simple optimization for 802.11 that might improve
> .  >>> performance 5% without any real change to the protocol :
> .  >>> 
> .  >>> As I understand 802.11 DCF, the backoff intervals are chosen
> .  >>> in the range of [0,CW] and then the backoff counter is
> .  >>> decremented at the END of each idle slot. Transmit immediately
> .  >>> when counter reaches 0.
> .  >>> 
> .  >>> Suggested modification:
> .  >>> 
> .  >>>   Choose backoff interval in the range [1,cw], and decrement
> .  >>>   backoff counter at the START of each slot. Transmit
> immediately
> .  >>>   when counter reaches 0.
> .  >>> 
> .  >>> CW in 802.11 is specifed as 2^k-1 for interger k. With the
> above
> .  >>> change CW should be simply 2^k so that the range of values
> .  >>> for backoff remains same as 802.11 (or, to put it differently,
> .  >>> choose new backoff as 802.11 backoff + 1).
> .  >>> 
> .  >>> Unless I am mistaken, the above change can save 1 idle
> .  >>> slot for each transmitted packets (with some exceptions).
> .  >>> 
> .  >>> To see this consider the case when 4 nodes (A, B, C, D)
> receive
> .  >>> a packet from upper layers while the channel is busy. Let us
> say that
> .  >>> they choose backoff intervals 0, 1, 2, 3 with the original
> 802.11,
> .  >>> and 1, 2, 3, 4 with the new modification.
> .  >>> 
> .  >>> In the original 802.11:
> .  >>> 
> .  >>>    A will transmit DIFS + 0 slot after current transmission
> ends.
> .  >>>    B will transmit DIFS + 1 slot after A's transmission.
> .  >>>    C will transmit DIFS + 1 slot after B's transmission.
> .  >>>    D will transmit DIFS + 1 slot after C's transmission.
> .  >>> 
> .  >>> With the modification:
> .  >>> 
> .  >>>    A will transmit DIFS + 0 slot after current transmission
> ends.
> .  >>>    B will transmit DIFS + 0 slot after A's transmission.
> .  >>>    C will transmit DIFS + 0 slot after B's transmission.
> .  >>>    D will transmit DIFS + 0 slot after C's transmission.
> .  >>> 
> .  >>> So we save 1 slot for each of the last 3 transmissions -- in
> general,
> .  >>> 1 slot may be saved whenever a non-zero backoff counter is
> chosen
> .  >>> by original 802.11 for a packet that arrives on a busy
> channel.
> .  >>> 
> .  >>> Any reason not to use the above modification to 802.11 ?
> .  >>> About 5 minutes of thought went into this suggestion, so if
> there
> .  >>> is a bug in my argument, feel free to point it out.
> .  >>> 
> .  >>> Happy holidays!
> .  >>> 
> .  >>> - nitin
> .  >>> 
> .  >>> _______________________________________________
> .  >>> manet mailing list
> .  >>> manet@ietf.org
> .  >>> https://www1.ietf.org/mailman/listinfo/manet
> .  >>
> .  >>
> .  >>__________________________________________________
> .  >>Do you Yahoo!?
> .  >>The New Yahoo! Search - Faster. Easier. Bingo
> .  >>http://search.yahoo.com
> .  >>
> 


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Tue Apr 15 19:49:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16980
	for ; Tue, 15 Apr 2003 19:49:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FNwJk16454
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 19:58:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FNwJ816451
	for ; Tue, 15 Apr 2003 19:58:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16943
	for ; Tue, 15 Apr 2003 19:49:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195aDW-0005Ss-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 19:51:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195aDW-0005Sp-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 19:51:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FNbj815626;
	Tue, 15 Apr 2003 19:37:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FNR9814531
	for ; Tue, 15 Apr 2003 19:27:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16371
	for ; Tue, 15 Apr 2003 19:18:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195ZjN-0005Kt-00
	for manet@ietf.org; Tue, 15 Apr 2003 19:20:49 -0400
Received: from amber.crhc.uiuc.edu ([130.126.143.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 195ZjN-0005Kq-00
	for manet@ietf.org; Tue, 15 Apr 2003 19:20:49 -0400
Received: from chaos.crhc.uiuc.edu (chaos.crhc.uiuc.edu [130.126.143.233])
	by amber.crhc.uiuc.edu (8.12.9/8.12.9) with ESMTP id h3FNKkFc008681;
	Tue, 15 Apr 2003 18:20:46 -0500 (CDT)
Received: from localhost (nhv@localhost)
	by chaos.crhc.uiuc.edu (8.11.6/8.11.6) with ESMTP id h3FNJXZ19535;
	Tue, 15 Apr 2003 18:19:33 -0500
X-Authentication-Warning: chaos.crhc.uiuc.edu: nhv owned process doing -bs
Date: Tue, 15 Apr 2003 18:19:33 -0500 (CDT)
From: "Nitin H. Vaidya" 
To: YangXiao@ieee.org
cc: MANET mailing list 
Subject: Re: [manet] 802.11 - minor optimization
In-Reply-To: <20030415220213.49581.qmail@web21003.mail.yahoo.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-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


On Tue, 15 Apr 2003, Yang Xiao wrote:

.  >>Nitin
.  >>
.  >>Thanks for the comments. 
.  >>
.  >>Now I understand your point.
.  >>
.  >>You are saying that instead of 
.  >>
.  >>"Decrementing backoff counter at the END of each slot. Transmit in the
.  >>next slot if it reaches zero"
.  >>
.  >>you modify it as 
.  >>
.  >>"Decrement backoff counter at the START of each slot. Transmit
.  >>immediately when counter reaches 0."
.  >>
.  >>However, as for my impression, the device may not sense that "fast" so
.  >>that it can not sense the channel idle and transmit at the same slot.
.  >>It will takes D1 time that the device to get a conclusion that the slot
.  >>is idle. D1>"listening status" to a "transmitting status" which is called
.  >>"turned-around time". The time (D1+ the turned around time) is almost a
.  >>slot time. Therefore, the earliest time to transmit is the next slot
.  >>time.
.  >>
.  >>In summary, it is because of the physical implementation limitation
.  >>that your modification might not work. I may be wrong.
.  >> 
.  >>I hope I explain it clear, but I might be wrong.

With current 802.11, a node can in fact choose backoff interval = 0
for a packet. So, whenever current 802.11 would decide to
transmit with backoff =0 (after DIFS), is the time when the backoff
would be decremented with the modification I was suggesting. I do not have
the 802.11 specs handy, but I vaguely recall that the D1 interval is
already built into the IFSs.
- nitin


.  >>
.  >>Please let me if you think me wrong. 
.  >>
.  >>Thanks
.  >>
.  >>Best Regards
.  >>
.  >>Yang
.  >>
.  >> 
.  >> 
.  >> 
.  >>--- "Nitin H. Vaidya"  wrote:
.  >>> 
.  >>> Yang:
.  >>> 
.  >>> On Tue, 15 Apr 2003, Yang Xiao wrote:
.  >>> 
.  >>> .  >>nitin
.  >>> .  >>
.  >>> .  >>I am sorry that my response to this email is quick late.
.  >>> .  >>
.  >>> .  >>I read your email today and feel that I can not understand your
.  >>> .  >>argument. I might be missing something.
.  >>> .  >>
.  >>> .  >>In your example, 
.  >>> .  >>
.  >>> .  >>> and 1, 2, 3, 4 with the new modification.
.  >>> .  >>  
.  >>> .  >>> With the modification:
.  >>> .  >>> 
.  >>> .  >>>    A will transmit DIFS + 0 slot after current transmission
.  >>> ends.
.  >>> .  >>>    B will transmit DIFS + 0 slot after A's transmission.
.  >>> .  >>>    C will transmit DIFS + 0 slot after B's transmission.
.  >>> .  >>>    D will transmit DIFS + 0 slot after C's transmission.
.  >>> .  >>
.  >>> .  >>I am not sure how you get above observations. Since the backoff
.  >>> counter
.  >>> .  >>is stopped when busy, it seems to me that the above argument
.  >>> might not
.  >>> .  >>be correct. It seems to me that
.  >>> .  >>
.  >>> .  >>    A will transmit DIFS + 1 slot after current transmission
.  >>> ends.
.  >>> 
.  >>> Node A decrements at the START of an idle slot (so it will decrement
.  >>> after
.  >>> DIFS interval, reach 0 at that time, and transmit).
.  >>> - nitin
.  >>> 
.  >>> .  >>    B will transmit DIFS + 1 slot after A's transmission.
.  >>> .  >>    C will transmit DIFS + 1 slot after B's transmission.
.  >>> .  >>    D will transmit DIFS + 1 slot after C's transmission.
.  >>> .  >>
.  >>> .  >>Therefore, backoff [1 CW] seems to me "did not gain 1 slot"
.  >>> .  >>
.  >>> .  >>I might be wrong. Please let me know.
.  >>> .  >>
.  >>> .  >>Sorry for the late response
.  >>> .  >>
.  >>> .  >>Best Regards
.  >>> .  >>
.  >>> .  >>Yang
.  >>> .  >>
.  >>> .  >>
.  >>> .  >>--- "Nitin H. Vaidya"  wrote:
.  >>> .  >>> 
.  >>> .  >>> Hello all:
.  >>> .  >>> 
.  >>> .  >>> Anyone on the list from 802.11 standards group ?
.  >>> .  >>> Here is a trivial idea worth 2 cents (more like 5%) ...
.  >>> .  >>> 
.  >>> .  >>> A simple optimization for 802.11 that might improve
.  >>> .  >>> performance 5% without any real change to the protocol :
.  >>> .  >>> 
.  >>> .  >>> As I understand 802.11 DCF, the backoff intervals are chosen
.  >>> .  >>> in the range of [0,CW] and then the backoff counter is
.  >>> .  >>> decremented at the END of each idle slot. Transmit immediately
.  >>> .  >>> when counter reaches 0.
.  >>> .  >>> 
.  >>> .  >>> Suggested modification:
.  >>> .  >>> 
.  >>> .  >>>   Choose backoff interval in the range [1,cw], and decrement
.  >>> .  >>>   backoff counter at the START of each slot. Transmit
.  >>> immediately
.  >>> .  >>>   when counter reaches 0.
.  >>> .  >>> 
.  >>> .  >>> CW in 802.11 is specifed as 2^k-1 for interger k. With the
.  >>> above
.  >>> .  >>> change CW should be simply 2^k so that the range of values
.  >>> .  >>> for backoff remains same as 802.11 (or, to put it differently,
.  >>> .  >>> choose new backoff as 802.11 backoff + 1).
.  >>> .  >>> 
.  >>> .  >>> Unless I am mistaken, the above change can save 1 idle
.  >>> .  >>> slot for each transmitted packets (with some exceptions).
.  >>> .  >>> 
.  >>> .  >>> To see this consider the case when 4 nodes (A, B, C, D)
.  >>> receive
.  >>> .  >>> a packet from upper layers while the channel is busy. Let us
.  >>> say that
.  >>> .  >>> they choose backoff intervals 0, 1, 2, 3 with the original
.  >>> 802.11,
.  >>> .  >>> and 1, 2, 3, 4 with the new modification.
.  >>> .  >>> 
.  >>> .  >>> In the original 802.11:
.  >>> .  >>> 
.  >>> .  >>>    A will transmit DIFS + 0 slot after current transmission
.  >>> ends.
.  >>> .  >>>    B will transmit DIFS + 1 slot after A's transmission.
.  >>> .  >>>    C will transmit DIFS + 1 slot after B's transmission.
.  >>> .  >>>    D will transmit DIFS + 1 slot after C's transmission.
.  >>> .  >>> 
.  >>> .  >>> With the modification:
.  >>> .  >>> 
.  >>> .  >>>    A will transmit DIFS + 0 slot after current transmission
.  >>> ends.
.  >>> .  >>>    B will transmit DIFS + 0 slot after A's transmission.
.  >>> .  >>>    C will transmit DIFS + 0 slot after B's transmission.
.  >>> .  >>>    D will transmit DIFS + 0 slot after C's transmission.
.  >>> .  >>> 
.  >>> .  >>> So we save 1 slot for each of the last 3 transmissions -- in
.  >>> general,
.  >>> .  >>> 1 slot may be saved whenever a non-zero backoff counter is
.  >>> chosen
.  >>> .  >>> by original 802.11 for a packet that arrives on a busy
.  >>> channel.
.  >>> .  >>> 
.  >>> .  >>> Any reason not to use the above modification to 802.11 ?
.  >>> .  >>> About 5 minutes of thought went into this suggestion, so if
.  >>> there
.  >>> .  >>> is a bug in my argument, feel free to point it out.
.  >>> .  >>> 
.  >>> .  >>> Happy holidays!
.  >>> .  >>> 
.  >>> .  >>> - nitin
.  >>> .  >>> 
.  >>> .  >>> _______________________________________________
.  >>> .  >>> manet mailing list
.  >>> .  >>> manet@ietf.org
.  >>> .  >>> https://www1.ietf.org/mailman/listinfo/manet
.  >>> .  >>
.  >>> .  >>
.  >>> .  >>__________________________________________________
.  >>> .  >>Do you Yahoo!?
.  >>> .  >>The New Yahoo! Search - Faster. Easier. Bingo
.  >>> .  >>http://search.yahoo.com
.  >>> .  >>
.  >>> 
.  >>
.  >>
.  >>__________________________________________________
.  >>Do you Yahoo!?
.  >>The New Yahoo! Search - Faster. Easier. Bingo
.  >>http://search.yahoo.com
.  >>

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



From mailnull@www1.ietf.org  Tue Apr 15 23:05:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20913
	for ; Tue, 15 Apr 2003 23:05:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G3DXR30069
	for manet-archive@odin.ietf.org; Tue, 15 Apr 2003 23:13:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G3DX830066
	for ; Tue, 15 Apr 2003 23:13:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20909
	for ; Tue, 15 Apr 2003 23:04:38 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195dGO-0006Cd-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 23:07:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195dGN-0006Ca-00
	for manet-web-archive@ietf.org; Tue, 15 Apr 2003 23:07:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G30f828563;
	Tue, 15 Apr 2003 23:00:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2sT828327
	for ; Tue, 15 Apr 2003 22:54:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20511
	for ; Tue, 15 Apr 2003 22:45:35 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195cxx-00066f-00
	for manet@ietf.org; Tue, 15 Apr 2003 22:48:05 -0400
Received: from amber.ccs.neu.edu ([129.10.116.51])
	by ietf-mx with esmtp (Exim 4.12)
	id 195cxw-00066c-00
	for manet@ietf.org; Tue, 15 Apr 2003 22:48:04 -0400
Received: from denali.ccs.neu.edu (denali.ccs.neu.edu [129.10.116.200])
	by amber.ccs.neu.edu (Postfix) with ESMTP
	id 00B3B6B4E4; Tue, 15 Apr 2003 22:48:12 -0400 (EDT)
Date: Tue, 15 Apr 2003 22:48:12 -0400 (EDT)
From: Guevara Noubir 
To: manet@ietf.org, mobile-ip@sunroof.eng.sun.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] CFP: ACM Workshop on Wireless Security (WiSe) in conjunction with
 ACM MobiCom
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	



Our apologies if you receive multiple copies of the CFP.

-----------------------------------------------------------------

                        Call for Papers

              Workshop on Wireless Security (WiSe)

                      in conjunction with
                       ACM MobiCom 2003

                      September 19, 2003
                         San Diego, CA

              http://www.ece.cmu.edu/~adrian/wise2003

                     Sponsored by SIGMOBILE


The workshop on Wireless Security will be held in conjunction with ACM
MobiCom 2003. The objective of this workshop is to bring together
researchers from research communities in wireless networking,
security, applied cryptography, and dependability; with the goal of
fostering interaction. With the proliferation of wireless networks,
issues related to secure and dependable operation of such networks are
gaining importance. Topics of interest include, but are not limited
to:

        * Key management in wireless/mobile environments
        * Trust establishment
        * Intrusion detection, detection of malicious behaviour
        * Revocation of malicious parties
        * Secure PHY/MAC/routing protocols
        * Secure location determination
        * Denial of service
        * User privacy
        * Anonymity, prevention of traffic analysis
        * Dependable wireless networking
        * Monitoring and surveillance


Paper submission instructions:

        Submission of papers based on work-in-progress is encouraged.
        Submitted papers must not be previously published elsewhere or
        currently under review for any other publication. Please direct
        any questions about the paper submission process to the Program
        Co-Chairs.

        All paper submissions will be handled electronically. Authors should
        prepare a PostScript or Portable Document Format (PDF) version of
        their paper.

        Papers must meet the following restrictions: No longer
        than 10 pages (single or double column); in font no smaller than
        11 points; must fit properly on US Letter-sized paper
        (8.5 inch x 11 inch) with reasonable margins.

        Instructions for electronic submission of papers will be posted
        at http://www.ece.cmu.edu/~adrian/wise2003/submission.html

Important dates:

        Paper submissions due: May 27, 2003

        Notification of acceptance: July 25, 2003

        Camera-ready papers due: August 1, 2003

        Workshop date: September 19, 2003

Workshop Co-Chairs:

        * Douglas Maughan, Defense Advanced Research Projects Agency
          (dmaughan@darpa.mil)
        * Adrian Perrig, Carnegie Mellon University
          (perrig@cmu.edu)

Program Committee:

        Bill Arbaugh, University of Maryland
        Brian Noble, University of Michigan
        Brian Van Leeuwen, Sandia National Laboratories
        Chinya Ravishankar, University of California at Riverside
        Jean-Pierre Hubaux, Swiss Federal Institute of Technology, Lausanne
        Jonathan Smith, University of Pennsylvania
        Leendert van Doorn, IBM
        Markus Jakobsson, RSA Security
        Radha Poovendran, University of Washington
        Stephen Zabele, Alphatech
        Wenke Lee, Georgia Institute of Technology
        Yair Amir, Johns Hopkins University

Publicity Co-Chairs:

        Mohsen Guizani, University of West Florida
        Guevara Noubir, Northeastern University

Publication Chair:

        Saad Biaz, Auburn University

Registration Chair:

        Robin Kravets, University of Illinois at Urbana-Champaign

Treasurer

        Yongguang Zhang, HRL Labs and UT-Austin
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr 16 02:27:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15945
	for ; Wed, 16 Apr 2003 02:27:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G6Zv421549
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 02:35:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G6Zv821546
	for ; Wed, 16 Apr 2003 02:35:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15920
	for ; Wed, 16 Apr 2003 02:26:56 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195gQB-0006is-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 02:29:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195gQB-0006ip-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 02:29:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G6N8820686;
	Wed, 16 Apr 2003 02:23:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G6GZ820018
	for ; Wed, 16 Apr 2003 02:16:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01386
	for ; Wed, 16 Apr 2003 02:07:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195g7S-0006eq-00
	for manet@ietf.org; Wed, 16 Apr 2003 02:10:06 -0400
Received: from pit.erg.sri.com ([128.18.100.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 195g7S-0006eb-00
	for manet@ietf.org; Wed, 16 Apr 2003 02:10:06 -0400
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 XAA05156;
	Tue, 15 Apr 2003 23:09:38 -0700 (PDT)
Message-Id: <200304160609.XAA05156@pit.erg.sri.com>
To: manet@ietf.org
CC: ogier@erg.sri.com
From: ogier@erg.sri.com
Reply-to: ogier@erg.sri.com
Date: Tue, 15 Apr 2003 23:09:38 -0700
Subject: [manet] TBRPF progression
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


All,

We have updated the TBRPF draft as planned, and have incorporated 
some helpful comments provided during the Last Call period.

The current version can be found at:
   http://www.erg.sri.com/projects/tbrpf/docs/draft08.txt

We will submit the draft to the IETF in a few days, after carefully
proofreading it and waiting for any additional comments.

The main changes since version 07 are as follows:

   o  HELLO messages have been changed to include neighbor interface
      addresses instead of neighbor router IDs. Correspondingly, the
      neighbor discovery protocol maintains (for each local interface)
      the status of each neighbor interface instead of the status of
      each neighbor.

   o  Neighbor discovery has been modified slightly to allow a node to
      restart (clear its neighbor table) without waiting for neighbors
      to expire their links to the node.

   o  A minimum time between HELLO messages is specified, to ensure that
      the HELLO sequence number does not wrap around to the same number
      within NBR_HOLD_TIME.

   o  A mechanism is described for limiting the propagation radius of
      topology information, by limiting the reportable node set to
      include only nodes that are within the desired radius.

   o  The Security Considerations section has been modified.

Thanks to those of you who have provided helpful comments.

Richard

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



From mailnull@www1.ietf.org  Wed Apr 16 07:36:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25938
	for ; Wed, 16 Apr 2003 07:36:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GBjXs12382
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 07:45:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GBjX812379
	for ; Wed, 16 Apr 2003 07:45:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25934
	for ; Wed, 16 Apr 2003 07:36:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195lFh-0000WW-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 07:38:57 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195lFh-0000WT-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 07:38:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GBTk810788;
	Wed, 16 Apr 2003 07:29:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GBNb810607
	for ; Wed, 16 Apr 2003 07:23:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25491
	for ; Wed, 16 Apr 2003 07:14:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195kuU-0000Pq-00
	for manet@ietf.org; Wed, 16 Apr 2003 07:17:02 -0400
Received: from web41805.mail.yahoo.com ([66.218.93.139])
	by ietf-mx with smtp (Exim 4.12)
	id 195kuU-0000PU-00
	for manet@ietf.org; Wed, 16 Apr 2003 07:17:02 -0400
Message-ID: <20030416111641.12622.qmail@web41805.mail.yahoo.com>
Received: from [193.95.32.166] by web41805.mail.yahoo.com via HTTP; Wed, 16 Apr 2003 13:16:41 CEST
Date: Wed, 16 Apr 2003 13:16:41 +0200 (CEST)
From: =?iso-8859-1?q?ines=20benbrahim?= 
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-124127094-1050491801=:11797"
Subject: [manet] about ZRP!!
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

--0-124127094-1050491801=:11797
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3GBTk810788
Content-Transfer-Encoding: quoted-printable

hiI need to know if packet have a TTL (number of hops or other) because t=
here are a situation when a destination has discovered but another nodes =
in the network continue to routing in their zones!thanks


---------------------------------
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais !
Testez le nouveau Yahoo! Mail
--0-124127094-1050491801=:11797
Content-Type: text/html; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3GBTk810788
Content-Transfer-Encoding: quoted-printable


hi


I need to know if packet have a TTL (number of hops or other) becaus=
e there are a situation when a destination has discovered but another nod=
es in the network continue to routing in their zones!


thanks

Do You Yahoo!? -- Une adresse @yahoo=
.fr gratuite et en fran=E7ais !

Testez le nouveau Yahoo! Mail
--0-124127094-1050491801=:11797--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr 16 08:41:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27643
	for ; Wed, 16 Apr 2003 08:41:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GCoaQ17009
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 08:50:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCoa817006
	for ; Wed, 16 Apr 2003 08:50:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27631
	for ; Wed, 16 Apr 2003 08:41:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195mGd-0000oI-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 08:43:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195mGd-0000oF-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 08:43:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCbm816043;
	Wed, 16 Apr 2003 08:37:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCV3814956
	for ; Wed, 16 Apr 2003 08:31:03 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27003;
	Wed, 16 Apr 2003 08:21:55 -0400 (EDT)
Message-Id: <200304161221.IAA27003@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: manet@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 16 Apr 2003 08:21:55 -0400
Subject: [manet] I-D ACTION:draft-ietf-manet-olsr-09.txt
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Optimized Link State Routing Protocol
	Author(s)	: T. Clausen, P. Jacquet
	Filename	: draft-ietf-manet-olsr-09.txt
	Pages		: 72
	Date		: 2003-4-15
	
This document describes the Optimized Link State Routing (OLSR)
protocol for mobile ad hoc networks.  The protocol is an optimization
of the classical link state algorithm tailored to the requirements of
a mobile wireless LAN.  The key concept used in the protocol is that
of multipoint relays (MPRs) [1], [2].  MPRs are selected nodes which
forward broadcast messages during the flooding process.  This
technique substantially reduces the message overhead as compared to a
classical flooding mechanism, where every node retransmits each
message when it receives the first copy of the message.  In OLSR,
link state information is generated only by nodes elected as MPRs.
Thus, a second optimization is achieved by minimizing the number of
control messages flooded in the network.  As a third optimization, an
MPR node may chose to report only links between itself and its MPR
selectors.  Hence, as contrary to the classic link state algorithm,
partial link state information is distributed in the network.  This
information is then used by for route calculation.  OLSR provides
optimal routes (in terms of number of hops).  The protocol is
particularly suitable for large and dense networks as the technique
of MPRs works well in this context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-olsr-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-olsr-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-16083707.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-manet-olsr-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-manet-olsr-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-16083707.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Wed Apr 16 09:16:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00089
	for ; Wed, 16 Apr 2003 09:16:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GDOfZ19863
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 09:24:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDOf819860
	for ; Wed, 16 Apr 2003 09:24:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00077
	for ; Wed, 16 Apr 2003 09:15:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195mnb-0001RT-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 09:18:03 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195mnb-0001RQ-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 09:18:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDAq819196;
	Wed, 16 Apr 2003 09:10:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GD5G818096
	for ; Wed, 16 Apr 2003 09:05:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28992
	for ; Wed, 16 Apr 2003 08:56:08 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195mUo-0001AR-00
	for manet@ietf.org; Wed, 16 Apr 2003 08:58:38 -0400
Received: from mx.laposte.net ([213.30.181.11])
	by ietf-mx with esmtp (Exim 4.12)
	id 195mUo-00019g-00
	for manet@ietf.org; Wed, 16 Apr 2003 08:58:38 -0400
Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053)
        id 3E97480E000C09C0 for manet@ietf.org; Wed, 16 Apr 2003 14:58:16 +0200
Date: Wed, 16 Apr 2003 14:58:16 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" 
To: "=?iso-8859-1?Q?manet?=" 
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 193.95.33.18
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GD5G818097
Subject: [manet] =?iso-8859-1?Q?metrics_in_ad_hoc_networks?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3GDAq819196
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GDOf819860
Content-Transfer-Encoding: 8bit

 hi every body ,

I am a student in computer engineering, I prepare my memory 
about routing protocols on ad hoc networks! I still search how 
can we compute the batterry life, the power consumption, the 
SNR signal noise ratio and how we can estimate the effective 
bandwith and delai betwen neigbors

can you help me by proposing me a topic what I can start with 
it in my research!!

thank you!

 
 

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



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



From mailnull@www1.ietf.org  Wed Apr 16 10:56:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04660
	for ; Wed, 16 Apr 2003 10:56:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GF55P27595
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 11:05:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GF55827592
	for ; Wed, 16 Apr 2003 11:05:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04653
	for ; Wed, 16 Apr 2003 10:55:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195oMj-000212-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 10:58:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195oMi-00020z-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 10:58:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEpj826810;
	Wed, 16 Apr 2003 10:51:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GElo826623
	for ; Wed, 16 Apr 2003 10:47:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03894
	for ; Wed, 16 Apr 2003 10:38:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195o63-0001tF-00
	for manet@ietf.org; Wed, 16 Apr 2003 10:41:11 -0400
Received: from f109.law11.hotmail.com ([64.4.17.109] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195o62-0001sl-00
	for manet@ietf.org; Wed, 16 Apr 2003 10:41:10 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 16 Apr 2003 07:40:49 -0700
Received: from 137.226.12.88 by lw11fd.law11.hotmail.msn.com with HTTP;
	Wed, 16 Apr 2003 14:40:49 GMT
X-Originating-IP: [137.226.12.88]
X-Originating-Email: [hemper81@hotmail.com]
From: "yrty ryrty" 
To: manet@ietf.org
Date: Wed, 16 Apr 2003 14:40:49 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 16 Apr 2003 14:40:49.0328 (UTC) FILETIME=[2C327B00:01C30426]
Subject: [manet] looking for a place to write my master thesis
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

hello dear researchers

, i have done my bachelor project about mobile ada hoc networks and now
i am
making master in RWTH aachen, i will like to do my thesis in amerika,
so can
you help me or give information about how to come and write my thesis
about
mobile communication...
actually i apreciate your studies so that is why i am writing this
email,
but it is aliitle bit open end so i will send this master thesis
research
place advertisements to all manet researchers. but please know that i
am
focused on communication networks not only on mobile ad hoc networks.

if you need an assitant or researc assistant, at least if you can offer
me a
possible master thesis under your supervision.it will be great.can you
please show me how to make master in Germany. if you can accept me as
under
your supervision it will be great, actually i will write my thesis 1
year
later but i just wanted to find a possible master thesis place, if you
have
any idea about it.that will be really great for me. at the moment i
finished
my bachelor in Bilkent university, Turkey and doing my master here in
germany aachen RWTH.so for 6 month to 1 year i am looking for a place
to
write my master thesis.i think i should send my cv at the moment, but i
can
not send my new transcript because i am at the beginning of the master
study. but you can have an overlook to my program by the site

http://www.rwth-aachen.de/zrs/v0001/english_ms_msegl_mediaegl.htm

and also my courses are in page:         http://mi.b-it-center.de/

and also under page :
http://137.226.138.70/rwth/all_en/subfields.asp?field=Media+Informatics+%28M%2ESc%2E%29&field_en=Media+Informatics+%28M%2ESc%2E%29&group=Master+of+Science+%28M%2ESc%2E%29


i am as young jedi, looking for possible home to do my master thesis,
any
one interested about helping me please write to muhtaroglu@yahoo.com
adress
which is my private email adress...

thanx in advance
sincerely
ilke muhtaroglu

ps: please do not hesitate about asking more information about me. any 
interested i can send my cv, trancipt, motivation letter and references

i can speak 3 languages:
english
german
turkish,
and have basic level in italien, france, spanish

i am open to every country...

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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



From mailnull@www1.ietf.org  Wed Apr 16 15:56:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14832
	for ; Wed, 16 Apr 2003 15:56:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GK5Aq18276
	for manet-archive@odin.ietf.org; Wed, 16 Apr 2003 16:05:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GK59818273
	for ; Wed, 16 Apr 2003 16:05:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14820
	for ; Wed, 16 Apr 2003 15:55:53 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195t31-0003Rz-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 15:58:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195t31-0003Rv-00
	for manet-web-archive@ietf.org; Wed, 16 Apr 2003 15:58:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GJob817464;
	Wed, 16 Apr 2003 15:50:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GJjp817273
	for ; Wed, 16 Apr 2003 15:45:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14003
	for ; Wed, 16 Apr 2003 15:36:34 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195skL-0003LO-00
	for manet@ietf.org; Wed, 16 Apr 2003 15:39:05 -0400
Received: from memphis.ece.cornell.edu ([128.84.81.8])
	by ietf-mx with esmtp (Exim 4.12)
	id 195skK-0003LK-00
	for manet@ietf.org; Wed, 16 Apr 2003 15:39:04 -0400
Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138])
	by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h3GJdDR15322;
	Wed, 16 Apr 2003 15:39:13 -0400
Date: Wed, 16 Apr 2003 15:34:18 -0400 (EDT)
From: Prince Samar 
To: =?iso-8859-1?q?ines=20benbrahim?= 
cc: manet@ietf.org
Subject: Re: [manet] about ZRP!!
In-Reply-To: <20030416111641.12622.qmail@web41805.mail.yahoo.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by memphis.ece.cornell.edu id h3GJdDR15322
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GJjp817274
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3GJob817464
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GK59818273
Content-Transfer-Encoding: 8bit


Hi Ines,

The proactive updates of a node have a time-to-live (TTL) which limit 
their broadcast to the scope of the node's routing zone.

When a route query is initiated, the query control mechanisms used 
by ZRP ensure that the query packets travel "outward," towards newer, 
unexplored regions of the network. Based on certain rules, a node marks 
its routing zone as "covered" for a particular query, which allows it to 
drop any later instance of the route query that it may encounter. 

Techniques like expanding ring search (which rely on TTL) can easily be 
used with ZRP to possibly reduce the routing overhead.

Hope this answers your question.

Regards,
Prince


On Wed, 16 Apr 2003, ines benbrahim wrote:

>hi
>I need to know if packet have a TTL (number of hops or other) because
>there are a situation when a destination has discovered but another nodes
>in the network continue to routing in their zones!thanks
>
>
>---------------------------------
>Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
>Testez le nouveau Yahoo! Mail





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



From mailnull@www1.ietf.org  Thu Apr 17 08:01:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18052
	for ; Thu, 17 Apr 2003 08:01:43 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HCAmD29574
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 08:10:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCAm829571
	for ; Thu, 17 Apr 2003 08:10:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18016
	for ; Thu, 17 Apr 2003 08:01:13 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19687B-0007FB-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 08:03:41 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19687B-0007F7-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 08:03:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBkS827440;
	Thu, 17 Apr 2003 07:46:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBZi826185
	for ; Thu, 17 Apr 2003 07:35:44 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15793;
	Thu, 17 Apr 2003 07:26:09 -0400 (EDT)
Message-Id: <200304171126.HAA15793@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: manet@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 17 Apr 2003 07:26:09 -0400
Subject: [manet] I-D ACTION:draft-ietf-manet-dsr-09.txt
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: The Dynamic Source Routing Protocol for Mobile Ad Hoc 
                          Networks (DSR)
	Author(s)	: D. Johnson et al.
	Filename	: draft-ietf-manet-dsr-09.txt
	Pages		: 111
	Date		: 2003-4-16
	
The Dynamic Source Routing protocol (DSR) is a simple and efficient
routing protocol designed specifically for use in multi-hop wireless
ad hoc networks of mobile nodes.  DSR allows the network to be
completely self-organizing and self-configuring, without the need
for any existing network infrastructure or administration.  The
protocol is composed of the two mechanisms of 'Route Discovery'
and 'Route Maintenance', which work together to allow nodes to
discover and maintain source routes to arbitrary destinations in the
ad hoc network.  The use of source routing allows packet routing
to be trivially loop-free, avoids the need for up-to-date routing
information in the intermediate nodes through which packets are
forwarded, and allows nodes forwarding or overhearing packets to
cache the routing information in them for their own future use.  All
aspects of the protocol operate entirely on-demand, allowing the
routing packet overhead of DSR to scale automatically to only that
needed to react to changes in the routes currently in use.  This
document specifies the operation of the DSR protocol for routing
unicast IP packets in multi-hop wireless ad hoc networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-dsr-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-dsr-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-16135644.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-manet-dsr-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-manet-dsr-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-16135644.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Thu Apr 17 08:37:50 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19264
	for ; Thu, 17 Apr 2003 08:37:50 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HCkum31997
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 08:46:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCku831994
	for ; Thu, 17 Apr 2003 08:46:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19260
	for ; Thu, 17 Apr 2003 08:37:19 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968g8-0007aP-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 08:39:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968g8-0007aM-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 08:39:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCV8830425;
	Thu, 17 Apr 2003 08:31:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCRA830277
	for ; Thu, 17 Apr 2003 08:27:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18811
	for ; Thu, 17 Apr 2003 08:17:34 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968N1-0007TT-00
	for manet@ietf.org; Thu, 17 Apr 2003 08:20:03 -0400
Received: from f115.law11.hotmail.com ([64.4.17.115] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968N1-0007TC-00
	for manet@ietf.org; Thu, 17 Apr 2003 08:20:03 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 17 Apr 2003 05:19:43 -0700
Received: from 137.226.12.91 by lw11fd.law11.hotmail.msn.com with HTTP;
	Thu, 17 Apr 2003 12:19:43 GMT
X-Originating-IP: [137.226.12.91]
X-Originating-Email: [hemper81@hotmail.com]
From: "yrty ryrty" 
To: manet@ietf.org
Subject:    [manet] searching place to write my master thesis
Date: Thu, 17 Apr 2003 12:19:43 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 17 Apr 2003 12:19:43.0962 (UTC) FILETIME=[A0DBE3A0:01C304DB]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	








>From: "yrty ryrty" 
>To: manet@ietf.org
>Subject: [manet] looking for a place to write my master thesis
>Date: Wed, 16 Apr 2003 14:40:49 +0000
>
>hello dear researchers
>
>, i have done my bachelor project about mobile ada hoc networks and now
>i am
>making master in RWTH aachen, i will like to do my thesis in amerika,
>so can
>you help me or give information about how to come and write my thesis
>about
>mobile communication...
>actually i apreciate your studies so that is why i am writing this
>email,
>but it is aliitle bit open end so i will send this master thesis
>research
>place advertisements to all manet researchers. but please know that i
>am
>focused on communication networks not only on mobile ad hoc networks.
>
>if you need an assitant or researc assistant, at least if you can offer
>me a
>possible master thesis under your supervision.it will be great.can you
>please show me how to make master in Germany. if you can accept me as
>under
>your supervision it will be great, actually i will write my thesis 1
>year
>later but i just wanted to find a possible master thesis place, if you
>have
>any idea about it.that will be really great for me. at the moment i
>finished
>my bachelor in Bilkent university, Turkey and doing my master here in
>germany aachen RWTH.so for 6 month to 1 year i am looking for a place
>to
>write my master thesis.i think i should send my cv at the moment, but i
>can
>not send my new transcript because i am at the beginning of the master
>study. but you can have an overlook to my program by the site
>
>http://www.rwth-aachen.de/zrs/v0001/english_ms_msegl_mediaegl.htm
>
>and also my courses are in page:         http://mi.b-it-center.de/
>
>and also under page :
>http://137.226.138.70/rwth/all_en/subfields.asp?field=Media+Informatics+%28M%2ESc%2E%29&field_en=Media+Informatics+%28M%2ESc%2E%29&group=Master+of+Science+%28M%2ESc%2E%29
>
>
>i am as young jedi, looking for possible home to do my master thesis,
>any
>one interested about helping me please write to muhtaroglu@yahoo.com
>adress
>which is my private email adress...
>
>thanx in advance
>sincerely
>ilke muhtaroglu
>
>ps: please do not hesitate about asking more information about me. any 
>interested i can send my cv, trancipt, motivation letter and references
>
>i can speak 3 languages:
>english
>german
>turkish,
>and have basic level in italien, france, spanish
>
>i am open to every country...
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*  
>http://join.msn.com/?page=features/junkmail
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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



From mailnull@www1.ietf.org  Thu Apr 17 09:47:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20970
	for ; Thu, 17 Apr 2003 09:47:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HDurp04474
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 09:56:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HDuq804471
	for ; Thu, 17 Apr 2003 09:56:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20942
	for ; Thu, 17 Apr 2003 09:47:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1969ll-00009X-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 09:49:41 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1969ll-00009U-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 09:49:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HDZZ802308;
	Thu, 17 Apr 2003 09:35:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HDV8802139
	for ; Thu, 17 Apr 2003 09:31:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20159
	for ; Thu, 17 Apr 2003 09:21:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1969Ms-0007lB-00
	for manet@ietf.org; Thu, 17 Apr 2003 09:23:58 -0400
Received: from aragorn.bbn.com ([128.33.0.62])
	by ietf-mx with esmtp (Exim 4.12)
	id 1969Ms-0007kX-00
	for manet@ietf.org; Thu, 17 Apr 2003 09:23:58 -0400
Received: from 78-RC321.bbn.com (tc238-232.bbn.com [128.33.238.232])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HDMr5w029499;
	Thu, 17 Apr 2003 09:22:54 -0400 (EDT)
Message-Id: <5.1.0.14.2.20030417091423.027e74f0@po2.bbn.com>
X-Sender: celliott@po2.bbn.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Apr 2003 09:19:40 -0400
To: Mobile Ad-hoc Networks  
From: Chip Elliott 
Cc: Chip Elliott 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HDV9802140
Subject: [manet] First Use of Military Ad Hoc Networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3HDZZ802308
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HDuq804471
Content-Transfer-Encoding: 8bit


Fellow MANET folk:

I believe the following article reports the first battlefield
use of military ad hoc networks, which took place in the
past day or two. The article concentrates on the computer
screen but the communications is actually
carried by mobile, ad hoc networks.

-- Chip



Battlefield Internet Helps Forces in Iraq
Thu Apr 17, 2:16 AM ET

By DAVID RISING, Associated Press Writer

NORTH OF BAGHDAD, Iraq - A computer system that tracks friendly and enemy 
forces and pinpoints hazards like minefields on video game-like touch 
screens got its first use in battle. Commanders are hoping it can cut down 
on friendly fire deaths.

The Army's 4th Infantry Division is guided by a sophisticated computer 
network that tracked the division's 1st Brigade during a skirmish Wednesday 
for the Taji air base north of Baghdad.

The computer network is known as Force 21 Battle Command Brigade and Below, 
and works as a battlefield Internet that keeps track of fast-moving combat 
vehicles.

The system's global positioning satellite navigation system also warns 
whenever a vehicle strays from its planned path.

Proponents say such systems could prevent tragedies like the March 23 
ambush deaths of nine soldiers from the 507th Maintenance Company after 
their convoy took a wrong turn in southern Iraq (news - web sites).

The network "provides a level of situational awareness that is second to 
none," said 1st Brigade commander Col. Don Campbell.

Campbell and his staff used the battlefield networking system Wednesday to 
direct his troops — represented by blue icons — toward the positions of 
"red" Iraqi paramilitaries identified by spotters in helicopters.

Soldiers of 1st Brigade took control of the Taji base, killing four 
combatants and taking at least two dozen prisoners. There were no American 
casualties.

Using the system to pinpoint exact vehicle positions also can prevent 
friendly fire deaths.

On the system's networked screens, blue icons denote friendly forces and 
are constantly updated. Red icons show the enemy, which are added as 
they're spotted. The 4th Infantry also has unmanned aircraft that can 
handle surveillance tasks.

Hazards like minefields, areas where poison gas has been reported or other 
pitfalls can be added so units can steer clear.

By touching a screen icon, anyone from a commander in the rear to a tank 
crewman can get specific data about a vehicle — what it is, how fast it is 
moving and in which direction. If a vehicle is captured, the system has a 
self-destruct mechanism that can be triggered remotely.

Another touch allows soldiers to send text messages between vehicles or 
back to the command post, cutting down on radio chatter.

Maj. Mike Silverman, operations officer for the 1st Brigade, said that 
saves time to use voice communications for more detailed reports.

For Chief Warrant Officer II John Hanks, a maintenance technician for the 
4th Battalion, 42nd Field Artillery, the text messaging means troops can 
send quick assessments of problems without miscommunication through radio 
garble.

"The faster the vehicles can get to me saying, `We need a part,' the faster 
I can come up with it and get them back into the fight," Hanks said.

Developed by Los Angeles-based Northrop Grumman, the computers were first 
fielded in 1995, said Mike Iacobacci, a Northrop technician traveling with 
the 1st Brigade.

The FBCB2 system transmits by bouncing data from vehicle to vehicle until 
it hits the brigade or division command centers. This "mesh network" lets 
the 4th Infantry update its positions faster than the rest of the Army, 
which must cope with the five-minute delay inherent in its satellite 
communications systems.

Younger soldiers, many of them raised on video games, quickly learn how to 
use the system, Iacobacci said.

"Some of these kids grew up on Nintendo (news - web sites) and Play 
Stations, so once they get on it's easy," he said.

The 4th is considered the Army's most lethal heavy division, boasting the 
latest tanks, troop carriers and Apache attack helicopters. But it missed 
out on nearly all the fighting in Iraq after Turkey refused to let the 
United States use that country as a staging ground.

Wednesday's skirmish was the first combat the division has seen since the 
Vietnam War. 

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



From mailnull@www1.ietf.org  Thu Apr 17 11:48:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25862
	for ; Thu, 17 Apr 2003 11:48:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HFvJ713767
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 11:57:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HFvJ813764
	for ; Thu, 17 Apr 2003 11:57:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25841
	for ; Thu, 17 Apr 2003 11:47:38 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196BeI-0000oX-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 11:50:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196BeH-0000oU-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 11:50:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HFOO811125;
	Thu, 17 Apr 2003 11:24:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HFK4810976
	for ; Thu, 17 Apr 2003 11:20:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24823
	for ; Thu, 17 Apr 2003 11:10:23 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196B4F-0000b0-00
	for manet@ietf.org; Thu, 17 Apr 2003 11:12:51 -0400
Received: from mx.laposte.net ([213.30.181.11])
	by ietf-mx with esmtp (Exim 4.12)
	id 196B4F-0000an-00
	for manet@ietf.org; Thu, 17 Apr 2003 11:12:51 -0400
Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053)
        id 3E975199000F975A for manet@ietf.org; Thu, 17 Apr 2003 17:12:33 +0200
Date: Thu, 17 Apr 2003 17:12:33 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" 
To: "=?iso-8859-1?Q?manet?=" 
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 193.95.33.18
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HFK4810977
Subject: [manet] =?iso-8859-1?Q?monotoring_of_ad_hoc?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3HFOO811125
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HFvJ813764
Content-Transfer-Encoding: 8bit

hi every body ,

I am a student in computer engineering, I prepare my memory 
about implementation of a monotoring tool for ad hoc networks! 
I still search how can we compute the batterry life, the power 
consumption, the SNR signal noise ratio and how we can 
estimate the effective bandwith and delai betwen neigbors.

if anyone know any information about this topic, please send 
me 
thank you

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



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



From mailnull@www1.ietf.org  Thu Apr 17 12:51:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28213
	for ; Thu, 17 Apr 2003 12:51:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HH0Z020906
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 13:00:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HH0Z820903
	for ; Thu, 17 Apr 2003 13:00:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28184
	for ; Thu, 17 Apr 2003 12:50:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CdU-0001Gw-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 12:53:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CdT-0001Gt-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 12:53:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HGdG817925;
	Thu, 17 Apr 2003 12:39:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HGY3816855
	for ; Thu, 17 Apr 2003 12:34:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27323
	for ; Thu, 17 Apr 2003 12:24:21 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CDp-000157-00
	for manet@ietf.org; Thu, 17 Apr 2003 12:26:49 -0400
Received: from 66-152-29-4.ded.btitelecom.net ([66.152.29.4] helo=mail.scires.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CDp-00014y-00
	for manet@ietf.org; Thu, 17 Apr 2003 12:26:49 -0400
Received: from SRCATL-MTA by mail.scires.com
	with Novell_GroupWise; Thu, 17 Apr 2003 12:27:23 -0400
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta
Date: Thu, 17 Apr 2003 12:27:12 -0400
From: "Pete Sholander" 
To: 
Cc: 
Subject: Re: [manet] monotoring of ad hoc
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HGY3816856
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3HGdG817925
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HH0Z820903
Content-Transfer-Encoding: 8bit

On Red Hat Linux, some *simplistic* approaches are:

a) Battery and Power consumption: use the info from /proc/apm
b) Bandwidth: count bytes using Traffic Control
c) SNR/BER: estimate it from the Hello Packet loss rate or get it from
the NIC
d) Delay: ping works ;-)  The other technique is something like NRL's
mgen which time-stamps test traffic.

Hope this helps.  Finally, you might summarize back to the list the
various suggestions and tools that you get/find.

>>> "ghannay.sana@laposte.net"  04/17/03
11:12AM >>>
hi every body ,

I am a student in computer engineering, I prepare my memory 
about implementation of a monotoring tool for ad hoc networks! 
I still search how can we compute the batterry life, the power 
consumption, the SNR signal noise ratio and how we can 
estimate the effective bandwith and delai betwen neigbors.

if anyone know any information about this topic, please send 
me 
thank you

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



_______________________________________________
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 mailnull@www1.ietf.org  Thu Apr 17 12:52:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28255
	for ; Thu, 17 Apr 2003 12:52:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HH1EK20978
	for manet-archive@odin.ietf.org; Thu, 17 Apr 2003 13:01:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HH1E820975
	for ; Thu, 17 Apr 2003 13:01:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28236
	for ; Thu, 17 Apr 2003 12:51:33 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Ce7-0001HQ-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 12:53:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Ce7-0001HN-00
	for manet-web-archive@ietf.org; Thu, 17 Apr 2003 12:53:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HGmW820171;
	Thu, 17 Apr 2003 12:48:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HGiQ819106
	for ; Thu, 17 Apr 2003 12:44:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27666
	for ; Thu, 17 Apr 2003 12:34:45 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CNr-000191-00
	for manet@ietf.org; Thu, 17 Apr 2003 12:37:11 -0400
Received: from f69.pav1.hotmail.com ([64.4.31.69] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196CNr-00018o-00
	for manet@ietf.org; Thu, 17 Apr 2003 12:37:11 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 17 Apr 2003 09:36:54 -0700
Received: from 129.215.102.74 by pv1fd.pav1.hotmail.msn.com with HTTP;
	Thu, 17 Apr 2003 16:36:53 GMT
X-Originating-IP: [129.215.102.74]
X-Originating-Email: [edtyy@hotmail.com]
From: "Edwin Tan" 
To: manet@ietf.org
Date: Fri, 18 Apr 2003 00:36:53 +0800
Mime-Version: 1.0
Content-Type: text/html
Message-ID: 
X-OriginalArrivalTime: 17 Apr 2003 16:36:54.0734 (UTC) FILETIME=[8E50D6E0:01C304FF]
Subject: [manet] Organisation of multi-functional nodes in ad hoc sensor network
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	




Dear all,


 


Has anyone worked on ad hoc sensor network with multi-functional nodes in it?  I would like to know any papers or books that I can read about mainly on the architecture and organisation of them within the network .


 


Thank You
Edwin







Get free gift vouchers every week with MSN Premium Vouchers
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sat Apr 19 08:04:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23723
	for ; Sat, 19 Apr 2003 08:04:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3JCEfM08287
	for manet-archive@odin.ietf.org; Sat, 19 Apr 2003 08:14:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JCEf808284
	for ; Sat, 19 Apr 2003 08:14:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23715
	for ; Sat, 19 Apr 2003 08:04:08 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196r71-0004IH-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 08:06:31 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196r71-0004ID-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 08:06:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JBYF805665;
	Sat, 19 Apr 2003 07:34:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JBLQ805380
	for ; Sat, 19 Apr 2003 07:21:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23156
	for ; Sat, 19 Apr 2003 07:10:52 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196qHW-0004AR-00
	for manet@ietf.org; Sat, 19 Apr 2003 07:13:18 -0400
Received: from mx.laposte.net ([213.30.181.11])
	by ietf-mx with esmtp (Exim 4.12)
	id 196qHV-0004AK-00
	for manet@ietf.org; Sat, 19 Apr 2003 07:13:17 -0400
Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053)
        id 3E9750F30014D0EB for manet@ietf.org; Sat, 19 Apr 2003 13:13:04 +0200
Date: Sat, 19 Apr 2003 13:13:04 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" 
To: "=?iso-8859-1?Q?manet?=" 
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 193.95.33.18
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3JBLQ805381
Subject: [manet] =?iso-8859-1?Q?transmit_power_of_802.11_wireless_card_?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3JBYF805665
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3JCEf808284
Content-Transfer-Encoding: 8bit

Hi all!

Does anybody know how to compute or to know or to extract the 
transmit power of a wireless card because I need this value in 
my program

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



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



From mailnull@www1.ietf.org  Sat Apr 19 11:24:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27286
	for ; Sat, 19 Apr 2003 11:24:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3JFYn618072
	for manet-archive@odin.ietf.org; Sat, 19 Apr 2003 11:34:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JFYn818069
	for ; Sat, 19 Apr 2003 11:34:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27283
	for ; Sat, 19 Apr 2003 11:24:10 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196uEd-0004ma-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 11:26:35 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196uEc-0004mX-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 11:26:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JFIb817498;
	Sat, 19 Apr 2003 11:18:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JF6o816423
	for ; Sat, 19 Apr 2003 11:06:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26852
	for ; Sat, 19 Apr 2003 10:56:12 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196tnZ-0004h9-00
	for manet@ietf.org; Sat, 19 Apr 2003 10:58:37 -0400
Received: from liman.rutgers.edu ([128.6.110.6] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 196tnY-0004h6-00
	for manet@ietf.org; Sat, 19 Apr 2003 10:58:37 -0400
Received: from liman2a (winlaba3.rutgers.edu [165.230.120.71])
	by liman.rutgers.edu (8.12.9/8.12.2) with ESMTP id h3JEwruv015396;
	Sat, 19 Apr 2003 10:58:54 -0400 (EDT)
Date: Sat, 19 Apr 2003 11:02:10 -0400 (EDT)
From: Sachin Ganu 
X-X-Sender: sachin@liman2a
To: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" 
cc: =?iso-8859-1?Q?manet?= 
Subject: Re: [manet] =?iso-8859-1?Q?transmit_power_of_802.11_wireless_card_?=
In-Reply-To: 
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h3JF6o816424
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3JFIb817498
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3JFYn818069
Content-Transfer-Encoding: 8bit

Hi Ghannay

That depends on which card you are using. At the driver level, there are
different ways to do it. For Cisco aironet cards, you could get it
from the ConfigRid structure. For Prism2 cards you could get it using
the call prism2_get_stats (older versions of the driver)

You could also use the iwconfig utility for Prism 2 based cards where as
for Cisco cards you can set it using
echo "XmitPower: "value" > /proc/drivers/aironet/"interface"/Config


HTH
Sachin
-----------------------------------------------------------
Sachin Ganu Graduate Research Assistant
WINLAB, Rutgers University
73 Brett Rd, Piscataway NJ 08854

On Sat, 19 Apr 2003, [iso-8859-1] ghannay.sana@laposte.net wrote:

> tatus: O
> X-Status:
> X-Keywords:
> X-UID: 7724
>
> Hi all!
>
> Does anybody know how to compute or to know or to extract the
> transmit power of a wireless card because I need this value in
> my program
>
> Accédez au courrier électronique de La Poste : www.laposte.net ;
> 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
>
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Sat Apr 19 23:30:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15603
	for ; Sat, 19 Apr 2003 23:30:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3K3f7m23683
	for manet-archive@odin.ietf.org; Sat, 19 Apr 2003 23:41:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3K3f6823680
	for ; Sat, 19 Apr 2003 23:41:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15592
	for ; Sat, 19 Apr 2003 23:30:13 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1975ZF-0000lM-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 23:32:37 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1975ZF-0000lJ-00
	for manet-web-archive@ietf.org; Sat, 19 Apr 2003 23:32:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3K3Eq822031;
	Sat, 19 Apr 2003 23:14:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3K32N821006
	for ; Sat, 19 Apr 2003 23:02:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14924
	for ; Sat, 19 Apr 2003 22:51:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1974xn-0000dY-00
	for manet@ietf.org; Sat, 19 Apr 2003 22:53:55 -0400
Received: from ms01.net.ie.niigata-u.ac.jp ([133.35.156.1] ident=postfix)
	by ietf-mx with esmtp (Exim 4.12)
	id 1974xn-0000dV-00
	for manet@ietf.org; Sat, 19 Apr 2003 22:53:55 -0400
Received: from ibm-jxnz3moc7yy.ie.niigata-u.ac.jp (rus169.ce.ie.niigata-u.ac.jp [133.35.163.169])
	by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id E55A911E75
	for ; Sun, 20 Apr 2003 11:54:06 +0900 (JST)
Message-Id: <4.3.2-J.20030420112057.00e09030@133.35.156.1>
X-Sender: mase@133.35.156.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Sun, 20 Apr 2003 11:54:05 +0900
To: manet@ietf.org
From: mase 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [manet] Topology update message ofTBRPF
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Hi all,

I have two questions in the topology update message ofTBRPF.
(1) Section 8.2 says that the next NRNL of the v_k are "non-reported leaf 
nodes", and the last n-(NRL+NRNL) of the v_k are "non-reported non-leaf 
nodes". This should be that the the next NRNL of the v_k are "reported 
non-leaf nodes", and the last n-(NRL+NRNL) of the v_k are "non-reported 
nodes" (not in RN in 8.4.5).
(2) If the last n-(NRL+NRNL) of the v_k are not in RN, the link (u, v_k) 
does not belong to RT, because RT consists of links (u,v) of T such that u 
is in RN. This seems to contradict to the definition of FULL, wihich says 
that a FULL update reports that the link (u, v_1),...(u, v_n) belong to the 
sending router's RT, and RT contains no other links with tail u.

Maybe my understanding is not enough. I appreciate your clarification.

Kenichi


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



From mailnull@www1.ietf.org  Mon Apr 21 07:41:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10133
	for ; Mon, 21 Apr 2003 07:41:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LBqOD23153
	for manet-archive@odin.ietf.org; Mon, 21 Apr 2003 07:52:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBqO823150
	for ; Mon, 21 Apr 2003 07:52:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10074
	for ; Mon, 21 Apr 2003 07:40:51 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zha-0006tg-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 07:43:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zha-0006tc-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 07:43:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBdD822674;
	Mon, 21 Apr 2003 07:39:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBK2821437
	for ; Mon, 21 Apr 2003 07:20:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09393
	for ; Mon, 21 Apr 2003 07:08:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZCH-0006oh-00
	for manet@ietf.org; Mon, 21 Apr 2003 07:10:53 -0400
Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZCH-0006od-00
	for manet@ietf.org; Mon, 21 Apr 2003 07:10:53 -0400
Received: from kenny.ee.surrey.ac.uk ([131.227.74.2] ident=exim)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 197ZCT-0003Wf-00
	for manet@ietf.org; Mon, 21 Apr 2003 12:11:05 +0100
Received: from eem1tk (helo=localhost)
	by kenny.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5)
	id 197ZCR-0004QC-00
	for manet@ietf.org; Mon, 21 Apr 2003 12:11:03 +0100
Date: Mon, 21 Apr 2003 12:11:03 +0100 (BST)
From: Teng Kang 
X-X-Sender: eem1tk@kenny.ee.surrey.ac.uk
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Status: No, hits=-110.8 required=5.5
	tests=AWL,BAYES_00,USER_AGENT_PINE,USER_IN_WHITELIST
	autolearn=ham	version=2.50
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Scanner: exiscan *197ZCT-0003Wf-00*kk/Rp/Un9j.* (SECM, UniS)
Subject: [manet] Implementation of PCF under Glomosim
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Dear all:
My current work is about the implementation PCF under Glomosim. I just
want to know is there any one has done this work before, if yes, would you
give me some advices

Btw how can I find the code of PCF implementation.
Many thanks in advance!

Cheers

kang Teng

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



From mailnull@www1.ietf.org  Mon Apr 21 13:23:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22998
	for ; Mon, 21 Apr 2003 13:23:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LHYQm13434
	for manet-archive@odin.ietf.org; Mon, 21 Apr 2003 13:34:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHYP813431
	for ; Mon, 21 Apr 2003 13:34:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22917
	for ; Mon, 21 Apr 2003 13:22:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197f2S-0001ha-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 13:25:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197f2S-0001hW-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 13:25:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHJr812954;
	Mon, 21 Apr 2003 13:19:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHBu812729
	for ; Mon, 21 Apr 2003 13:11:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22349
	for ; Mon, 21 Apr 2003 13:00:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197egi-0001Yc-00
	for manet@ietf.org; Mon, 21 Apr 2003 13:02:40 -0400
Received: from mx2.isti.cnr.it ([146.48.126.38])
	by ietf-mx with esmtp (Exim 4.12)
	id 197egh-0001YY-00
	for manet@ietf.org; Mon, 21 Apr 2003 13:02:39 -0400
Received: from CONVERSION.MAIL.IAT.CNR.IT by mx.isti.cnr.it (PMDF V6.2 #30641)
 id <01KV0084IZB49LVC7A@mx.isti.cnr.it> for manet@ietf.org; Mon,
 21 Apr 2003 19:01:45 +0200
Received: from iit.cnr.it (nas10.iit.cnr.it [146.48.124.90])
 by mx.isti.cnr.it (PMDF V6.2 #30641)
 with ESMTP id <01KV0081G3G69KM2RC@mx.isti.cnr.it> for manet@ietf.org; Mon,
 21 Apr 2003 19:01:43 +0200
Date: Mon, 21 Apr 2003 19:01:55 +0200
From: Raffaele Bruno 
To: manet 
Message-id: <3EA42403.60309@iit.cnr.it>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_69Pb7460NTr45sQdyqJlYQ)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
Subject: [manet] PWC2003: CALL FOR PROJECTS' PRESENTATIONS
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


--Boundary_(ID_69Pb7460NTr45sQdyqJlYQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


[Our apologies if you receive multiple copies of this message]


CALL FOR PROJECTS' PRESENTATIONS

PWC 2003

The Eight International Conference on Personal Wireless Communications 
Sponsored
by the IFIP WG 6.8 - Mobile and Wireless Communications
http://www.iit.cnr.it/pwc2003/project-call.html

September 23-25, 2003 Telecom Italia Future Centre - Venice, Italy
http://www.futurecentre.telecomitalia.it/eng/


PWC is the premier international forum for discussions between researchers,
practitioners and students interested in the symbiosis of mobile 
computing and
wireless networks. PWC 2003 is the eight conference of this series and is
sponsored by IFIP WG 6.8


The PWC 2003 technical program committee is soliciting extended abstracts
presenting on-going research projects on wireless and mobile communications.
Areas of interest include those that are listed on the conference call for
papers, which can be found at http://www.iit.cnr.it/pwc2003
We are looking for projects performed either at a single-country level or
involving several countries (e.g., European Commission projects)

WHY should you submit a project presentation?
---------------------------------------------
This is a great chance for disseminating the results of your project to 
a wide
audience. Dissemination is the previous activity to exploitation, and 
could be
considered as the market strategy to create awareness around your project.


WHAT you have to do NOW
-----------------------
You must submit an extended abstract presenting your project. An extended
abstract (maximum 1500 words) must clearly describe the scope of the 
project, the innovative ideas behind it, partners involved, etc. In 
addition, if appropriate, please shortly present results already 
achieved. Extended abstracts will be reviewed  for novelty, timeliness, 
and relevance for this conference.

Submissions should be sent by email to pwc2003@iit.cnr.it by April 27, 
2003. Please use the following subject: "pwc2003 project presentation".


WHAT you have to do if the submission is accepted
-------------------------------------------------
Authors of accepted submissions will prepare a camera-ready version of 
the extended
abstract to be published in the conference proceedings published by
Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series
http://www.springer.de/comp/lncs/index.html

In addition, you have to prepare a poster presenting your project and
attend the PWC2003 poster session to present your poster.

A poster is a 1 meter x 1.25 meter rectangular board on which you can affix
visually appealing material that describes your research. How you use 
this is up
to you: you may choose to print out several 8.5"x11" or A4 sheets of 
paper (e.g., paper copies of overheads) and "tile" the poster board with 
these pages. Or, you may choose to print a single large sheet of paper 
describing the work and attach that to the poster board. Several 
document companies produce professional-looking posters from material 
produced on software like Powerpoint; you may want to use such a facility.


IMPORTANT DATES
===============

Project presentation proposal due: April 27, 2003

Notification:   May 15, 2003

Camera Ready due: June 10, 2003

--Boundary_(ID_69Pb7460NTr45sQdyqJlYQ)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  



PWC2003: CALL FOR PROJECTS' PRESENTATIONS
  

[Our apologies if you receive multiple copies of this
message]

 





 





 

CALL FOR PROJECTS' PRESENTATIONS

 





 

PWC 2003

 





 

The Eight International Conference on Personal Wireless
Communications Sponsored

 

by the IFIP WG 6.8 - Mobile and Wireless Communications

 

 





 

September 23-25, 2003 Telecom Italia Future Centre -
Venice, Italy

 

 





 





 

PWC is the premier international forum for discussions between researchers,

 

practitioners and students interested in the symbiosis of mobile computing
and

 

wireless networks. PWC 2003 is the eight conference of this series and
is

 

sponsored by IFIP WG 6.8

 





 





 

The PWC 2003 technical program committee is soliciting extended abstracts

 

presenting on-going research projects on wireless and mobile communications.

 

Areas of interest include those that are listed on the conference call
for

 

papers, which can be found at http://www.iit.cnr.it/pwc2003

 

We are looking for projects performed either at a single-country level
or

 

involving several countries (e.g., European Commission projects)

 





 

WHY should you submit a project presentation?

 

---------------------------------------------

 

This is a great chance for disseminating the results of your project
to a wide

 

audience. Dissemination is the previous activity to exploitation, and
could be

 

considered as the market strategy to create awareness around your project.

 





 





 

WHAT you have to do NOW

 

-----------------------

 

You must submit an extended abstract presenting your project. An extended

 

abstract (maximum 1500 words) must clearly describe the scope of the
project, the innovative ideas behind it, partners involved, etc. In addition,
if appropriate, please shortly present results already achieved. Extended
abstracts will be reviewed  for novelty, timeliness, and relevance for this
conference.

 





 

Submissions should be sent by email to pwc2003@iit.cnr.it by April 27,
2003. Please use the following subject: "pwc2003 project presentation".

 





 





 

WHAT you have to do if the submission is accepted

 

-------------------------------------------------

 

Authors of accepted submissions will prepare a camera-ready version
of the extended

 

abstract to be published in the conference proceedings published by

 

Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series

 

 





 

In addition, you have to prepare a poster presenting your project and

 

attend the PWC2003 poster session to present your poster.

 





 

A poster is a 1 meter x 1.25 meter rectangular board on which you can
affix

 

visually appealing material that describes your research. How you use
this is up

 

to you: you may choose to print out several 8.5"x11" or A4 sheets of
paper (e.g., paper copies of overheads) and "tile" the poster board with
these pages. Or, you may choose to print a single large sheet of paper describing
the work and attach that to the poster board. Several document companies
produce professional-looking posters from material produced on software like
Powerpoint; you may want to use such a facility.

 





 





 

IMPORTANT DATES

 

===============

 





 

Project presentation proposal due: April 27, 2003

 





 

Notification:   May 15, 2003

 





 

Camera Ready due: June 10, 2003

 



--Boundary_(ID_69Pb7460NTr45sQdyqJlYQ)--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 21 13:29:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23359
	for ; Mon, 21 Apr 2003 13:29:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LHehi14828
	for manet-archive@odin.ietf.org; Mon, 21 Apr 2003 13:40:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHeh814825
	for ; Mon, 21 Apr 2003 13:40:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23267
	for ; Mon, 21 Apr 2003 13:29:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197f8X-0001nI-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 13:31:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197f8X-0001nF-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 13:31:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHQM813162;
	Mon, 21 Apr 2003 13:26:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LHBv812733
	for ; Mon, 21 Apr 2003 13:11:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22352
	for ; Mon, 21 Apr 2003 13:00:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197egi-0001Yh-00
	for manet@ietf.org; Mon, 21 Apr 2003 13:02:40 -0400
Received: from mx2.isti.cnr.it ([146.48.126.38])
	by ietf-mx with esmtp (Exim 4.12)
	id 197egh-0001YY-01
	for manet@ietf.org; Mon, 21 Apr 2003 13:02:40 -0400
Received: from CONVERSION.MAIL.IAT.CNR.IT by mx.isti.cnr.it (PMDF V6.2 #30641)
 id <01KV008KG46O9LVC7A@mx.isti.cnr.it> for manet@ietf.org; Mon,
 21 Apr 2003 19:02:06 +0200
Received: from iit.cnr.it (nas10.iit.cnr.it [146.48.124.90])
 by mx.isti.cnr.it (PMDF V6.2 #30641)
 with ESMTP id <01KV008FSZ0I9KM2RC@mx.isti.cnr.it> for manet@ietf.org; Mon,
 21 Apr 2003 19:02:06 +0200
Date: Mon, 21 Apr 2003 19:02:15 +0200
From: Raffaele Bruno 
To: manet 
Message-id: <3EA42417.2040506@iit.cnr.it>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_da/RhIkTNZr5YEiFXeVhzA)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1)
 Gecko/20020823 Netscape/7.0
Subject: [manet] PWC2003: CALL FOR NEW IDEAS and EARLY RESULTS
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


--Boundary_(ID_da/RhIkTNZr5YEiFXeVhzA)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


[Our sincere apologies if you receive multiple copies of this CFP]


CALL FOR NEW IDEAS and EARLY RESULTS

PWC 2003

The Eight International Conference on Personal Wireless Communications 
Sponsored
by the IFIP WG 6.8 - Mobile and Wireless Communications
http://www.iit.cnr.it/pwc2003/early-call.html

September 23-25, 2003 Telecom Italia Future Centre - Venice, Italy
http://www.futurecentre.telecomitalia.it/eng/


PWC is the premier international forum for discussions between researchers,
practitioners and students interested in the symbiosis of mobile 
computing and
wireless networks. PWC 2003 is the eight conference of this series and is
sponsored by IFIP WG 6.8


The PWC 2003 technical program committee is soliciting short papers on 
wireless and mobile communications that bring out interesting and novel 
ideas at an early stage in their development. The goals are to allow 
timely presentation and publication of these ideas. Short papers don't 
need to describe
completed work, but the work should be advanced beyond the initial stages.


Areas of interest include those that are listed on the conference call for
papers, which can be found at http://www.iit.cnr.it/pwc2003


WHY should you submit a short paper?
------------------------------------
This is a great chance for disseminating early results of your research 
to a wide and competent audience. This will help to create awareness 
around your ideas, will give you relevant feedbacks and open some 
discussions in your research direction.


WHAT you have to do NOW
-----------------------
You must submit a short paper presenting your ideas. A short paper
(maximum 2000 words) must clearly describe the subject of your research, the
innovative ideas behind it, the results already achieved, and your 
further work. Proposals submissions will be reviewed for novelty and 
timeliness, relevance,  technical correctness, and accuracy.

Submissions should be sent by email to  by April 27, 
2003. Please use the following subject: "pwc2003 short-paper proposal".


WHAT you have to do if the proposal is accepted
-----------------------------------------------
Authors of accepted proposal will prepare a camera-ready version of the 
short paper to be published in the conference proceedings published by
Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series
http://www.springer.de/comp/lncs/index.html

In addition, youmust attend the conference to present your paper at the 
conference. 15 minutes will be assigned for each short-paper presentation.



IMPORTANT DATES
===============

Novel Idea proposal due: April 27, 2003

Notification:   May 15, 2003

Camera Ready due: June 10, 2003


--Boundary_(ID_da/RhIkTNZr5YEiFXeVhzA)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  



PWC2003: CALL FOR NEW IDEAS and EARLY RESULTS
  

[Our sincere apologies if you receive multiple copies of this CFP]

 





 





 

CALL FOR NEW IDEAS and EARLY RESULTS

 





 

PWC 2003

 





 

The Eight International Conference on Personal Wireless
Communications Sponsored

 

by the IFIP WG 6.8 - Mobile and Wireless Communications

 

 





 

September 23-25, 2003 Telecom Italia Future Centre -
Venice, Italy

 

 





 





 

PWC is the premier international forum for discussions between researchers,

 

practitioners and students interested in the symbiosis of mobile computing
and

 

wireless networks. PWC 2003 is the eight conference of this series and
is

 

sponsored by IFIP WG 6.8

 





 





 

The PWC 2003 technical program committee is soliciting short papers
on wireless and mobile communications that bring out interesting and novel
ideas at an early stage in their development. The goals are to allow timely
presentation and publication of these ideas. Short papers don't need to describe

 

completed work, but the work should be advanced beyond the initial stages.

 





 





 

Areas of interest include those that are listed on the conference call
for

 

papers, which can be found at http://www.iit.cnr.it/pwc2003

 





 





 

WHY should you submit a short paper?

 

------------------------------------

 

This is a great chance for disseminating early results of your research
to a wide and competent audience. This will help to create awareness around
your ideas, will give you relevant feedbacks and open some discussions in
your research direction.

 





 





 

WHAT you have to do NOW

 

-----------------------

 

You must submit a short paper presenting your ideas. A short paper

 

(maximum 2000 words) must clearly describe the subject of your research,
the

 

innovative ideas behind it, the results already achieved, and your further
work. Proposals submissions will be reviewed for novelty and timeliness,
relevance,  technical correctness, and accuracy.

 





 

Submissions should be sent by email to <pwc2003@iit.cnr.it> by
April 27, 2003. Please use the following subject: "pwc2003 short-paper proposal".

 





 





 

WHAT you have to do if the proposal is accepted

 

-----------------------------------------------

 

Authors of accepted proposal will prepare a camera-ready version of
the short paper to be published in the conference proceedings published by

 

Springer-Verlag in the Lecture Notes in Computer Science (LNCS) series

 

 





 

In addition, youmust attend the conference to present your paper at
the conference. 15 minutes will be assigned for each short-paper presentation.

 





 





 





 

IMPORTANT DATES

 

===============

 





 

Novel Idea proposal due: April 27, 2003

 





 

Notification:   May 15, 2003

 





 

Camera Ready due: June 10, 2003

 





 



--Boundary_(ID_da/RhIkTNZr5YEiFXeVhzA)--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Mon Apr 21 14:36:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25643
	for ; Mon, 21 Apr 2003 14:36:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LIlMm19196
	for manet-archive@odin.ietf.org; Mon, 21 Apr 2003 14:47:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LIlM819193
	for ; Mon, 21 Apr 2003 14:47:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25638
	for ; Mon, 21 Apr 2003 14:35:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197gB1-0002Gp-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 14:38:03 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197gB1-0002Gm-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 14:38:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LIVJ817539;
	Mon, 21 Apr 2003 14:31:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LINA817302
	for ; Mon, 21 Apr 2003 14:23:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24718
	for ; Mon, 21 Apr 2003 14:11:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197fnc-00026U-00
	for manet@ietf.org; Mon, 21 Apr 2003 14:13:52 -0400
Received: from farley3.colorado.edu ([128.138.129.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 197fnb-00026H-00
	for manet@ietf.org; Mon, 21 Apr 2003 14:13:51 -0400
Received: (from nobody@localhost)
	by farley3.Colorado.EDU (8.12.9/8.12.8/ITS-6.0/webmail) id h3LIDwIT023548;
	Mon, 21 Apr 2003 12:13:58 -0600 (MDT)
From: Shweta.Bhandare@colorado.edu
Received: from eternal.esniff.com (eternal.esniff.com [65.100.174.33]) 
	by webmail.colorado.edu (IMP) with HTTP 
	for ; Mon, 21 Apr 2003 12:13:57 -0600
Message-ID: <1050948837.3ea434e589768@webmail.colorado.edu>
Date: Mon, 21 Apr 2003 12:13:57 -0600
To: manet@ietf.org, kohler@icir.org, megoldsby@ca.sandia.gov,
        mmjohns@sandia.gov
Cc: timxb@colorado.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2-cvs
Content-Transfer-Encoding: 8bit
Subject: [manet] Release of DSR source code in CLICK
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

Our research group at University of Colorado at Boulder have decided to 
provide the Click implementation of the DSR protocol. 

More details about the download of the protocol are 
available at http://pecolab.colorado.edu 

We would appreciate any comments/suggestions/*bugs* discovered.

Thanks,
Shweta


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



From mailnull@www1.ietf.org  Mon Apr 21 17:42:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03771
	for ; Mon, 21 Apr 2003 17:42:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LLrfK31757
	for manet-archive@odin.ietf.org; Mon, 21 Apr 2003 17:53:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LLrf831754
	for ; Mon, 21 Apr 2003 17:53:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03758
	for ; Mon, 21 Apr 2003 17:41:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197j5H-0003fo-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 17:44:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197j5G-0003fl-00
	for manet-web-archive@ietf.org; Mon, 21 Apr 2003 17:44:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LLe8831296;
	Mon, 21 Apr 2003 17:40:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LLWM830223
	for ; Mon, 21 Apr 2003 17:32:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02998
	for ; Mon, 21 Apr 2003 17:20:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197ikd-0003Un-00
	for manet@ietf.org; Mon, 21 Apr 2003 17:23:00 -0400
Received: from farley3.colorado.edu ([128.138.129.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 197ikd-0003Uk-00
	for manet@ietf.org; Mon, 21 Apr 2003 17:22:59 -0400
Received: (from nobody@localhost)
	by farley3.Colorado.EDU (8.12.9/8.12.8/ITS-6.0/webmail) id h3LLNKoF002059;
	Mon, 21 Apr 2003 15:23:20 -0600 (MDT)
From: Shweta.Bhandare@colorado.edu
Received: from eternal.esniff.com (eternal.esniff.com [65.100.174.33]) 
	by webmail.colorado.edu (IMP) with HTTP 
	for ; Mon, 21 Apr 2003 15:23:20 -0600
Message-ID: <1050960200.3ea46148af5a0@webmail.colorado.edu>
Date: Mon, 21 Apr 2003 15:23:20 -0600
To: Chris Hart 
Cc: manet@ietf.org
Subject: Re: [manet] Release of DSR source code in CLICK - Modified
References: <1050948837.3ea434e589768@webmail.colorado.edu> <001901c3084b$4ec6b2c0$c82d6051@vaio2003>
In-Reply-To: <001901c3084b$4ec6b2c0$c82d6051@vaio2003>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2-cvs
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Sorry that was the wrong URL - the URL for information regarding the DSR Click 
Implementation is 

http://pecolab.colorado.edu/DSR.html

Thanks,
Shweta.

Quoting Chris Hart :

> There is no obvious download at your site, while there are a couple of
> obvious errors!
> Cheers,
> 
> CH
> ----- Original Message ----- 
> From: 
> To: ; ; ;
> 
> Cc: 
> Sent: Monday, April 21, 2003 7:13 PM
> Subject: [manet] Release of DSR source code in CLICK
> 
> 
> > Hi,
> >
> > Our research group at University of Colorado at Boulder have decided to
> > provide the Click implementation of the DSR protocol.
> >
> > More details about the download of the protocol are
> > available at http://pecolab.colorado.edu
> >
> > We would appreciate any comments/suggestions/*bugs* discovered.
> >
> > Thanks,
> > Shweta
> >
> >
> > _______________________________________________
> > 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 mailnull@www1.ietf.org  Tue Apr 22 11:09:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13073
	for ; Tue, 22 Apr 2003 11:09:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MFKvF13369
	for manet-archive@odin.ietf.org; Tue, 22 Apr 2003 11:20:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFKv813366
	for ; Tue, 22 Apr 2003 11:20:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13050
	for ; Tue, 22 Apr 2003 11:08:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197zQO-0002QY-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 11:11:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197zQO-0002QV-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 11:11:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MF7U812199;
	Tue, 22 Apr 2003 11:07:30 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEvU811215
	for ; Tue, 22 Apr 2003 10:57:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12223
	for ; Tue, 22 Apr 2003 10:45:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z3i-0002Fg-00
	for manet@ietf.org; Tue, 22 Apr 2003 10:47:46 -0400
Received: from mx.laposte.net ([213.30.181.11])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z3h-0002FS-00
	for manet@ietf.org; Tue, 22 Apr 2003 10:47:46 -0400
Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053)
        id 3E9748DE0019CC19 for manet@ietf.org; Tue, 22 Apr 2003 16:47:34 +0200
Date: Tue, 22 Apr 2003 16:47:34 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" 
To: "=?iso-8859-1?Q?manet?=" 
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 193.95.33.18
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3MEvU811216
Subject: [manet] =?iso-8859-1?Q?/proc/net/wireless?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3MF7U812199
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3MFKv813366
Content-Transfer-Encoding: 8bit

Hi all
- Can anyone tell me what mean 'link', 'level' and 'noise' in 
/proc/net/wireless and if I can calculate the SNR from the 
informations in /proc/net/wireless(noise level) and from 
iwconfig(Txpower).
- is it possible to convert 'noise' and 'level' in db
thank you 


Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"



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



From mailnull@www1.ietf.org  Tue Apr 22 13:46:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17972
	for ; Tue, 22 Apr 2003 13:46:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MHwI625785
	for manet-archive@odin.ietf.org; Tue, 22 Apr 2003 13:58:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHwI825782
	for ; Tue, 22 Apr 2003 13:58:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17951
	for ; Tue, 22 Apr 2003 13:46:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981sc-0003X5-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 13:48:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1981sb-0003X0-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 13:48:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHie824628;
	Tue, 22 Apr 2003 13:44:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHdc824393
	for ; Tue, 22 Apr 2003 13:39:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17273
	for ; Tue, 22 Apr 2003 13:27:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981aY-0003MB-00
	for manet@ietf.org; Tue, 22 Apr 2003 13:29:50 -0400
Received: from che.onthejob.net ([63.146.38.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981aX-0003M7-00
	for manet@ietf.org; Tue, 22 Apr 2003 13:29:49 -0400
Received: from che.onthejob.net (localhost [127.0.0.1])
	by che.onthejob.net (8.12.8/8.12.5) with ESMTP id h3MHTgMs010591
	for ; Tue, 22 Apr 2003 12:29:42 -0500
Received: (from dyoung@localhost)
	by che.onthejob.net (8.12.8/8.12.8/Submit) id h3MHTgEp010589
	for manet@ietf.org; Tue, 22 Apr 2003 12:29:42 -0500
Date: Tue, 22 Apr 2003 12:29:42 -0500
From: David Young 
To: manet 
Subject: Re: [manet] /proc/net/wireless
Message-ID: <20030422172942.GA21236@che.onthejob.net>
Mail-Followup-To: manet 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4i
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

On Tue, Apr 22, 2003 at 04:47:34PM +0200, ghannay.sana@laposte.net wrote:
> Hi all
> - Can anyone tell me what mean 'link', 'level' and 'noise' in 
> /proc/net/wireless and if I can calculate the SNR from the 
> informations in /proc/net/wireless(noise level) and from 
> iwconfig(Txpower).

  I believe that level & noise are only meaningful in an infrastructure
  network, where they tell the received signal strength and an average
  noise level of packets received from the AP. I recommend that you
  read the driver source to find out for certain. Also, search the Prism
  "knowledge base" at Intersil for questions and answers regarding signal
  & noise measurements.

  The Tx power control that the hostap driver gives is misleading and
  wrong. There is no reliable relationship between dBm and CR31 settings.
  A proper power control should use a feedback loop such as the Prism MAC
  firmware does. See .
  AN1037 was my guide for a NetBSD power control; see
  .

> - is it possible to convert 'noise' and 'level' in db

  Prism chips provide signal & noise indications with every received
  packet. Register 0xFC46 tells the constant to substract from the signal
  and noise indications to approximate dBm, but manufacturers may not
  reliably calibrate that register. RID 0xFC46 may also be the constant
  to subtract from the indications in /proc.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Tue Apr 22 16:16:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24370
	for ; Tue, 22 Apr 2003 16:16:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MKS3f05182
	for manet-archive@odin.ietf.org; Tue, 22 Apr 2003 16:28:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKS2805179
	for ; Tue, 22 Apr 2003 16:28:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24351
	for ; Tue, 22 Apr 2003 16:15:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1984DT-0004sU-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 16:18:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1984DT-0004sQ-00
	for manet-web-archive@ietf.org; Tue, 22 Apr 2003 16:18:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MKAb803721;
	Tue, 22 Apr 2003 16:10:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJuQ802367
	for ; Tue, 22 Apr 2003 15:56:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23151
	for ; Tue, 22 Apr 2003 15:44:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1983it-0004XI-00
	for manet@ietf.org; Tue, 22 Apr 2003 15:46:35 -0400
Received: from dinamo.ing.puc.cl ([146.155.4.14])
	by ietf-mx with esmtp (Exim 4.12)
	id 1983ib-0004X9-00
	for manet@ietf.org; Tue, 22 Apr 2003 15:46:18 -0400
Received: from dinamo.ing.puc.cl (unknown [127.0.0.1])
	by localhost (Postfix) with ESMTP id 4CEC446F88
	for ; Tue, 22 Apr 2003 19:46:15 +0000 (UTC)
Received: from RAPTOR (mercedario.ing.puc.cl [146.155.13.65])
	by dinamo.ing.puc.cl (Postfix) with SMTP id 7B40446F85
	for ; Tue, 22 Apr 2003 15:46:14 -0400 (CLT)
MIME-Version: 1.0
Message-Id: <3EA59C0D.000015.01752@RAPTOR>
Date: Tue, 22 Apr 2003 15:46:21 -0400 (Pacific SA Standard Time)
Content-Type: Multipart/related;
  type="multipart/alternative";
  boundary="------------Boundary-00=_99GRYHI1VA4000000000"
X-Mailer: IncrediMail 2001 (1750710)
From: "Roberto Aldunate" 
References: <20030422172942.GA21236@che.onthejob.net>
X-FID: FLAVOR00-NONE-0000-0000-000000000000
X-CNT: ;
X-Priority: 3
To: "manet@ietf.org" 
Subject: Re: [manet] /proc/net/wireless
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


--------------Boundary-00=_99GRYHI1VA4000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_99GRTSM1VA4000000000"


--------------Boundary-00=_99GRTSM1VA4000000000
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For some cards, I think that level & noise are meaningful not only in
infrastructure mode , but also in ad-hoc mode. In particular, I've used s=
uch
information using a Cisco aironet 340 receiving SS (link, noise and level=
)
from a Compaq WL110 card, the embedded one in the toshiba e740 and a Sock=
et
(the ones used in HP Jornada) (all of them running on ad hoc mode).=0D
=0D
regards, =0D
=0D
roberto.=0D
=0D
-------Original Message-------=0D
=0D
From: David Young=0D
Date: Tuesday, April 22, 2003 2:40:57 PM=0D
To: manet=0D
Subject: Re: [manet] /proc/net/wireless=0D
=0D
On Tue, Apr 22, 2003 at 04:47:34PM +0200, ghannay.sana@laposte.net wrote:=
=0D
> Hi all=0D
> - Can anyone tell me what mean 'link', 'level' and 'noise' in =0D
> /proc/net/wireless and if I can calculate the SNR from the =0D
> informations in /proc/net/wireless(noise level) and from =0D
> iwconfig(Txpower).=0D
=0D
I believe that level & noise are only meaningful in an infrastructure=0D
network, where they tell the received signal strength and an average=0D
noise level of packets received from the AP. I recommend that you=0D
read the driver source to find out for certain. Also, search the Prism=0D
"knowledge base" at Intersil for questions and answers regarding signal=0D
& noise measurements.=0D
=0D
The Tx power control that the hostap driver gives is misleading and=0D
wrong. There is no reliable relationship between dBm and CR31 settings.=0D
A proper power control should use a feedback loop such as the Prism MAC=0D
firmware does. See .=0D
AN1037 was my guide for a NetBSD power control; see=0D
.=0D
=0D
> - is it possible to convert 'noise' and 'level' in db=0D
=0D
Prism chips provide signal & noise indications with every received=0D
packet. Register 0xFC46 tells the constant to substract from the signal=0D
and noise indications to approximate dBm, but manufacturers may not=0D
reliably calibrate that register. RID 0xFC46 may also be the constant=0D
to subtract from the indications in /proc.=0D
=0D
Dave=0D
=0D
-- =0D
David Young OJC Technologies=0D
dyoung@ojctech.com Urbana, IL * (217) 278-3933=0D
_______________________________________________=0D
manet mailing list=0D
manet@ietf.org=0D
https://www1.ietf.org/mailman/listinfo/manet=0D
=2E
--------------Boundary-00=_99GRTSM1VA4000000000
Content-Type: Text/HTML;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



=0D

=0A








      
For some cards, I think that level & noise are meanin=
gful=20
      not only in infrastructure mode , but also in ad-hoc mode. In parti=
cular,=20
      I've used such information using a Cisco aironet 340 receiving=
 SS=20
      (link, noise and level) from a Compaq WL110 card, the emb=
edded=20
      one in the toshiba e740 and a Socket (the ones used in HP=20
      Jornada) (all of them running on ad hoc mode).

      
 

      
regards, 

      
 

      
roberto.

      
 

      
-------Original Message-------<=
/I>

      
 

      

      
From: David Young

      
Date: Tuesda=
y, April=20
      22, 2003 2:40:57 PM

      
To: manet

      
Subject: Re:=
 [manet]=20
      /proc/net/wireless

      
 
On Tue, Apr 22, 2003 at 04:47:34PM +0200, ghannay.sana@laposte.net=20
      wrote:
> Hi all
> - Can anyone tell me what mean 'link'=
,=20
      'level' and 'noise' in 
> /proc/net/wireless and if I can cal=
culate=20
      the SNR from the 
> informations in /proc/net/wireless(noise =
level)=20
      and from 
> iwconfig(Txpower).

I believe that level &a=
mp;=20
      noise are only meaningful in an infrastructure
network, where th=
ey tell=20
      the received signal strength and an average
noise level of packe=
ts=20
      received from the AP. I recommend that you
read the driver sourc=
e to=20
      find out for certain. Also, search the Prism
"knowledge base" at=
=20
      Intersil for questions and answers regarding signal
& noise=20
      measurements.

The Tx power control that the hostap driver gi=
ves is=20
      misleading and
wrong. There is no reliable relationship between =
dBm and=20
      CR31 settings.
A proper power control should use a feedback loop=
 such=20
      as the Prism MAC
firmware does. See <http://www.inte=
rsil.com/data/an/AN1037.pdf>.
AN1037=20
      was my guide for a NetBSD power control; see
<http://lists.bawug.org/pipermail/bsd-wireless/2003-March/00006=
1.html>.

>=20
      - is it possible to convert 'noise' and 'level' in db

Prism =
chips=20
      provide signal & noise indications with every received
packe=
t.=20
      Register 0xFC46 tells the constant to substract from the signal
=
and=20
      noise indications to approximate dBm, but manufacturers may=20
      not
reliably calibrate that register. RID 0xFC46 may also be the=
=20
      constant
to subtract from the indications in=20
      /proc.

Dave

-- 
David Young OJC Technologies
dyoung@ojctech.com Urbana, I=
L * (217)=20
      278-3933
_______________________________________________
mane=
t=20
      mailing list
manet@ietf.org
https://www1.i=
etf.org/mailman/listinfo/manet
.		







=09
=09
=09
=09
=09
=09
=09







____________________________________________________
  IncrediMail - Email has finally evolved -=20
Click=20
Here


--------------Boundary-00=_99GRTSM1VA4000000000--

--------------Boundary-00=_99GRYHI1VA4000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: 
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA
AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B
URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt
E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE
CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ
AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ
Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj
1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5
BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs=

--------------Boundary-00=_99GRYHI1VA4000000000--

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



From mailnull@www1.ietf.org  Wed Apr 23 01:58:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08817
	for ; Wed, 23 Apr 2003 01:58:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N6AAN18716
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 02:10:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6AA818713
	for ; Wed, 23 Apr 2003 02:10:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08808
	for ; Wed, 23 Apr 2003 01:57:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198DIc-0000DI-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 02:00:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198DIb-0000DE-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 02:00:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N5vN812513;
	Wed, 23 Apr 2003 01:57:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N5ir812153
	for ; Wed, 23 Apr 2003 01:44:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08295
	for ; Wed, 23 Apr 2003 01:32:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198CuA-000040-00
	for manet@ietf.org; Wed, 23 Apr 2003 01:34:50 -0400
Received: from patty.levels.unisa.edu.au ([130.220.36.156] helo=localhost)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Cu9-00003w-00
	for manet@ietf.org; Wed, 23 Apr 2003 01:34:50 -0400
Date: Wed, 23 Apr 2003 15:05:05 +0930
From: Peter Pham 
X-Mailer: The Bat! (v1.62 Christmas Edition) Personal
Reply-To: Peter Pham 
Organization: ITR
X-Priority: 3 (Normal)
Message-ID: <1791385612.20030423150505@myrealbox.com>
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] Cross Layer Design In Mobile Ad hoc Networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi All,
I would really appreciate anyone who can point out significant
contribution on cross layer design in mobile ad hoc networks.
I did a search on google and IEEExplore but could not find much..

Thanks

-- 
Best regards,
Peter



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



From mailnull@www1.ietf.org  Wed Apr 23 04:07:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07205
	for ; Wed, 23 Apr 2003 04:07:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N8Jtd02403
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 04:19:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8Jt802400
	for ; Wed, 23 Apr 2003 04:19:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07199
	for ; Wed, 23 Apr 2003 04:07:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198FK8-0001Eq-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 04:09:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198FK8-0001En-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 04:09:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N87C800863;
	Wed, 23 Apr 2003 04:07:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N7r5832337
	for ; Wed, 23 Apr 2003 03:53:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06585
	for ; Wed, 23 Apr 2003 03:40:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Eu7-00014D-00
	for manet@ietf.org; Wed, 23 Apr 2003 03:42:55 -0400
Received: from rumba.cefriel.it ([131.175.53.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Eu6-000143-00
	for manet@ietf.org; Wed, 23 Apr 2003 03:42:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 23 Apr 2003 09:44:56 +0200
Message-ID: <28C92BFE6EB5C943B15743D0E11E60360FE7A4@rumba.cefriel.it>
Thread-Topic: [manet] Cross Layer Design In Mobile Ad hoc Networks
Thread-Index: AcMJZZwDixqszmYKTbCYBslKU/UrTgABQlAA
From: "Nicola Alagia" 
To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3N7se832371
Subject: [manet] AODV - Destination Sequence Number
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi all,
I've a question about the update of the Destination Sequence Number (in AODV), made by the receiver node (i.e. when a node that is the destination node receive a RREQ and reply with a RREP).

In the following I refer to the draft-13.

At page 10 (section 6.1. Maintaining Sequence Numbers) I read:
"  A destination node increments its own sequence number in two
   circumstances:
    - [...]
    -  Immediately before a destination node originates a RREP in
       response to a RREQ, it MUST update its own sequence number to
       the maximum of its current sequence number and the destination
       sequence number in the RREQ packet."

Instead, at page 16 (section 6.6.1. Route Reply Generation by the Destination) I read:
"  If the generating node is the destination itself, it MUST increment
   its own sequence number by one if the sequence number in the
   RREQ packet is equal to that incremented value.  Otherwise, the
   destination does not change its sequence number before generating
   the RREP message.  The destination node places its (perhaps newly
   incremented) sequence number into the Destination Sequence Number
   field of the RREP, and enters the value zero in the Hop Count field
   of the RREP."

So, has the destination node to update his sequence number before generating the RREP message?
And what happens if a destination node has a sequence number "N" and receive a RREQ message containing a destination sequence number equals to (or grater than) "N+2"?

Thanks for replies!


-----
 Nicola Alagia
 Masterando Area eTECH
 nicola.alagia@cefriel.it
-----
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr 23 07:20:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12510
	for ; Wed, 23 Apr 2003 07:20:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NBWIA15355
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 07:32:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBWI815351
	for ; Wed, 23 Apr 2003 07:32:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12501
	for ; Wed, 23 Apr 2003 07:19:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198IKG-0002Qn-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 07:22:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198IKF-0002Qk-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 07:22:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBEH814409;
	Wed, 23 Apr 2003 07:14:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NB6l813304
	for ; Wed, 23 Apr 2003 07:06:47 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10975;
	Wed, 23 Apr 2003 06:54:17 -0400 (EDT)
Message-Id: <200304231054.GAA10975@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: manet@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 23 Apr 2003 06:54:17 -0400
Subject: [manet] I-D ACTION:draft-ietf-manet-tbrpf-08.txt
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Topology Dissemination Based on Reverse-Path 
                          Forwarding (TBRPF)
	Author(s)	: R. Ogier, M. Lewis, F. Templin
	Filename	: draft-ietf-manet-tbrpf-08.txt
	Pages		: 49
	Date		: 2003-4-22
	
TBRPF is a proactive, link-state routing protocol designed for mobile
ad-hoc networks, which provides hop-by-hop routing along shortest
paths to each destination. Each node running TBRPF computes a source
tree (providing paths to all reachable nodes) based on partial
topology information stored in its topology table, using a
modification of Dijkstra's algorithm. To minimize overhead, each node
reports only *part* of its source tree to neighbors. TBRPF uses a
combination of periodic and differential updates to keep all
neighbors informed of the reported part of its source tree. Each node
also has the option to report additional topology information (up to
the full topology), to provide improved robustness in highly mobile
networks. TBRPF performs neighbor discovery using 'differential'
HELLO messages which report only *changes* in the status of
neighbors. This results in HELLO messages that are much smaller than
those of other link-state routing protocols such as OSPF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-tbrpf-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-tbrpf-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-22151816.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-manet-tbrpf-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-manet-tbrpf-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-22151816.I-D@ietf.org>

--OtherAccess--

--NextPart--


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



From mailnull@www1.ietf.org  Wed Apr 23 07:37:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13893
	for ; Wed, 23 Apr 2003 07:37:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NBnfN17075
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 07:49:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBne817072
	for ; Wed, 23 Apr 2003 07:49:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13854
	for ; Wed, 23 Apr 2003 07:37:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Ib2-0002ss-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 07:39:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Ib1-0002sp-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 07:39:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBaR815466;
	Wed, 23 Apr 2003 07:36:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBTd815236
	for ; Wed, 23 Apr 2003 07:29:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12352
	for ; Wed, 23 Apr 2003 07:17:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198IHg-0002N1-00
	for manet@ietf.org; Wed, 23 Apr 2003 07:19:28 -0400
Received: from [61.129.65.20] (helo=mail5)
	by ietf-mx with esmtp (Exim 4.12)
	id 198IHX-0002MP-00
	for manet@ietf.org; Wed, 23 Apr 2003 07:19:27 -0400
Received: from commlablorry (socks.fudan.edu.cn [202.120.224.18])
 by mail5.eastday.com (iPlanet Messaging Server 5.2 (built Feb 21 2002))
 with ESMTPA id <0HDS00CX7NHDBR@mail5.eastday.com> for manet@ietf.org; Wed,
 23 Apr 2003 19:20:01 +0800 (CST)
Date: Wed, 23 Apr 2003 19:19:17 +0800
From: Ruiliang Chen 
Subject: Re: [manet] Cross Layer Design In Mobile Ad hoc Networks
To: Peter Pham 
Cc: manet@ietf.org
Message-id: <01b801c3098a$2e3c5ab0$1616270a@commlablorry>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <1791385612.20030423150505@myrealbox.com>
Content-Transfer-Encoding: 7BIT
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Wingho Yuen, Heung-no Lee and Timothy Anderson, "Simple but effective cross-layer networking system for mobile ad hoc networks," Proc. of IEEE PIMRC, 2002.
http://crl.ee.pitt.edu/publications/pimrc2002_adhoc.pdf

Best regards,

Ruiliang Chen

----- Original Message ----- 
From: "Peter Pham" 
To: 
Sent: Wednesday, April 23, 2003 1:35 PM
Subject: [manet] Cross Layer Design In Mobile Ad hoc Networks


> Hi All,
> I would really appreciate anyone who can point out significant
> contribution on cross layer design in mobile ad hoc networks.
> I did a search on google and IEEExplore but could not find much..
> 
> Thanks
> 
> -- 
> Best regards,
> Peter
> 
> 
> 
> _______________________________________________
> 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 mailnull@www1.ietf.org  Wed Apr 23 12:04:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24673
	for ; Wed, 23 Apr 2003 12:04:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NGG5106095
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 12:16:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGG5806092
	for ; Wed, 23 Apr 2003 12:16:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24637
	for ; Wed, 23 Apr 2003 12:03:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Mkn-00057x-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 12:05:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Mkm-00057u-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 12:05:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG1D803990;
	Wed, 23 Apr 2003 12:01:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NFtJ803704
	for ; Wed, 23 Apr 2003 11:55:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23827
	for ; Wed, 23 Apr 2003 11:42:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MQh-0004wj-00
	for manet@ietf.org; Wed, 23 Apr 2003 11:45:03 -0400
Received: from mx1.isti.cnr.it ([146.48.126.37])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MQg-0004wg-00
	for manet@ietf.org; Wed, 23 Apr 2003 11:45:02 -0400
Received: from CONVERSION.MAIL.IAT.CNR.IT by mx.isti.cnr.it (PMDF V6.2 #30641)
 id <01KV2Q3OVC9C9OCUXY@mx.isti.cnr.it> for manet@ietf.org; Wed,
 23 Apr 2003 17:44:13 +0200
Received: from iitpa6v64oitt1 (labgreg2.cnuce.cnr.it [146.48.82.129])
 by mx.isti.cnr.it (PMDF V6.2 #30641)
 with SMTP id <01KV2Q3O2QT29OCUX8@mx.isti.cnr.it> for manet@ietf.org; Wed,
 23 Apr 2003 17:44:12 +0200
Date: Wed, 23 Apr 2003 17:43:24 +0200
From: Eleonora Borgia 
To: manet@ietf.org
Message-id: <003101c309af$1ae8ff70$81523092@iitpa6v64oitt1>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_QFK6oo5Gw7Ir7+uuqq9WFA)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [manet] ..about carrier sense range
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

--Boundary_(ID_QFK6oo5Gw7Ir7+uuqq9WFA)
Content-type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all!!

In IEEE 802.11b there are four possible transmission rates for DATA =
frames, consequently  there are four different transmission ranges, one =
for each trasmission rate.=20
I'm wondering:
is it  correct thinking that, modelling a 802.11b network, there is only =
one carrier sense range and it isn't in relation to the transmission =
rate (i.e there isn't a carrier sense for  trasmission at 2 Mbps and a =
different one for  trasmission a 11 Mbps, etc..) ??

Thanks a lot.

Eleonora




--Boundary_(ID_QFK6oo5Gw7Ir7+uuqq9WFA)
Content-type: text/html;	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi =
all!!


 


In IEEE =
802.11b there are=20
four possible transmission rates for DATA =
frames, consequently =20
there are four different transmission ranges, one for each trasmission =
rate.=20



I'm =
wondering:


is it  =
correct thinking=20
that, modelling a 802.11b=20
network, there is only one carrier sense range and it isn't in =
relation to=20
the transmission rate (i.e there isn't a carrier sense for =20
trasmission at 2 Mbps and a different one for  trasmission a =
11 Mbps,=20
etc..) ??


 




Thanks a =
lot.


 


Eleonora




--Boundary_(ID_QFK6oo5Gw7Ir7+uuqq9WFA)--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Wed Apr 23 14:07:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28447
	for ; Wed, 23 Apr 2003 14:07:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NIJKm15379
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 14:19:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIJK815375
	for ; Wed, 23 Apr 2003 14:19:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28413
	for ; Wed, 23 Apr 2003 14:06:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Og1-0005zw-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:09:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Og0-0005zt-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:09:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI68813957;
	Wed, 23 Apr 2003 14:06:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI0L813759
	for ; Wed, 23 Apr 2003 14:00:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27858
	for ; Wed, 23 Apr 2003 13:47:43 -0400 (EDT)
From: idc@engineering.ucsb.edu
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198ONe-0005u7-00
	for manet@ietf.org; Wed, 23 Apr 2003 13:50:02 -0400
Received: from letters.cs.ucsb.edu ([128.111.41.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 198ONd-0005u4-00
	for manet@ietf.org; Wed, 23 Apr 2003 13:50:01 -0400
Received: from KENAI.cs.ucsb.edu (badlands.cs.ucsb.edu [128.111.40.116])
	by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h3NHoEC16131;
	Wed, 23 Apr 2003 10:50:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16038.53851.863000.14329@gargle.gargle.HOWL>
Date: Wed, 23 Apr 2003 10:50:19 -0700
To: "Nicola Alagia" 
Cc: 
Subject: RE:[manet] AODV - Destination Sequence Number
In-Reply-To: <28C92BFE6EB5C943B15743D0E11E60360FE7A4@rumba.cefriel.it>
References: <28C92BFE6EB5C943B15743D0E11E60360FE7A4@rumba.cefriel.it>
X-Mailer: VM 7.07 under Emacs 21.1.1
Reply-To: idc@engineering.ucsb.edu
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I believe for correct operation the destination sequence number must
be greater than or equal to the destination sequence number in the
RREQ AND greater than the previous destination sequence number by at
least 1.

I agree the draft could be clearer here.

Ian Chakeres


>Nicola Alagia wrote:
>Hi all,
>I've a question about the update of the Destination Sequence Number (in AODV), made by the receiver node (i.e. when a node that is the destination node receive a RREQ and reply with a RREP).
>
>In the following I refer to the draft-13.
>
>At page 10 (section 6.1. Maintaining Sequence Numbers) I read:
>"  A destination node increments its own sequence number in two
>   circumstances:
>    - [...]
>    -  Immediately before a destination node originates a RREP in
>       response to a RREQ, it MUST update its own sequence number to
>       the maximum of its current sequence number and the destination
>       sequence number in the RREQ packet."
>
>Instead, at page 16 (section 6.6.1. Route Reply Generation by the Destination) I read:
>"  If the generating node is the destination itself, it MUST increment
>   its own sequence number by one if the sequence number in the
>   RREQ packet is equal to that incremented value.  Otherwise, the
>   destination does not change its sequence number before generating
>   the RREP message.  The destination node places its (perhaps newly
>   incremented) sequence number into the Destination Sequence Number
>   field of the RREP, and enters the value zero in the Hop Count field
>   of the RREP."
>
>So, has the destination node to update his sequence number before generating the RREP message?
>And what happens if a destination node has a sequence number "N" and receive a RREQ message containing a destination sequence number equals to (or grater than) "N+2"?
>
>Thanks for replies!
>
>
>-----
> Nicola Alagia
> Masterando Area eTECH
> nicola.alagia@cefriel.it
>-----
>_______________________________________________
>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 mailnull@www1.ietf.org  Wed Apr 23 14:18:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28857
	for ; Wed, 23 Apr 2003 14:18:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NIUXB16009
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 14:30:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIUX816006
	for ; Wed, 23 Apr 2003 14:30:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28809
	for ; Wed, 23 Apr 2003 14:17:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Oqr-00065h-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:20:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Oqr-00065e-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:20:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIBu815073;
	Wed, 23 Apr 2003 14:11:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI7s814889
	for ; Wed, 23 Apr 2003 14:07:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28065
	for ; Wed, 23 Apr 2003 13:55:16 -0400 (EDT)
From: idc@engineering.ucsb.edu
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OUx-0005vn-00
	for manet@ietf.org; Wed, 23 Apr 2003 13:57:35 -0400
Received: from letters.cs.ucsb.edu ([128.111.41.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OUx-0005vk-00
	for manet@ietf.org; Wed, 23 Apr 2003 13:57:35 -0400
Received: from KENAI.cs.ucsb.edu (badlands.cs.ucsb.edu [128.111.40.116])
	by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h3NHvpC16704;
	Wed, 23 Apr 2003 10:57:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16038.54304.434000.545408@gargle.gargle.HOWL>
Date: Wed, 23 Apr 2003 10:57:52 -0700
To: Eleonora Borgia 
Cc: manet@ietf.org
Subject: RE:[manet] ..about carrier sense range
In-Reply-To: <003101c309af$1ae8ff70$81523092@iitpa6v64oitt1>
References: <003101c309af$1ae8ff70$81523092@iitpa6v64oitt1>
X-Mailer: VM 7.07 under Emacs 21.1.1
Reply-To: idc@engineering.ucsb.edu
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


I think there are probably different carrier sensing ranges for each
data rate.  Though all RTS, CTS and ACK (virtual carrier sensing)
packets occur at 1 or 2 Mbps.  Likewise the SYNC of every 802.11
packet occurs at 1 Mbps.

Ian Chakeres

>Eleonora Borgia wrote:
>Hi all!!
>
>In IEEE 802.11b there are four possible transmission rates for DATA frames, consequently  there are four different transmission ranges, one for each trasmission rate. 
>I'm wondering:
>is it  correct thinking that, modelling a 802.11b network, there is only one carrier sense range and it isn't in relation to the transmission rate (i.e there isn't a carrier sense for  trasmission at 2 Mbps and a different one for  trasmission a 11 Mbps, etc..) ??
>
>Thanks a lot.
>
>Eleonora
>
>
>
>
>
>
>
>
>
>
>
Hi all!!

>
 

>
In IEEE 802.11b there are 
>four possible transmission rates for DATA frames, consequently  
>there are four different transmission ranges, one for each trasmission rate. 
>

>
I'm wondering:

>
is it  correct thinking 
>that, modelling a 802.11b 
>network, there is only one carrier sense range and it isn't in relation to 
>the transmission rate (i.e there isn't a carrier sense for  
>trasmission at 2 Mbps and a different one for  trasmission a 11 Mbps, 
>etc..) ??

>
 

>

>
Thanks a lot.

>
 

>
size=2>Eleonora




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



From mailnull@www1.ietf.org  Wed Apr 23 14:20:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28953
	for ; Wed, 23 Apr 2003 14:20:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NIWEC16274
	for manet-archive@odin.ietf.org; Wed, 23 Apr 2003 14:32:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIWE816271
	for ; Wed, 23 Apr 2003 14:32:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28921
	for ; Wed, 23 Apr 2003 14:19:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OsV-00067A-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:21:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198OsV-000677-00
	for manet-web-archive@ietf.org; Wed, 23 Apr 2003 14:21:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIHv815307;
	Wed, 23 Apr 2003 14:17:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NID4815153
	for ; Wed, 23 Apr 2003 14:13:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28253
	for ; Wed, 23 Apr 2003 14:00:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OZx-0005y2-00
	for manet@ietf.org; Wed, 23 Apr 2003 14:02:45 -0400
Received: from bubba.nmsu.edu ([128.123.3.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OZw-0005xv-00
	for manet@ietf.org; Wed, 23 Apr 2003 14:02:45 -0400
Received: from dns1.nmsu.edu (dns1.NMSU.Edu [128.123.3.5])
	by bubba.NMSU.Edu (8.10.2+Sun/8.9.0) with ESMTP id h3NI2nU08749;
	Wed, 23 Apr 2003 12:02:53 -0600 (MDT)
Received: from nestor.NMSU.Edu (nestor.NMSU.Edu [128.123.34.146])
	by dns1.nmsu.edu (8.9.3/8.9.0) with ESMTP id MAA06410;
	Wed, 23 Apr 2003 12:02:50 -0600 (MDT)
Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103])
	by nestor.NMSU.Edu (AIX4.3/8.9.3/8.9.0) with ESMTP id MAA136188;
	Wed, 23 Apr 2003 12:02:50 -0600
From: "John Mullen" 
To: "'Eleonora Borgia'" 
Cc: 
Subject: RE: [manet] ..about carrier sense range
Date: Wed, 23 Apr 2003 12:02:52 -0600
Message-ID: <000301c309c2$8ef1c2e0$67f57b80@IEngr.ad.nmsu.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01C30990.445752E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <003101c309af$1ae8ff70$81523092@iitpa6v64oitt1>
Importance: Normal
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C30990.445752E0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Eleonora,
 
In general, the maximum data rate is a function of the signal-to-noise
ratio.  If you want to use a higher rate, you will need a higher SN
ratio.  All other things being equal, higher rates lead to shorter
ranges for communication because the SN falls off with distance.
However, since all things, including transmitter power, are equal, the
carrier sense range would remain about the same.
 
Hope this helps,
 
John Mullen

-----Original Message-----
From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of
Eleonora Borgia
Sent: Wednesday, April 23, 2003 8:43 AM
To: manet@ietf.org
Subject: [manet] ..about carrier sense range


Hi all!!
 
In IEEE 802.11b there are four possible transmission rates for DATA
frames, consequently  there are four different transmission ranges, one
for each trasmission rate. 
I'm wondering:
is it  correct thinking that, modelling a 802.11b network, there is only
one carrier sense range and it isn't in relation to the transmission
rate (i.e there isn't a carrier sense for  trasmission at 2 Mbps and a
different one for  trasmission a 11 Mbps, etc..) ??
 

Thanks a lot.
 
Eleonora




------=_NextPart_000_0004_01C30990.445752E0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable




Message






Hi=20
Eleonora,


 


In=20
general, the maximum data rate is a function of the signal-to-noise =
ratio. =20
If you want to use a higher rate, you will need a higher SN ratio.  =
All=20
other things being equal, higher rates lead to shorter ranges for =
communication=20
because the SN falls off with distance.  However, since all things, =

including transmitter power, are equal, the carrier sense range would =
remain=20
about the same.


 


Hope=20
this helps,


 


John=20
Mullen



  

  
-----Original Message-----
From:=20
  manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of=20
  Eleonora Borgia
Sent: Wednesday, April 23, 2003 8:43=20
  AM
To: manet@ietf.org
Subject: [manet] ..about =
carrier=20
  sense range


  
Hi =
all!!

  
 

  
In IEEE =
802.11b there are=20
  four possible transmission rates for DATA =
frames, consequently =20
  there are four different transmission ranges, one for each trasmission =
rate.=20
  

  
I'm=20
wondering:

  
is it  =
correct=20
  thinking that, modelling=20
  a 802.11b network, there is only one carrier sense range and it =
isn't in=20
  relation to the transmission rate (i.e there isn't a carrier =
sense=20
  for  trasmission at 2 Mbps and a different one for  =
trasmission a=20
  11 Mbps, etc..) ??

  
 

  

  
Thanks a =
lot.

  
 

  
Eleonora




------=_NextPart_000_0004_01C30990.445752E0--

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



From mailnull@www1.ietf.org  Thu Apr 24 18:19:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08049
	for ; Thu, 24 Apr 2003 18:19:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OMLtB17268
	for manet-archive@odin.ietf.org; Thu, 24 Apr 2003 18:21:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMLs817265
	for ; Thu, 24 Apr 2003 18:21:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08043
	for ; Thu, 24 Apr 2003 18:18:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198p5K-0002Jw-00
	for manet-web-archive@ietf.org; Thu, 24 Apr 2003 18:20:54 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198p5J-0002Js-00
	for manet-web-archive@ietf.org; Thu, 24 Apr 2003 18:20:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OM9H816743;
	Thu, 24 Apr 2003 18:09:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OM3c815681
	for ; Thu, 24 Apr 2003 18:03:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05770
	for ; Thu, 24 Apr 2003 18:00:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198one-0001z5-00
	for manet@ietf.org; Thu, 24 Apr 2003 18:02:38 -0400
Received: from web40405.mail.yahoo.com ([66.218.78.102])
	by ietf-mx with smtp (Exim 4.12)
	id 198one-0001yo-00
	for manet@ietf.org; Thu, 24 Apr 2003 18:02:38 -0400
Message-ID: <20030424220235.51385.qmail@web40405.mail.yahoo.com>
Received: from [144.214.61.67] by web40405.mail.yahoo.com via HTTP; Fri, 25 Apr 2003 06:02:35 CST
Date: Fri, 25 Apr 2003 06:02:35 +0800 (CST)
From: =?iso-8859-1?q?Seki=20Lau?= 
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] a Question on RTS/CTS
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Dear All,
I am thinking such case and I don't sure will it
happened or not.

Two nodes (X and Y) operating in Ad Hoc mode. X can
hear Y and Y can hear X. X has just received a RTS
from someone (let's call it H) and X is going to reply
a CTS. In almost the same time, Y backoff counter
already expire and it will transit from receiving mode
to transmitting mode and it is going to transmit a
RTS.
According to IEEE 802.11 standard, RTS is longer than
CTS in length.

So, the CTS signal from X will arrive Y. But at that
time , Y is in transmission mode, it can't hear(or
even not notice) a CTS arrive. The signal of RTS from
Y arrive X . Because RTS is longer than CTS, after X
transmitted its CTS, it notice something on the media.
It can't find it is meaningful. X back off and assume
it is noice. However, H can receive the CTS from X to
itself clearly. H decides to send a data packet to X.
In the mean time, Y's RTS gets response. Y receives a
CTS and it is going to send a Data packet. When both H
and Y send their data packet, the packets collide on
node X. 

My first question is , does what I said valid or not?
Althought the probability for it to happen is not
large, but I want to know will it be possible to
occur?

Ok , if what I said is possible, I would like to ask,
if we extent the size of CTS , the new length of the
CTS is the original length plus the length of RTS. If
so, the node Y in the case I said before will hear
some noice on channel after it finished transmitting
the RTS and after it transit from transmission mode to
receiving mode. It will back-off for eifs. Because
sifs is small. When the signal of CTS arrive node Y,
the CTS signal from X still in the hear-able from node
Y. Node Y keeps on hearing noice for a period of time.
So it will not be able to notice its RTS has been
responded. It will not send out data later on.

Can any one give me some hint on it?

Regards
Seki Lau
CityU HK


_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Fri Apr 25 01:36:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16255
	for ; Fri, 25 Apr 2003 01:36:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P5dij14366
	for manet-archive@odin.ietf.org; Fri, 25 Apr 2003 01:39:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5di814363
	for ; Fri, 25 Apr 2003 01:39:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16242
	for ; Fri, 25 Apr 2003 01:36:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198vut-0004wX-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 01:38:35 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198vus-0004wU-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 01:38:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5Qh812936;
	Fri, 25 Apr 2003 01:26:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5MI812838
	for ; Fri, 25 Apr 2003 01:22:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16020
	for ; Fri, 25 Apr 2003 01:18:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198ve1-0004rB-00
	for manet@ietf.org; Fri, 25 Apr 2003 01:21:09 -0400
Received: from cssvr7.cs.ust.hk ([143.89.41.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 198ve0-0004r5-00
	for manet@ietf.org; Fri, 25 Apr 2003 01:21:09 -0400
Received: from cs.ust.hk (csz514.cs.ust.hk [143.89.128.249])
	(authenticated bits=0)
	by cssvr7.cs.ust.hk (8.12.9/8.12.5) with ESMTP id h3P5LTOu008297
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 25 Apr 2003 13:21:33 +0800
Message-ID: <3EA8C5D9.1070406@cs.ust.hk>
Date: Fri, 25 Apr 2003 13:21:29 +0800
From: "Dr. Brahim BENSAOU" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en, fr, ar, zh-hk
MIME-Version: 1.0
To: Seki Lau 
CC: manet@ietf.org
Subject: Re: [manet] a Question on RTS/CTS
References: <20030424220235.51385.qmail@web40405.mail.yahoo.com>
In-Reply-To: <20030424220235.51385.qmail@web40405.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Seki,

What you said is valid and can occur and what you "proposed"
does also solve the problem.
However, both the problem and the solution you discuss
are the subject of the PhD Thesis of Chane Fullmer
at UCSC some years ago and was called FAMA  for Floor acquisition
Multiple Access.

- B.


Seki Lau wrote:

>Dear All,
>I am thinking such case and I don't sure will it
>happened or not.
>
>Two nodes (X and Y) operating in Ad Hoc mode. X can
>hear Y and Y can hear X. X has just received a RTS
>from someone (let's call it H) and X is going to reply
>a CTS. In almost the same time, Y backoff counter
>already expire and it will transit from receiving mode
>to transmitting mode and it is going to transmit a
>RTS.
>According to IEEE 802.11 standard, RTS is longer than
>CTS in length.
>
>So, the CTS signal from X will arrive Y. But at that
>time , Y is in transmission mode, it can't hear(or
>even not notice) a CTS arrive. The signal of RTS from
>Y arrive X . Because RTS is longer than CTS, after X
>transmitted its CTS, it notice something on the media.
>It can't find it is meaningful. X back off and assume
>it is noice. However, H can receive the CTS from X to
>itself clearly. H decides to send a data packet to X.
>In the mean time, Y's RTS gets response. Y receives a
>CTS and it is going to send a Data packet. When both H
>and Y send their data packet, the packets collide on
>node X. 
>
>My first question is , does what I said valid or not?
>Althought the probability for it to happen is not
>large, but I want to know will it be possible to
>occur?
>
>Ok , if what I said is possible, I would like to ask,
>if we extent the size of CTS , the new length of the
>CTS is the original length plus the length of RTS. If
>so, the node Y in the case I said before will hear
>some noice on channel after it finished transmitting
>the RTS and after it transit from transmission mode to
>receiving mode. It will back-off for eifs. Because
>sifs is small. When the signal of CTS arrive node Y,
>the CTS signal from X still in the hear-able from node
>Y. Node Y keeps on hearing noice for a period of time.
>So it will not be able to notice its RTS has been
>responded. It will not send out data later on.
>
>Can any one give me some hint on it?
>
>Regards
>Seki Lau
>CityU HK
>
>
>_______________________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
>
>  
>

-- 
Brahim Bensaou             | Computer Science Department.
Assistant Professor        | Hong Kong University of Science & Technology
brahim@cs.ust.hk           | Clear Water Bay, Kowloon, Hong Kong.
http://www.cs.ust.hk/~csbb | Ph: +852 23587014, Fax: +852 23581477


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



From mailnull@www1.ietf.org  Fri Apr 25 09:26:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08058
	for ; Fri, 25 Apr 2003 09:26:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PDTtl25687
	for manet-archive@odin.ietf.org; Fri, 25 Apr 2003 09:29:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDTs825684
	for ; Fri, 25 Apr 2003 09:29:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08040
	for ; Fri, 25 Apr 2003 09:25:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1993FO-0000aB-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 09:28:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1993FN-0000a8-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 09:28:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDGA824618;
	Fri, 25 Apr 2003 09:16:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDB0824413
	for ; Fri, 25 Apr 2003 09:11:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07535
	for ; Fri, 25 Apr 2003 09:07:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992xR-0000QE-00
	for manet@ietf.org; Fri, 25 Apr 2003 09:09:41 -0400
Received: from f113.law12.hotmail.com ([64.4.19.113] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1992xQ-0000QA-00
	for manet@ietf.org; Fri, 25 Apr 2003 09:09:40 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 25 Apr 2003 06:09:39 -0700
Received: from 212.4.33.133 by lw12fd.law12.hotmail.msn.com with HTTP;
	Fri, 25 Apr 2003 13:09:39 GMT
X-Originating-IP: [212.4.33.133]
X-Originating-Email: [bernervegge@hotmail.com]
From: "Berner Vegge" 
To: manet@ietf.org
Date: Fri, 25 Apr 2003 15:09:39 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 25 Apr 2003 13:09:39.0461 (UTC) FILETIME=[ED9EC350:01C30B2B]
Subject: [manet] SNMP, ANMP, Guerrilla
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

Hello!
Regarding management in ad hoc, ANMP and Guerrilla have come up as 
alternatives to SNMP.

My question is if you know what the main differences are between
using SNMP&RMON as compared to ANMP or Guerrilla.

All the Best!
/Berner





_________________________________________________________________
MSN Messenger http://www.msn.no/messenger - Den korteste veien mellom deg og 
dine venner

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



From mailnull@www1.ietf.org  Fri Apr 25 10:24:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10736
	for ; Fri, 25 Apr 2003 10:24:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PERXE30591
	for manet-archive@odin.ietf.org; Fri, 25 Apr 2003 10:27:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PERX830588
	for ; Fri, 25 Apr 2003 10:27:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10719
	for ; Fri, 25 Apr 2003 10:23:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19949T-00013A-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 10:26:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19949T-000137-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 10:26:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEEi829912;
	Fri, 25 Apr 2003 10:14:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEBl829792
	for ; Fri, 25 Apr 2003 10:11:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09662
	for ; Fri, 25 Apr 2003 10:08:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1993uE-0000wx-00
	for manet@ietf.org; Fri, 25 Apr 2003 10:10:26 -0400
Received: from dav41.law15.hotmail.com ([64.4.22.98] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1993uE-0000wu-00
	for manet@ietf.org; Fri, 25 Apr 2003 10:10:26 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 25 Apr 2003 07:10:24 -0700
Received: from 61.187.56.10 by law15-dav41.adinternal.hotmail.com with DAV;
	Fri, 25 Apr 2003 14:10:24 +0000
X-Originating-IP: [61.187.56.10]
X-Originating-Email: [xiaohui_kuang@hotmail.com]
From: "manet" 
To: 
Date: Mon, 28 Apr 2003 22:09:08 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C30DD2.CA5335D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: 
X-OriginalArrivalTime: 25 Apr 2003 14:10:24.0781 (UTC) FILETIME=[6A6673D0:01C30B34]
Subject: [manet] clustering computation help
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C30DD2.CA5335D0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

aGkNCiAgICAgSSBhbSBpbXBsZW1lbnQgc29tZSBjbHVzdGVyaW5nIGFsZ29yaXRobXMgaW4gbnMy
LCB0aGUgbm9kZSBtb3ZlbWVudCBpcyBiYXNlZCBvbiB0aGUNCiByYW5kb20gd2F5LXBvaW50IG1v
ZGVsLkJ1dCBJIHRoaW5rIHdoaWNoIG1pZ2h0IG5vdCBiZSBhbiBhY2N1cmF0ZSBtb2RlbGxpbmcg
b2YgdGhlDQpyZWFsIGxpZmUgYXBwbGljYXRpb25zLiBBcmUgdGhlcmUgbW9yZSBhY2N1cmF0ZSBt
b2JpbGl0eSBtb2RlbHMgYXZhaWxhYmxlLCBJIHRoaW5rIHdlIGNvdWxkIA0KZmluZCBtb3JlIGJl
dHRlciBjbHVzdGVyaW5nIGFsZ29yaXRobXMgb24gdGhlbS4NCiAgICAgIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGlkZGVu
IGRyYWdvbg0K

------=_NextPart_000_0005_01C30DD2.CA5335D0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yNzIyLjkwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC
T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPmhpPC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjxGT05UIHNp
emU9Mz4gSSBhbSBpbXBsZW1lbnQgDQpzb21lIGNsdXN0ZXJpbmcgYWxnb3JpdGhtcyBpbiBuczIs
IHRoZSBub2RlIG1vdmVtZW50IGlzIGJhc2VkIG9uIA0KdGhlPEJSPiZuYnNwO3JhbmRvbSB3YXkt
cG9pbnQgbW9kZWwuQnV0IEkgdGhpbmsgd2hpY2ggbWlnaHQgbm90IGJlIGFuIGFjY3VyYXRlIA0K
bW9kZWxsaW5nIG9mIHRoZTxCUj5yZWFsJm5ic3A7bGlmZSBhcHBsaWNhdGlvbnMuIEFyZSB0aGVy
ZSBtb3JlIGFjY3VyYXRlIA0KbW9iaWxpdHkgbW9kZWxzIGF2YWlsYWJsZSwgSSB0aGluayB3ZSBj
b3VsZCA8L0ZPTlQ+PC9ESVY+DQo8RElWPmZpbmQgbW9yZSBiZXR0ZXIgY2x1c3RlcmluZyBhbGdv
cml0aG1zIG9uIHRoZW0uPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaGlkZGVuIGRy
YWdvbjwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_0005_01C30DD2.CA5335D0--
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From mailnull@www1.ietf.org  Fri Apr 25 11:37:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12624
	for ; Fri, 25 Apr 2003 11:37:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PFefF04550
	for manet-archive@odin.ietf.org; Fri, 25 Apr 2003 11:40:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFef804547
	for ; Fri, 25 Apr 2003 11:40:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12604
	for ; Fri, 25 Apr 2003 11:37:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1995IF-0001a6-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 11:39:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1995IE-0001a3-00
	for manet-web-archive@ietf.org; Fri, 25 Apr 2003 11:39:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFON802609;
	Fri, 25 Apr 2003 11:24:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFIu802414
	for ; Fri, 25 Apr 2003 11:18:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12000
	for ; Fri, 25 Apr 2003 11:15:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1994xC-0001Pq-00
	for manet@ietf.org; Fri, 25 Apr 2003 11:17:34 -0400
Received: from cheviot3.ncl.ac.uk ([128.240.233.117] ident=root)
	by ietf-mx with esmtp (Exim 4.12)
	id 1994xB-0001Pm-00
	for manet@ietf.org; Fri, 25 Apr 2003 11:17:33 -0400
Received: from ncl.ac.uk (deerbook.ncl.ac.uk [128.240.149.114])
	by cheviot3.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h3PFI0321237;
	Fri, 25 Apr 2003 16:18:00 +0100
Date: Fri, 25 Apr 2003 16:18:00 +0100
Subject: Re: [manet] clustering computation help
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: 
To: "manet" 
From: Einar Vollset 
In-Reply-To: 
Message-Id: <1A5425C6-7731-11D7-9B28-000A9575BD30@ncl.ac.uk>
X-Mailer: Apple Mail (2.552)
X-Newcastle-MailScanner: Found to be clean
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3PFIu802415
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3PFON802609
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3PFef804547
Content-Transfer-Encoding: 8bit


I think the following is a very good summary of mobility models for 
MANETs:

http://citeseer.nj.nec.com/camp02survey.html

Cheers,

Einar

On Monday, Apr 28, 2003, at 15:09 Europe/London, manet wrote:

> hi
>      I am implement some clustering algorithms in ns2, the node 
> movement is based on the
>  random way-point model.But I think which might not be an accurate 
> modelling of the
> real life applications. Are there more accurate mobility models 
> available, I think we could
> find more better clustering algorithms on them.
>      
>                                                                hidden 
> dragon

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



From mailnull@www1.ietf.org  Wed Apr 30 00:50:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25746
	for ; Wed, 30 Apr 2003 00:50:27 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3U4tnl08072
	for manet-archive@odin.ietf.org; Wed, 30 Apr 2003 00:55:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U4tn808069
	for ; Wed, 30 Apr 2003 00:55:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25734
	for ; Wed, 30 Apr 2003 00:49:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AjZg-0003re-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 00:52:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AjZf-0003ra-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 00:52:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U4hq807487;
	Wed, 30 Apr 2003 00:43:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U4Xj806296
	for ; Wed, 30 Apr 2003 00:33:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25038
	for ; Wed, 30 Apr 2003 00:27:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AjEK-0003fa-00
	for manet@ietf.org; Wed, 30 Apr 2003 00:30:04 -0400
Received: from ms01.net.ie.niigata-u.ac.jp ([133.35.156.1] ident=postfix)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AjEJ-0003fW-00
	for manet@ietf.org; Wed, 30 Apr 2003 00:30:04 -0400
Received: from ms11.net.ie.niigata-u.ac.jp (ms11.net.ie.niigata-u.ac.jp [133.35.156.11])
	by ms01.net.ie.niigata-u.ac.jp (Postfix) with SMTP id 59D8311E29
	for ; Wed, 30 Apr 2003 13:30:09 +0900 (JST)
Date: Wed, 30 Apr 2003 13:27:59 +0900
From: goto 
To: manet@ietf.org
Message-Id: <20030430132759.3f1e2813.mgoto@net.ie.niigata-u.ac.jp>
X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-vine-linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] About TBRPF simulation code
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi all, 

In order to simulation in ns-2 by using TBRPF,
I'm looking for a simulation code of TBRPF in ns-2.
But I could not get the code.
Where can I get the code?

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



From mailnull@www1.ietf.org  Wed Apr 30 04:55:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25738
	for ; Wed, 30 Apr 2003 04:55:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3U90fR18160
	for manet-archive@odin.ietf.org; Wed, 30 Apr 2003 05:00:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U90f818157
	for ; Wed, 30 Apr 2003 05:00:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25729
	for ; Wed, 30 Apr 2003 04:54:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AnOZ-0005IB-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 04:56:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AnOZ-0005I8-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 04:56:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8mY817550;
	Wed, 30 Apr 2003 04:48:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8fY817268
	for ; Wed, 30 Apr 2003 04:41:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25340
	for ; Wed, 30 Apr 2003 04:35:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19An64-00059t-00
	for manet@ietf.org; Wed, 30 Apr 2003 04:37:48 -0400
Received: from marfik.cc.upv.es ([158.42.2.61] helo=marfik.upv.es)
	by ietf-mx with esmtp (Exim 4.12)
	id 19An63-00059q-00
	for manet@ietf.org; Wed, 30 Apr 2003 04:37:47 -0400
Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11])
	by marfik.upv.es (8.11.6/8.11.6) with ESMTP id h3U8cKM10203
	for ; Wed, 30 Apr 2003 10:38:20 +0200
Received: from smtp2.upv.es (smtp02.cc.upv.es [158.42.249.52])
	by pop.upv.es (8.11.3/8.11.3) with ESMTP id h3U8eEn08247
	for ; Wed, 30 Apr 2003 10:40:14 +0200 (METDST)
Received: from nao.disca.upv.es (nao.disca.upv.es [158.42.53.70])
	by smtp2.upv.es (8.11.4p2/8.11.4) with ESMTP id h3U8cJv12926
	for ; Wed, 30 Apr 2003 10:38:19 +0200
Received: from disca.upv.es (tux.grc.upv.es [158.42.61.34])
	by nao.disca.upv.es (Postfix on SuSE eMail Server 2.0) with ESMTP id 85BC51FE8B
	for ; Wed, 30 Apr 2003 10:37:58 +0200 (CEST)
Message-ID: <3EAF8B81.20503@disca.upv.es>
Date: Wed, 30 Apr 2003 10:38:25 +0200
From: Carlos Miguel Calafate 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by marfik.upv.es id h3U8cKM10203
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U8fY817269
Subject: [manet] Possible error in mac-802_11.cc
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3U8mY817550
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U90f818157
Content-Transfer-Encoding: 8bit

Hi everyone,

I think I have discovered a possible error applying to ns-2.26.
In the mac-802_11.cc file you have:

if((u_int32_t) ch->size() <= macmib_->RTSThreshold)
                ssrc_ = 0;
        else
                slrc_ = 0;


In a previous e-mail, I have reported an error occurring while 
performing FTP transfers between 2 nodes using AODV and AODV-UU.
I have solved it adding;
 ssrc_ = 0;

to the "else" section too.

Is this correct? Should additional changes be performed on that file?

Best regards,

-- 
_________________________________________________
Carlos Miguel Tavares de Araújo Cesariny Calafate
Becário de la Universidad Politécnica de Valencia
e-mail: calafate@disca.upv.es
http://reptar.grc.upv.es/~calafate/
_________________________________________________
\"In an open world without walls and fences who 
needs Windows and Gates?\"


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



From mailnull@www1.ietf.org  Wed Apr 30 06:02:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27072
	for ; Wed, 30 Apr 2003 06:02:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UA8H231269
	for manet-archive@odin.ietf.org; Wed, 30 Apr 2003 06:08:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UA8H831266
	for ; Wed, 30 Apr 2003 06:08:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27054
	for ; Wed, 30 Apr 2003 06:02:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AoRx-0005gs-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 06:04:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AoRx-0005gp-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 06:04:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U9ug827201;
	Wed, 30 Apr 2003 05:56:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U9qV827034
	for ; Wed, 30 Apr 2003 05:52:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26740
	for ; Wed, 30 Apr 2003 05:46:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AoCi-0005aE-00
	for manet@ietf.org; Wed, 30 Apr 2003 05:48:44 -0400
Received: from marfik.cc.upv.es ([158.42.2.61] helo=marfik.upv.es)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AoCh-0005aB-00
	for manet@ietf.org; Wed, 30 Apr 2003 05:48:44 -0400
Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11])
	by marfik.upv.es (8.11.6/8.11.6) with ESMTP id h3U9nLM16429
	for ; Wed, 30 Apr 2003 11:49:21 +0200
Received: from smtp2.upv.es (smtp02.cc.upv.es [158.42.249.52])
	by pop.upv.es (8.11.3/8.11.3) with ESMTP id h3U9pFb23018
	for ; Wed, 30 Apr 2003 11:51:15 +0200 (METDST)
Received: from nao.disca.upv.es (nao.disca.upv.es [158.42.53.70])
	by smtp2.upv.es (8.11.4p2/8.11.4) with ESMTP id h3U9nKv27770
	for ; Wed, 30 Apr 2003 11:49:20 +0200
Received: from disca.upv.es (tux.grc.upv.es [158.42.61.34])
	by nao.disca.upv.es (Postfix on SuSE eMail Server 2.0) with ESMTP id B1C3E1FE8B
	for ; Wed, 30 Apr 2003 11:48:59 +0200 (CEST)
Message-ID: <3EAF9C27.4000303@disca.upv.es>
Date: Wed, 30 Apr 2003 11:49:27 +0200
From: Carlos Miguel Calafate 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: en-us
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] Possible error in mac-802_11.cc
References: <3EAF8B81.20503@disca.upv.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by marfik.upv.es id h3U9nLM16429
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U9qV827035
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3U9ug827201
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3UA8H831266
Content-Transfer-Encoding: 8bit

Oops, sorry, wrong mailing list!


-- 
_________________________________________________
Carlos Miguel Tavares de Araújo Cesariny Calafate
Becário de la Universidad Politécnica de Valencia
e-mail: calafate@disca.upv.es
http://reptar.grc.upv.es/~calafate/
_________________________________________________
\"In an open world without walls and fences who
needs Windows and Gates?\"

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



From mailnull@www1.ietf.org  Wed Apr 30 11:32:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08807
	for ; Wed, 30 Apr 2003 11:32:10 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UFbkH10449
	for manet-archive@odin.ietf.org; Wed, 30 Apr 2003 11:37:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFbk810446
	for ; Wed, 30 Apr 2003 11:37:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08799
	for ; Wed, 30 Apr 2003 11:31:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Atai-0000Xr-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 11:33:52 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Atah-0000Xo-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 11:33:51 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFPs802135;
	Wed, 30 Apr 2003 11:25:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFLI801986
	for ; Wed, 30 Apr 2003 11:21:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08368
	for ; Wed, 30 Apr 2003 11:15:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AtKm-0000R1-00
	for manet@ietf.org; Wed, 30 Apr 2003 11:17:24 -0400
Received: from bay2-f19.bay2.hotmail.com ([65.54.247.19] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AtKl-0000Qs-00
	for manet@ietf.org; Wed, 30 Apr 2003 11:17:23 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 30 Apr 2003 08:17:32 -0700
Received: from 195.12.26.4 by by2fd.bay2.hotmail.msn.com with HTTP;
	Wed, 30 Apr 2003 15:17:31 GMT
X-Originating-IP: [195.12.26.4]
X-Originating-Email: [jianwu53@hotmail.com]
From: "jian wu" 
To: manet@ietf.org
Date: Wed, 30 Apr 2003 15:17:31 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 30 Apr 2003 15:17:32.0176 (UTC) FILETIME=[9EFAE900:01C30F2B]
Subject: [manet] routing
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	


Dear all

I am a student currently working on ad hoc routing. I have a question here: 
I know that in reactive protocols such as DSR or AODV, source nodes send out 
RREQ to discover routes and expect RREP back. I wonder whether there is any 
route computation (e.g. using Dijkstra's or Bellman Ford algorithm) involved 
in this process? And how about proactive protocols such as OLSR, is Dijkstra 
used there when computing the routing table?

Many thanks, Jian Wu



_________________________________________________________________
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger

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



From mailnull@www1.ietf.org  Wed Apr 30 13:34:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13903
	for ; Wed, 30 Apr 2003 13:34:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UHe2V06251
	for manet-archive@odin.ietf.org; Wed, 30 Apr 2003 13:40:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHe2806244
	for ; Wed, 30 Apr 2003 13:40:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13869
	for ; Wed, 30 Apr 2003 13:33:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvUy-0001nA-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 13:36:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvUy-0001n7-00
	for manet-web-archive@ietf.org; Wed, 30 Apr 2003 13:36:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHOe822334;
	Wed, 30 Apr 2003 13:24:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHKG822106
	for ; Wed, 30 Apr 2003 13:20:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13133
	for ; Wed, 30 Apr 2003 13:14:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvBs-0001cq-00
	for manet@ietf.org; Wed, 30 Apr 2003 13:16:20 -0400
Received: from concorde.inria.fr ([192.93.2.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvBr-0001cR-00
	for manet@ietf.org; Wed, 30 Apr 2003 13:16:19 -0400
Received: from zephyrin (byzantium.inria.fr [128.93.17.6])
	by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h3UHGQH20878;
	Wed, 30 Apr 2003 19:16:26 +0200 (MET DST)
Message-ID: <006401c30f3c$981d0940$1f175d80@inria.fr>
From: "Philippe Jacquet" 
To: "jian wu" , 
References: 
Subject: Re: [manet] routing
Date: Wed, 30 Apr 2003 19:19:01 +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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Mobile Ad-hoc Networks  
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Yes OLSR uses Dijkstra, but DSDV uses Belman-Ford. It depends whether the
proactive protocol is link state or not.

Philippe
----- Original Message -----
From: jian wu 
To: 
Sent: Wednesday, April 30, 2003 5:17 PM
Subject: [manet] routing


>
> Dear all
>
> I am a student currently working on ad hoc routing. I have a question
here:
> I know that in reactive protocols such as DSR or AODV, source nodes send
out
> RREQ to discover routes and expect RREP back. I wonder whether there is
any
> route computation (e.g. using Dijkstra's or Bellman Ford algorithm)
involved
> in this process? And how about proactive protocols such as OLSR, is
Dijkstra
> used there when computing the routing table?
>
> Many thanks, Jian Wu
>
>
>
> _________________________________________________________________
> Use MSN Messenger to send music and pics to your friends
> http://www.msn.co.uk/messenger
>
> _______________________________________________
> 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